BootROM dumping #7

Open
opened 2026-06-19 19:56:23 -04:00 by chipmunkmc · 2 comments
Owner

Rumors (well okay, some exploit writeups) says the USB controller has complete access to the phone's memory, at least in download mode conditions. Perhaps this means we can read/write "forbidden" areas of memory, such as the bootROM and secure monitor firmware?

We already have BootROM exploits of course, but those require entering a special "USB Boot mode" which boots the device via a USB connection to another machine (not over mass storage like on a PC). Entering said mode often requires zeroing or corrupting the bootloader region, which is possible but annoying to restore (you must split up the sboot.bin file properly and boot it over USB). Even worse, however, getting exploits to work requires guessing some addresses at the very least, and dumping the bootROM via EL1 exploits can make porting such exploits easier.

This also means it could be made easier to load a custom secure monitor (no need to run a proprietary blob at all times, yay!). Who knows, perhaps it's even possible to touch modem memory (though I'm too much of a noob to know).

Rumors (well okay, some exploit writeups) says the USB controller has complete access to the phone's memory, at least in download mode conditions. Perhaps this means we can read/write "forbidden" areas of memory, such as the bootROM and secure monitor firmware? We already have BootROM exploits of course, but those require entering a special "USB Boot mode" which boots the device via a USB connection to another machine (not over mass storage like on a PC). Entering said mode often requires zeroing or corrupting the bootloader region, which is possible but annoying to restore (you must split up the `sboot.bin` file properly and boot it over USB). Even worse, however, getting exploits to work requires guessing some addresses at the very least, and dumping the bootROM via EL1 exploits can make porting such exploits easier. This also means it could be made easier to load a custom secure monitor (no need to run a proprietary blob at all times, yay!). Who knows, perhaps it's even possible to touch modem memory (though I'm too much of a noob to know).
Author
Owner

I'm not sure how we'd do this yet (if possible) though. Perhaps we just patch process_packet to call S-BOOT's USB tx or rx function? Or perhaps we need to do it manually... (frankly I've never worked with hardware directly so I might be lost when it comes to this, but more importantly this could be hardware-specific)

I'm not sure how we'd do this yet (if possible) though. Perhaps we just patch `process_packet` to call S-BOOT's USB tx or rx function? Or perhaps we need to do it manually... (frankly I've never worked with hardware directly so I might be lost when it comes to this, but more importantly this could be hardware-specific)
Author
Owner

It also feels to me as if a phone without proprietary blobs in its lower rings (like EL3) is probably more free than any post-Intel-ME PC. Kinda funny if you think about it.

It also feels to me as if a phone without proprietary blobs in its lower rings (like EL3) is probably more free than any post-Intel-ME PC. Kinda funny if you think about it.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
chipmunkmc/osmium#7
No description provided.