If we are serious about unlocking the bootloader

Search This thread

awskier08

Senior Member
Sep 23, 2011
101
13
0
not sure if this is relevent..

Those of you who like to tinker and jailbreak Android phones should take notice of some new research conducted on Samsung Galaxy S4 Android devices shipped by AT&T and Verizon. Both device makers ship the Galaxy S4 smartphones with a locked down bootloader that prevents users from uploading custom kernels or from making modifications to software on the phone.

Azimuth Security researcher Dan Rosenberg has found a vulnerability in the manner in which the devices do cryptographic checks of boot image signatures and was able to exploit the flaw and upload his own unsigned kernel to the device.

Related Posts
New Android Malware Steals SMS Messages, Intercepts Calls
January 22, 2014 , 3:01 pm
WhatsApp Spam Spreads New Banking Trojan
January 21, 2014 , 2:59 pm
Starbucks Fixes Vulnerable iOS App, Geolocation Issue Persists
January 20, 2014 , 4:19 pm
An attacker could do the same and upload a malicious kernel or software and own the device.

Rosenberg has previously published work on Android devices built by Motorola where he was able to exploit a hole in the TrustZones deployed in the devices’ ARM processor. TrustZones are security extensions to the processor that essentially run a secure kernel alongside the main kernel where sensitive applications such as mobile payment apps may execute. Motorola was using TrustZones to also control a lockdown of the bootloader.

The AT&T and Verizon devices are built on the Qualcomm APQ8064T chip which relies on its QFuses technology to implement a trusted boot sequence, Rosenberg said. The technology, which is a one-time configuration of hashes and keys, cryptographically verifies the next stage of boot up before it’s launched and then Samsung’s application secondary bootloader (APPSL) runs.

“This bootloader differs between locked and unlocked variants of the Galaxy S4 in its enforcement of signature checks on the boot and recovery partitions,” Rosenberg said.

Rosenberg discovered that the aboot bootloader on the devices is nearly identical to the open source Little Kernel bootloader project, which he said aided him in finding the functions that implement signature verification and booting of the Linux kernel. Once a particular boot function determines whether it is to load the main kernel or a recovery subsystem, it loads the appropriate partition into memory from the eMMC flash storage on the phone, Rosenberg said.

That programming logic is flawed, Rosenberg said.

“Because the boot image header is read straight from eMMC flash prior to any signature validation, it contains essentially untrusted data,” Rosenberg said. “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.”

Signature checks are done after the kernel image is loaded, but if an attacker is able to access the process before this step, he can beat the signature validation. Aboot, for example, uses an open source implementation of RSA encryption for signature validation which compares the decrypted signature of the boot image to the SHA1 hash of the boot image, Rosenberg said.

Rosenberg said his exploit was a boot image where the ramdisk load address was equal to the address of the signature verification function in aboot. Rosenberg replaced the ramdisk with shellcode and flashed this image instead. Aboot reads the exploit image instead from flash and overwrites the signature check function with the shellcode.

“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,” Rosenberg said.

http://threatpost.com/researcher-un...tloader-for-att-verizon-android-phones/100757
 

Surge1223

Recognized Contributor
Nov 6, 2012
2,603
7,397
203
Florida
Naw, this was all well after that. I don't think H3llsdroid was claiming to do it with out opening the phone... or at least I always though he was doing it via a standard jtag/riff box/whatever....

Early on there was talk of, for lack of a better explanation, a jtag mode or circuit/extra software.... however it worked but a way to do it with just a usb cable.

I don't know if we are still stuck with the efuse then...
The screen shot of the forum post that says you can shows that the poster is a support, which could just mean a subscriber or active community member... The actual product manager replied less concretely to the same post with the response:

The whole forum reads like its translated, so its hard to tell exact intent but I read that as "Ehh it might work. You will at least need a direct connection to the EMMC connection."

About that, that boot repair.exe is pretty sophisticated. It actually has parts from odin and qpst in it but most surprisingly it contains bootloaders for the i9505 and has the ability to flash the mbr and gpt back to the emmc because it has the only correct partition0.bin, rawprogramm.xml, patch0.xml and partition_boot.xml I've ever seen (essentially together they define the fornat/structure of the emmc)


Also, ill just go ahead and post this now too. I have a pretty good idea of where, when, why and how the Knox kernel warranty void bit gets set (my screenshot bassically confirmed the data/code I got from ida)

Bassically, during the boot procedure after aboot is verified it waits for the rpm to give it the "green light" before loading/booting the system.

Failure results in an SMC call being made to the TZ, thus setting the warranty void bit.


Sent form my SCH-I545 using XDA Premium 4 mobile app
 

Attachments

  • 1390646831439.jpg
    1390646831439.jpg
    93.5 KB · Views: 699
