yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S 4] k1mu:
That's been already discussed. Please read this thread.

But, to explain; it's locked by being cryptographically signed using a private key that is only known to Samsung. Each component of the boot chain verifies the integrity of the next component using a secure hash algorithm. We can't bypass this unless there's a way to introduce content that we control, but we can't provide a signature that will verify our code since we don't have Samsung's key. And the signature algorithm doesn't permit us to modify the code without detection.

Brute forcing the signature key would require every computer on the planet to be dedicated to that task for a few hundred thousand years.

Perhaps there's a fully buzzword-compliant agile lean scrum seven sigma team that can do that faster, though. :)

More seriously, if you really don't understand the problems with reverse engineering a block of code designed to resist tampering, then think twice about posting here. Much of the recent posts aren't helping and simply divert the active researchers from their work.

And yes, this is true for this post as well.
[Verizon Samsung Galaxy S 4] numbR7:
Thanks for the reply it helped me verify something.
[Verizon Samsung Galaxy S 4] numbR7:
Thanks for the second paragraph as it addressed the question. The last two being anonymous in nature seem a little fainthearted to me. Also, you said this had been discussed--I agree. But, the thrust of my question is are all these issues logged and organized for quick and cross reference. So far the answer seems to be "no." Unfortunately, I do not possess an eidetic memory. As far as the last and most "serious" paragraph, if you want to dicuss intelligence, education, accomplishments and real engineering I'd be glad too -- however, I believe that is best done in private. And I apologize if I diverted "active reseachers" from discussing the possibility of a fake AOSP rom. I sincerely was trying to add at least modicum of good to the discussion. Finally, I agree that a lot of posts are off topic especially insults. I really enjoy the community here at xda but good grief there are a ton of insults hurled about. I simply can't understand the nature of such bitterness.
[Verizon Samsung Galaxy S 4] Surge1223:
All the information we have isn't from having some sort of privileged info, nor being in the "know", everything thing we've learned anyone has the means to learn as well, I've posted viewmem, devmem2, and reademem for the purpose of others wanting to learn. Since you seem to be interested, I guess I can post what the actual problems are. Might also help people in the future if we fail as well.

I'll update this post soon.......
[Verizon Samsung Galaxy S 4] numbR7:
Thanks a lot man. I get what your saying. That would be really generous and I sincerely appreciate it. :good:
[Verizon Samsung Galaxy S 4] jeboo:
I honestly can't blame this thread for getting philosophical so often, there hasn't been a lot of progress lately. Many have asked what state it is at, I'd say we've pretty much ruled out any kind of implementation flaw at this point. By this, I mean there's no vulnerability in the chain-of-trust design or partition structure/PIT. This would also include any possible JTAG-based bypass. Surge has done amazing work on this and discovered a ton of info though!

I have looked for known exploits in many of the associated libraries used (openSSL, JPEG, etc.) and found none. I would say if after the S5 release, nothing comes out, it's bleak :p But we keep fighting the good fight!
[Verizon Samsung Galaxy S 4] jsaxon2:
I used to love her but I had to kill her. I was and still am extremely impressed with Samsung hardware but I feel the need to have flexibility when it comes to software. I hate touchwiz. I have all the respect in the world for surge, but I just don't see it happening. I now have the htc one m8 and it has already been unlocked and s-off. I wish the best for Samsung users that want to customize, but don't see it happening any time soon. Good luck and even though I know longer have the s4, I will still donate if it becomes unlocked. Good luck Surge and everyone else
[Verizon Samsung Galaxy S 4] gnubian:
Cool story bro. This post may be the answer to our bootloader problems.
[Verizon Samsung Galaxy S 4] Hashbang173:
LOL there needs to be an "Off topic Discussion about an unlocked boot loader" thread. Let's make one and move all the posts that do not relate to the boot loader being unlocked. (Including this post) Ones that don't help with the unlock process.
[Verizon Samsung Galaxy S 4] scryan:
There are multiple. Or start a new one. Yet everyone tends to the big thread... because obviously we need poetry about your phone for development to progress...

While it counts for nothing because I don't know how to chroot let alone kexec... But I can't help but feel (again) like this is the closest thing to an answer? I know Hash was having problems with cache, but I don't know how much time he spent on it (or what that means exactly lol) or if whether its something to figure out vs a road block.

Is get/put user exploit fixed in the 4.4 leaks that have been out? I worry that the update is going to move most peoples phones past being able to load kernel modules... But if we (lol, ok you guys :P) get kexec working we basically have an unlocked BL all functional purposes?

I think I only need like 8 more years to read/practice... Then I can contribute!
[Verizon Samsung Galaxy S 4] peppersu812:
I think we should make a money pot and help that way if we are really serious to get it unlocked. If it's up to the community then let the community put in on a bounty. I'm sure it would get solved then.
[Verizon Samsung Galaxy S 4] decaturbob:
there is a bounty thread for this with thousands of dollars pledged...money sometimes can't buy a miracle. The security lock down is sophisticated with more to come.
[Verizon Samsung Galaxy S 4] ryanbg:
I agree to an extent. However, I do believe there are other viable methods other than a vulnerability within aboot or sbl itself. I'm doing a lot of research on the RIL/DTT/Baseband and Qfuses right now. Now that we've got a full register map, the possibilities open up a little bit. There's a 64 bit debug key that can be blown which will enable SEC TAP access in addition to possibility activating the TEST BIT in Rollback Protection. The MSM HW ID also happens to be 64 bits. It might even be possible to preserve a modified shadow register through reboot, or just long enough to modify what's needed. Still, lots more research is needed.
[Verizon Samsung Galaxy S 4] peppersu812:
Just came over from t mobile so I'm new to all this. Lol
[Verizon Samsung Galaxy S 4] fillyo:
Well, after watching this for months, I guess I will be watching the same on the S5, I'm moving on any day now. Best of luck, something tells me neither of these devices will be cracked.
[Verizon Samsung Galaxy S 4] dmt010:
Hot off the press.. You'll probably end up LOVING this ..

https://www.cert.fi/en/reports/2014/vulnerability788210.html

http://heartbleed.com/

https://www.openssl.org/news/secadv_20140407.txt

http://www.exploit-db.com/exploits/32745/

diff: http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db902

Or maybe not..

Also:

RIP Kurt Cobain Friday, February 20, 1967 - April 8, 1994
[Verizon Samsung Galaxy S 4] Hashbang173:
Does the Verizon s4 use the version of openssl effected
[Verizon Samsung Galaxy S 4] dmt010:
Hmm I wonder why this is on nist.gov's website

Samsung OpenSSL Cryptographic Module

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2120.pdf

Weird...

---------- Post added at 08:06 PM ---------- Previous post was at 07:52 PM ----------

Not really sure man. Save that for the nerds.
[Verizon Samsung Galaxy S 4] Hashbang173:
We need to get devs to looks at this. [MENTION=4243514]Hashcode[/MENTION] [MENTION=4939386]Surge1223[/MENTION] [MENTION=2471504]jeboo[/MENTION] [MENTION=766721]ryanbg[/MENTION]
[Verizon Samsung Galaxy S 4] Dhs92:
http://heartbleed.com

Golden Eye V26 Safestrap Edition
[Verizon Samsung Galaxy S 4] Hashbang173:
Still doesnt metion anything about android and the bootloader
[Verizon Samsung Galaxy S 4] dmt010:
Here's a good diagnosis of what and how it's done..

http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html
[Verizon Samsung Galaxy S 4] Hashbang173:
Sorry still a little confused but does this mean we can make a modified bootloader and install it becasue of this?

sorry if this is completly impossible
[Verizon Samsung Galaxy S 4] chuciulla93:
Not directly. It sounds like what the exploit allows is for information to be read from secured sections of the file system. Depending on what information can be extracted, we may have a lead to follow. :highfive: In the mean time we need to be patient and allow those knowledgeable in openssl to work their magic.
[Verizon Samsung Galaxy S 4] jwhistler:
Clarkes third law of technology: Any sufficiently advanced technology is indistinguishable from magic.

Yes. Let them work their magic!
[Verizon Samsung Galaxy S 4] dmt010:
Its actually worse..

If possible, The vuln may allow private keys to be easily breached from secureboot embedded devices without much hard work. Which effectively would eventually lead to world domination. Since nobody knows these keys. Good luck. Looking forward to knowing if openssl is vuln within the samsung s4.

Rest in Peace Kurt Cobain!

[MENTION=2877135]jwhistler[/MENTION] MAGIC!!
[Verizon Samsung Galaxy S 4] NighthawkXL:
So I've spent the last few hours going over the Heart Bleed exploit... (I'm actually still watching Security Now live right now) and I hate to break it to you all but it's unlikely we'll be able to exploit this in any meaningful manner regarding unlocking our bootloader. Don't get me wrong, this is a nasty exploit... but not for what we're trying to do. I'll wait until others view it and post their opinions but I'm 99.9% sure it won't be of use to us.
[Verizon Samsung Galaxy S 4] Oishikatta:
The OpenSSL exploit is specifically between clients and servers, so it doesn't apply to the boot process at all.

