Exynos4Bootrom » History » Version 12
Denis 'GNUtoo' Carikli, 11/04/2019 04:15 PM
1 | 1 | Denis 'GNUtoo' Carikli | h1. Exynos4 Bootrom |
---|---|---|---|
2 | 11 | Denis 'GNUtoo' Carikli | |
3 | {{toc}} |
||
4 | 1 | Denis 'GNUtoo' Carikli | |
5 | h2. Background information |
||
6 | |||
7 | The Replicant project wants to support devices with free software bootloaders, but most/all the smartphones and tablets supported by Replicant do check the signature of the first stage bootloader. |
||
8 | |||
9 | A presentation on the situation of some of the devices supported by Replicant was made at the Replicant contributors meeting in July 2019. The "presentation slides":https://ftp.osuosl.org/pub/replicant/conferences/replicant-contributors-meeting-july-2019-france/replicant-and-bootloaders.pdf and "video":https://ftp.osuosl.org/pub/replicant/conferences/replicant-contributors-meeting-july-2019-france/replicant-and-bootloaders.webm are available. |
||
10 | |||
11 | h2. Exynos 4 signature check |
||
12 | |||
13 | The Exynos4 bootrom has a strange way to check the signatures: |
||
14 | * The first stage bootloader is encrypted |
||
15 | * The signature check is not very clear[1] |
||
16 | * The header that holds the key has a "func_ptr_BaseAddr" field[1]. |
||
17 | |||
18 | h2. Tests to attempt |
||
19 | |||
20 | 3 | Denis 'GNUtoo' Carikli | * Test with qemu[2] if func_ptr_BaseAddr is somehow used by the bootrom, when verifying the BL1. |
21 | 1 | Denis 'GNUtoo' Carikli | * Try to understand better the scheme used to check the signature. |
22 | 4 | Kurtis Hanna | * Try to see if the fuses can still be written (zeroed) and see whether it's computationally feasible to compute the private key for a zeroed fuses hash. |
23 | 2 | Denis 'GNUtoo' Carikli | * Try to understand why encryption is used. |
24 | 8 | Kurtis Hanna | * Try to see if "Cadmium":https://wikileaks.org/ciav7p1/cms/files/cadmium.pdf, released in Wikileak's Vault 7 documents, can be ported to devices we support |
25 | 9 | Kurtis Hanna | * See if we can reach full code execution within s-boot using "this technique":https://hexdetective.blogspot.com/2017/02/exploiting-android-s-boot-getting.html#comment-form |
26 | 1 | Denis 'GNUtoo' Carikli | |
27 | h2. Test setup |
||
28 | |||
29 | 3 | Denis 'GNUtoo' Carikli | Either qemu[2] or a development board with JTAG can be used to do the test. |
30 | 1 | Denis 'GNUtoo' Carikli | |
31 | 3 | Denis 'GNUtoo' Carikli | Testing with qemu[2] is probably way more easy. |
32 | 1 | Denis 'GNUtoo' Carikli | |
33 | fn1. https://fredericb.info/2018/03/emulating-exynos-4210-bootrom-in-qemu.html |
||
34 | 5 | Kurtis Hanna | |
35 | 3 | Denis 'GNUtoo' Carikli | fn2. https://github.com/frederic/qemu-exynos-bootrom |
36 | 6 | Denis 'GNUtoo' Carikli | |
37 | 12 | Denis 'GNUtoo' Carikli | h1. HOWTO |
38 | |||
39 | 7 | Kurtis Hanna | h2. Loading a bootloader from SD |
40 | 6 | Denis 'GNUtoo' Carikli | |
41 | When booting Parabola with a Replicant 9 kernel on a Galaxy SIII (i9300), it is possible to erase the bootloader to make the device boot from the microSD instead. |
||
42 | |||
43 | This could be used to do some testing, for instance to see if the BL1 signature can somehow be bypassed, however as no free software bootloaders do exist yet (u-boot relies on nonfree and non-redistributable software), this is not very useful yet. |
||
44 | |||
45 | If you really want to erase the bootloader (your device will be broken and will never boot anymore), you could run the following: |
||
46 | |||
47 | <pre> |
||
48 | # echo 0 > /sys/class/block/mmcblk2boot0/force_ro |
||
49 | # ddrescue -f /dev/zero /dev/mmcblk2boot0 |
||
50 | GNU ddrescue 1.24 |
||
51 | Press Ctrl-C to interrupt |
||
52 | ipos: 4194 kB, non-trimmed: 0 B, current rate: 4194 kB/s |
||
53 | opos: 4194 kB, non-scraped: 0 B, average rate: 4194 kB/s |
||
54 | non-tried: 9223 PB, bad-sector: 0 B, error rate: 0 B/s |
||
55 | rescued: 4194 kB, bad areas: 0, run time: 0s |
||
56 | pct rescued: 0.00%, read errors: 0, remaining time: n/a |
||
57 | time since last successful read: n/a |
||
58 | Copying non-tried blocks... Pass 1 (forwards) |
||
59 | ddrescue: Write error: No space left on device |
||
60 | </pre> |
||
61 | |||
62 | And then verify that it's erased: |
||
63 | <pre> |
||
64 | # hexdump -C /dev/mmcblk2boot0 |
||
65 | 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
||
66 | * |
||
67 | 00400000 |
||
68 | |||
69 | </pre> |
||
70 | |||
71 | Also verify that the following partitions are also erased: |
||
72 | * mmcblk2boot1 |
||
73 | * BOTA0 |
||
74 | * BOTA1 |
||
75 | |||
76 | I'm not sure what BOTA0 and BOTA1 are but they were already blank in my case. |
||
77 | 12 | Denis 'GNUtoo' Carikli | |
78 | h2. Recovering from a bad u-boot |
||
79 | |||
80 | Note that I didn't manage yet to go from u-boot to s-boot. |
||
81 | |||
82 | Requirements: |
||
83 | * A supported device (i9300 or i9305) |
||
84 | * A programable PSU or another human that can help you |
||
85 | * A serial cable |
||
86 | * Very thin/precise multimeter probes that you connect together |
||
87 | |||
88 | HOWTO: |
||
89 | * Prepare a microSD with u-boot |
||
90 | * Disassemble the device and connect the device to a programable PSU. The PSU has to be off |
||
91 | ** VCC is available on the battery connector |
||
92 | ** GND is available at many places |
||
93 | * Make sure that the PSU will go to the right voltage when set to on |
||
94 | * script the PSU power on, for instance wait 10 seconds before power on |
||
95 | * short the resistor with the multimeter probes |
||
96 | |||
97 | You then should have u-boot running which can boot Parabola, so you can then easily recover. |
||
98 | |||
99 | Note that to run Parabola you need to make sure that you use an MBR and no gpt as u-boot is to be put at the second 512B block. |