Last edited:

Blahness

Member
Jan 11, 2014
14
31
0
How does the developer edition unlock the bootloader? Through fastboot (as I'm expecting)?

Also, how can I see the debug statements? For example, there are dprintf() calls in functions when they are called (i.e. "odin3_init()" is printed to somewhere when the fastboot init function is called). Can I listen on a COM port or something? Are there logs?
 
Last edited:

Surge1223

Recognized Contributor
Nov 6, 2012
2,603
7,397
203
Florida
I reversed that S4 usb repair tool, that is the soft circuit alternative we discussed at the beginning of this thread. Ill post conclusions and comments of my analysis of how it works later today. At the very least it looks like its creating some files that would be useful to have.

if ( v1 == 0 )
v1 = (int (__stdcall ***)(int, int))loc_401090(-2147467259);
v154 = ((int (__thiscall *)(int (__stdcall ***)(int, int)))(*v1)[3])(v1) + 16;
v156 = 0;
sub_4139DC((void *)v2, 1000, &v154);
if ( !*(_DWORD *)(v154 - 12) )
sub_407DD9(L"Please Input Port Number!!", 0, 0);
v3 = sub_40364A();
if ( v3 == 0 )
v3 = (int (__stdcall ***)(int, int))loc_401090(-2147467259);
v155 = ((int (__thiscall *)(int (__stdcall ***)(int, int)))(*v3)[3])(v3) + 16;
LOBYTE(v156) = 1;
sub_401560(&v155, v2, (int)L"emmcdl.exe", 10);
sub_403230(&v155, (int)L" -p ", 4u);
sub_403230(&v155, v154, *(_DWORD *)(v154 - 12));
sub_403230(&v155, (int)L" -f MPRG8064.hex -x rawprogram0.xml", 0x23u);
v4 = sub_40364A();
if ( v4 == 0 )
v4 = (int (__stdcall ***)(int, int))loc_401090(-2147467259);
v7 = ((int (__thiscall *)(int (__stdcall ***)(int, int)))(*v4)[3])(v4);
v6 = v7 + 16;
v152 = v7 + 16;
v151 = v8;
LOBYTE(v156) = 2;
lpFileName = (LPCWSTR)&v151;
sub_401180(&v151, v2, (int)L"emmcdl.exe");
sub_402030(0x92u, v151);
lpFileName = (LPCWSTR)&v151;
sub_401180(&v151, v2, (int)L"aboot.mbn");
sub_402030(0x82u, v151);
lpFileName = (LPCWSTR)&v151;
sub_401180(&v151, v2, (int)L"configuration.xml");
sub_402030(0x83u, v151);
 

Blahness

Member
Jan 11, 2014
14
31
0
I believe this may already be mentioned but if not, here goes nothing.

It seems that fastboot/aboot distinguishes between "developer mode" and retail is stored at the address 0x88F439C8. In my aboot, the value is default 0; in the aboot of the MJ7 bootchain that was posted by Surge, the value is nonzero. As aboot starts, it calls a check for the value of this code:
Code:
ROM:88E15BE8                 BL              is_dev_device
ROM:88E15BEC                 CMP             R0, #0
ROM:88E15BEE                 BNE             loc_88E15CA4
ROM:88E15BF0
ROM:88E15BF0 loc_88E15BF0                            ; CODE XREF: ROM:88E15CB2j
ROM:88E15BF0                 MOVW            R0, #0x7F7F
ROM:88E15BF4                 LDR             R1, =aWriteProtectionE ; "WRITE PROTECTION: Enable"
ROM:88E15BF6                 MOVT.W          R0, #0x7F
ROM:88E15BFA                 BL              print_to_screen_grey
ROM:88E15BFE                 BL              sub_88E00AE0
ROM:88E15C02                 MOV             R4, R0
ROM:88E15C04                 BL              sub_88E00AE8
ROM:88E15C08                 MOV             R1, R0
ROM:88E15C0A                 MOV             R0, R4
ROM:88E15C0C                 BL              fastboot_init__
ROM:88E15C10
ROM:88E15C10 loc_88E15C10                            ; CODE XREF: ROM:88E15C8Aj
ROM:88E15C10                 BL              udc_start
ROM:88E15C14                 ADD             SP, SP, #8
Code:
ROM:88E10170 is_dev_device                            ; CODE XREF: sub_88E0A2D0:loc_88E0A35Ep
ROM:88E10170                                         ; sub_88E1419C+714p ...
ROM:88E10170                 MOV             R3, 0x88F439C8
ROM:88E10178                 LDR             R0, [R3]
ROM:88E1017A                 BX              LR
As you can see, if the result is not equal to 0, it goes to another function:
Code:
ROM:88E15CA4 loc_88E15CA4                            ; CODE XREF: ROM:88E15BEEj
ROM:88E15CA4                 MOVW            R0, #0x7F7F
ROM:88E15CA8                 LDR             R1, =aModeDeveloper ; "MODE: Developer"
ROM:88E15CAA                 MOVT.W          R0, #0x7F
ROM:88E15CAE                 BL              print_to_screen_grey
ROM:88E15CB2                 B               loc_88E15BF0
The last branch goes back to calling function in the first code excerpt:
Code:
ROM:88E15BF0 loc_88E15BF0                            ; CODE XREF: ROM:88E15CB2j
ROM:88E15BF0                 MOVW            R0, #0x7F7F
ROM:88E15BF4                 LDR             R1, =aWriteProtectionE ; "WRITE PROTECTION: Enable"

There seems to be one reference as to where the data at this location is changed. Perhaps it's a secure method, I'm not sure (I also don't quite understand the TZ and calls made to it quite yet).
Code:
ROM:88E1021A                 MOV             R0, SP
ROM:88E1021C                 MOV             R1, R4
ROM:88E1021E                 LDR             R2, =unk_88F36AA8
ROM:88E10220                 BL              sub_88E0A2C4
ROM:88E10224                 LDR             R2, =dword_88F439C8
ROM:88E10226                 CMP             R0, #0
ROM:88E10228                 ITE NE
ROM:88E1022A                 MOVNE           R3, #0
ROM:88E1022C                 MOVEQ.W         R3, #0xFFFFFFFF
ROM:88E10230                 IT NE
ROM:88E10232                 MOVNE           R0, #1
To decode the logic after the subroutine is executed:
Code:
if r0 != 0
 r3 = 0
else
 r3 = -1

if r0 != 0
 r0 = 1

is_dev_device_flag = r0
r0 = r3
Remember that when the is_dev_device_flag is 0 it means that it is not a developer device.

Unfortunately the subroutine found at 0x88E0A2C4 is fairly convoluted. It'll take some more time to reverse it and see if there is any adaptable backdoor to put the device into dev mode for the current power cycle. Just wanted to share this to shed some light of if anyone has ideas.

Edit/note: I am also unsure if changing this flag will have any effect on unlocking the bootloader. It's possible that this flag is used later to enable fastboot commands
 
Last edited:

Surge1223

Recognized Contributor
Nov 6, 2012
2,603
7,397
203
Florida
I believe this may already be mentioned but if not, here goes nothing.

It seems that fastboot/aboot distinguishes between "developer mode" and retail is stored at the address 0x88F439C8. In my aboot, the value is default 0; in the aboot of the MJ7 bootchain that was posted by Surge, the value is nonzero. As aboot starts, it calls a check for the value of this code:
Code:
ROM:88E15BE8                 BL              is_dev_device
ROM:88E15BEC                 CMP             R0, #0
ROM:88E15BEE                 BNE             loc_88E15CA4
ROM:88E15BF0
ROM:88E15BF0 loc_88E15BF0                            ; CODE XREF: ROM:88E15CB2j
ROM:88E15BF0                 MOVW            R0, #0x7F7F
ROM:88E15BF4                 LDR             R1, =aWriteProtectionE ; "WRITE PROTECTION: Enable"
ROM:88E15BF6                 MOVT.W          R0, #0x7F
ROM:88E15BFA                 BL              print_to_screen_grey
ROM:88E15BFE                 BL              sub_88E00AE0
ROM:88E15C02                 MOV             R4, R0
ROM:88E15C04                 BL              sub_88E00AE8
ROM:88E15C08                 MOV             R1, R0
ROM:88E15C0A                 MOV             R0, R4
ROM:88E15C0C                 BL              fastboot_init__
ROM:88E15C10
ROM:88E15C10 loc_88E15C10                            ; CODE XREF: ROM:88E15C8Aj
ROM:88E15C10                 BL              udc_start
ROM:88E15C14                 ADD             SP, SP, #8
Code:
ROM:88E10170 is_dev_device                            ; CODE XREF: sub_88E0A2D0:loc_88E0A35Ep
ROM:88E10170                                         ; sub_88E1419C+714p ...
ROM:88E10170                 MOV             R3, 0x88F439C8
ROM:88E10178                 LDR             R0, [R3]
ROM:88E1017A                 BX              LR
As you can see, if the result is not equal to 0, it goes to another function:
Code:
ROM:88E15CA4 loc_88E15CA4                            ; CODE XREF: ROM:88E15BEEj
ROM:88E15CA4                 MOVW            R0, #0x7F7F
ROM:88E15CA8                 LDR             R1, =aModeDeveloper ; "MODE: Developer"
ROM:88E15CAA                 MOVT.W          R0, #0x7F
ROM:88E15CAE                 BL              print_to_screen_grey
ROM:88E15CB2                 B               loc_88E15BF0
The last branch goes back to calling function in the first code excerpt:
Code:
ROM:88E15BF0 loc_88E15BF0                            ; CODE XREF: ROM:88E15CB2j
ROM:88E15BF0                 MOVW            R0, #0x7F7F
ROM:88E15BF4                 LDR             R1, =aWriteProtectionE ; "WRITE PROTECTION: Enable"

There seems to be one reference as to where the data at this location is changed. Perhaps it's a secure method, I'm not sure (I also don't quite understand the TZ and calls made to it quite yet).
Code:
ROM:88E1021A                 MOV             R0, SP
ROM:88E1021C                 MOV             R1, R4
ROM:88E1021E                 LDR             R2, =unk_88F36AA8
ROM:88E10220                 BL              sub_88E0A2C4
ROM:88E10224                 LDR             R2, =dword_88F439C8
ROM:88E10226                 CMP             R0, #0
ROM:88E10228                 ITE NE
ROM:88E1022A                 MOVNE           R3, #0
ROM:88E1022C                 MOVEQ.W         R3, #0xFFFFFFFF
ROM:88E10230                 IT NE
ROM:88E10232                 MOVNE           R0, #1
To decode the logic after the subroutine is executed:
Code:
if r0 != 0
 r3 = 0
else
 r3 = -1

if r0 != 0
 r0 = 1

is_dev_device_flag = r0
r0 = r3
Remember that when the is_dev_device_flag is 0 it means that it is not a developer device.

Unfortunately the subroutine found at 0x88E0A2C4 is fairly convoluted. It'll take some more time to reverse it and see if there is any adaptable backdoor to put the device into dev mode for the current power cycle. Just wanted to share this to shed some light of if anyone has ideas.

Edit/note: I am also unsure if changing this flag will have any effect on unlocking the bootloader. It's possible that this flag is used later to enable fastboot commands

Dude awesome job! Im working on determining that now taking apart the TZ...

Sent from my SCH-I545 using XDA Premium 4 mobile app
 

Blahness

Member
Jan 11, 2014
14
31
0
Dude awesome job! Im working on determining that now taking apart the TZ...

It's possible (just a gut feeling) the subroutine is an SMC to check the QFuse and set a software variable with the value of the fuse. In this case, it probably would be hard to hack the function for a certain output.
 

NighthawkXL

Senior Member
Mar 4, 2013
396
313
93
Florida
It's possible (just a gut feeling) the subroutine is an SMC to check the QFuse and set a software variable with the value of the fuse. In this case, it probably would be hard to hack the function for a certain output.

While I'm not fluent in the required expertise to understand the bulk of this... could someone actually explain where the qFuse actually is. I know they are physical unlike a eFuse but are they located within the Snapdragon itself? (ie. Inside the chips wiring) or are they a simple fuse on the motherboard itself. I suppose it's the former... in which case outside of having a electron microscope and the tools to repair it would be highly unlikely to replace. Also, if this is the case what happens when you physically swap the Snapdragon on the board with a non-blown one Snapdragon from a different pre-blown S4? I mentioned along with someone else awhile back the possibility of say a modchip to bypass everything from the start like we've done with gaming consoles for years now. Granted, this method would be highly impractical for most end-users even if it were possible

Forgive my ignorance, I'm just trying to glean some knowledge by following the progress here.
 

Blahness

Member
Jan 11, 2014
14
31
0
While I'm not fluent in the required expertise to understand the bulk of this... could someone actually explain where the qFuse actually is. I know they are physical unlike a eFuse but are they located within the Snapdragon itself? (ie. Inside the chips wiring) or are they a simple fuse on the motherboard itself. I suppose it's the former... in which case outside of having a electron microscope and the tools to repair it would be highly unlikely to replace. Also, if this is the case what happens when you physically swap the Snapdragon on the board with a non-blown one Snapdragon from a different pre-blown S4? I mentioned along with someone else awhile back the possibility of say a modchip to bypass everything from the start like we've done with gaming consoles for years now. Granted, this method would be highly impractical for most end-users even if it were possible

Forgive my ignorance, I'm just trying to glean some knowledge by following the progress here.

I haven't done a lot of research but I'm pretty sure it's in the chip. And replacing the chip would be impractical even for experienced repair technicians. You could damage the rest of the board(s) or something wouldn't go right. Replacing transistors, physical fuses, and other like components is easier. But embedded processors is a whole other ballpark. At that point you should just go buy a dev phone haha.
 

ryanbg

Inactive Recognized Developer
Jan 3, 2008
855
1,735
123
movr0.com
I believe this may already be mentioned but if not, here goes nothing.

It seems that fastboot/aboot distinguishes between "developer mode" and retail is stored at the address 0x88F439C8. In my aboot, the value is default 0; in the aboot of the MJ7 bootchain that was posted by Surge, the value is nonzero. As aboot starts, it calls a check for the value of this code:
Code:
ROM:88E15BE8                 BL              is_dev_device
ROM:88E15BEC                 CMP             R0, #0
ROM:88E15BEE                 BNE             loc_88E15CA4
ROM:88E15BF0
ROM:88E15BF0 loc_88E15BF0                            ; CODE XREF: ROM:88E15CB2j
ROM:88E15BF0                 MOVW            R0, #0x7F7F
ROM:88E15BF4                 LDR             R1, =aWriteProtectionE ; "WRITE PROTECTION: Enable"
ROM:88E15BF6                 MOVT.W          R0, #0x7F
ROM:88E15BFA                 BL              print_to_screen_grey
ROM:88E15BFE                 BL              sub_88E00AE0
ROM:88E15C02                 MOV             R4, R0
ROM:88E15C04                 BL              sub_88E00AE8
ROM:88E15C08                 MOV             R1, R0
ROM:88E15C0A                 MOV             R0, R4
ROM:88E15C0C                 BL              fastboot_init__
ROM:88E15C10
ROM:88E15C10 loc_88E15C10                            ; CODE XREF: ROM:88E15C8Aj
ROM:88E15C10                 BL              udc_start
ROM:88E15C14                 ADD             SP, SP, #8
Code:
ROM:88E10170 is_dev_device                            ; CODE XREF: sub_88E0A2D0:loc_88E0A35Ep
ROM:88E10170                                         ; sub_88E1419C+714p ...
ROM:88E10170                 MOV             R3, 0x88F439C8
ROM:88E10178                 LDR             R0, [R3]
ROM:88E1017A                 BX              LR
As you can see, if the result is not equal to 0, it goes to another function:
Code:
ROM:88E15CA4 loc_88E15CA4                            ; CODE XREF: ROM:88E15BEEj
ROM:88E15CA4                 MOVW            R0, #0x7F7F
ROM:88E15CA8                 LDR             R1, =aModeDeveloper ; "MODE: Developer"
ROM:88E15CAA                 MOVT.W          R0, #0x7F
ROM:88E15CAE                 BL              print_to_screen_grey
ROM:88E15CB2                 B               loc_88E15BF0
The last branch goes back to calling function in the first code excerpt:
Code:
ROM:88E15BF0 loc_88E15BF0                            ; CODE XREF: ROM:88E15CB2j
ROM:88E15BF0                 MOVW            R0, #0x7F7F
ROM:88E15BF4                 LDR             R1, =aWriteProtectionE ; "WRITE PROTECTION: Enable"

There seems to be one reference as to where the data at this location is changed. Perhaps it's a secure method, I'm not sure (I also don't quite understand the TZ and calls made to it quite yet).
Code:
ROM:88E1021A                 MOV             R0, SP
ROM:88E1021C                 MOV             R1, R4
ROM:88E1021E                 LDR             R2, =unk_88F36AA8
ROM:88E10220                 BL              sub_88E0A2C4
ROM:88E10224                 LDR             R2, =dword_88F439C8
ROM:88E10226                 CMP             R0, #0
ROM:88E10228                 ITE NE
ROM:88E1022A                 MOVNE           R3, #0
ROM:88E1022C                 MOVEQ.W         R3, #0xFFFFFFFF
ROM:88E10230                 IT NE
ROM:88E10232                 MOVNE           R0, #1
To decode the logic after the subroutine is executed:
Code:
if r0 != 0
 r3 = 0
else
 r3 = -1

if r0 != 0
 r0 = 1

is_dev_device_flag = r0
r0 = r3
Remember that when the is_dev_device_flag is 0 it means that it is not a developer device.

Unfortunately the subroutine found at 0x88E0A2C4 is fairly convoluted. It'll take some more time to reverse it and see if there is any adaptable backdoor to put the device into dev mode for the current power cycle. Just wanted to share this to shed some light of if anyone has ideas.

Edit/note: I am also unsure if changing this flag will have any effect on unlocking the bootloader. It's possible that this flag is used later to enable fastboot commands

I'm pretty sure fastboot determines whether the device is a developer model or not through device serial number. I found how to modify this too, but not early enough in boot, and it might be a different serial. Use google translate but check this out
 
  • Like
Reactions: Brooklynsour

Blahness

Member
Jan 11, 2014
14
31
0
I'm pretty sure fastboot determines whether the device is a developer model or not through device serial number. I found how to modify this too, but not early enough in boot, and it might be a different serial. Use google translate but check this out

The article doesn't specify about separate serial ports/speeds/etc. It just shows how to flash an image using flashboot.
 
  • Like
Reactions: Brooklynsour

Top Liked Posts

  • There are no posts matching your filters.
  • 64
    Scroll down for recent updates;

    Has anyone ever heard more from h311sdr0id about his post (see here) to get more info about this "state" that allows you to flash MDK over ME7 in Odin? I'm curious to see if we can use that state, maybe in QDL mode to somehow either push an image to the phone or communicate with it using some methods/commands that E:V:A refers to on this page and a few pages after and before. It's also possible that we then might be able to use a modified unbrick.img (see here) to restore an MDK bootloader. So far those are the two ideas that I think have the best chance.

    Also in this thread I started with the intention of compiling the entire stock firmware for the Dev edition (OYUAMDK), I mentioned at the bottom that when flashing the stock MDK restore Odin tar on an ME7 phone users usually get a "SW REV. CHECK FAIL: FUSED: 3, Binary: 1" message meaning that your current fuse counter in aboot is set to 3 but the binary your attempting to flash is set to 1 so the flashing attempt will fail and I'm willing to bet if you're on VRUDMI1 and you attempt to flash the MDK restore you will get a similar message but the FUSED: value will be set to 4, you can see the counter upped in this post from jeboo here. However, with flashing the dev OYUAMDK aboot file on S4's with a ME7 bootloader users will receive a "SECURE CHECK FAIL: aboot" message instead, I don't know if we might be able to use dev OYUAMDK aboot file and bypass the fused counter entirely, since the dev edition has an unlocked bootloader and the fuse is an efuse, so software enforced, not a hardware enforced qfuse. If anyone wants to go into more detail, or wants to expand on these ideas we I can expand on this info or we can collaborate ideas in the Dev discussion thread.

    Other points to consider:

    • If you know how to use IDA pro, and can help with the base address of the binaries, that is probably our best bet to find a vulnerability in aboot, you can see jeboo and djrbliss discuss this a bit (here) and you can see Ralekdev show his findings here, also this gives the explanation of why you see the "custom unlock" boot screen that people constantly post about in the Q&A thread. Both of these threads along with djrbliss' blog discussing the S4 aboot vulnerability that lead to Loki (here), and exploiting the TrustZone (tz.mbn) on Moto's bootloaders (here) are good starting points in trying to find a new vulnerability.
    • If you know how to hexedit, then hexedit aboot.mbn from MDK, ME7, OYUAMDK, and MI1. You can see ME7 and MI1 are similar in both size and content, while MDK and OYUAMDK are more similar to each other in size and content. Obviously OYUAMDK differs from the others in the way it checks the recovery and boot partitions, (in djrbliss' blog on the S4 exploit he says "This bootloader differs between "locked" and "unlocked" variants of the Galaxy S4 in its enforcement of signature checks on the boot and recovery partitions.") but we are able to flash all bootloader partitions from the OYUAMDK firmware restore Odin file I made except aboot, so if you have any ideas on how we might be able to exploit any of that, please feel free to share.
    • If you do hexedit a dd'ed partition (if you copy mmcblk0p6 from your phone to your pc) you will see that its padded with zeroes at the end. You have to cut the padded zeros from the dd'ed image in order for the partition to be registered as a signed partition in Odin, etc. To do this, use Linux, open a terminal and type
      Code:
      sudo apt-get install hexedit
      then enter your password and hit enter. Then go to the folder that contains the partitions you want to hexedit (for instance type cd /home/Your user name folder/Desktop/S4partitionbackups/" where "your user name folder" is whatever your username is and "S4partitionbackups" is a folder you create on your desktop containing a backup of your partitions) If you don't have a back up of your partitions you can create them using something like the command below, substituting mmcblk0p6 and aboot.mbn with the partition(s) you are interested in.
    Code:
    adb shell su -c 'dd if=/dev/block/mmcblk0p6 of=/sdcard/backup/aboot.mbn'
    then
    Code:
    adb pull /sdcard/backup/aboot.mbn /home/Your user name folder/Desktop/S4partitionbackups/
    then
    Code:
    cd /home/Your user name folder/Desktop/S4partitionbackups/
    Code:
    hexedit aboot.mbn
    Quick guide on Hexedit controls/keys

    • shift+> will take you to the end of the hex file
    • shift+< will take you to the beginning
    • page up/page down it will take you up a page and down a page respectively
    • ctrl+c you will exit the hex file without saving any changes
    • esc+t you will truncate the file at the current location
    • ctrl+x you will save the file with all changes you have done.
    This is an example of a padded aboot.mbn, before hexediting, and prior to truncating the file a at the first "0" in the string "00 01" found between the end of the actual file and the padded zero's and repeating F's
    View attachment 2353922
    This is an example of a properly signed aboot.mbn after hexediting
    View attachment 2353923

    How to find start addresses

    First you have to open the selected bootloader with a hex file editor and look at the header, converting for little endian you can find the start addresses and offsets

    Code:
    [B]sbl1.mbn = 0x2a000000[/B]
    00000000   D1 DC 4B 84  34 10 D7 73  15 00 00 00  FF FF FF FF  ..K.4..s........
    00000010   FF FF FF FF  50 00 00 00  [COLOR=Red]00 00 00 2A[/COLOR]  40 72 01 00  ....P......*@r..
    00000020   40 41 01 00  40 41 01 2A  00 01 00 00  40 42 01 2A  @[email protected]*[email protected]*
    00000030   00 30 00 00  01 00 00 00  04 00 00 00  FF FF FF FF  .0..............
    
    [B] sbl2.mbn = 0x2e000000[/B]
    00000000   16 00 00 00  03 00 00 00  00 00 00 00  [COLOR=Red]00 00 00 2E[/COLOR]  ................
    00000010   40 51 02 00  40 20 02 00  40 20 02 2E  00 01 00 00  @[email protected] [email protected] ......
    00000020   40 21 02 2E  00 30 00 00  12 00 00 EA  5F 00 00 EA  @!...0......_...
    00000030   62 00 00 EA  65 00 00 EA  68 00 00 EA  6B 00 00 EA  b...e...h...k...
    
    [B] sbl3.mbn = 0x8ff00000[/B]
    00000000   18 00 00 00  03 00 00 00  00 00 00 00  [COLOR=Red]00 00 F0 8F[/COLOR]  ................
    00000010   20 20 04 00  20 EF 03 00  20 EF F3 8F  00 01 00 00    .. ... .......
    00000020   20 F0 F3 8F  00 30 00 00  D3 F0 21 E3  D3 F0 21 E3   ....0....!...!.
    00000030   00 70 A0 E1  09 02 A0 E3  00 D0 A0 E1  DB F0 21 E3  .p............!.
    
    [B] aboot.mbn = 0x88e00000 offset = 0x285[/B]
    00000000   05 00 00 00  03 00 00 00  00 00 00 00  [COLOR=Red]00 00 E0 88 [/COLOR] ................
    00000010   10 56 14 00  10 25 14 00  10 25 F4 88  00 01 00 00  .V...%...%......
    00000020   10 26 F4 88  00 30 00 00  06 00 00 EA  F0 38 00 EA  .&...0.......8..
    00000030   F6 38 00 EA  FC 38 00 EA  02 39 00 EA  08 39 00 EA  .8...8...9...9..
    
    [B] tz.mbn = 0x2a000000[/B]
    00000000   19 00 00 00  03 00 00 00  00 00 00 00  [COLOR=Red]00 00 00 2A[/COLOR]  ...............*
    00000010   C4 3A 03 00  C4 09 03 00  C4 09 03 2A  00 01 00 00  .:.........*....
    00000020   C4 0A 03 2A  00 30 00 00  09 00 00 EA  90 F2 9F E5  ...*.0..........
    00000030   90 F2 9F E5  90 F2 9F E5  90 F2 9F E5  84 F2 9F E5  ................
    
    [B] rpm.mbn = 0x00020000[/B]
    00000000   17 00 00 00  03 00 00 00  00 00 00 00 [COLOR=Red] 00 00 02 00[/COLOR]  ................
    00000010   38 57 02 00  38 26 02 00  38 26 04 00  00 01 00 00  8W..8&..8&......
    00000020   38 27 04 00  00 30 00 00  06 00 00 EA  1E 00 00 EA  8'...0..........
    00000030   2C 00 00 EA  39 00 00 EA  46 00 00 EA  53 00 00 EA  ,...9...F...S...
    EDIT: 2/01/2014 - Updated OP to include where we're at

    2/01/2014

    1. Figuring out what Hellsdroid's method was - Unfortunately this seems unlikely as of now (figuring out what he did that is) On the other hand, @TMcGrath50 and I discussed a method we thought to be similar to his starting around here and then I learned how to use ida better as time went on and recently disassembled that I9505 S4 USB repair tool. I have not done a thorough analysis of the pseudocode yet though. But even so, this method has never been done before (as far as I know) and 
in addition to assuming the information in the pic below is true, and we can in fact reset the emmc on our devices with Secure Boot 3.0 (would this be a way of getting around having to reset the Secure Boot bit in the pbl to "0"?) I still think this idea needs to be refined a bit before its worth exploring because some questions remain in regards to if it would even work in the first place. For example, when a JTAG solution was tested previously, the VRUAMDK aboot.mbn didn't flash on a device with VRUAME7 after all the partitions were wrote over with VRUAMDK partitions via JTAG, why? @jeboo may be able to help answer that.

    Also, it was previously questioned whether or not the flash programmer (8064 hex) would need to be signed or not. As I have two S4's one thats working and one in QDL QHSUSB dload mode, in doing some recent testing through usb (S4 to S4) I was able to get some info back about my bricked S4, namely that I had sent it the wrong hex file ( see the last line here) because the dmesg and last_kmsg logs say something to the effect of "the the cpu clocks cannot start because its configured for the wrong device" and the last line from the my pastebin post says "8660" among other things as well.

    Status - Unknown - More Research Required


    pCgmFhal.png


    2. Using a Developer edition S4 to unlock a retail S4 - So here's what we know, the dev kernel (boot.img) is flashable and will work with retail S4's, but the recovery.img and aboot will not. Flashing the dev recovery.img will succeed in Odin/Heimdall, but if you try to boot into recovery it will inform you that your device is "tampered" and and will void your warranty by setting the Knox warranty bit to 0x1. Before I discuss why aboot.mbn wont flash consider this; neither the Developer edition of the GS4 nor the Developer edition of the Note 3 has every received an OTA or a factory Odin tar. This is not by random chance. Every Developer edition owner has a unique MD5 for their aboot. If you couple this with the fact that Dev edition devices have retail stickers under their dev stickers, you will probably come to the conclusion that Samsung/Verizon/AT&T haven't released updates to dev devices because they would have to do it on a 'per device' basis, that or risk handing us a method to convert retail devices into developer edition devices. If the method by which Samsung uses device specific info to sign developer edition aboot partitions were discovered this may work, or if their method to determine if a device is a developer edition or consumer retail edition is similar to what Dan R (djrbliss) took advantage of then this could be a possibility.
    3,4,5,6, coming up....updating...this will be a long post...advance warning.

    Status - Possibly - More Research Required
    47
    Happy one year anniversary. I can't believe I wrote the OP one year ago today, I've learned so much since then, in fact im embarrassed to read the OP because reading it now I realize I didnt know much back when this thread started however ive learned a lot since then and thats mostly due to the contributions made in this thread and the people I have met here, so I just wanted to take a moment and say Thanks. :)

    #stillfightin
    37
    Any answer would just be a guess. My guess is ryanbg is feeling lonely on this project now...my hunch is that surge has moved on but the unsolved problem will bug him until it's solved, so his foot's in the door still... just a guess, I don't know either one personally. I think either one of them or any other dev is likely working on newer bootloaders... so maybe there's more effort on nc5 right now than on <mk2. Then again maybe a vulnerability is discovered for one of the older bootloaders and was patched in the newer ones.

    I'm sticking on mk2. My favorite ROM works best with the version for that bootloader, and if an unlock for a newer bootloader is ever available, I'll just upgrade at that point.

    Not moved on... just been busy and didn't have anything useful to contribute..until today anyways.

    I finally was able to re-patch the live kernel to allow insecure modules again. Meaning kexec and trustzone vulnerabilities are back on the table.

    The method I used to evoke the patch to the kernel is somewhat involved so I'll release it as a small apk or binary soon. For the time being this only effects vzw users, since I didn't check the att kernel.
    36
    Cripes, we used to self-police well enough in here, lately thats not the case. Lets get our crap together before we lose this thread. Everyone here is smart enough to know if their post is useful or not, grow up people. We're giving this all the we've got, be patient. Other devs and I are in constant communication, not by pm but mostly through other means. Listen I know some of you may be frustrated with my lack of posting new info but just know that there are watching eyes on this thread that we don't want. Take the OYUAMDK thread I posted in original development, Samsung knows about that thread and I know that for a fact. I went to Best Buy and asked a Samsung rep (in the Samsung dept/area) how dev edition devices could get updates and the guy had no idea who I was but I started talking to him and he casually got more friendly and told me "Hey listen, I know theres no official dev stock images but check the XDA threads" then told me exactly where to check and said Samsung doesn't officially give dev device updates but knows they can be made/extracted, he said "someone already extracted it for the S4" so he essentially directed me to my own thread without knowing who I was. So theres a reason some stuff isn't posted here, please understand that. Also some of you are worried since there are no updates on kexec, I can confirm its being worked on.


    TLDR - Hold your horses

    Edit: Also we're working on some stuff today, I'll post an update tonight.
    36
    Ok that's it. Its become apparent to me that far too many people are under the impression that the "bootloader" is a single entity, and that it is just too complex to understand. This is unacceptable to me. I had no idea what a bootloader was before I got this S4. Im going to detail the process first with a general overview, then again in more detail. Plus I dont see the current threads on this topic that include all we know, like the hexagon modem/kernel and the function of the tz and sbl2 are way over generalized. And discussion of the device cookie is completely missing. Ill post it in a new thread thread and link it here when im done.

    Sent from my SCH-I545 using XDA Premium 4 mobile app
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone