yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S 4] Surge1223:
I've literally tried to read it like 4 times. Each time I get a little bit more out of it but holy hell his English is the most atrocious thing I've ever seen. At this point it may be useful to translate it paragraph by paragraph.
[Verizon Samsung Galaxy S 4] gnubian:
Haha yeah. It was painful to read. Hopefully he can write it in polish and someone can translate it, and that is has some benefit for us.
[Verizon Samsung Galaxy S 4] ryanbg:
So there was a member who recently posted about mounting NON-HLOS.bin in loopback and took a look inside. He found /prov_data/Knox/Knox.dat which is in EFS. Now on an actual device, that directory has two folders, (/prov_data) and it looks like they are both encrypted/hashed. Very interesting... since none of those are encrypted in the image itself.

Also, it looks like the N3 T-Mobile guys successful built a working SDCARD mode recovery. Something we can look into to restore an older/compatibe sboot.bin and flash insecure aboot. Just a thought.
[Verizon Samsung Galaxy S 4] Surge1223:
You can mount both NONHLOS.bin and modem.bin and there's some interesting stuff in there (more than what you'd find in /firmware and /firmware-mdm) but I've never seen any Knox.dat file, I'll take another look though. As for the sdcard boot, I know for a fact it exists, as aboot has strings in it for a T-flash and I've seen references to boot from sd but how to actually get it to work I don't know. I've tried for a while though.
[Verizon Samsung Galaxy S 4] ryanbg:
I compared Note 3 MI9 and MJ7 to my MG3 engineering build. The MG3 engineering build leaked by designgears has no TIMA files in it from NON-HLOS, and the others all do. I'm convinced I have an insecure aboot, but unfortunately there's no way to flash it. It's even signed I think, but Knox does some sort of version checking on top of signature verification. I get 'NO SYS VER FAIL: No Version" in Odin mode. I also noticed since using MI9 kernel, then trying saferoot/bypasslkm just to see if the kernel is vulnerable, TIMA_debug_log in EFS keeps spitting out kernel verification failed, but it doesn't shut me down or anything.

Have you seen the leaked Samsung SM-N900 boot recovery guide for SD? I'd imagine the process is very similar for the S4.
[Verizon Samsung Galaxy S 4] Walter.White:
Here try this, use this unbrick image for Verizon http://www.androidfilehost.com/?fid=23159073880937014 and rest is same as this guide http://xdaforums.com/showthread.php?t=2476353
[Verizon Samsung Galaxy S 4] gunz.jones:
Is there a naming convention for the update file to be placed on sdcard and flashing os fixes or updates? It used to work on old moto devices when there was no computer around and fix stock fw through stock recovery.
[Verizon Samsung Galaxy S 4] k1mu:
Question: "bypasslkm" - is that something that allows unsigned kernel modules, or something else?

There's a talk called "The Evolution of Linux Kernel Module Signing" at Shmoocon this weekend that I'm very much looking forward to. Knowledge is power. :)
[Verizon Samsung Galaxy S 4] NighthawkXL:
Yeah, bypasslkm is a new exploit that [MENTION=2471504]jeboo[/MENTION] discovered a few weeks back... here's his thread over on the AT&T S4 forum.

http://xdaforums.com/showthread.php?t=2578566
[Verizon Samsung Galaxy S 4] Surge1223:
Also in relation to that, I compiled lime for MJ7 using our kernel source. So anyone who knows what they're doing can download the kernel module lime.ko here https://www.dropbox.com/s/ik4tp3j8bwkdqta/lime.ko I'm not posting directions on how to dump and analyze ram here though.
[Verizon Samsung Galaxy S 4] gnubian:
The sweet smell of progress. Glad you and Jeboo are still going at it strong.
[Verizon Samsung Galaxy S 4] michael3770:
Oh that's a huge step forward
[Verizon Samsung Galaxy S 4] tech_head:
Very cool.

Similar to an idea I have.

I'm old school (hardware design with some software experience) and remember copy protection and other things using "self modifying code".

I also know of some copy protection hacks on Unix system that overwrite kernel memory in real time.

So I ask, and maybe SE Linux preventing it is the answer, why not just boot the device, then overwrite the kernel with whatever you want and create a new runtime environment? What prevents a rooted device from coming in and overwriting the kernel and killing itself?

