BP Internals
From OpenEZX
Contents |
Hardware
BP for gen2 phones is running on same processor unit as old non-linux phones like L7 named Neptune LTE2. The only difference is reduced features set (no display etc) and reduced flash and ram size (BP has own ram and flash).
Flash used in my A1200 identified as vendor id 20, product id 8815, which is analog of intel's nor 89/8881 (GE28F320W18BD60). Flash size is 4 MB, ram size seems to be 4MB too (not confirmed).
BP also has special in-cpu rom, called IROM (and corresponding IRAM) where initial bootloader placed.
Physycal memory map
| Name | Adreess |
|---|---|
| IROM | 0x0 |
| IRAM | 0x03f80000 |
| FLASH | 0x10000000 - 0x103fffff |
| RAM | 0x14000000 - 0x143fffff |
Flash partition map
| Code Group | Name | Adreess |
|---|---|---|
| CG0 | boot | 0x10000000 - 0x1000ffff |
| None | PDS 1 | 0x10010000 - 0x1001ffff |
| None | PDS 2 | 0x10020000 - 0x1002ffff |
| None | panic log | 0x10030000 - 0x1003ffff |
| CG3 | ?? | 0x10040000 - 0x1007ffff |
| CG1 | firmware | 0x10080000 - 0x102fffff (not sure) |
| CG18 | firmware sign | 0x10330000 - 0x1033ffff |
| CG7 | FOTA | 0x10350000 - 0x1035ffff |
Bootloaders
LTE phones has two bootloaders, one in IROM and other one in flash memory. Both have capabilities to execute signed code via USB. Flash bootloader is also capable to dump permitted memory ranges contents via USB.
PDS
PDS is Persistand Data Storage. It's created during factory flashing only and never reflashed. It's a some sort of filesystem with numbered files and simple checksum. Some files (for example, operator lock settings) are encrypted with private phone key, so PDS from one phone cant be flashed to other, even if it's the same model. Losing PDS is PAIN!
PDS header has different version from fw to fw. For example, E2 has version 4015, but A1200 has 4017.
Flashing broken fw or fw from different phone can broke your PDS.
Boot sequence
On powerup, execution starts from 0x0 (IROM) which initialize hardware and checks flash bootloader presence and validity. If this check fails, irom boot goes to "blank" state and initializes USB as "S Blank Neptune LTE2", product id 4903. There is a flaw in blank bootloader, allowing to load and execute unsigned code (see Firmware upgrade#Hacks). Forsing phone to go in "blank" state procedure is called "test point". Flash bootloader has no such flaw and the only way to flash it is using signed motorola ramloader (CG0 in every firmware).
Note: during suspend mode debugging i saw bp in blank state several times without test point.
Bootloader check
Bootloader starts from such header:
010000000 10 00 46 F4 00 00 00 B1 00 13 02 01 FF 00 09 84
010000010 01 13 02 FF 07 00 09 84 10 00 46 FC 10 00 00 00
010000020 10 00 EF D7 10 00 4A 9C 10 00 E8 00 10 00 F0 00
010000030 10 35 08 00 00 00 00 00 10 08 00 00 28 63 29 20
Where
- 10 00 46 F4 is bootloader entry point.
- 10 00 E8 00 is bootloader signature address
- 10 08 00 00 is firmware header address.
Note: bootloader signed area ends at 0x10005E10, but signature starts from 0x1000E800
So irom boot reads this header from 0x010000000 and reads signature from 0x1000E800. Every signature specifies addresses covered by it, so irom checks this addresses hashsum. If the check is ok, irom remembers this addresses as trusted area and checks if entry point belongs to such area. If it's ok, the bootloader starts.
Firmware check
Firmware have such header:
010080000 10 21 EF 95 00 00 00 B1 00 13 02 06 FF FF 11 52
....
0100800A0 FF FF FF FF FF FF FF FF FF FF FF FF 10 33 00 00
Where
- 10 21 EF 95 is firmware entry point
- 10 33 00 00 firmware signature header
Firmware sign header:
010330000 10 33 00 10 00 00 00 B1 01 13 02 06 FF FF 11 52
Where
- 10 33 00 10 is actual signature address
The check process is the same as with boot, bootloader reads fw header from 0x010080000, then sign header from 0x010330000 and actual signature from 0x10330010. Signature itself contains addresses of signed area (CG1 aka firmware) and its hash checked.
If it's ok, boot adds this addresses to trusted area and checks entry point. If it's ok, boot jumps to entry point. If something fails, bootloader goes to flash mode (maybe writes to panic log?) as "S Flash Neptune LTE2", pid 4903. Work with bootloader via USB described in Firmware upgrade.
Signature check flaw
In old bootloaders there is no check about fw header, so entry point can referer to other signed area and other signature, keeping fw unchecked. Its is enought to trick rsa checks. Bootloader on my A1200 have this check, so see section below.
Bootloader downgrade
This flaw was closed in new bootloaders (A1200) but not on E2. Since both A1200 (version 984) and E2 (version 910) are signed with same key, its possible to downgrade bootloader using test point and ramldr2. Firmware checks bootloader version so its impossible to downgrade bootloader without removing rsa protection from fw and patching it.
Bootloader critical error
There is one big problem with flash bootloader, it can fail before enabling USB. It's also PAIN. How can this be?
- flash bootloader does not check for flashkey press itself! after firmware boots, it checks flashkey and goes back to bootloader
- flash bootloader reads PDS and goes to critical error without enabling USB if pds is broken
bootloader in this state looks from host like this:
usb 4-1: device not accepting address 24, error -71 hub 4-0:1.0: unable to enumerate USB device on port 1
