BootROM dumping

chipmunkmc commented

2026-06-19 19:56:23 -04:00

Owner

Rumors (well okay, some exploit writeups) say 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) say 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).

chipmunkmc commented

2026-06-19 19:59:12 -04:00

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)

chipmunkmc commented

2026-06-19 20:00:40 -04:00

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.

chipmunkmc commented

2026-07-10 00:03:38 -04:00

Author

Owner

So I tried to dump the bootrom of the SM-J327T. First of all I wrote some shellcode (targetting the factory binary bootloader) to overwrite the usb respond function pointer with a pointer to some code to try dumping the bootrom with usb_xfer_tx.

_start:
	ldr x0, resp_ptr
	adr x1, dump_bootrom
	ldr x0, [x1]
	ret
dump_bootrom:
	mov x0, #0x0 /* address */
	mov x1, #0x20000 /* size */
	ldr x2, usb_xfer_tx_ptr
	br x2

.align 8
resp_ptr:
	.quad 0x73819128
usb_xfer_tx_ptr:
	.quad 0x73537d38

Next, I patched the uploader program to actually read the bootrom to a file.

diff --git a/uploader/odin_exploit.c b/uploader/odin_exploit.c
index 9f494e5..8f3480e 100644
--- a/uploader/odin_exploit.c
+++ b/uploader/odin_exploit.c
@@ -135,6 +135,18 @@ int exec_shellcode_rptr(char *shellcode, long shellcode_size, sboot_info *sboot,
 	packet.arg = sboot32(ODIN_CMD_RESET);
 	if (send_packet(&packet, info)) return -1;
 
+	/* Call our hijacked respond function */
+	packet.type = sboot32(ODIN_TYPE_PIT);
+	packet.arg = sboot32(ODIN_CMD_FLASH_MODE);
+	if (usb_write(&packet, sizeof(odin_packet), info)) return -1;
+
+	/* And now just read the bootrom */
+	char bootrom[0x20000];
+	if (usb_read(&bootrom, sizeof(bootrom), info)) return -1;
+	/* and of course save it */
+	FILE *output = fopen("bootrom.bin", "w+b");
+	fwrite(&bootrom, 1, sizeof(bootrom), output);
+
 	return 0;
 }

I tested this on two of my SM-J327T(1) devices. Unfortunately, All I got back on both of them were seemingly incoherent byte sequences consisting mostly of 0x00 with varying bytes in other places. Some but not most sequences matched between both dumps. I'd also like to note that both start with octet 0x65.

So I tried to dump the bootrom of the SM-J327T. First of all I wrote some shellcode (targetting the factory binary bootloader) to overwrite the usb respond function pointer with a pointer to some code to try dumping the bootrom with `usb_xfer_tx`. ```armasm _start: ldr x0, resp_ptr adr x1, dump_bootrom ldr x0, [x1] ret dump_bootrom: mov x0, #0x0 /* address */ mov x1, #0x20000 /* size */ ldr x2, usb_xfer_tx_ptr br x2 .align 8 resp_ptr: .quad 0x73819128 usb_xfer_tx_ptr: .quad 0x73537d38 ``` Next, I patched the uploader program to actually read the bootrom to a file. ```diff diff --git a/uploader/odin_exploit.c b/uploader/odin_exploit.c index 9f494e5..8f3480e 100644 --- a/uploader/odin_exploit.c +++ b/uploader/odin_exploit.c @@ -135,6 +135,18 @@ int exec_shellcode_rptr(char *shellcode, long shellcode_size, sboot_info *sboot, packet.arg = sboot32(ODIN_CMD_RESET); if (send_packet(&packet, info)) return -1; + /* Call our hijacked respond function */ + packet.type = sboot32(ODIN_TYPE_PIT); + packet.arg = sboot32(ODIN_CMD_FLASH_MODE); + if (usb_write(&packet, sizeof(odin_packet), info)) return -1; + + /* And now just read the bootrom */ + char bootrom[0x20000]; + if (usb_read(&bootrom, sizeof(bootrom), info)) return -1; + /* and of course save it */ + FILE *output = fopen("bootrom.bin", "w+b"); + fwrite(&bootrom, 1, sizeof(bootrom), output); + return 0; } ``` I tested this on two of my SM-J327T(1) devices. Unfortunately, All I got back on both of them were seemingly incoherent byte sequences consisting mostly of `0x00` with varying bytes in other places. Some but not most sequences matched between both dumps. I'd also like to note that both start with octet `0x65`.

chipmunkmc commented

2026-07-21 10:49:50 -04:00

Author

Owner

Perhaps I could overwrite some EL3 code, like the SMC handler, using USB and then finish dumping the bootrom with the help of the CPU?

chipmunkmc commented

2026-07-21 11:14:02 -04:00

Author

Owner

@chipmunkmc wrote in #7 (comment):

So I tried to dump the bootrom of the SM-J327T. First of all I wrote some shellcode (targetting the factory binary bootloader) to overwrite the usb respond function pointer with a pointer to some code to try dumping the bootrom with usb_xfer_tx. [snip]

And of course I used &bootrom when the correct way to point to the array would be just bootrom, oh what a fool I am! This issue could very well corrupt the result.
I'm unfortunately not at home and don't have any of my Exynos hardware at the moment so I can't check what would happen if I fixed this issue.

@chipmunkmc wrote in https://code.chipmunk.land/chipmunkmc/osmium/issues/7#issuecomment-1535: > So I tried to dump the bootrom of the SM-J327T. First of all I wrote some shellcode (targetting the factory binary bootloader) to overwrite the usb respond function pointer with a pointer to some code to try dumping the bootrom with `usb_xfer_tx`. *[snip]* And of course I used `&bootrom` when the correct way to point to the array would be just `bootrom`, oh what a fool I am! This issue could very well corrupt the result. I'm unfortunately not at home and don't have any of my Exynos hardware at the moment so I can't check what would happen if I fixed this issue.

Rows
Columns

BootROM dumping #7