BootROM reversing

[NewDwarf]

I began reversing of the dumped BootROM. If I correctly defined, the entry point of the BootROM is:

ROM:00001498             sub_1498
ROM:00001498 00 21                       MOVS    R1, #0
ROM:0000149A 0A 46                       MOV     R2, R1
ROM:0000149C 0B 46                       MOV     R3, R1
ROM:0000149E 0C 46                       MOV     R4, R1
ROM:000014A0 0D 46                       MOV     R5, R1
ROM:000014A2 0E 46                       MOV     R6, R1
ROM:000014A4 0F 46                       MOV     R7, R1
ROM:000014A6 88 46                       MOV     R8, R1
ROM:000014A8 89 46                       MOV     R9, R1
ROM:000014AA 8A 46                       MOV     R10, R1
ROM:000014AC 8B 46                       MOV     R11, R1
ROM:000014AE 8C 46                       MOV     R12, R1
ROM:000014B0 00 48                       LDR     R0, =0x14B9
ROM:000014B2 00 47                       BX      R0              ; loc_14B8
ROM:000014B2             ; End of function sub_1498

The BootROM actively uses the high addresses 0xe0000000 ... These addresses are defined as CPU registers. What are actually these registers?

ROM:00001A8C             sub_1A8C                                ; CODE XREF: ROM:000014BC↑p
ROM:00001A8C 06 4A                       LDR     R2, =0xE000EDFC
ROM:00001A8E 13 68                       LDR     R3, [R2]
ROM:00001A90 03 F0 7E 43                 AND.W   R3, R3, #0xFE000000
ROM:00001A94 43 F0 80 73                 ORR.W   R3, R3, #0x1000000
ROM:00001A98 13 60                       STR     R3, [R2]
ROM:00001A9A 04 4A                       LDR     R2, =0xE0001000
ROM:00001A9C 13 68                       LDR     R3, [R2]
ROM:00001A9E 43 F0 01 03                 ORR.W   R3, R3, #1
ROM:00001AA2 13 60                       STR     R3, [R2]
ROM:00001AA4 70 47                       BX      LR
ROM:00001AA4             ; End of function sub_1A8C

And another one high address range is in 0x40000000 ... defined as HW registers. Whether I correctly understand that it is timers, watchdog, global control registers to configure, say, access to the memory regions, RSA HW accelerator registers, etc...?

ROM:00001B5C             sub_1B5C                                ; CODE XREF: sub_1B70:loc_1B7E↓p
ROM:00001B5C                                                     ; sub_1BE4+14↓p ...
ROM:00001B5C 03 4B                       LDR     R3, =0x40320030
ROM:00001B5E 18 68                       LDR     R0, [R3]
ROM:00001B60 80 F0 04 00                 EOR.W   R0, R0, #4
ROM:00001B64 C0 F3 80 00                 UBFX.W  R0, R0, #2, #1
ROM:00001B68 70 47                       BX      LR
ROM:00001B68             ; End of function sub_1B5C
ROM:00001B68
ROM:00001B68             ; ---------------------------------------------------------------------------
ROM:00001B6A 00                          DCB    0
ROM:00001B6B BF                          DCB 0xBF
ROM:00001B6C 30 00 32 40 off_1B6C        DCD 0x40320030          ; DATA XREF: sub_1B5C↑r

If you have already defined purpose of some HW and CPU registers, could you share it, please?

[max-r-b]

What we called CPU Registers are the ones defined by the Cortex-m3 architecture (there are public). HW registers are custom ones and correspond, as you mentioned to timers, watchdog, etc. You will find some symbols in the Ghidra loader (symbols.xml). We don't plan to release more details for now.

[NewDwarf]

Looks promising. Thanks! SYMBOL ADDRESS="40224060" NAME="HW_KEY" Is it the SoC OTP storage of the 768 bit public key? For RSA it looks very small but for ECC very big. Just learned that it is RSA-3072 and the HW_KEY register (0x40224060) and next 96 DWORD-length registers are used to tmp keep the public RSA key stored directly in the BootRom. So, these registers are RW.

[NewDwarf]

The code section of the BootRom is pretty small. The functions are short and very simple for reviewing. The main challenge in disassembling is a large number of specific HW and CPU registers but the symbols.xml gives a great insight of the purpose of the specific register/s. Additionally, I created the SRAM segment and load the dumped SRAM area from the real device. It helps to achieve better browsing in the disassembling listing and keeping the execution context in mind.

Did you/your team try to run the BootRom in the ARM emulator (Qemu)? I think it would be nice environment for fuzz testing. Probably, implementing of HW and CPU registers in Qemu is not a big challenge for your team.

[max-r-b]

Yes we played a bit with emulation, but we did not emulated these specific hw devices. It could definitely be interesting to do so.