Breaking Samsung's Security

Problem: The Verizon Galaxy S4 is bootloader locked.

Well, what exactly is a Locked Bootloader? A locked bootloader checks for a digital signature on certain images/partitions on the device. This prompted me to begin to research ways to work around this.

The Verizon Galaxy S4 (hereon referred to as VZW S4) checks the integrity of signatures on all of the following partitions;

-          Boot (boot.img)

-          TrustZone (TZ.img)

-          Aboot  (aboot.mbn)

-          RPM (RPM.mbn)

-          SBL1 (sbl1.mbn)

-          SBl2 (sbl2.mbn)

-          SBl3 (sbl3.mbn)

-          The Partition Map (JFLTE_USA_VZW.pit)

-          Recovery (recovery.img)

-          Modem
-          NON-HLOS

 Partitions not checked:

-          System (/system, only checked during OTA Update)

-          Persdata (/Data)

-          Cache (/cache)

-          Hidden.img

Basic Understanding of the boot sequence:

PDF: https://drive.google.com/file/d/0B1rm1VFiz_2FY0gxVU92dEFiMEk/view?usp=sharing

Visio: https://drive.google.com/file/d/0B1rm1VFiz_2FUGV0Nk5FdTg3czQ/view?usp=sharing

Where to start? There are many vantage points to be taken.

1.      One was described in a recent leak: There is a QFUSE on device under the label of TESTBIT. By reverse engineering a Verizon Galaxy S4 (SCH-i545) VRUFNK1 aboot.mbn in IDA, we can follow the decompiled functions down to the function that calls to check the value of TESTBIT in memory.

We can also deduce from here that the value of TESTBIT’s shadow in memory is 0x700438+0x4000. Though, it is worth noting that aboot does not check TESTBIT’s shadow, it checks the base fuse, which makes overwriting the shadow in memory almost entirely useless.

With this info, we can use JTAG to set the fuse value and boot an MDK aboot. This allows us to use a Loki like attack to boot a custom recovery and kernel.

The only way to permanently blow the fuse would be to use a flaw/vulnerability in TrustZone blow the base fuse to our desired value. Dan Rosenberg's QSEE exploit could easily be leveraged. We could even likely apply M0nk's work on the 8974 to get TZ shellcode, and over-write the fuse value in the shared-cache.

Another fuse that would work similarly would be the Commercial bit, however, this fuse has proven extremely hard to find. Though I am sure it exists. This would be the fuse that is read out by aboot, and dictates whether or not the developer edition checks are enforced. Though, from my findings in aboot, some form of CID hash (at the minimum) spoof would also have to be present.

Theoretically Vulnerable Devices:

-          Galaxy S4 (All QCOM Variants) Method: Downgrade to Pre-Knox Bootloader, or to exploitable firmware, i.e. MDK (SCH-i545), MDL (SGH-i337)

-          Note 3 (All QCOM Variants) NOTE: Note 3 has no Loki vulnerable Bootloader, meaning this only disables roll back for these devices.

-          Galaxy S5 (All QCOM Variants) NOTE: Galaxy S5 has no Loki vulnerable Bootloader, meaning this only disables roll back for these devices.

-          Galaxy S3 (All QCOM Variants) Method: Downgrade to “African-Sock-Monkey” leaked Insecure (Unlocked) Bootloader

Likelihood: (WITH JTAG ONLY)  0/10 – EDIT: The TESTBIT check function looks for 0x20, and the ones digit of the increment fuse is already blown to 0x01, meaning if we blew 0x20 to the fuse, it would return 0x21 and brick.*, still working on Commercial BIT - FAILED -- Could still work with the advent of M0nk's shellcode escalation? Still researching.

