osmium

This is an exploit for booting unsigned images over USB on Samsung's S-BOOT bootloader, the bootloader formerly used for Samsung's Exynos devices. This exploits SVE-2020-16712, which is described here (mirror) (I'll make a writeup of my own soon:TM:).

Usage

First, grab a copy of uploader. You can get a binary from releases, or compile it with make (you need aarch64 binutils and a C compiler; read the Makefiles and set variables accordingly). Where uploader or uploader.exe is the name of the binary, you may need to invoke it as ./uploader (sh), uploader (cmd.exe), .\uploader.exe (cmd.exe, PowerShell).

For now you need an sboot info file, which is a text file containing info (mainly memory addresses) needed to exploit the bootloader. I have prepared some working ones in the sboot_info/ folder, where each file is named after the last 3 characters of the build number.

Let's say you have an SM-J327T1 on the latest SH2 bootloader (just like my daily driver!) and want to boot a copy of TWRP named recovery.img; the command is simply ./uploader boot sboot_info/SM-J327T1/SH2.txt recovery.img!

Porting

To port the exploit to a new device, first decide which bootloader to target. I would suggest the latest one for your bootloader revision (or if you dare, the actual latest one) that still has the vulnerability, or if there is none, the factory binary (see below) release for your bootloader revision.

If you are on Windows, you need to set up some drivers. First of all, install Samsung's drivers. Next, plug in a phone in Download Mode, grab a copy of Zadig, run it, check Options->List All devices, choose the first Gadget Serial device, change the driver from WinUSB to libusbK (no other drivers work!!!), and click Replace Driver. Now you should be ready to run the tool under Windows.

To check if the device's running bootloader is vulnerable, run ./uploader crash --verbose. If it gets stuck on ->Writing 8208 bytes..., chances are the exploit is patched. If it gets stuck after <-packet 100 37, this means it's unpatched and the bootloader freezes on data abort exceptions. If you get a reboot or upload mode, your bootloader has a good exception handler.

In the last case mentioned above, debugging the bootloader can be fairly easy. In such a case, punch *#9900# into the dialer in Android, and set the debug level to HIGH and let your phone reboot. Now bootloader exceptions will throw you into upload mode, and using bkerler's sboot_dump tool you can dump RAM. ./samupload.py partition 0 to dump logs, ./samupload.py partition 1 to dump S-BOOT, or use ./samupload.py range to dump other ranges of memory. Of course, ./uploader crash can deliberately trigger an exception in download mode!

To start a new S-BOOT info file, run ./uploader check /dev/null > sboot_info.txt. Notes (also sorry if I got some names wrong):

• pit_fail_download_ptr is the pointer to the instruction of the call to do_download in load_kernel made when the boot partition cannot be found.
• signature_check_ptr is the call to pit_check_signature in load_kernel (may be in make_security_decisions or something in newer bootloaders)
• rev_check_ptr is the call to the function with the string "KERNEL REV. Invalid magic string.\n" in load_kernel
• boot_kernel_ptr is the handler for the boot command
• write_protect_1_ptr and write_protect_2_ptr are calls to MMC write protection functions in boot_kernel.
• reset_handler_ptr_ptr is the function pointer used in the reset command handler (not the pointer to the handler itself) used to gain code execution; said command is invoked from process_packet
• loke_file_ptr can be found in process_packet and is usually initialized to a high value like 80000000 in the initialization packet.
• root_chunk_ptr is the root heap chunk used in malloc when the uncached flag is 1.
• next_core_ptr is the value used in next_available_cpu.
• The v3_smp values can be found in v3_smp_thread_handler, where v3_smp_cmd_flag is referenced in a function called in another function called there, where the return value is then checked against -2, and the v3_smp_flash_ptr_ptr call is made after.
• loke_packet_ptr is the address of the process_packet's packet buffer on the stack. The value of sp is shown when entering upload mode due to an exception, and its initial value is set in the function jumped to at the very start of the bootloader.
• psci_cpu_off is the code for the PSCI call to shutdown the current core; should be 84000002 (hexadecimal) usually.

An analyze command to help automate this may be added later.

Naming

All I remember about naming it was it was an element that ended with mium like Cadmium, the name of another S-BOOT exploit. It's blue like the download mode background, and the exploit targets said mode to boot custom images.

About the other exploit, its writeup can be found here (mirror); it's an untethered exploit for booting custom images. While the origins of the exploit may glow in the dark, the exploit itself is quite awesome. A friend told me she could get TWRP to boot on her S6 using it!

Credits

Credit goes to:

• Jeffxx - Finding the original vulnerability and creating the writeup used to implement this.
• bkerler - sboot_dump, a tool used I used to dump RAM on phones when testing. It was highly useful for debugging the exploit since the very start.
• Heimdall and https://github.com/Samsung-Loki/Thor - These source code of these projects was helpful for implementing the Odin mode protocol, and I frequently use the former to flash my testing devices.
• ashyx & thepcwiz101 - Creating the original root method, which I could use on a secondary device I obtained from a friend by luck
• Ghidra - Being a great reverse-engineering tool I used while working on, as far as I know, all of my exploit releases.
• Various people - Providing hardware, helping me learn about programming, and just things unrelated to phones...

I've had access to my SM-J327T1 since I was young (it originally a parent's), and have always wanted to play with root and custom ROMs on it someday. When I truly came into posession of the phone I started to look into that, just for the bootloader to be locked, and the root method to target an old firmware revision...

So I decided to do a quick search for Exynos bootloader exploits, and as luck would have it, I came across the document linked earlier. After doing more work with phones I began to understand the document more, and a few months ago began to exploit the vulnerability on my own hardware.

By patching my phone's boot.img with Magisk and using this exploit to boot it, I can now have semi-tethered root, and if I charge my phone often it's not that bad; and yes, I've already tweaked my system a bit. In the future I could completely replace the stock ROM. So thank you very much for everything...