°[All Dev's][Galaxy S4 Secure Boot Exploit][Think Tank] - Galaxy S 4 Developer Discussion [Developers-Only]

Hey guys!
I'm not an experienced dev or programmer and messing with aboot partition and stuff is certainly a risky thing. But im annoyed by Samsung's new Firmware Architekture, in detail the new locked Bootloader.
After days of excessive Google'ing i found this impressive posting: http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html
I'm not really a programmer so we will need experienced Dev's to step forward and to get rid off this damn Knox Bootloader.
@dev' s
What do you think ?
Launched in April 2013, the Samsung Galaxy S4 is expected to be one of the top-selling smartphones of the year, having sold 10 million units in its first month of sales. While the majority of released models include an unlocked bootloader, which allows users to flash custom kernels and make other modifications to the software on their own devices, AT&T and Verizon branded devices ship with a locked bootloader that prevents these types of modifications. In this post, I'll provide details on how Samsung implement this locking mechanism, and publish a vulnerability in the implementation that allows bypassing the signature checks to run custom unsigned kernels and recovery images.
Both the AT&T (SGH-I337) and Verizon (SCH-I545) models utilize the Qualcomm APQ8064T chipset. As described in my previous blog post on Motorola's bootloader, Qualcomm leverages software-programmable fuses known as QFuses to implement a trusted boot sequence. In summary, each stage of the boot process cryptographically verifies the integrity of the subsequent stage, with the trust root originating in QFuse values. After the early boot stages bootstrap various hardware components, Samsung's APPSBL ("Application Secondary Bootloader") is loaded and run. This bootloader differs between "locked" and "unlocked" variants of the Galaxy S4 in its enforcement of signature checks on the boot*and*recovery*partitions.
A quick glance at aboot*(adopting the name of the partition on which this bootloader resides) revealed that it is nearly identical to the open source lk*("Little Kernel") project, which undoubtedly saved me many hours of tedious reverse engineering. By locating cross-references to strings found in both lk*and aboot, I was able to quickly identify the functions that implement signature verification and booting of the Linux kernel.
The central logic to load, verify, and boot the Linux kernel and ramdisk contained in either the boot*or recovery*partitions is implemented in the boot_linux_from_mmc()*function. First, the function determines whether it is booting the main boot*partition, containing the Linux kernel and ramdisk used by the Android OS, or the recovery*partition, which contains the kernel and ramdisk used by the Android recovery subsystem. Then, the first page of the appropriate partition is read into physical memory from the eMMC flash storage:
Code:
if (!boot_into_recovery) {
index = partition_get_index("boot");
ptn = partition_get_offset(index);
if (ptn == 0) {
dprintf(CRITICAL, "ERROR: No boot partition found\n");
return -1;
}
}
else {
index = partition_get_index("recovery");
ptn = partition_get_offset(index);
if (ptn == 0) {
dprintf(CRITICAL, "ERROR: No recovery partition found\n");
return -1;
}
}
if (mmc_read(ptn + offset, (unsigned int *) buf, page_size)) {
dprintf(CRITICAL, "ERROR: Cannot read boot image header\n");
return -1;
}
This code is straight out of lk's implementation. Next, after performing some sanity-checking of the boot image, which contains a custom header format, the function loads the kernel and ramdisk into memory at the addresses requested in the boot image header:
Code:
hdr = (struct boot_img_hdr *)buf;
image_addr = target_get_scratch_address();
kernel_actual = ROUND_TO_PAGE(hdr->kernel_size, page_mask);
ramdisk_actual = ROUND_TO_PAGE(hdr->ramdisk_size, page_mask) + 0x200;
imagesize_actual = (page_size + kernel_actual + ramdisk_actual);
memcpy(image_addr, hdr, page_size);
offset = page_size;
/* Load kernel */
if (mmc_read(ptn + offset, (void *)hdr->kernel_addr, kernel_actual)) {
dprintf(CRITICAL, "ERROR: Cannot read kernel image\n");
return -1;
}
memcpy(image_addr + offset, hdr->kernel_addr, kernel_actual);
offset += kernel_actual;
/* Load ramdisk */
if (mmc_read(ptn + offset, (void *)hdr->ramdisk_addr, ramdisk_actual)) {
dprintf(CRITICAL, "ERROR: Cannot read ramdisk image\n");
return -1;
}
memcpy(image_addr + offset, hdr->ramdisk_addr, ramdisk_actual);
offset += ramdisk_actual;
This is still essentially identical to lk's implementation, with the addition of code to copy the individual pieces of the boot image to the image_addr*location. Finally, the function performs signature verification of the entire image. If signature verification succeeds, the kernel is booted; otherwise, a tampering warning is displayed and the device fails to boot:
Code:
if (check_sig(boot_into_recovery))
{
if (!is_engineering_device())
{
dprintf("kernel secure check fail.\n");
print_console("SECURE FAIL: KERNEL");
while (1)
{
/* Display tampered screen and halt */
...
}
}
}
/* Boot the Linux kernel */
...
The is_engineering_device()*function simply returns the value of a global variable that is set at an earlier stage in the boot process based on whether or not the chipset ID (an unchangeable hardware value) of the device indicates it is an engineering or production device.
Examining the check_sig()*function in more detail revealed that*aboot*uses the open-source mincrypt*implementation of RSA for signature validation. The bootloader uses an RSA-2048 public key contained in aboot*to decrypt a signature contained in the boot image itself, and compares the resulting plaintext against the*SHA1 hash of the boot image. Since any modifications to the boot image would result in a different SHA1 hash, it is not possible to generate a valid signed boot image without breaking RSA-2048, generating a specific SHA1 collision, or obtaining Samsung's private signing key.
The astute reader will have already noticed the design flaw present in the above program logic. Notice the order in which the steps are performed: first, aboot*loads the kernel and ramdisk into memory at the addresses requested by the boot image header, and then signature validation is performed after this loading is complete. Because the boot image header is read straight from eMMC flash prior to any signature validation, it contains essentially untrusted data. As a result, it's possible to flash a maliciously crafted boot image whose header values cause aboot*to read the kernel or ramdisk into physical memory directly on top of aboot*itself!
Exploitation of this flaw proved to be fairly straightforward. I prepare a specially crafted boot image that specifies a ramdisk load address equal to the address of the check_sig() function in aboot physical memory. In my malicious boot image, I place shellcode where the ramdisk is expected to reside. I flash this image by leveraging root access in the Android operating system to write to the boot block device. When aboot reads the supposed ramdisk from eMMC flash, it actually overwrites the check_sig() function with my shellcode, and then invokes it. The shellcode simply patches up the boot image header to contain sane values, copies the actual kernel and ramdisk into appropriate locations in memory, and returns zero, indicating the signature verification succeeded. At this point, aboot continues the boot process and finally boots my unsigned kernel and ramdisk. Victory!
Click to expand...
Click to collapse
Regards

---

You do realize this has been for a whileee now, right? This is djrbliss' loki exploit.
http://forum.xda-developers.com/showthread.php?t=2292157

---

... yes i do. Question is: will this work in similar ways on a international gt-i9505/ i9500 ?
*Hier könnte ihre Werbung stehen* *

---

Try it. But only on the qualcomm variants.

---

Does aboot still allow a boot.img to be loaded from emmc before signiture checks? If so another loki-like exploit is possible. Could use qpst and flash a custom emmc maybe and change the modem back to MDK but another exploit would need to be found first.
Sent from my cm_tenderloin using xda app-developers app

---

silentscreamer said:
Hey guys!
I'm not an experienced dev or programmer and messing with aboot partition and stuff is certainly a risky thing. But im annoyed by Samsung's new Firmware Architekture, in detail the new locked Bootloader.
After days of excessive Google'ing i found this impressive posting: http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html
I'm not really a programmer so we will need experienced Dev's to step forward and to get rid off this damn Knox Bootloader.
@dev' s
What do you think ?
Regards
Click to expand...
Click to collapse
A few people have already pointed this out but LOKI is actually a bootloader exploit that was used for AT&T MDB and MDL firmwares so LOKI'd custom recoveries and Kernels could be put onto the phone. You can find more information about it in the bootloader exploit thread in original development. This exploit also worked (after a little modification) on earlier Verizon S4s and is now being ported to other phones with locked bootloaders. However, the MF3 firmware update from AT&T patched the LOKI exploit so it can no longer be used with MF3 bootloaders.
So, for MF3 S4s, LOKI is not an option any more, however, the idea of still trying to get the bootloader unlocked is an ongoing process. You can do a search for the topic and you should see several existing threads present themselves. It is important to read the information in those threads in order to better understand where the process is at. And before you think, "well maybe this will work...or can this be tried...", understand, it probably has been tried an did not work.
This isn't to say it is a lost cause or shouldn't be pursued, it's just about realistic expectations. Basically, without Samsung's encrypted signing Key, or a means to generate it, or a reliable way to put a separate bootloader on the phone, it is a stuck project. SafeStrap, creates an entirely new environment for a ROM(S) to exist on a phones internal SD card, therefore, once again, sidestepping the original bootloader.
Search for other threads (about this subject) and contact some of the people that have similar interests from those threads. I won't drop any names because I'm not sure who is still investing time and who has moved on. That will be for you to decide. But please, before posting anything else about this or asking any more questions, search, read, and learn about what has already been done and you will find yourself with a much better understanding about what can be done. Good luck.

---

Exploit for local Linux Kernel (K2.6.37-3.8.9)
scott14719 said:
A few people have already pointed this out but LOKI is actually a bootloader exploit that was used for AT&T MDB and MDL firmwares so LOKI'd custom recoveries and Kernels could be put onto the phone. You can find more information about it in the bootloader exploit thread in original development. This exploit also worked (after a little modification) on earlier Verizon S4s and is now being ported to other phones with locked bootloaders. However, the MF3 firmware update from AT&T patched the LOKI exploit so it can no longer be used with MF3 bootloaders.
So, for MF3 S4s, LOKI is not an option any more, however, the idea of still trying to get the bootloader unlocked is an ongoing process. You can do a search for the topic and you should see several existing threads present themselves. It is important to read the information in those threads in order to better understand where the process is at. And before you think, "well maybe this will work...or can this be tried...", understand, it probably has been tried an did not work.
This isn't to say it is a lost cause or shouldn't be pursued, it's just about realistic expectations. Basically, without Samsung's encrypted signing Key, or a means to generate it, or a reliable way to put a separate bootloader on the phone, it is a stuck project. SafeStrap, creates an entirely new environment for a ROM(S) to exist on a phones internal SD card, therefore, once again, sidestepping the original bootloader.
Search for other threads (about this subject) and contact some of the people that have similar interests from those threads. I won't drop any names because I'm not sure who is still investing time and who has moved on. That will be for you to decide. But please, before posting anything else about this or asking any more questions, search, read, and learn about what has already been done and you will find yourself with a much better understanding about what can be done. Good luck.
Click to expand...
Click to collapse
hey guys, are these two links new methods or just more links to the Loki method?
http://m.h-online.com/open/news/ite...irculation-Update-1863892.html?from-classic=1
and​
https://patchwork.kernel.org/patch/2441281/​

---

What you want to achieve by this exploit?
This exploit has been designed to boot modified and thus unacceptable boot.img/recovery.img because of security enforcement on ATT/VZW models.
I9505 allows to boot any modified boot.img/recovery.img, thus there is no point for this explorer.
As for KNOX flag: it's set before aboot.img and affects TrustedZone. You cannot affect this flag from even aboot.img context.

---

Since Knox Bootloader : aboot downgrade does not work anymore *

---

silentscreamer said:
Since Knox Bootloader : aboot downgrade does not work anymore *
Click to expand...
Click to collapse
on Qualcomm devices, downgrade usually prohibited by qFuse. If you will find the way to flash an older aboot then you will end up with hard brick because qFuse is checking not only while flashing, but also while booting. Signatures of all bootloaders include status of qFuse set. Blown qFuse invalidates all previous valid signatures.
I don't recommend to find the other way to downgrade tz, sbl1-3, rpm and aboot parts if it's not possible to do in Odin. Risk of hard brick is very high!
And, by the way, as i've mentioned above, Knox flag is checked on much earlier stage (TZ) than aboot. You won't gain anything by replacing aboot to an older version.

---

I could really use something if you guys have it... im hard bricked and vzw model s4 isnt supported my any of the regular " unlock boxes" i mean i checked Riff, easy Jtag, Medusa, NS Pro, octopus!!! nothing... so I need some support. something I can throw on my phone when I wire it up to at least get me to the bootloader?>?? thx a bunch guys.

---

I think best buy can flash latest firmware on crapped out phone..

---

lgkahn said:
I think best buy can flash latest firmware on crapped out phone..
Click to expand...
Click to collapse
they probably can. AT&T did it on my bricked s4 now im mf3 though...

---

Guys, this horse is already well dead and apparently still being beaten.
Short of some astounding exploit being found this may not ever happen if you ever went past the original release firmware.
As jcase and others have said, it comes with the device and most/all knew going in - eyes wide open.
The alternative is to wait for a dev device and pay for it when it is made available.
(Doesn't work for Sprint but we don't seem to face these issues... yet.)
Edit:
By request the thread has been re-opened as it is a central point to collaborate on S4 bootloaders.
Things have also changed with 4.3 that now include more than Verizon and AT&T.
For example, Sprint is now seeing similar restrictions as the Note 3.
I would though kindly request this: Let's keep it relevant and on topic.
Let's not let this turn into a "Can I haz an unlocked bootloader" thread. We all have better things to do.

---

Ill start taking the RSA way
Okay,
So I can start cracking, this might take months or years, idk, but its worth a shot.
If I do crack it, Ill get 80% of that nice fat bounty
Whoever patches it gets 20% of that nice fat bounty
So first ill need, the rsa certificate/key (doesnt matter) that verifies aboot.mbn, or if you can, sbl1.mbn (stored in PBL, so prob not unless u can dump it)
Next Ill need the signature u want me to crack (for sbl1.mbn, u cant miss the 256 bytes). This is so I can verify it if I do get it cracked)
Finally, the offset of where to sign.
And thats all
Also, if u patch it, I sign it, and u test it, because i have no verizon, nor a Galaxy S4.
There, thxs!

