Exynos4Bootrom » History » Version 11
Denis 'GNUtoo' Carikli, 11/04/2019 02:33 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 | 7 | Kurtis Hanna | h2. Loading a bootloader from SD |
38 | 6 | Denis 'GNUtoo' Carikli | |
39 | 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. |
||
40 | |||
41 | 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. |
||
42 | |||
43 | If you really want to erase the bootloader (your device will be broken and will never boot anymore), you could run the following: |
||
44 | |||
45 | <pre> |
||
46 | # echo 0 > /sys/class/block/mmcblk2boot0/force_ro |
||
47 | # ddrescue -f /dev/zero /dev/mmcblk2boot0 |
||
48 | GNU ddrescue 1.24 |
||
49 | Press Ctrl-C to interrupt |
||
50 | ipos: 4194 kB, non-trimmed: 0 B, current rate: 4194 kB/s |
||
51 | opos: 4194 kB, non-scraped: 0 B, average rate: 4194 kB/s |
||
52 | non-tried: 9223 PB, bad-sector: 0 B, error rate: 0 B/s |
||
53 | rescued: 4194 kB, bad areas: 0, run time: 0s |
||
54 | pct rescued: 0.00%, read errors: 0, remaining time: n/a |
||
55 | time since last successful read: n/a |
||
56 | Copying non-tried blocks... Pass 1 (forwards) |
||
57 | ddrescue: Write error: No space left on device |
||
58 | </pre> |
||
59 | |||
60 | And then verify that it's erased: |
||
61 | <pre> |
||
62 | # hexdump -C /dev/mmcblk2boot0 |
||
63 | 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
||
64 | * |
||
65 | 00400000 |
||
66 | |||
67 | </pre> |
||
68 | |||
69 | Also verify that the following partitions are also erased: |
||
70 | * mmcblk2boot1 |
||
71 | * BOTA0 |
||
72 | * BOTA1 |
||
73 | |||
74 | I'm not sure what BOTA0 and BOTA1 are but they were already blank in my case. |