yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S 4] Surge1223:
I know, I have two ideas I want to test, and i'll test them myself since I have two S4's and one of them is in QDL mode anyways. One is booting to sd card mode (Ramdump mode?) and writing over the emmc. Second idea is to actually create an sdcard boot image that might not only potentially get us important info we could use about the partitions, but even if it doesn't work we might get a debrick.img out of it. It might also give us a more clear idea what's checking aboot, and where, I know sbl3 has to approve, but something else has to be checking it as well. Below there are pass/fail messages that lead me to believe an sdcard solution maybe possible.

1. We need to create the correct rawimage0.xml, partition0.bin, patch0.xml, and partition_boot.xml files etc files. In order to do that we would need a signed MPRG8690.hex file....that might be the hard part. I'm looking at sbl1 and sbl2 to see if I can figure out a way for the phone to accept the a modified MPRG8690.hex as signed.

2. I need to know the mbr/ebr/gpt system info. Someone will probably have a partition0.bin file. I have attached some useful tools/documents and scripts. A lot of these are not mine and I still have to give people credit, but i'll do so later. All of the rawimage0.xml, patch0.xml, and partition_boot.xml files need to be edited. The ones that say copy next to them are a WIP and meant to be edited. Let me know if you make an edits etc.

TLDR- I need help getting these files right, find all mistakes, edit them and let me know.

Download the tools here: FU_VZW
[Verizon Samsung Galaxy S 4] antwong45157:
keep up your work surge, I have faith! share your work everywhere!
[Verizon Samsung Galaxy S 4] :
No it does not mean anything. I can only assume your rooted. After rooting MJ7 I show unlocked and custom. Boot loader is still locked though.
[Verizon Samsung Galaxy S 4] Mistertac:
You guys are awesome, wish I could help in someway. Keep up the great work!
[Verizon Samsung Galaxy S 4] saltytaco:
Well with Option 1 I'd doubt the phone would accept the hex file as signed. I guess it'd be nice to try, but I have some doubts.
[Verizon Samsung Galaxy S 4] Surge1223:
Its made using sbl1 sbl2 and sbl3. Comparing the original to the ones from different phones might tell us how we should edit it. Hell, we've managed to figure out how to make partitions from dumps signed so i don't imagine it would more difficult than that.
[Verizon Samsung Galaxy S 4] trook:
20 bucks says you crack this beeotch the day after I get so mad I throw it in my fireplace. We really appreciate all who haven't given up, as well as those who tried and just couldn't get it, you give us hope and we thank you for your countless selfless hours.
[Verizon Samsung Galaxy S 4] Steedent:
seeing all this work being done gives me hope in civilization! i check this thread a few times a day to see the efforts being mad, im eager to see the day i read, "Bootloader Unlocked!!" i know it'll happen soon enough, i wish i could contribute with the efforts! Im curious, what is making this bootloader more difficult to unlock vs others out there? is samsung/verizon getting more strategic in locking it up? i hope this message doesnt clutter up the thread, im just curious... i know you're all busy, so if theres no time to answer me, i definitely understand!
[Verizon Samsung Galaxy S 4] xs11e:
Personally, I doubt we'll ever see an unlocked bootloader on the S4, they've been working on that since the phone was introduced with no success.

Fortunately, we did get the LOKI workaround which allows us to root and flash a different recovery along with custom ROMS but Samsung closed that loophole with an update, the devs came back with SafeStrap which allows us to flash some custom ROMs, it really isn't as good a workaround as LOKI but it looks like that's all we're going to get and I'm sure Samsung will stop that with the next update or the one after that.....

Now for the real doom and gloom, I believe we'll see future phones completely locked with no possibility of rooting or changing any part of the stock software.

I really hope I'm wrong but I don't think I am, sorry.

