Refactor #6

New issue

Open

opened 2026-03-06 19:43:05 -05:00 by chipmunkmc · 0 comments

chipmunkmc commented

2026-03-06 19:43:05 -05:00

Owner

Multiple things are currently sub-optimal

Currently all numbers on the host are assumed to be little-endian. We could do endian conversion in a very portable way as described here, but we'd need to use char arrays for the numbers I think. (related: #2)
Newer bootloaders configure the CPU to reject unaligned memory access it seems. As such using unaligned chunks to overwrite the reset function pointer fails.
Fortunately newer bootloaders store the saved link register right after the packet buffer which is exploitable.
As such we should support multiple methods, either explicitly (like method=rptr) or implicitly (so reset_handler_ptr_ptr=12345678 implies the same) (related: #3)
In addition, although using the packet buffer to execute shellcode, mainly longer shellcode programs is unreliable (invalid instruction exceptions can occur), its location is easier to find out, so it's useful for porting.
This could go in a separate branch, though not necessarily.
Currently the shellcode assumes the bootloader has parallel download support, while some don't, and don't even include SMP-related code (related: #4 / #5)
The sboot info handling code might be kinda ugly (and maybe sorta rushed)
Hijacking the parallel download handler might not be ideal and/or broken on a phone. It might be possible to use sboot's exception handler instead (related: #3)
Aside from the revision check, newer bootloaders implement even more checks on boot images, like the eng/usr one on SM-S367VL.
What these two checks have in common is a non-zero kernel type (used for custom images) being set skips these. The shellcode should probably set said type instead of just patching the rev check (related: #3)

Multiple things are currently sub-optimal * Currently all numbers on the host are assumed to be little-endian. We could do endian conversion in a very portable way as described [here](https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html), but we'd need to use char arrays for the numbers I think. (related: #2) * Newer bootloaders configure the CPU to reject unaligned memory access it seems. As such using unaligned chunks to overwrite the reset function pointer fails. Fortunately newer bootloaders store the saved link register right after the packet buffer which is exploitable. As such we should support multiple methods, either explicitly (like `method=rptr`) or implicitly (so `reset_handler_ptr_ptr=12345678` implies the same) (related: #3) * In addition, although using the packet buffer to execute shellcode, mainly longer shellcode programs is unreliable (invalid instruction exceptions can occur), its location is easier to find out, so it's useful for porting. This could go in a separate branch, though not necessarily. * Currently the shellcode assumes the bootloader has parallel download support, while some don't, and don't even include SMP-related code (related: #4 / #5) * The sboot info handling code might be kinda ugly (and maybe sorta rushed) * Hijacking the parallel download handler might not be ideal and/or broken on a phone. It might be possible to use sboot's exception handler instead (related: #3) * Aside from the revision check, newer bootloaders implement even more checks on boot images, like the eng/usr one on SM-S367VL. What these two checks have in common is a non-zero kernel type (used for custom images) being set skips these. The shellcode should probably set said type instead of just patching the rev check (related: #3)

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#6

No description provided.

Rows
Columns