Burning custom secure boot keys

chipmunkmc commented

2026-07-21 11:01:03 -04:00

Owner

So I heard that many retail Exynos devices actually have unused keybanks (in the form of efuses) that one can install their own secure boot key to, and then be able to self-sign any bootloader they desire and boot it from internal storage (non-tethered).
Now I was linked one repository (mirror) relating to burning keys, and I noticed it actually patches S-BOOT to call some functions (likely involving smcs) to do so from download mode.
Since osmium is a download mode exploit, perhaps it can pull this off? >:D

So I heard that many retail Exynos devices actually have unused keybanks (in the form of efuses) that one can install their own secure boot key to, and then be able to self-sign any bootloader they desire and boot it from internal storage (non-tethered). Now I was linked one [repository](https://github.com/henr1kas/Exynos) ([mirror](https://code.chipmunk.land/max/Exynos9810-custom-key)) relating to burning keys, and I noticed it actually patches S-BOOT to call some functions (likely involving `smc`s) to do so from download mode. Since osmium is a download mode exploit, perhaps it can pull this off? >:D

ktoya commented

2026-08-16 14:15:55 -04:00

@chipmunkmc wrote in #8 (comment):

Since osmium is a download mode exploit, perhaps it can pull this off? >:D

Maybe

@chipmunkmc wrote in https://code.chipmunk.land/chipmunkmc/osmium/issues/8#issue-413: > Since osmium is a download mode exploit, perhaps it can pull this off? >:D Maybe

chipmunkmc commented

2026-08-17 18:35:36 -04:00

Author

Owner

I looked into it a bit, particularly by looking for these functions in a copy of S-BOOT I have, and I think I found them.

The cm_otp_write_rom_sec_boot_key function can be identified with the string "[OTP] ROM_SECURE_BOOT_KEY program start\n". It takes a key and a length (expected to be 32).
It seems to create a 160-byte buffer, copy the key to the beginning, add the length value at offset 128, and what looks like a checksum at offset 132. It then calls a function which seemingly clears the buffer from the CPU cache, and then calls smc 0 with 0xc2001014 in x0.

The cm_otp_write_use_rom_sec_boot_key function has the string "[OTP] USE_ROM_SEC_BOOT_KEY program start\n", and it seems to call smc 0 with 0xc2001014 in x0 and 2 in x1.

I suppose the simplest thing to do would be to use osmium to run a small program that calls these functions. I'm not sure which device(s) I want to test this on though (since fusing is a permanent operation).

I looked into it a bit, particularly by looking for [these](https://github.com/henr1kas/Exynos/blob/97047e7cb38f24889e47b560680f8b5c1699edd6/scripts/patch.py#L112-L113) functions in a copy of S-BOOT I have, and I think I found them. The `cm_otp_write_rom_sec_boot_key` function can be identified with the string `"[OTP] ROM_SECURE_BOOT_KEY program start\n"`. It takes a key and a length (expected to be 32). It seems to create a 160-byte buffer, copy the key to the beginning, add the length value at offset 128, and what looks like a checksum at offset 132. It then calls a function which seemingly clears the buffer from the CPU cache, and then calls `smc 0` with `0xc2001014` in `x0`. The `cm_otp_write_use_rom_sec_boot_key` function has the string `"[OTP] USE_ROM_SEC_BOOT_KEY program start\n"`, and it seems to call `smc 0` with `0xc2001014` in `x0` and 2 in `x1`. I suppose the simplest thing to do would be to use osmium to run a small program that calls these functions. I'm not sure which device(s) I want to test this on though (since fusing is a permanent operation).

chipmunkmc commented

2026-08-18 16:43:48 -04:00

Author

Owner

It seems as if the two functions I mentioned likely do not exist on older chipsets' bootloaders, like that of my SM-J327T1 (edit: and SM-J727T1). They exist in the SM-S367VL S-BOOT though.
I also looked at the signing data at the end of an SM-J327T1 bootloader, and apparently it uses signer version 3. The SM-S367VL bootloader uses version 4, though the data in both bootloaders otherwise looked alike.

I still see some interesting strings in the SM-J327T1 bootloader, like "[OTP] OEM_KEY0 setting: start 1/2...\n" and "[OTP] OEM_KEY1 setting: start 1/2\n". Maybe OEM_KEY1 is another keybank?
I also see "[CM] TEST 04/11: call cm_secure_boot_set_pubkey()\n", though it exists in SM-S367VL S-BOOT too.

It seems as if the two functions I mentioned likely do not exist on older chipsets' bootloaders, like that of my SM-J327T1 (edit: and SM-J727T1). They exist in the SM-S367VL S-BOOT though. I also looked at the signing data at the end of an SM-J327T1 bootloader, and apparently it uses signer version 3. The SM-S367VL bootloader uses version 4, though the data in both bootloaders otherwise looked alike. I still see some interesting strings in the SM-J327T1 bootloader, like `"[OTP] OEM_KEY0 setting: start 1/2...\n"` and `"[OTP] OEM_KEY1 setting: start 1/2\n"`. Maybe OEM_KEY1 is another keybank? I also see `"[CM] TEST 04/11: call cm_secure_boot_set_pubkey()\n"`, though it exists in SM-S367VL S-BOOT too.

Rows
Columns

Burning custom secure boot keys #8