Meanwhile, I'll keep hoping while running my LOKIed S4 with CyanogenMod and I'm grateful I've learned one important thing, NEVER ALLOW AN OTA UPDATE before checking it out here to see what it breaks!
[Verizon Samsung Galaxy S 4] saltytaco:
Oh ok. :) I'm gonna see what I can think up.
[Verizon Samsung Galaxy S 4] th3bl3d:
this post is pretty darn depressing to read, i say if it has been unlocked bfore it can be unlocked again. all they did was update the security hole, well in the IT world there is ALWAYS another security hole we just haven't been able to find it yet....keep up the good work guys.
[Verizon Samsung Galaxy S 4] Surge1223:
I know the bootloader will probably never be unlocked unless we get a leak. In my mind I don't see it as "we did get the LOKI workaround.." We didn't do anything, djrbliss gifted it to us. In the mean time ill continue to seek all avenues available to find an exploit. It already took me months to figure out how to use ida correctly, then figure out how and what base addressess correspond to which binaries and thats still a gigantic WIP. Along the way I learned what where and how the bootloaders worked, and now im just trying to get more ideas to try. I've collected Qualcomm pdfs, some of which I don't even think E:V:A has, and read through them. I realize how the emmc might be able to help us and I think its worth exploring. I know not many people know how to use QPST, or whatever but I'm only posting what I'm doing here so that if people find a fault in what im doing they can help me correct it or recommend alternatives. Also I didn't take the OTA. I have an MDK phone, but having an MDK phone doesn't mean we should just give up.
[Verizon Samsung Galaxy S 4] Jraider44:
Surge,

Guys like you are what make this community so great... Keep up the good work...
[Verizon Samsung Galaxy S 4] jhasty01:
I'd like to know more about this...
[Verizon Samsung Galaxy S 4] Surge1223:
Ok, enough with the off-topic stuff. Especially about defending Verizon and their actions. Also, the developer edition doesn't have a stripped down version of SDM.apk or anything. They literally cannot push updates to Developer devices because they know that we would be able to unlock retail devices if we knew how they modified Dev devices with device specific info. Also the qfuse for FORCE_TRUSTED_BOOT is blown on both developer edition and retail S4's. So developer devices are initially locked as well and get unlocked because some device specific info is used to make device specific hash values in pbl, tz, irom or other memory regions impossible for us to maliciously make vulnerable. That's why each developer edition S4 has a unique md5 for aboot. This explains why developer devices don't get updates, why they can still be locked by retail firmware, and why developer devices have retail stickers underneath the developer stickers. Yes, that does mean theoretically you can turn retail devices into developer devices. This scenario unlikely at this time though, since we don't know the method or area the device specific info is sent to or permissions to access those areas even if we did. However, Dan R's TZ exploit is more than a good enough start in exploring if we can accomplish that.

In actually relevant news here's

viewmen

that I compiled for the S4. This contains the ndk source as well but since its already compiled for the S4 you can just use

viewmem

without having to compile/build it since I already took care of that. Download

viewmem

for the S4 here

---------

Please

don't publicly post data you find from the lower memory regions, as that can both lead to trouble for you but far worse it could tip off Samsung/Verizon to anything we might find useful.
[Verizon Samsung Galaxy S 4] sokrboot:
One of the later posts on the knox thread a guy mentions PBL then SBL then a "3rd type" of bootloader that is write protected and cant even be JTAG'd. This is something we already know right?...just being described differently than the way we do here bc the topics are different?

http://xdaforums.com/showthread.php?t=2486346

[Bounty] Reset KNOX counter to 0x0 (UPDATE- $3030)
[Verizon Samsung Galaxy S 4] gnubian:
Pretty sure he's just blowing smoke.....
[Verizon Samsung Galaxy S 4] scryan:
Probably read Jeboo's post on the kernel exploit and was like

"BOOM! EXPLOIT!

Where is the bootloader unlock buttin?"