Just asking...
[Verizon Samsung Galaxy S 4] Surge1223:
That's kind of what we're trying to do with kexec. But a better answer is that we only have root privileges at the system level not at the kernel level. Also there are protections in place like SE Android (SE Linux) and other checks preventing elevation of privileges and overwriting some parts of the bootchain.
[Verizon Samsung Galaxy S 4] tech_head:
Got it. I understand that SE Linux creates, for lack of a better term a "sandbox" for apps to play in and they can't play outside the "sandbox". I do understand now; "root" isn't really "root" that I am accustomed to.

On boxes that I'm used to, root = kernel level root.

An old exploit of flexlm back in Solaris days was modifying strings in kernel memory while the system was running, or intercepting the call and returning what you wanted.

Anyway, I'd love to help but don't know what I can do.
[Verizon Samsung Galaxy S 4] k1mu:
SELinux adds additional security restrictions on what applications can do. It's not exactly a sandbox or jail; it's additional restrictions on what users and applications can do, Root can't override these permission decisions. You can build very detailed policies, such as not allowing specific applications to open specific files or directories. Very fine grained,
[Verizon Samsung Galaxy S 4] UnLoK:
I also am coding a mj7 unlocked bootloader
[Verizon Samsung Galaxy S 4] gnubian:
Did you ever actually tell the tbolt owners what you needed and how to get it?

Your posts on the subject seem trollish at best.
[Verizon Samsung Galaxy S 4] scryan:
He definitely never contacted me with anything.

I'm willing to play along for the time being though .
[Verizon Samsung Galaxy S 4] tech_head:
Hi,

I am aware of this but didn't want to go into that much detail.

Cracking the bootloader is going to be tough.

General Dynamics and Samsung worked to get the S3 and the S4 NSA certified with the knox functionality.

The keys for signing are super secure because they want this thing to be used where the General Dynamics Sectera Edge was used.

We might get there, but it will be a long road.

Willing to lend compute resources and/or whatever skill I have.
[Verizon Samsung Galaxy S 4] ryanbg:
It appears to be SHA256. Not too bad.
[Verizon Samsung Galaxy S 4] tech_head:
SHA256 has no failures as of yet.....

Bitcoin uses SHA256 and there are chips for SHA256 hashing.

The NSA designed SHA256 to be FIPS compliant and secure.

I don't know of any known collisions or attacks for SHA256. So were you saying "not too bad" to be funny???

I'm no cryptography expert but have done work in Multi2, DVB-CA and AES. SHA256 appears by all account to be secure for a while. Maybe less with all the bitcoin mining. But I don't thing a broken SHA256 is in the pipe.

Anyway, a brute force attack on the bootloader doesn't appear to be a productive endeavor.

The possibility of a leaked key to sign with doesn't sound likely since the bootloader with KNOX is being used by General Dynamics and Samsung.

http://www.generaldynamics.com/news/press-releases/detail.cfm?customel_dataPageID_1811=17753

http://www.generaldynamics.com/news/press-releases/detail.cfm?customel_dataPageID_1811=18330

http://www.gdc4s.com/gd-protected

So a compromise in the knox bootloader, ie. being able to sign it with a key that would bypass the security would not make Samsung or GD very happy.

So, how to progress..........
[Verizon Samsung Galaxy S 4] k1mu:
I think it was intended to be sarcasm.

The only ways to bypass this are to either obtain a leaked private key, find a way to bypass the signature verification code, or use "rubber hose" cryptanalysis.

I do not doubt that all of those will be hard to do.
[Verizon Samsung Galaxy S 4] vt0r:
SHA256 is definitely not something you want to try brute forcing, so you're very much correct assuming we're not getting their key this way.

A leak is always possible, but getting the government "signoff" on their KNOX protected bootloader required some VERY stringent internal security, which would require the absolute smallest number of people with access to the original signing key. This means your every day disgruntled employee will be useless for this cause.

The best bet still lies in attempting to exploit any unknown vulnerability(ies) in the bootloader itself, as we do have access to perform these tests.

Surge, et al are definitely on the right track in their attempts to reverse the bootloader code, as attacking pseudo code is how a lot of great exploits come to fruition.

I haven't done any serious reversing or exploit testing in probably 10-12 years, but I'd be happy to donate any free time I can come up with to try and help the cause, even though it will not be much.

I'll be running through this whole thread again to try and get up to speed on the current state of everyone's progress to this point.