The S4 uses mincrypt (not necessarily that version, just an example). There would need to be a vulnerability in that to be significant for the S4's boot process.

The S4 does not have private keys. Samsung has private keys, S4 has public keys. Public keys can be used to verify things signed (i.e. SBL2, kernel, recovery, etc) by private keys. In essence, even if it were possible to exploit, there is nothing to be taken from the S4. Surge has already provided viewmem etc which we can use to access arbitrary data in ram (not sure on TZ ram).

SMC calls are not made using SSL, so it is not possible that that particular exploit could give you access to the TZ's memory either. (But we already have the tz binary anyways...)

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0301h/Chdfjdgi.html

If you scroll down to "System boot sequence", you'll see a warning about how it does not protect from hardware attacks.

From what I understand, Samsung uses Mask ROM (PBL) to verify by sha1 the SBL1 (i.e. protect from hardware attacks). This establishes the COT (Chain of Trust), as from then on RSA (mincrypt) provides verification.

Because there is no possibility of editing/overwriting PBL, we cannot prevent entry into the COT. That means a notable cryptography-related vulnerability would have to be in mincrypt, specifically mincrypt's RSA implementation.

Ideally I'm wrong about the last part.
[Verizon Samsung Galaxy S 4] dmt010:
I understand. However was hoping that the same vulnerability could have been invoked differently.
[Verizon Samsung Galaxy S 4] Surge1223:
This is correct and summed up very nicely. I wanted to add that we can write/attack/send SMC calls to the TZ. We just have no consensus on where to send/write memory at. You have to use ida for that.
[Verizon Samsung Galaxy S 4] k1mu:
That's correct.

Heartbleed exploits an extension to the TLS protocol. TLS (transport level security) is used to set up secure network connections - for example, the secure connection to https://yourbank.com/.

If your bank uses OpenSSL on their webserver, they're scared.

This flaw has nothing whatsoever to do with using the OpenSSL libraries to sign or verify signatures of files. There's no exploit here that'll help unlock the bootloader.
[Verizon Samsung Galaxy S 4] Charlie115:
unlock code

I would like to ask a question sorry if not in the right place but it seems to fit here! If I was to get an unlock code for bootloader from Samsung could I roll back off from 4.3 or no??
[Verizon Samsung Galaxy S 4] joshm.1219:
lol how would you go about doing that

Sent from my SCH-I545 using Xparent Skyblue Tapatalk 2
[Verizon Samsung Galaxy S 4] Charlie115:
Lol corporate persuasion! !
[Verizon Samsung Galaxy S 4] scryan:
People have offered about five thousand dollars for the bootloader to be unlocked... so yes convince samsung to give you their secret security key and you can not only flash what ever you want, but you can come here and collect thousands of dollars too.

But these threads wouldnt be going on for nearly that long if it was that easy would they?
[Verizon Samsung Galaxy S 4] Charlie115:
It was just a question sport!! Save your sarcasm and snooty comments for people that want to play that game!! Be respectful it's much more gratifying, but on a lesser note thank you for the answer.
[Verizon Samsung Galaxy S 4] killajoe:
Do you have contacts to do such things? If so you would be a Savior to us s4 users

Sent From The Future
[Verizon Samsung Galaxy S 4] trook:
I'm currently loading up about 20 magazines with 155 grain "corporate persuasion".... Anyone know where Samsung North America is? (yo since some people in this thread seem well... Sensitive, I feel like I have to say I'm joking. I for one am saving all my ammo incase they try to make pootietang 2, then it's on!)
[Verizon Samsung Galaxy S 4] Charlie115:
Well I'm in charge of tracking and communications for a company with 425 galaxy s4 that were promised to make my life easier! ! Well now this update just **** in my cheerios! ! So I have complained and have lawsuit papers started I'll see what I can do!!!
[Verizon Samsung Galaxy S 4] :
What's wrong with the update that hinders your company's productivity to the extent that you're willing to file a lawsuit?
[Verizon Samsung Galaxy S 4] Charlie115:
Biggest problems app fcs and bluetooth issues with vehicle ecm and gps transponders that were not present on 4.2.2
[Verizon Samsung Galaxy S 4] :
Ouch, I did notice the xda app fcing but thought that was the app itself. Hope they resolve your issues! At least we don't get the BSOD like the iPhone :P