Likelihood: (WITHOUT JTAG) 0/10, would require a TrustZone Exploit to blow TESTBIT (Dan's TZ, and I can count the amount of public TrustZone Exploits I have seen in my career on two hands (5 HTC Specific, 3 Motorola Specific, 2 Generic TrustZone)

2.       Another method was described in a recent leak: There is a special hardware protected partition on the eMMC called “RPMB” (Not to be confused with RPM.mbn), that stores the roll back information on the QCOM Galaxy S4 variants. This can be theoretically restored to a blank state by removing the eMMC and hooking it up (using the correct pin outs) to a Linux Machine, which would then have to issue several (confidential/not-public knowledge) Toshiba eMMC Vendor Commands to wipe RPMB (or write the lowest known firmware value to it). After placing the eMMC back in the device, the device could theoretically downgrade to any previous firmware.

It is worth noting that all devices released by Samsung after the Galaxy S4 blow a physical QFUSE to signify rollback, meaning that they are not vulnerable (i.e. Note 3, Galaxy S5).

Theoretically Vulnerable Devices:

-          Galaxy S4 (All QCOM Variants) Method: Downgrade to Pre-Knox Bootloader, or to exploitable firmware, i.e. MDK (SCH-i545), MDL (SGH-i337)

-          Galaxy S3 (All QCOM Variants) Method: Downgrade to “African-Sock-Monkey” leaked Insecure (Unlocked) Bootloader

Likelihood:  4/10, would work if we had the correct pin-out for our eMMC, and the Toshiba Vendor Commands, but getting our hands on the latter is unlikely. – Still under research

3.       Yet another method is described below:

KEXEC is a tool used to overwrite the Linux kernel in memory with a new kernel, and then execute the new kernel without ever taking the system down for full reboot (hardware always remains live). It has become increasingly more common to see KEXEC implementations to bypass android device Bootloader security, as many times, it is far simpler than finding a vulnerability that would allow a full unlock.

KEXEC must be loaded in as a kernel module to work correctly. So, to even attempt a KEXEC bring up, we first need root access and the ability to load custom (un-signed) kernel modules. I will be speaking about the Verizon Galaxy S4 almost exclusively here, although this theoretically applies to most Samsung devices.

First step is root, easily attained on all >4.4.4 devices via the Futex bug (originally by Comex, though ported to android by George Hotz in the form of TowelRoot.apk), and as long as the device in question hasn’t been upgraded to Android 5.0 yet, you can always just roll back to a Futex vulnerable firmware and root. We then install BusyBox, and SafeStrap (A boot hijack that allows us to flash ROM’s, and access a terminal before any partitions are mounted originally by HashCode, updated by Muniz_ri), this gives us a base for KEXEC work/debugging, and a place to optimally execute it. Next is un-signed kernel modules, on the S4, the process that checks to see if kernel module signatures are require is called KLSM. There is a known exploit by Jeboo that was initially created for 4.3 (MK2) called BypassLKSM, that was later ported to 4.4.2 (NC5) by Surge1223, and then later to 4.4.2 (NK1) by myself and Demetulth.

– EDIT: VZW S4 has Lollipop (5.0.1, OC1), researching BypassLKSM addresses now…

-EDIT 2: Found them.

Now, we build our version of KEXEC using the NC5 kernel source (As Samsung has yet to release the NK1 kernel source 5 months after release, GPL violation? Big time)

Now to actually execute KEXEC! We then boot up to safestrap (a recovery boot hijack, and at that, a special version with devmem2 & viewmem), push the built KEXEC modules, ramdisk, and vmlinuz (kernel) to the root of the device, connect the device to your computer via USB, and run  commands with similar syntax(s) to these:

Adb shell

Su

Insmod kexec_arm.ko

Insmod kexec_machine.ko

Insmod Kexec.ko

Lsmod       #Expected output should list all 3 modules listed above

kexec -l /stock_nk1_zImage --ramdisk=/ramdisk.cpio.gz --append="($cat $cmdline)" --atags-file=/atags

unmount –a #My recommendation would be to unmounts all partitions manually

(In a separate terminal)ADB Shell su –c “dmesg”

(In the first terminal) kexec- e

After the system attempts to soft-boot the kernel (and inevitably fails), we have to pull a last_kmesg, and look at the DMESG we got in the second terminal we pulled up earlier. We then try to debug the problems it is having. Right now, we are hanging at being unable to flush the kernel caches correctly & at the correct time in the KEXEC sequence, as well as the kernel being corrupted in purgatory.

Likelihood:  7/10, will work if we can debug all of the issues, not a question of “if”, as it is “how”, and “when” – Still under research.

4.       An alternative idea was to mask TESTBIT in memory using JTAG to disable rollback, and then KEXEC to boot to Download Mode and attempt to do so without emptying the memory. This failed in our attempts, because for one reason or another, we were unable to keep the memory from reverting the value of TESTBIT to the pre-masked version.

Likelihood:  1/10, failed miserably, if we could find a way to retain memory contents after the softboot to Download Mode, it could work.

5.       Another proposed method of attack was using KEXEC Hardboot (a way to KEXEC to a new kernel from a full reboot) – This posed extremely similar results to KEXEC, but provided no logs whatsoever, as last_kmesg had been cleared upon reboot, and the DMESG was of no use, as it just stated that the system went down for reboot, so we had no method to debug it.

Likelihood:  1/10, failed miserably in testing, no way to debug it due to lack of logs.

6.       A proposed method, that has yet to come to fruition, is the potential for a vulnerability in QCOM Download Mode (See the referenced bootchain.pdf earlier in the article for explanation), as it allows you to boot an SBL1 (as long as it is signed and within rollback), from the SD Card. This mode can only be accessed if SBL1 is damaged/not signed/not present.

Likelihood:  1/10, failed miserably in testing, no documentation provided for QCOM mode, hard to work with.

7.        Similar to the above method, is the potential for a vulnerability in QCOM Download Mode itself, and the way it boots SBL1 from the SD Card (via debrick.img).

Likelihood:  3/10, requires more research, no documentation provided for QCOM mode, hard to work with, and would require specially crafted debrick.img. – Still under research

8.       Another proposed potential vantage point is a vulnerability in ODIN that would allow us to modify protected partitions of the device.

Likelihood:  1/10, almost complete chance, would require reverse engineering of ODIN, and a special kind of vulnerability.

9.       Yet another method is to reverse engineer how developer edition devices aboot is signed, though, even if we deduced the algorithm, we would still need access to Samsung’s RSA & Private Key (likely could only happen via a leak).

Likelihood:  0.000000001/10, would require Samsung’s RSA & Private key to be leaked, which is almost impossible.

10.   Another idea to be considered is finding a way to write the CID of the device, allowing us to boot another (developer edition) devices signed, unlocked aboot.

Likelihood:  6/10, Can definitely work, but would be highly illegal, as we legally can’t spoof our device’s CIDs, falls under the same category as IMEI/ESN spoofing, but is much harder to do.

12.   On final idea to consider is that there is a mode known only as “Factory Mode”, this is the mode wherein the manufacturer writes the CID, partition layout, fuse values, etc. It basically serves as a “God-Mode” for the device, but can only be accessed once, and then it is permanently disabled. If we could find a way to get the device to revert to this mode, anything would be possible.

Likelihood:  0.00000000000000001/10, would require a godsend of a vulnerability, would likely have to be at PBL level, and would likely affect all QCOM devices if found.