Thanks to everyone who has put in work so far, especially those who already have Loki-patched MDK phones and still aren't satisfied.
[Verizon Samsung Galaxy S 4] Surge1223:
I apologize in advance because this thread is highly fragmented. The first couple pages or so are probably logical but after that it's more of ideas and responses. Also there isn't a description of what's currently being worked on because at most times it's more than one person working on ideas and there's usually a couple people working on different ideas, some related some not.

In all honesty I haven't tried changing or altering the direction of this thread because a lot of these threads get closed or locked and we're one of the last threads that's active on this issue if you look at the VZW note 3 or AT&T threads they don't have a dedicated bootloader thread. They congregate with us here so it's not just for the vzw s4 here, and I frequently look at the note 3 and AT&T devices code as well.
[Verizon Samsung Galaxy S 4] awskier08:
Here is my aboot.mbn is anyone is interested.
[Verizon Samsung Galaxy S 4] travisjshepherd:
That's why I come in here, I've been following this since the thread opened. I love how it just bounces all over heavens creation. But remember that's how ideas are born, by spitballing.
[Verizon Samsung Galaxy S 4] WarEagleUS:
Interesting news on the general dynamics c4 systems working with Samsung. I worked for GDC4S up until a few years ago. If they have a key, so to speak, they're systems are able to be "gotten" into, or they were from my time with them here in Huntsville. Both Huntsville and Scottsdale (HQ) has vulnerabilities that led to attacks several times a month.
[Verizon Samsung Galaxy S 4] tech_head:
La la la la la la...... Ears plugged.

The bootloader exploit seems to be the most likely.

Willing to help troll through code, etc.

Not willing to brick my phone for the effort.

I'm still using it.
[Verizon Samsung Galaxy S 4] ryanbg:
Feel free to shoot me a PM, I can get you up to pace on what we've been looking at.
[Verizon Samsung Galaxy S 4] KaratemanTJ:
So I know each stage in the boot chain checks the signature of the next and that means we can't tweak aboot. Is it possible to start with the PBL and work at removing those checks? Let me know if I'm way off base here or if that's what's already being done. Haha
[Verizon Samsung Galaxy S 4] pingpong1109:
I've been watching this tread for a while. I'm not to knowledgeable in bootloaders but if the VZW s4 has an issue with flashing backwards because of a 3 in place instead of a 1 like I have seen in a couple threads. These were something along the lines of "000000003000000" in a her editor. (numbers are for examples) So if we have those numbers and we think it is those numbers, can't we just change those numbers? Also keep up the good work, I am replacing my S4 soon with the Moto X.
[Verizon Samsung Galaxy S 4] gnubian:
If it were that easy it wouldn't be a problem....changing code voids the checksum and we don't have the key to sign it iirc
[Verizon Samsung Galaxy S 4] tech_head:
No the bootloader is with SHA256. If the signature is not correct then the existing bootloader with not "unlock" to load the new one. If you do in fact manually replace the bootloader by copying partitions, the device will not boot because the settings in flash don't match the bootloader.

Although the MDK bootloader was compromised, it was not unlocked so flashing backwards won't work. If at one time the bootloader was unlocked you might be able to use JTAG or something but the bootloader had never been unlocked.

With Samsung working with General Dynamics and making the S3/S4 platform secure, compromising a hardened bootloader will be a phenomenal feat. Not that it's impossible, but they have attempted to close all the holes.

MDK -> ME7 -> MI1 -> MJ7 -> MK2; each one more tamper resistant than the last.

Now KNOX fully implemented.

Once I am no longer incontract and the phone is out of warranty, they should allow me to unlock my bootloader.

At that point my phone is no different than a developer phone at full retail.

BTW - I bought my phone out of contract, but the edition wasn't available at the time.

Samsung sucks in this regard. I'm waiting for an alternative. The only reason I have Samsung is there is no other S600 or S800 device on Verizon with expandable storage.
[Verizon Samsung Galaxy S 4] gnubian:
You said you bought your phone off contract and expect verizon to unlock the bootloader. You are delusional if you think verizon will unlock it when you are off contract.
[Verizon Samsung Galaxy S 4] decaturbob:
no doubt samsung will never release anything to unlock any bootloader no matter if they are in or out of contract. Cracking this beast is near impossible task with the mix of software and hardware locks/fuses. We gotta of some hope. Hashcode was able to get safestrap in place and so far thru Mk2, its still functional. I suspect that exploit will be closed soon too.