---

sir best of luck to you, i have been wanting to run aosp based roms, but cant. i hope to look forward to testing this

---

tcf38012 said:
Okay,
So I can start cracking, this might take months or years, idk, but its worth a shot.
Click to expand...
Click to collapse
Why do you need an unlocked bootloader if you have already have a quantum computer

---

We dont want this thread to get locked again. Read garwynn's post.
Has anyone been able to resurrect/boot off their sdcard by using a debrick image or by writing an entirely new emmc to their sdcard? The reason I ask is because im pretty sure its the sbl2 located in modem.bin thats causing aboot to fail the revision check. If you dump mmcblk0p2 then mount modem.bin by using:
Code:
adb shell su 'dd if=/dev/block/mmcblk0p2 of=/mnt/extSdCard/backup/mdm.bin bs=512'
adb pull /mnt/extSdCard/backup/mdm.bin
Then mount in linux using:
mount -o loop mdm.bin /mnt/mkdirhere
You can compare sbl1 and sbl2 inside the mounted modem to the sbl1 and sbl2 in mmcblk0p3 and mmcblk0p4 from the odin image of whatever build your on. I think sbl2 is calling aboot. Anyone have more info? If we dd the sbl1 and sbl2 from an unlockable builds odin image and get the corresponding apps.mbn maybe we can figure something out. Also I checked the mounted modem's sbl1 and sbl2 from the dev edition vs consumer and the RSA encryption of the dev edition is referred to in the modem sbl2, which might explain the different odin failure messages one recieves when trying to flash an aboot from the dev edition vs a consumer edition see here http://forum.xda-developers.com/showthread.php?t=2483619
Sent from my SCH-I535 using xda app-developers app

