If we are serious about unlocking the bootloader - Verizon Samsung Galaxy S 4

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
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
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

---

This really sucks. Looks like the dev that knows how to downgrade from ME7 to MDK is locked up for a while.
h311sdr0id is currently indisposed and will probably not be getting out anytime soon. He has court next month. If anyone is interested in writing him, please send a message to his account and I will give you his info.
- Mrs. h311sdr0id

---

Travisdroidx2 said:
This really sucks. Looks like the dev that knows how to downgrade from ME7 to MDK is locked up for a while.
h311sdr0id is currently indisposed and will probably not be getting out anytime soon. He has court next month. If anyone is interested in writing him, please send a message to his account and I will give you his info.
- Mrs. h311sdr0id
Click to expand...
Click to collapse
Man... Samsung's really cracking down...
Sent from my SCH-I545 using XDA Premium 4 mobile app

---

Is it confirmed this is Samsung's doing?
Sent from my SCH-I535 using XDA Premium 4 mobile app

---

Travisdroidx2 said:
This really sucks. Looks like the dev that knows how to downgrade from ME7 to MDK is locked up for a while.
h311sdr0id is currently indisposed and will probably not be getting out anytime soon. He has court next month. If anyone is interested in writing him, please send a message to his account and I will give you his info.
- Mrs. h311sdr0id
Click to expand...
Click to collapse
WOW, this is news to me! It explains why I haven't seen him update his VS3 rom in awhile.
@Nicgraner
Sarcastic joke, or are you serious?

---

I noticed in the note 3 part of the forum a member started a petition to unlock the boot loader. Can someone start one or combine with the note 3 page?

---

Petitions just turn into complaint threads. I wanted to give this a last shot, so I posted alot of info and plenty of references with the intent that even less experienced s4 users could learn and eventually contribute to helping unlock this bootloader. I also offered some ideas as a starting point. Ive never joined irc's or google talk sessions with others in trying to solve things, I mostly read and learned on my own and im by no means a dev. But I don't think we can unlock this unless we stop complaining and one-uping each other and start working together. I wish that people would stop asking if devs are still trying to unlock this, or being pessimistic about it and start being part of the solution by reading a little and then helping contribute to a solution. All suggestions are welcome. But if you don't know what comprises the "bootloader", learning the flashing order of the partitions at least uptil tz.mbn would benefit you greatly.
P.S.
Just because your not a dev doesn't mean you cant help, most devs are knowledgeable about their devices, but some don't know much beyond how to use android kitchen.
Sent from my XT912 using xda app-developers app

---

Surge1223 said:
Petitions just turn into complaint threads. I wanted to give this a last shot, so I posted alot of info and plenty of references with the intent that even less experienced s4 users could learn and eventually contribute to helping unlock this bootloader. I also offered some ideas as a starting point. Ive never joined irc's or google talk sessions with others in trying to solve things, I mostly read and learned on my own and im by no means a dev. But I don't think we can unlock this unless we stop complaining and one-uping each other and start working together. I wish that people would stop asking if devs are still trying to unlock this, or being pessimistic about it and start being part of the solution by reading a little and then helping contribute to a solution. All suggestions are welcome. But if you don't know what comprises the "bootloader", learning the flashing order of the partitions at least uptil tz.mbn would benefit you greatly.
P.S.
Just because your not a dev doesn't mean you cant help, most devs are knowledgeable about their devices, but some don't know much beyond how to use android kitchen.
Sent from my XT912 using xda app-developers app
Click to expand...
Click to collapse
On that note, I thank you for developing the OYUAMDK FW. I have not tried it yet just waiting for another guinea pig or at least have a backup device to swap SIMs so that I can have something to use.
Samsung has their first Dev Conference today in San Francisco and hopefully there will be Devs there to get better insight on Samsungs position on ROMs and bootloaders etc...

---

Awesome analysis Surge, that hellsdroid thread piqued the interest of several devs, including myself. Unfortunately I believe his thread was a bit misleading, which may explain why he closed it. There has been no demonstrated method to boot vulnerable BLs (ie, loki-fiable aboot) once the qfuse has been incremented.
Some of us are looking at the binaries, but no exploit has popped out yet. I did find it interesting they updated SBL1 in the latest OTA, that may be a hint towards something..

---