TBH.
[Verizon Samsung Galaxy S 4] jjppott:
Did you guys see this thread: http://xdaforums.com/showthread.php?t=2621750 which references this: http://forum.gsmhosting.com/vbb/f672/easy-jtag-1-0-99-0-new-year-new-revolution-solution-repair-rebuild-emmc-1769456/ ?
[Verizon Samsung Galaxy S 4] jeboo:
Interesting, but I dont see how it will help reset qfuses...
[Verizon Samsung Galaxy S 4] gnubian:
I'm kind of confused...so we can downgrade via jtag? As hellsdroid said he figured out?
[Verizon Samsung Galaxy S 4] jjppott:
I was hoping someone that knew more would be able to determine that, but from what I can tell it looks like we probably can.
[Verizon Samsung Galaxy S 4] gnubian:
Doesn't do us much good. Unless someone (experienced and reputable) offered the service at a reasonable price....The wait time would no doubt be ridiculous though.
[Verizon Samsung Galaxy S 4] jjppott:
I would agree, it is definitely not ideal, but its still nice to know that at the end of the day there might be an option (not that I have the knowledge or the ability to use jtag). I certainly hope the Surge's and everyone else's hard work pays off and we get a solution that most everyone can use.
[Verizon Samsung Galaxy S 4] gnubian:
For sure. Hopefully jeboo hashcode and surge are making some more progress behind the scenes.
[Verizon Samsung Galaxy S 4] scryan:
Uggg, feel like I am going to show some ignorance here, but...

Wasn't there talk here about some for of soft jtag or whatever being possible or potentially possible with the device?

I remember discussion of the PS3, and how it is basically jtagged but through an extra circuit or something that allows it to be done over a USB cable? Someone then mentioned that S4 had similar... I though Surge had even been able to work with it but didn't really know what to do with it once he got it to work?

I know nothing of PS3 hacking or jtag... so yeah.

I'm still curious if Hash has been able to look at Kexec, and if he should most likely be able to do it. I know when I read up on android + Kexec I found at least one case of them having the ability to add a kexec modual but never being able to get it to work enough to use, issues of instability, ect...

Hoping that Hash has the familiarity to make it work on the S4, curious how confident he is/should be...
[Verizon Samsung Galaxy S 4] gnubian:
I think you are referring to h3llsdroid. He could jtag an S4 into a state where odin would allow a backwards flash to mdk. Even stated he had "it down to an art." He said he was willing to do it for developers for free as they needed their devices to be able to develop, test, etc. However he is currently incarcerated I believe.
[Verizon Samsung Galaxy S 4] scryan:
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."
[Verizon Samsung Galaxy S 4] KaratemanTJ:
So with this eemc tool one could then flash mdk to the emmc and that's that? Aren't there still qfuse checks or am I missing something entirely?
[Verizon Samsung Galaxy S 4] maxjivi05:
There's a dev on the Note 2 who made away to flash the bootloader from the SDCARD by jumping a couple pins at startup after the bootloader img he has made for the note 2 is written to the sdcard now I know this is about the S4 but with them both being locked down in a similar fashion would that allow downgrading and unlocking?
[Verizon Samsung Galaxy S 4] gunz.jones:
That's how the Rezound ended up being forced open with an insecure boot image as well. I'm not a programmer and mostly just read over what everyone is doing with a loose understanding, but it seems a viable option. The only problem is that jumping pins can cause shorts and bricks just like bad software. The developer for such a trick would have to have spare phones or be very lucky. You've never had a time at unlocking a phone unless you've had the pleasure of timing the pin jump on a Rezound.

HyperDriven MK2
[Verizon Samsung Galaxy S 4] maxjivi05:
He has the pins timed to 3-5 seconds and has images of what pins. Maybe I'll try it when I get a SDCARD adapter to write the img. Hmm...
[Verizon Samsung Galaxy S 4] jeboo:
We've been able to do that with the riffbox jtag for a long time..Unfortunately it doesnt bypass any of the restrictions..
[Verizon Samsung Galaxy S 4] awskier08:
not sure if this is relevent..

http://threatpost.com/researcher-un...tloader-for-att-verizon-android-phones/100757
[Verizon Samsung Galaxy S 4] MehStrongBadMeh:
Wow, this essentially offers the same benefits as the loki exploit (custom kernels and recoveries) if I am reading it right.
[Verizon Samsung Galaxy S 4] gunz.jones:
Should Dan release the exploit for use one it's perfected, it would be great. Otherwise, the teams on it might be trying the same things. *fingers crossed* Hopefully not too long now.

HyperDriven MK2
[Verizon Samsung Galaxy S 4] JLow0214:
Thats because this is the article for when loki came out look at the date.... may 2013

