yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S 4] TMcGrath50:
On h311sdr0id's method

I've been meaning to comment on this for a long time. h311sdr0id suggested using the GS4 JTAG. JTAG is a dark, evil place. You will brick your phone. Or at least, I've bricked a phone trying to implement JTAG.

Essentially, this is what it does: JTAG is a hardware implementation that allows a manufacturer to hard reset a device and install its stock firmware back on the device. It puts the phone in software "no man's land," waiting for you to push an image to it. In short answer, probably, it would probably be possible to exploit the JTAG to reset the device and push MDK from QDL. BUT I've never seen anyone try to implement a JTAG exploit around a qfuse. That qfuse would complicate things exponentially... without an unbrick.img and a modified MDK tar, I have no clue how to implement it. Surge, can you get the signed 8960_msimage.mbn? If we could unbrick with the signed version, it might be possible.

My story: I use to have a Droid Charge, and a little bit of knowledge in electrical engineering. JTAG is a hardware piece, which requires hooking up a circuit to reset the phone. I had my circuit, it exploited, and then got stuck in QDL. I didn't have any unbrick method at the time, and the bootloader was still uncracked. Since then, the bootloader has become unlocked, so I could probably find a way to push an old firmware to the phone to get it up and running, but then I got a GS4 and gave up.

Now that being said, h311sdr0id claims to have pushed it into JTAG mode and brought it back into MDK. I suppose he didn't trip qfuse. No one's heard from him in a long time though. But I'm not sure how he implemented it--did he use a reset circuit to bring it to JTAG, like they did here: http://xdaforums.com/showthread.php?t=1000175 Or did he use a soft circuit parallel? There's no telling. But either way, JTAG is no place that the lay programmer should be. Even if we used his method and could successfully push MDK, I'd imagine there might be 11 people with this phone who could take advantage of it.

---------- Post added at 01:39 AM ---------- Previous post was at 01:34 AM ----------

Everyone please see the link I put in that post. It shows the JTAG process for the Captivate. My Charge had a similar method--you had to use a hard (physical) circuit to exploit JTAG.

Surge, everything I said in the above post was assuming the JTAG process was similar; that you needed a hard circuit and EE skills. But that being said, there are some devices where JTAG can be reset with a soft (programming) circuit. All devices have JTAGs. My PS3, for example, has a soft circuit. If the bootloader on it were unlocked, you could stick that thing in JTAG mode from your computer. My TV's JTAG, however, requires a hard circuit. If this phone would only require a soft circuit, one skilled programmer could make a tool that would exploit it and push MDK in Odin....

But my old Charge required a hard circuit, just like the captivate. It would seem Samsung likes hard JTAGs. And if that's the case, I wouldn't focus efforts too much on that approach, it's just not universal enough.
[Verizon Samsung Galaxy S 4] Surge1223:
Im working on getting the 8960_msimage.bin. Problem is you need the right version of qpst and the right xml files that i mentioned/attached earlier. From what ive read, qpst should be able to communicate with the phone in qdl and rewrite partitions. Im pretty sure that a soft circuit software implementation exists for the i9505 see here ( http://forum.legija.net/showthread....-galaxy-S4-(i9505-and-similar)-via-USB-Cable?) otherwise how would that be possible?

With that being said, I believe you bring up a good point. We need to test debrick.imgs before we can test anything. Maybe I should start a WIP thread on the side to create Debrick.imgs while we continue to do the hard research here.
[Verizon Samsung Galaxy S 4] TMcGrath50:
Wow, that thread was really interesting. Did you notice that it was for i9505, and h311sdr0id comment on the forum and asked if it would work for I545? That thread must have been his inspiration for trying to apply that same method to I545.

That being said, you're right. It looks like you can use a soft method to put the phone into JTAG mode. That's phenomenal news, if someone knew how to do it. It looked like h311sdr0id was really close if he didn't actually succeed. But if we could get the phone into JTAG mode, we could probably get the phone into QDL mode and push commands via E:V:A or some other method to install a modified MDK.

But yes, we would absolutely need the debrick.imgs before we could really count on that idea. I'm not sure what JTAG mode is like on the GS4, but on my old phone, JTAG'ing the phone put it into a hard brick mode, and you HAD to have the debrick.imgs to restore it. JTAG mode literally bricked the phone. But once we had those imgs, we could get it into QDL mode and flash a bootloader from there. (I never did that, like I said in my old post). JTAG'ing I545 might put it into a hard brick that requires a debrick.img, though h311sdr0id seemed to get it out and back to MDK.

So we have two options: 1) Get a hold of h311sdr0id, and ask him how he implemented JTAG, or 2) start a WIP thread on the side for getting the debrick.imgs and wing it ourselves.
[Verizon Samsung Galaxy S 4] Surge1223:
Yeah, the first time I read that I came to the same conclusion and was suprised when I saw his name. Since h311sdr0id is locked up I guess we'll have to start option 2. Ill start a thread tonight or tomorrow.