jeboo said:
Awesome analysis Surge, that hellsdroid thread piqued the interest of several devs, including myself. Unfortunately I believe his thread was a bit misleading, which may explain why he closed it. There has been no demonstrated method to boot vulnerable BLs (ie, loki-fiable aboot) once the qfuse has been incremented.
Some of us are looking at the binaries, but no exploit has popped out yet. I did find it interesting they updated SBL1 in the latest OTA, that may be a hint towards something..
Click to expand...
Click to collapse
So I just started analyzing my emmc back up (took the entire 16gb mmcblk0 to make sure I didnt miss anything) have you looked through the emmc? I think the modem and apnhlos are more involved in the security checks than we previously thought. Plus these tima, tzapps, and apps.mbn etc files may have contributed to the failure of flashing the mdk aboot on the me7 device you guys were attempting, is there a reason you guys didnt include the mdk modem and apnhlos in your attempt to restore the mdk bootchain? I flashed the dev bootloader with the exception of the dev aboot, boot and recovery using 3 heimdall packages. The first contained the modem, apnhlos and sbl1-3. The second contained rpm and tz, and the third contained boot and recovery (as expected this package failed) the result was my device was now on the dev bootchain with the exception of aboot, boot and recovery and confirmed these results via hexedit. So I think we can rule out sbl3 being the main culprit in checking the fuses when trying to flash a new aboot, also I dont get the "fused 3 binary 1 aboot" failure message when I attempt to flash aboot anymore, just the "secure check fail aboot" message. I definitely think its worth looking into using the dev tz.mbn to find an exploit because I no longer ever see the "samsung custom unlock" boot screen and my device believes its unmodified, and reports its official. My device is so far from unmodified its ridiculous. That means the dev tz.mbn partition I flashed is behaving as if my s4 is a dev edition (see ralekdev's post I linked to in the OP)
Sent from my TouchPad using xda app-developers app

---

Surge1223 said:
So I just started analyzing my emmc back up (took the entire 16gb mmcblk0 to make sure I didnt miss anything) have you looked through the emmc? I think the modem and apnhlos are more involved in the security checks than we previously thought. Plus these tima, tzapps, and apps.mbn etc files may have contributed to the failure of flashing the mdk aboot on the me7 device you guys were attempting, is there a reason you guys didnt include the mdk modem and apnhlos in your attempt to restore the mdk bootchain? I flashed the dev bootloader with the exception of the dev aboot, boot and recovery using 3 heimdall packages. The first contained the modem, apnhlos and sbl1-3. The second contained rpm and tz, and the third contained boot and recovery (as expected this package failed) the result was my device was now on the dev bootchain with the exception of aboot, boot and recovery and confirmed these results via hexedit. So I think we can rule out sbl3 being the main culprit in checking the fuses when trying to flash a new aboot, also I dont get the "fused 3 binary 1 aboot" failure message when I attempt to flash aboot anymore, just the "secure check fail aboot" message. I definitely think its worth looking into using the dev tz.mbn to find an exploit because I no longer ever see the "samsung custom unlock" boot screen and my device believes its unmodified, and reports its official. My device is so far from unmodified its ridiculous. That means the dev tz.mbn partition I flashed is behaving as if my s4 is a dev edition (see ralekdev's post I linked to in the OP)
Sent from my TouchPad using xda app-developers app
Click to expand...
Click to collapse
So does this mean if I flash your OUYAMDK ODIN image my Dev Ed phone will think its OOB without custom unlock?

---

Theres a post in that thread where a dev owner achieved those results as well he only flashed a couple partitions, you can get more details there
Sent from my XT912 using xda app-developers app

---

thread cleaned of selling and or trading and the ensuing discussion.
Use Swappa.com for that.

---

neh4pres said:
Is it confirmed this is Samsung's doing?
Sent from my SCH-I535 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I've always known Samsung to be like Google when it comes to consumer development. Google supports and encourages the freedom to modify Android, it being open source in the first place. Samsung doesnt mind, themselves; it's carrier security teams that require companies like Samsung to create their own methods of locking down the device for the average user. I'm quite impressed with the Knox bootloader and secure VM app. It may not be done anytime soon, but it can always be cracked. But, the fact that this code is so hard to modify, thanks to carriers, is actually a good thing.

---

Hey guys I am totally supporting this thread. Unfortunately i have no experience in this kinda stuff or else i would help. Good luck!

---

Much like most of us. Still out there Surge?
Sent from my SCH-I545 using xda app-developers app

---

Still here I use tw based roms so my motivation for wanting to unlock this isnt for AOSP or custom kernels. Its just the challenge, that and out of hate for Verizon lol. The Droid X sitting on my desk is a painful reminder of defeat. Cant let them win twice..
Sent from my SCH-I535 using xda app-developers app

---

Surge1223 said:
Still here I use tw based roms so my motivation for wanting to unlock this isnt for AOSP or custom kernels. Its just the challenge, that and out of hate for Verizon lol. The Droid X sitting on my desk is a painful reminder of defeat. Cant let them win twice..
Sent from my SCH-I535 using xda app-developers app
Click to expand...
Click to collapse
No doubt... can't believe i left my G-Nex for this locked down thing... unfortunately i had to craigslist an upgrade and couldn't snag one of these when they first came out.

---

i am also in full support of this thread! running stock MJ7 never rooted my phone once, i have taken all the OTAs i'm really crossing my fingers that someone can break this thing so i can finally root and install a stock google rom, i hate TW so much! with all the headache with safestrap and junk on the MI1 i was not wanting to root my device just to have a half assed recovery.

---

Does it mean anything that my S4 is still showing unlocked and custom? Should it still show that even if it is in fact locked?