P.S. sorry this was off-topic
[Verizon Samsung Galaxy S 4] Charlie115:
Yes now deal with 425 of these dam phones with a bunch dumb dumbs that call every 5 mins my phone won't work!! Ughhhg
[Verizon Samsung Galaxy S 4] Surge1223:
Lets stay on topic here guys. Samsungs not going to give us their key. Also remember questions belong in Q&A.
[Verizon Samsung Galaxy S 4] TMcGrath50:
Please, please, please, please limit the discussion posts here. We have a pretty good development roll going on. I don't want this thread getting hijacked.

I know this isn't *officially* a development thread, but please have respect for those of us who are trying to find a bootloader exploit by limiting the idle chatting in between our posts.
[Verizon Samsung Galaxy S 4] Charlie115:
Wow!!! Really I thought this was a general thread about bootloader unlocking guess my general interpretation of the thread title was grossly misunderstood! I do apologize for my blatant ignorance on this matter!
[Verizon Samsung Galaxy S 4] Surge1223:
So I got my MDK to switch over from QDL mode to "unsupported usb device type" on a consistent basis when I send it the MPRG8064.hex (which leads me to believe that if I was using the right drivers id have access to the emmc, thus id be able to push/overwrite files in the emmc.) Also I read an interesting Vietnamese android forum thread about the relative insignificance of having a signed xxxx_msimage.mbn file.
[Verizon Samsung Galaxy S 4] Defiant79:
Any chance a BOINC type project could used to crack/unlock the bootloader on the S4? I'd gladly donate some CPU cycles for a cause like this!
[Verizon Samsung Galaxy S 4] Surge1223:
Anyone have a Jtag or Pbl dump?
[Verizon Samsung Galaxy S 4] NighthawkXL:
I don't know if it's relevant, but user Kaito95 posted a experiment over on the dev forums earlier today. Here's a link...

He hasn't had any replies as of yet though.
[Verizon Samsung Galaxy S 4] sokrboot:
Not sure if this S5 owner is legit or not but perhaps it is worth contacting him to see how similar it is to the S4

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

S5 Owner

Samsung Galaxy S4 "Fort Knox Edition"
[Verizon Samsung Galaxy S 4] rebel1699:
Being in Korea, it would be an international version with an unlocked bootloader anyways. Likely of no use to those of us on locked bl.
[Verizon Samsung Galaxy S 4] sokrboot:
Good point. Anyway I found all kinds od system dumps and info in the S5 forums (go figure). Maybe I should have checked there first. DUH!

Samsung Galaxy S4 "Fort Knox Edition"
[Verizon Samsung Galaxy S 4] LongSimple:
Please keep on topic, heartbleed will not work and might not be as bad as previously thought. Looking at the galaxy s5 boot loader from a different country/carrier is a wild chase and completely divergent from what we are currently doing.
[Verizon Samsung Galaxy S 4] TonyApuzzo:
Heartbleed actually could help if somehow Samsung was (unwisely) signing the bootloader with the same keys they were using to SSL-protect a web-server. Then it would be possible to use heartbleed to compromise the keys on that server, and then someone could create a "valid" custom bootloader that the existing bootloader would load, no local exploit needed.