Enterprise customers control the shots and if they want phones 100% secure, they will have it. The rest of us will have choices to go with a dev phone or not until they take that option away.
[Verizon Samsung Galaxy S 4] pyroman512:
I'm starting to look at this from a whole new perspective.. I get why security is a big deal and they cannot just release a bootloader unlocker. Anyone that actually requires KNOX would be screwed if just anyone could unlock their phone. That being said I feel locking the phone down in the first place should be the consumer's choice. When I bought the phone I had no idea this KNOX crap storm was coming. As much as I enjoy samsung products, I may never buy another one.
[Verizon Samsung Galaxy S 4] pingpong1109:
This is the single best idea I have ever heard! It's a compromise. Maybe even have two different ones. A unlockable one for the average consumer that you would buy at your local phone store. Than a Knox secured one for businesses or if you want yours extra secure, but you have to buy it through their site.
[Verizon Samsung Galaxy S 4] JLow0214:
Ya that sounds like a good idea...... do i think sammy will do it.....NOPE!!!!! While i love samsung products because they are made well im probably never going to buy a samsung phone after this one, i mean come on samsung your software is just terrible.... sorry all you tw loving ppl just my opinion.

Sent from my SCH-I545 using Xparent Skyblue Tapatalk 2
[Verizon Samsung Galaxy S 4] pyroman512:
People love touchwiz?? I honestly don't think that samsung cares whether their phones are unlocked. The carriers control it. Based on how much attention they are giving the dev S4, I doubt dev phones will be released in the future.
[Verizon Samsung Galaxy S 4] tech_head:
No. I'm not delusional.

I don't expect Verizon to do anything but try to squeeze every dime they can from me and everybody else.

What I said was, that once a phone is paid for, that is contract fufilled how is it any different than a developer phone.

If I pay full retail, out of contract why should they not unlock the bootloader?

If they are worried about compatibility they could lock the modem.

Keeping the bootloader locks limits my options if I want to move the phone to a different carrier.

Bootloader locking is the new SIM locking.

They want you to pay for a phone but they still want to own and control it.
[Verizon Samsung Galaxy S 4] BJSerpas:
Speaking of Hash, do we have any indication on how he's progressing? Last I heard, he was looking at this exploit, but I haven't read anything else regarding this in his development of SafeStrap.

And that was a while ago, too.
[Verizon Samsung Galaxy S 4] Brooklynsour:
Its all our gov and of course Samsung abiding... I've been following here since the start I think... Can someone gimmie info on weather to update or not, also 4.4 should be coming soon too? (Att s4 mf3 on stock rooted and ss)
[Verizon Samsung Galaxy S 4] ryanbg:
So after running into a few dead ends, I took a big step. I found how to erase and provision rpmb. Not only is this useful, if it doesn't work, I still found how to issue secure commands into TrustZone. I really need to get an S4 so I can play with kernel modules. Or figure out how to enable kernel modules on the N3.
[Verizon Samsung Galaxy S 4] Surge1223:
Nice. I just compiled viewmem for the s4 so I've been looking at the pbl and mostly low level stuff. I'm attempting to make a module using various Qualcomm sources so I can get a better idea of what's going on in the emmc and during early boot (especially in regards to what smc/scm calls are occuring at boot with the TZ). Unfortunately I've had to edit/add a lot more code/addresses from the S4 kernel source that I anticipated.
[Verizon Samsung Galaxy S 4] ryanbg:
I'll pm you with the latest :p
[Verizon Samsung Galaxy S 4] JCBiznatch:
I firmly disagree. There is an exploit that works for every update. Being tested right now
[Verizon Samsung Galaxy S 4] gnubian:
Huh?
[Verizon Samsung Galaxy S 4] :
Samsung is not the one that locks the bootloader, but you know that.

Verizon does it for consumer security, in reality, while it does limit customization, which is the epitome of Android, it does provide a very nice layer of protection against some viruses and low level malware. Most people buy smartphones for Internet and the quick game while in the waiting room. They dont know about the deeper features. So, locking the bootloader adds security and takes away features not many use anyways. Its a win-win, for the majority.

Not saying its right, but it does work.

On the other hand, the S4 dev edition is an entirely different phone. When you buy it, you get it straight from Samsung, without service. You then must purchase a plan and SIM card for the phone in order to use it. The hardware is set up a bit different, there is an actual hardware enforced qFuse that determines the bootloader being unlocked or not. The phone has the MDK build of Verizon Touchwiz, but stripped of the OTA downloader app, SDM.apk, that is responsible for updating. Samsung states that the phone was meant for you to just flash AOSP or something, for the pure Google Android experience, but on the powerful S4 hardware.