---

Hello,
I wonder if the I9505 has the same functionality to boot from a special prepared SD-Card , like a newer I9300 I just had in my hands...
http://forum.xda-developers.com/showthread.php?p=47234165#post47234165
In this case we accidently managed to access SDCARD MODE by only a key combination, without shorteing the internal resistor.
If yes, this maybe could be a possibility to downgrade the I9505 bootloader.
However, DO NOT test this without a special prepared SD-Card or you will brick your device immediately cause your working bootloader will be overwritten.
Maybe someone with I9505 and a JTAG can test this procedure on I9505 and report back...
BR
Robert

---

Rob2222 said:
Hello,
I wonder if the I9505 has the same functionality to boot from a special prepared SD-Card , like a newer I9300 I just had in my hands...
http://forum.xda-developers.com/showthread.php?p=47234165#post47234165
In this case we accidently managed to access SDCARD MODE by only a key combination, without shorteing the internal resistor.
If yes, this maybe could be a possibility to downgrade the I9505 bootloader.
However, DO NOT test this without a special prepared SD-Card or you will brick your device immediately cause your working bootloader will be overwritten.
Maybe someone with I9505 and a JTAG can test this procedure on I9505 and report back...
BR
Robert
Click to expand...
Click to collapse
i would say you can use a "sd card" that you have nothing on, i'll go and see if i have one somewhere
and i think we also need sboot.bin but we ain't having that file