Sent from my SCH-I545 using Xparent Skyblue Tapatalk 2
[Verizon Samsung Galaxy S 4] MehStrongBadMeh:
I am an idiot, no idea how I missread the date
[Verizon Samsung Galaxy S 4] gnubian:
Um. Yeah. Super fail.
[Verizon Samsung Galaxy S 4] kirch21:
Bummer lol
[Verizon Samsung Galaxy S 4] Surge1223:
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
[Verizon Samsung Galaxy S 4] Blahness:
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?
[Verizon Samsung Galaxy S 4] Surge1223:
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.
[Verizon Samsung Galaxy S 4] cyrushehe:
<3 You're fantastic.
[Verizon Samsung Galaxy S 4] Blahness:
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:

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

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:

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:

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).

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:

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
[Verizon Samsung Galaxy S 4] Surge1223:
Dude awesome job! Im working on determining that now taking apart the TZ...
[Verizon Samsung Galaxy S 4] Blahness:
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.
[Verizon Samsung Galaxy S 4] NighthawkXL:
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.
[Verizon Samsung Galaxy S 4] Blahness:
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.
[Verizon Samsung Galaxy S 4] ryanbg:
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
[Verizon Samsung Galaxy S 4] Blahness:
The article doesn't specify about separate serial ports/speeds/etc. It just shows how to flash an image using flashboot.
[Verizon Samsung Galaxy S 4] Walter.White:
I'm gonna fire up Ida pro once I get home. Which aboot are you using? And what was your config like on Ida?
[Verizon Samsung Galaxy S 4] Blahness:
MI1, 0x88e0000 loading address, 0x28 offset if I remember correctly

I set the ARM device to Any in the Processor Options
[Verizon Samsung Galaxy S 4] Walter.White:
Can you please upload or link to that aboot?
[Verizon Samsung Galaxy S 4] Blahness:
I'll have to do it in a few hours.
[Verizon Samsung Galaxy S 4] Surge1223:
Just a friendly reminder: this thread gets over a thousand views a day... lately more. Please be mindful of what you post publicly. Remember theres always irc, pm's, and hangouts. Were not at that point yet but firgured i should post this since we're flirting with the line, also remember Kitkat is coming soon.
[Verizon Samsung Galaxy S 4] michaelg117:
I don't mean to stray off track but I just feel the need to thank everyone that I'd actively working to fix this problem, it will be a great help for everyone in the S4 community.
[Verizon Samsung Galaxy S 4] Blahness:
MI1 aboot.mbn: https://www.mediafire.com/?ydae3s8e5vdlelb
[Verizon Samsung Galaxy S 4] jeboo:
As was mentioned, they are physically inaccessible. As for our purposes, they are accessed via the QFPROM @ 0x70000 (described in djrbliss' motorola essay). They are accessed directly, I have some of the important qfuses mapped in my IDA. There are also some qfuses accessed in PBL if I recall correctly..I'm currently on the road, but I'll be back home thurs.

Btw, for those of you getting familiar with IDA, if your copy has python support then you can use a good buddy of mines awesome loader. He posted it @ http://xdaforums.com/showpost.php?p=45783809&postcount=199 . Allows you to load all the relevant partitions into one big IDB, I think we left SBL1 out at the time because the ME7 update didnt change it.
[Verizon Samsung Galaxy S 4] Surge1223:
python.plw and python.p64 work for me so its already in my plugin coctail lol. He did do an awesome job.
[Verizon Samsung Galaxy S 4] ryanbg:
I sent you the wrong link! Sorry here run it through Google Translate.

File: mt_devs.c

__init int mt_board_init (void)

{

uint64_t key;

# If defined (CONFIG_MTK_USB_UNIQUE_SERIAL) | | defined (MTK_SEC_FASTBOOT_UNLOCK_SUPPORT) / / use the serial number or use the "0123456789ABCDEF" open and close the configuration

key = get_devinfo_with_index (13);

key = (key << 32) | get_devinfo_with_index (12);

# Else

key = 0;

# Endif

if (key! = 0)

get_serial (key, get_chip_code (), serial_number); / / get cpu chip id

else

memcpy (serial_number, "0123456789ABCDEF", 16);
[Verizon Samsung Galaxy S 4] cyrushehe:
Any kind of update on whether or not there has been progress would be nice right about now. :?