My point is that, there is a difference between your off-contract S4 and a dev S4. Buying a dev S4 is like buying a T-Mobile one (which do not have locked bootloaders) and getting it programmed for Verizon. Buying a Verizon S4 off-contract means its still gonna have Verizon's name on it, so they can modify it as they please.
[Verizon Samsung Galaxy S 4] tech_head:
I guess we will need to agree to disagree. The Dev edition can have the bootloader locked if you flash wrong. Same hardware. They could offer same experience on request if my phone is out of contract. They don't own my phone.
[Verizon Samsung Galaxy S 4] tshelby73:
Shall we keep on topic?
[Verizon Samsung Galaxy S 4] ls5454ss:
I'm hoping I don't get smacked for asking this, but...

I just purchased an S4 without realizing all of these bootloader issues, among other setting that are disabled. Does anybody on here see someone coming up with a way to unlock the bootloader in the next 6 months? If so, I'm just going to return the phone and get a G2. Appreciate any input here...I'd trust it coming from this forum over all the others that I have seen. Thank you in advance, and sorry to be of any annoyance. - Steve
[Verizon Samsung Galaxy S 4] jon102034050:
Sorry bud, you can't force these things. It'll happen when we least expect it. Could be 20 minutes from now, could be never.
[Verizon Samsung Galaxy S 4] gunz.jones:
They can't give a time frame. They can work hard, but with the encryption used and currently only a kexec exploit available, it could be as bad as the rezound or, even worse, the Motorola droid series.

HyperDriven MK2
[Verizon Samsung Galaxy S 4] Mightycaptain:
If your within your return period and want to flash aosp. I would take it back. If you're okay running custom TouchWiz roms for the foreseeable future then keep the s4.

Edit... But seriously... The thread is spiraling a little. This is the kind of talk the mods closed the bounty thread for. The Dev vs retail, lock vs unlock who's right and wrong for locking it. Doesn't matter. Practically Everybody who owns this phone wants the ability whether they use it or not to flash custom kernels and AOSP or any other mod. Everybody can definitely agree on that.

Thanks to those with the knowledge for continuing to chug away on a very difficult problem. [MENTION=4939386]Surge1223[/MENTION] thanks for keeping the dream alive.

Thanks to the thread. Keep your thoughts on contributions, ideas or even questions if you don't know the answer related to the bootloader and cracking this beast.
[Verizon Samsung Galaxy S 4] Surge1223:
Yes it should still show that if your system is modified in anyway.

-Anyways, ill post an update with what ive learned/discovered since the OP. Nothing major, just a couple ideas I had. Then maybe one idea helps anothers persons idea and who knows?
[Verizon Samsung Galaxy S 4] phobia09:
I'm now following both your thread and this one from the Note 3 section.

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

I'm from the AT&T side of things and it's good to see bootloader unlocking discussion taking place. Can't say I would be of great help due to my ignorance on the matter. Best of luck to you and I look forward to your findings.
[Verizon Samsung Galaxy S 4] TMcGrath50:
What version are you running? There are many reasons it could show that. If you were loki'd back on MDK, yep, that would show. But also safe strap would do it.
[Verizon Samsung Galaxy S 4] thevance1:
To answer the OP... Yeah we're serious! Get out there and kick some @$$!!!... No seriously though, these developers are great and have hooked me up for a while. They're brilliant and will figure it out for us who lack that talent. So yeah, go team!

---------- Post added at 11:20 PM ---------- Previous post was at 11:15 PM ----------

Sorry guys, didn't mean to cause clutter with that last post or this one
[Verizon Samsung Galaxy S 4] TMcGrath50:
I'm anxiously awaiting your ideas, Surge.
[Verizon Samsung Galaxy S 4] Surge1223:
Okay I need a couple people on MDK to run a python script for me and post the output. You dont need to be python savvy or anything but if you were running linux it be convenient. PM me if you can. All this script is doing is outputing mbr info.
[Verizon Samsung Galaxy S 4] saltytaco:
Apparently someone was able to boot the S3 up from a special prepared SD card. I wonder also if something would come up with GS4. http://xdaforums.com/showthread.php?p=47285482#post47285482