P.S. - I took a "deeper" look into that i9505 debrick .exe and noticed it uses a MPRG8064.hex and 8064_msimage.bin when its executing. I thought the international version had similar specs to ours? IDK but maybe I should be trying to use a 8064_msimage.bin instead of 8960_msimage.bin..
[Verizon Samsung Galaxy S 4] TMcGrath50:
Good point. I'm not really sure. I would think that the i9505 would be identical. Where did you get the impression that you should use the 8960 images?
[Verizon Samsung Galaxy S 4] Surge1223:
A lot of reasons, one being our board is msm8960. But ive gotten confirmation its 8064 from some reliable info.
[Verizon Samsung Galaxy S 4] th3bl3d:
we need a donation thread for bootloader unlock on mj7 that should help speed things up :)
[Verizon Samsung Galaxy S 4] enfurnic:
Agreed
[Verizon Samsung Galaxy S 4] Fu5ion:
I wish the other one hadn't gotten locked up. Imagine how big it'd be by now.
[Verizon Samsung Galaxy S 4] TMcGrath50:
Surge, I've been looking into a JTAG exploit, and this might be a lot more promising than I thought. It absolutely depends on the debrick.imgs, though. And whipping out a modified MDK image to push. Maybe using E:V:A. (I know nothing about that, but it's a method you brought up to pursue.) I've gotta figure out how he got around the qfuse, though. It seems like the method would trip it every time...

But I've confirmed that there *could be* a soft circuit JTAG on all GS4 models. That's great news, but it means that if we can find an exploit, we'd have to build an executable, using ODIN, to flash this stuff. It would, most likely, end up being far too long and risky of a process to leave to simple directions.

More news will come as my investigation deepens.
[Verizon Samsung Galaxy S 4] Surge1223:
Im glad you said that because i was just going to post that i needed help building an .exe file. ill update this post in a little bit

Update:

Okay I think I have the files we need for building the executable, this executable at this point needs to prove it can debrick a phone before we can even think exploits. My MDK is in QDL mode, I intentionally put it there and have the means to JTAG it later if needed (plus I don't use it on a daily basis I use my razr and S3 more often). Now I'm going to have to ask someone for a debrick image because:

1. I don't trust my usb ports

2. My attempt at using my own debrick image didn't work

What this means:

We need someone who is more knowledgeable at reverse engineering/ can help build an .exe file that will execute files in a certain order or way (this might not be necessary as I can probably learn how to do it tonight after doing some research but if someone is good at both reverse engineering and building .exe's it'd be helpful.)

I need someone on MDK with an MDK non-hlos and modem (doesnt matter if its a custom rom or not though) to build a debrick image and they will have to have a linux machine (or live cd) and I can give them instructions, ive asked people for this before but this time its going to be a larger file just to make sure (probably 500MB). Note: You will be giving me some personal information if we use this method, but I'll remove it and use my own efs I have backed up so no worries and I promise I wont repost/look into your info (ill delete it immediately).

If you fit the profile of either of the above PM me.
[Verizon Samsung Galaxy S 4] FordNate:
you know coming from HTCville i learned very little about the inner workings n files passed through the bootloader but learned S-on S-off meaning. Just be lucky y'all never had to do the wire trick to gain S off (security flag protocol). I would love a good tutorial on the workings of a bootloader though. I'm just glad i havent had to do a wire trick hold for 10 seconds n hope that did it if not it was a reset and do the whole process again. btw is there a way to do a wire trick like on Samsungs? Htc was popular for em
[Verizon Samsung Galaxy S 4] ohbuckeyeman:
I wish there was a wire trick available. It was 10 minutes and then you were s-off flashing a new bootloader. These guys certainly wouldn't be working as hard as they are if they had a wire trick. Surge is actually trying to figure out if there are any holes in the boot chain somewhere he can attack. Even if he gets that, we will probably still not be in as good shape as you are used to htc land.
[Verizon Samsung Galaxy S 4] Mistertac:
At great risk of sounding dumb on this topic I wanted to share something..

Someone on a Sprint S4 says he successfully downgraded from 4.4 to 4.3 . he said he did this by first flashing the MK2 modem then the MK2 tar itself. It would fail if he didn't do the modem first.

Now i realize their bootloaders are not locked like ours. However they have the same issue of not being able to downgrade like us.

Is this something that could help at all? If not I'm sorry to take up more space here. I realize there's a lot more I would need to learn before I could make that determination myself so just wanted to ask the heavy hitters in here.
[Verizon Samsung Galaxy S 4] jamesd1085:
They do have the same lockdown issue we have...the reason they are able to downgrade probably means they used the same bootloader due to the fact that no one has cracked it yet...just like we can go back to mj7 from mk2...its because they share the same or very similar bootloaders
[Verizon Samsung Galaxy S 4] Mistertac:
Well I figured there was a more technical explanation than the one I could come up with. And I know Surge and everyone in here are working on things that look Chinese to me, just wanted to share... You never know
[Verizon Samsung Galaxy S 4] jamesd1085:
Most of what goes on here looks foreign to me too but I have learned a lot just reading through what's posted here and Google searching anything I don't get and reading up...even going through old posts that seem to have no bearing with this work helps in learning...it was a post from late 2011 that actually helped me fix my efs partition while I couldn't find anything relevant or helpful in current forums
[Verizon Samsung Galaxy S 4] ryanbg:
Generally, he's right on. Anytime there's a milestone release for things like aboot or sbl1 (milestone means like a major change or update,) they change the rollback counters stored in the QFPROM. When you go to download mode, you see the RP SWREV: S1 T1 R1 A2 P1 (yours will be different) those are the rollback flags. Inside aboot and all the bootloader files, there are 5 or 6 certificates, and one of them called an attestation certificate. This certificate tells Odin what device it's supposed to be installed on, and has a SW_ID tag. That SW_ID tag contains the rollback flag number. For example on the Note 3, MI9 was a '1' and MJ7 and subsequent releases are all '2'. Something major was changed from MI9 > MJ7. It could be a vulnerability patch, bug fixes, etc... You can actually open up aboot in a text editor like Notepad or N++ or a hex editor, and search for the string 'SW_ID'.

...U....South Korea1.0...U....Suwon City1.0...U....Samsung Corporation1.0...U....DMC1#0!..U....Samsung AttestationCA cert1%0#..*†H†÷......m.security@samsung.com0...130830154632Z..330825154632Z0‚.w1.0...U....KR1!0...U....Samsung Attestation CERT1.0...U....Suwon City1.0...U....
Samsung Corporation1.0...U....South Korea1.0...U....04 0000

OEM_ID1%0#..*†H†÷......m.security@samsung.com1.0...U....05 000FFDBC SW_SIZE1.0...U....06 0000

MODEL_ID1.0...U....07 0001 SHA2561"0 ..U....01 [B]0000000200000009 SW_ID[/B]1"0 ..U....02 007B00E100000000 HW_ID1"0 ..U....03 0000000000000002 DEBUG0‚.

Notice the two in the middle? That means this is at least an MJ7 aboot. You can also see HW_ID after that. The HW_ID is 007B00E1 which I believe is either a qfuse with the HW_ID burned in, or some other hardware flag. This prevents you from installing an S4 aboot on the N3.

We can absolutely edit and modify these flags, but the problem is that when we do, we 'break' the hash. Basically when Samsung signs aboot for example, they use their private key to hash it, which goes through a mathematical formula/equation that uses the size of the file. This way, if we modify even a single byte, the hash changes, and is no longer a valid aboot. That's where the 'SECURE CHECK FAIL: aboot' comes from. The hash is stored in a file called signature.bin near the certificates inside aboot. I can change the hash too, but I can't calculate the right one without the private key.

I love answering these kinds of questions, so if you guys are curious about more technical stuff, feel free to ask me, but please don't flood my inbox with stuff that could be answered with a simple search. We're still making progress, it's just a very complicated and lengthy series of systems.
[Verizon Samsung Galaxy S 4] Mistertac:
Well thank you for that [MENTION=766721]ryanbg[/MENTION]

It's definitely some interesting stuff even though a lot of It is way beyond my skill level. But your explanation does make sense to me so again thanks for taking the time to write that up!
[Verizon Samsung Galaxy S 4] tanishq.dubey:
Samsung's hashing formula.

I have been following this thread for quite some time, and as a lightweight dev, I know what is going on, but I am still trying to learn about cryptography and hashes. From my understanding, this is just a Samsung version of a MD5 hash, and this hash is checked when a new update is installed. Now, we can either try to bypass the check, or fool this check into thinking we are legit, and install our own software, correct? If we want to fool the check, could we derive the formula for Samsung's hashing method? My idea would be to compare the hashes of multiple files and then, with the differences, try to get the hashing formula. Is this even feasible?
[Verizon Samsung Galaxy S 4] jhasty01:
You would probably need a hell of a lot of them to be able to generate your own.
[Verizon Samsung Galaxy S 4] Surge1223:
In addition to this, SW_ID and HW_ID flags are present in the pbl. So that adds another wrinkle to our problem. The below code is strings from my pbl on my S4.

SVC:SPSR,R0-R14
FIQ:SPSR,R9-14
IRQ:SPSR,R13,R14
UND:SPSR,R13,R14
ABT:SPSR,R13,R14
SYS:R13-R14
pbl_error_handler.c
dload.c
dload.c
pbl_auth\secboot_rsa_math.c
pbl_auth\secboot_rsa_math.c
pbl_error_handler.c
pbl_auth.c
SHA256
pbl_spi_driver.c
~PBL_DloadVER2.0
Q`omm
[B] SHA1
DEBUG
SW_ID
HW_ID
OEM_ID
SHA256[/B]
pbl_loader.c
pbl_flash_sdcc.c
pbl_spi_driver.c
pbl_pmic.c
pbl_auth.c
pbl_auth\secboot.c
pbl_auth\secboot_x509.c
QUALCOMM COPYRIGHT 2011BOOT ROM VERSION: 1.0QHSUSB VERSION: 02.02.13
BOOT ROM AUTHOR: AshuS

Though the specific values of SW_ID and HW_ID arent readable above, if you look at the code of the pbl you can probably find it, the above just contains strings. To be able to view your own pbl you will have to use the viewmem utility i provided a few pages back.

Also I was asked how I know the locations/addresses to analyze bootloaders in ida with. You can find these on your own looking at the headers of a partition. For aboot you can see its address is 0x88e00000 from looking at the header.

aboot 0x88e00000
[Verizon Samsung Galaxy S 4] ryanbg:
My best guess is DES-EDE3-CBC, but it's not an MD5, I believe it's a SHA256. Unfortunately it is not feasible unless you've got a team of the brightest mathematicians in the world sitting in one room for about 40 years, and NASA's computing power times 20.
[Verizon Samsung Galaxy S 4] tech_head:
Samsung hashes/signs the files with SHA256.

Unless someone leaks the signature key, forget it.
[Verizon Samsung Galaxy S 4] Hashbang173:
Don't forget Moores law
[Verizon Samsung Galaxy S 4] sokrboot:
http://www.mooreslaw.org/
[Verizon Samsung Galaxy S 4] jhasty01:
I'm not sure this helps much but maybe it might spark some thoughts

http://www.theregister.co.uk/2014/03/13/samsung_remote_file_backdoor/

Keep up the great work! Been following this thread for quite a while.
[Verizon Samsung Galaxy S 4] ryanbg:
Every time I think it's starting to slow down, it speeds right back up. It's almost become more of a PR matter/release timing ordeal. When you think about it, we've come to expect the latest and greatest. Every financial quarter seems like a new era of smartphone these days.
[Verizon Samsung Galaxy S 4] sokrboot:
So is this different than hacking a phone with a Femtocell?

I do find it intriguing that they wrote their own code to replace Samsung's RIL, (this could shed some light on the subject if we do a side-by-side comparison) but the phones listed dont have the same security measures as our phone. ..do they?
[Verizon Samsung Galaxy S 4] ericerk:
Dan Rosenberg had something to say about that.

http://www.androidpolice.com/2014/0...sung-backdoor-vulnerability-published-by-fsf/
[Verizon Samsung Galaxy S 4] tech_head:
Okay with Moore's law maybe 5-10 years.

It just won't be in a timely fashion.

Also we are presuming to brute force a key.

What happens if in 3 months they release a new bootloader signed with a different key?

Brute force just won't work.
[Verizon Samsung Galaxy S 4] waiters:
Didn't Dan rage quit and insult the xda community before he did?
[Verizon Samsung Galaxy S 4] ericerk:
I'm pretty sure he's still in, at least a little.
[Verizon Samsung Galaxy S 4] numbR7:
OPEN QUESTION: As you see it--as of now--what are the TRUE odds the BL will be unlocked notwithstanding who is behind it and why?

You do not have to explain why--this I not an exam--though I wouldn't mind hearing your opion.

It seems to me there is a little bit too much back and forth at this juncture.
[Verizon Samsung Galaxy S 4] tshelby73:
My opinion is no. Great if it happens and commend the one that does it. I just check every now and then but not holding my breath.
[Verizon Samsung Galaxy S 4] decaturbob:
Im not a android expert but I understand security lock down. ..I suspect the odds are nil for a bootloader exploit. We do need to have hope and safe strap has provided it for me
[Verizon Samsung Galaxy S 4] gnubian:
Nothing is infallible. There is always a chance and surge and jeboo have learned a lot already.
[Verizon Samsung Galaxy S 4] Mistertac:
I'm just thinking positive.. Surge and the crew in here are going to do it!
[Verizon Samsung Galaxy S 4] ryanbg:
Well, don't ask me how I found this because it was on complete accident... but this seems very important....

I would recommend not playing with this. You can brick your device beyond Kies/ODIN repair. Hard bricked.
[Verizon Samsung Galaxy S 4] jamesd1085:
Hey [MENTION=4939386]Surge1223[/MENTION] idk if you have seen it yet but there is a guy in q and a forum with a baseband version I haven't seen...vrudmg7...its 4.2.2...could it be pre mdk?...and could we learn from it possibly?might be worth checking out
[Verizon Samsung Galaxy S 4] jeboo:
I would have to agree with the previous poster and say no as well. At this point it's been ~8 months with no solution. This is not for lack of effort, myself and many others have dedicated countless hours exploring the BL, as was done with the GS3 before the leak.

You have to understand there are politics behind such a task, this is not a true free-for-all "hacking" environment (Though you could probably create one with a $100k+ bounty). Many of the individuals capable of this have a vested interest in the mobile security field. They may work with manufacturers often, and may even have NDAs with them. You can't expect them to jeopardize their livelihood for such a task.

And who knows, maybe someone is sitting on a nice exploit for the S5 release! :fingers-crossed:

(I'm not betting on this and will not purchase another locked device again.)
[Verizon Samsung Galaxy S 4] Surge1223:
I'm going to have to go against popular opinion and say yes. Saying no would suggest ive already admitted defeat. I think the stipulations surrounding my yes vote are steep though, it would require more people taking up an interest in this and helping, even if that requires quite a bit of learning on their part. I cant just sit here, think no, and hope for some kind of afternoon delight. It just doesn't work that way.
[Verizon Samsung Galaxy S 4] sokrboot:
Id like to put some work in in this. Are there any devs who'd be willing to do a Google hangout or something to teach me some stuff? One time only, I promise.

sent from my VZW S4 w unlocked ME7 bootloader
[Verizon Samsung Galaxy S 4] Surge1223:
Anyone can always reach me @ surge1223@gmail.com on hangouts. I dont always respond right away but eventually I will.

Also I posted this in the OP but ill post it here as well.

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

[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 @A..@A.*....@B.*
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 @Q..@ ..@ ......
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...