Now, this is highly unlikely, and at this point it is likely too late to get keys from Samsung's servers anyway even to check, but a roundabout way of gaining access would still be access.
[Verizon Samsung Galaxy S 4] Hashbang173:
Would this be to any use?
[Verizon Samsung Galaxy S 4] Oishikatta:
Heartbleed is irrelevant, please stop posting about it.
[Verizon Samsung Galaxy S 4] ryanbg:
This is actually theoretical. TIMA Attestation (where your device measures and hashes your kernel to make sure it's signed stock, and other stuff like RODATA) could be exploited for this purpose. However, I already carved the certificates from the apps and compared to the Attestation certificates. They are different. I've noticed from all the certificates I find, there are many different divisions in Samsung working on this. It seems very segregated in the fashion they do their work. As if they pass the device through each department without communication between, and then build it. Perhaps even TrustZone could be exploited...

I've found two keys inside a TrustZone image blob. One is called SSD Auth Key and the other SSD Key Encryption Key (KEK?). There's also strings pointing to a "ssdksimg" (SSD Keystore Image?) and something moderately similar in aboot. I don't know how to use them yet, but it could have been just for an earlier testing device also, so no racing to conclusions here. Our SSD partition if I remember correctly is blank or like 3 bytes flipped to 01. I also noticed strings referring to 'PARAM' partition. RODATA kernel parameters apparently, but this partition is also blank...

So what is going on here? In the BP, which is integerated SoC so with AP, and TrustZone I noticed references and code relating to encrypted filesystems (sfs_, etc.) I also found references to a modem Auth/AES Key and IV file which is stored locally and accessible on the device in /data/radio. There are a few files in here with 4 or 5 (can't remember) character names. I've also found the motherload of IPC (socket connection) commands, which I've discovered to interpret AT commands which are hidden or proprietary. From what I see, it's just converted into hex, but only a set list of commands are accepted. Of course, I just 'strings' the right areas, and find the accepted commands. Lots of goodies. That's where I'm at right now. More questions than when I started... which lead to more questions.
[Verizon Samsung Galaxy S 4] dmt010:
Glad to hear that my post wasnt necessary full of brain dead material. But we're all here to help one way or another. . thanks for looking into it

May you also find these links here and where they link to possibly useful as well.

http://www.cryptsoft.com/fips140/out/vendor/Samsung_Electronics.html

Related to AT modem commands.. Anyway anybody know much about m2m?

http://m2msupport.net/m2msupport/atcsim-generic-sim-access/

http://m2msupport.net/m2msupport/at-commands-to-get-device-information/

Hope i'm not derailing much.
[Verizon Samsung Galaxy S 4] RuggedHunter:
This looks interesting....I can't d/l the certificate tho....

I recognize m2m from my work's secure servers...

☆☆☆☆☆☆☆☆☆☆☆☆☆☆

i337 MDB > MF3 > MK2 > SafeRoot > SafeStrap 3.71 > HyperDrive 12

Interesting read.... HERE !
[Verizon Samsung Galaxy S 4] failedjedi:
http://www.cryptsoft.com/fips140/unpdf/140sp2044.html

I don't know what much of this means, but it seems to get pretty detailed about how samsung implements things.
[Verizon Samsung Galaxy S 4] tshelby73:
Any progress or are we just changing directions.
[Verizon Samsung Galaxy S 4] k1mu:
If there was progress that the developers wanted to make public, it would be posted here as that would be killer news.

No, they're not changing directions. There's been a bunch of distraction posts that aren't on topic (Heartbleed, for example). But no change in what's being attempted.
[Verizon Samsung Galaxy S 4] xXsquirr3lsXx:
I know this might be really stupid and will not contribute to this what-so-ever but what EXACTLY happens when the KNOX Warranty is voided?

I only know it changes from 0x0 to 0x1 (Which is void)

But will it not allow the phone to boot or something?
[Verizon Samsung Galaxy S 4] virusx_64:
Just voids warranty from what I understand
[Verizon Samsung Galaxy S 4] tanishq.dubey:
It's useful for distributors to check if you have tried to mod your phone in the past even if you have brought your phone back to stock.
[Verizon Samsung Galaxy S 4] k1mu:
This is really off topic here, but to answer your question:

Knox is a marketing umbrella term that Samsung is using to market their phones to companies that want to provide "bring your own device" service to their employees. Samsung provides a secure container that contains the company e-mail data, documents, and so forth, which the company can control, wipe, etc. in case they suspect a device is compromised, lost, or whatever. If you don't have the encryption key for that secure container, you can't grab the company data.

So, one of the Knox program initiatives is to provide such a secure container.

The problem is that the security of such a container depends upon the operating system strictly keeping any applications from bypassing the security controls that keep applications from hacking into the container. The Samsung-supplied Kernel depends upon SEAndroid to do that, so if you boot a non-Samsung kernel, it may allow people to bypass the protections. Allowing a nonstandard bootloader also allows bypassing the container, as you can flash custom images that don't enforce the Knox protections.

For both of those cases, the "Knox Warranty Void" flag is set. This means that Knox can no longer guarantee that the phone will enforce the Knox container protections, and is no longer trustworthy.

By design, you can't turn that flag back off. You did bad things, so Samsung will no longer guarantee the security of the Knox container. That security of the Knox container is the warranty that it's talking about.

The ONLY thing that the flag does is to disallow you from using the Knox Container feature.

A smart tech could check that flag and disallow a warranty claim, but that's really hard for them to enforce since it's difficult to prove that having flashed a custom ROM in the past broke the phone. It really has nothing to do with having the repair warranty invalidated.
[Verizon Samsung Galaxy S 4] david515:
Thank you!

Thank you