yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S 4] E:V:A:
So does anyone have a good working theory how to do this? (What is it?)

We need a summary of the ideas that we think should work, versus what has been tested (and to what extent).

[43 pages is getting too long for full and clear overview.]

If you have hard beliefs that something would not work, please back up that statement with detailed (testable) reasons why or why not!
[Verizon Samsung Galaxy S 4] Chris Kurisu:
I have also been curious. This thread is fascinating. But I propose that we non-developers treat this thread as a "developer only" thread (unless we're fortunate enough to be called upon as guinea pigs or otherwise).

Requests for progress can clutter and detract from what is, at least to me, an amazing chronicling of this near heroic endeavor. Let us all allow this thread to be as efficient for our soldiers as possible.

I, for one, rest assured that many other pet projects along with quite a few paying ones have been placed on the back burner. I don't want to do anything that might cut their groove in the slightest.

So during this time, I humbly suggest we quietly try to read between the lines of these posts that make no sense to us non-devs and trust that our devs are doing their utmost for the community.

Let's all warm up our index fingers and thank the heck out of each of our devs.
[Verizon Samsung Galaxy S 4] jamesd1085:
We don't mind long posts coming from you and jeboo...lol...though many of us fail to understand most of what you guys post you being excited enough to post it tells us its a step in the right direction... Lol...keep up the great work guys!
[Verizon Samsung Galaxy S 4] :
Looks like he's "out" http://xdaforums.com/showthread.php?t=2608827
[Verizon Samsung Galaxy S 4] Surge1223:
Okay if you're wondering why I forgot to add 3,4,5 and 6, I didn't forget, I just got distracted (which in this case is good news). I happened to come across some useful files/data. I'll summarize:

1. I extracted data from my old S4 (long complicated and not fully understood process) about 4 gb worth. 1.6gb of is in the form of an adb backup (.ab file extention) that I cant extract yet because either my Java is out of wack or I don't have the password. But of the remaining ~2.4gb I can freely see but all files are renamed and most are in .txt, .elf, or .tar.gz format and they are in 48 separate directories with over 70 files in each so I haven't had time to go through all of them. I did find an interesting log though, I posted a snippet of it here. I got curious and typed /system/bin/ks into terminal and here is the output:

​

2. I came across some very useful files (also will make IDA analysis easier) I have a few I9505 ELF files, namely RPM.elf and its legitimately from the European I9505

So we may be able to use these somehow..maybe not to flash but for something else maybe..

3. Based on initial analysis, the function that determines "MODE: Developer" is still implemented the same as in ME7 and MI1, but the location has changed slightly which makes sense since starting with ME7 the aboot has slightly increased size with every update. The below is a picture, but don't hold that address as 100% accurate because that was just an initial analysis and that idb was quite large (sbl1-3, aboot, tz, rpm).

​

4. I also retrieved the output of the following:

[MENTION=4372730]E:V:A[/MENTION] I was basically using the documentation you provide in the chipset architecture post...are there any updated pdfs and/or changes to that data regarding the addresses for the pbl, qfprom etc?
[Verizon Samsung Galaxy S 4] sokrboot:
I wonder what the "old" PBL boot structure is?? (reference your first pic). Could it be a way to get ME7 and later versions back to a loki-able state?
[Verizon Samsung Galaxy S 4] ryanbg:
I think it's in reference to pre-Knox PBL, or before they fused to prohibit custom binaries.
[Verizon Samsung Galaxy S 4] decemberchild:
I'm not entirely sure if anything is going to come from this thread, but I sure hope it does. I do have a question. Can all of the stuff being done also work on the att version?
[Verizon Samsung Galaxy S 4] jamesd1085:
It may share enough of the same code to work for att with little to no editing...may not help at all
[Verizon Samsung Galaxy S 4] failedjedi:
In theory. It's highly unlikely samsung has 2 different methods of locking down the same phone. There may be minor differences, but in theory any major exploit should work on both.
[Verizon Samsung Galaxy S 4] ky5ever:
Im not a developer and I really dont want to further fragment this thread, but I want to state here and now, that Samsung had nothing to do with the locked bootloaders on any of the phones. This is entirely Verizon and AT&T's doing. T-Mobile has the phone completely unlocked.

Knowing this, it may be that this exploit does not work on the AT&T variant of the S4. We will have to wait and see.

But please, do NOT go and think that you can just unlock any phone if and when the devs release something. Be sure to READ and LISTEN TO THE DEVS so you dont brick your device. Thats the last thing we want.
[Verizon Samsung Galaxy S 4] joshm.1219:
Well obviously it's the carriers who want the bootloader locked, but isn't it Samsung who actually does the "locking"? Just speculation of course, but my guess would be that the same method could work for multiple carriers if one was discovered. It's only recently that carriers other than Verizon are locking bootloaders right?
[Verizon Samsung Galaxy S 4] ky5ever:
Its the carriers that doo the locking, yes. Samsung stated in a blog post that KNOX was made to allow you to boot custom ROMS and kernels naturally, with no problem, but doing so will set the warranty flag.

Verizons bootloader lock is different than the one AT&T uses. Similar enough that it should be hard to port any exploits to work on it, unless the exploit was literally the key to the bootloader. If that was the case, the key to Verizons house wont work on AT&Ts house.

Also, it was only recently that any carrier decided to do major locking. If a device was locked, it actually was from the manufacturer, but was relatively easy to unlock. Think of HTCDev. Some phones come locked for enhanced security regardless of what the carrier does. Carriers can add further security to prevent you from EVER booting a custom ROM, but if the carrier doesnt mind, then you simply load up HTCDev and use their tool and youre unlocked. Simple. You void warranty, and accept you can only get help from the community, but thats a good price to pay.

For some reason, it switched. While HTC still locks bootloaders, just for those who want it, carriers are doing their own thing and preventing any form of customization because "we only want secure, tested, and approved devices on our network, to ensure the safety of our customers."

Well, at least thats what Verizon said.
[Verizon Samsung Galaxy S 4] failedjedi:
Yes. The carriers decide to lock it, but it's still Samsungs technology, and they do the locking. It's samsungs security system, knox is samsung, and you need Samsung signed stuff to do anything.

Any exploit found in theory would not only apply to the other carrier S4's, but also to the note 3.

So there is probably differences, but the underlying tech is very similar if not the same, just how it's executed could be different. Until an exploit is found for one of them though, it's hard to be certain.
[Verizon Samsung Galaxy S 4] joshm.1219:
Two different opinions?
[Verizon Samsung Galaxy S 4] coolsilver:
Removed
[Verizon Samsung Galaxy S 4] jd67890:
Verizon

So what if we all called Verizon and threatened to switch to T-mobile because of the BL? You think they'd unlock it to keep their customers?

On another note, they will price match t-mobile!
[Verizon Samsung Galaxy S 4] gnubian:
no they would laugh in your face. Let's keep this on topic...
[Verizon Samsung Galaxy S 4] ky5ever:
Guys, please. I told you I didnt want to fragment this thread, its already on the brink of death because people keep asking questions like these.

If you want to argue over whose fault it is the bootloader is locked, lets make another thread.

But please, lets keep this one as clean as we can.

Ill say it once more to clarify: Samsung did nothing to lock the bootloader. There was a blog post saying those exact words, but it led to people bricking their phones because it described how to flash custom recoveries and ROMs but didnt state that some carriers, namely Verizon and AT&T, added further measures to prevent this. I contacted Samsung directly, and they confirmed it isnt possible on those carriers, and they will revise the blog post.

Now, please, pretty please with sugar on top, let me take the blame for starting yet another tussle, and lets keep this thread to the devs.
[Verizon Samsung Galaxy S 4] Surge1223:
Okay, let's steer this in the right direction. Well usually aboot is the problem, but for our device id say the TrustZone (tz.mbn) and Resource Power Management (rpm.mbn) are more if not equal to aboot in terms of being roadblocks to getting this thing unlocked. Now messing with the rpm is dangerous as it can easily render a device inoperable. The image below is referring to 8660 but I think it still applies to our device.

Now with jeboo's exploit, im going to attempt to compile a module that will allow us to access/trace SMC calls in the TrustZone's "Secure World". Ive determined the address that aboot queries through the TrustZone to determine if a device is a "Developer" type or not. But we currently have no access to that area. If I/we can trace where/what is there we can get a better understanding of where were at.

Theres some complications with this though, not every driver or module has access to the TrustZone's "secure world" so its going to be a trial/error process of compiling modified modules, then using bypasslkm and determining the output etc. I have good reason to believe bluetooth based modules may have access so ill start there.

Figuring out a way to convert our device to a developer edition isnt the only interest we have for entering the TrustZone. If we could manipulate it elsewhere we could also remove the blacklisted aboot checks and/or run code to boot to an "insecure aboot" similar to what Ralekdev did when he exploited the Note 2. If anyone knows more about the TZ please feel free to point out the flaws in my logic. Ive been heavily studying the TZ from both analysis of the way it works in our device and from as much Qualcomm and ARM documentation that I can find.

...Unrelated but also this could be used as a means through which we could learn more about the possibility of reseting the warranty void bit aka the "knox warranty void counter" since ive confirmed its sent through an SMC call as well but if anyone is more inrerested in that they can start a new thread about it.
[Verizon Samsung Galaxy S 4] NighthawkXL:
Sounds great, and I agree a new thread could go a long way with gaining for traction... start fresh with a recap of all we've learned here. A more popping title name could also draw some other people our way to. Also, did anyone take a look at jeboo's latest essay in the BypassLKM thread it was quite informative, despite not being able to be applied to us at the moment with the BL still locked. Lastly, has there been any updates on Hash's kexec module he's attempting to make for Safestrap using the BypassLKM exploit? I can't help feeling we're definitely on the right track...
[Verizon Samsung Galaxy S 4] Surge1223:
By the way I may not have been clear on how to use viewmem. Ive attached a zip of the version that works specifically for our S4 (its also in the S4 viewmem source I attached earlier but unless you know how to use the source file it isn't the easiest to understand what viewmem file you should use)

1. Unzip viewmem.zip

2. adb push /path-to-unzipped-viewmem/viewmem /data/local/tmp

3. type adb shell then:

viewmem usage:

1. first cd /data/local/tmp

2. refer to this post but whenever it says to use "hexdump -C" instead use "hexdump -Cv" that way you see all the data. To read the output either use cat or open the file with a text editor.
[Verizon Samsung Galaxy S 4] pingpong1109:
If we start a new thread can it get linked here because I have been following this thread for months and don't wanna lose reading these comments
[Verizon Samsung Galaxy S 4] gnubian:
what on Buddha's green earth are you talking about. Stop posting unnecessarily. They meant starting a new thread for comments that do not contribute to unlocking the BL . U can always still follow this one.
[Verizon Samsung Galaxy S 4] daredevl99:
Several pages back someone mentioned using a fake cell tower to send a modified ota. Just wanted to bring this idea up again but with some tweaks. For ps3 there is a "proxy" tool that allows you to redirect outgoing connections from the ps3 to anywhere you want. It is used to install pirated games and what not on non jailbroken systems. We could either adapt that application to apply here or build our own. The ps3 is set so that you cant install pkgs (games etc downloaded from the ps store) unless bought from the ps store. Using this method you can trick it to think the pkg you are installing is from the ps store as long as it is a legitimate sony pkg. This may work for us if we redirected the ota query to our computer and it downloaded this ota with a modified cot to allow unsigned or non samsung installs. May work i havent looked into what checks for a valid ota if anything does.
[Verizon Samsung Galaxy S 4] MehStrongBadMeh:
Just like the previous fake cell tower suggestion. This suggestion completely ignores the fact the phone enforces signature verification at a hardware level on every single boot (using q-fuses to alter said signature every update). Installing a modified bootloader is easy, making it actually boot... Well, that's why this thread exists.
[Verizon Samsung Galaxy S 4] daredevl99:
I understand it is checked at boot. Was just throwing an idea that might be able to circumvent some verifications as it did on ps3. Didnt expect it to work just thought id speak my thoughts.
[Verizon Samsung Galaxy S 4] ryanbg:
This is a viable (although not probable) option, although it won't be like a fake cell tower. The FOTA key is universal, and if we got it we could make something happen.
[Verizon Samsung Galaxy S 4] Surge1223:
Im not very knowledgable about the fake cell tower scenario...someone else would have to comment/work on that. Im still exploring the TZ route. Understanding the TZ is kind of a pain because of the limited amount of actual exploits that utilize the TZ and the relatively small amount of useful documentation. I still think this is the best route though based on how unexplored it is and how much privilege it has.
[Verizon Samsung Galaxy S 4] daredevl99:
I agree this is the best plan of attack. The only draw back is as you said. Have we found out why hellsdroid was busted? Personal reasons or because of what he found? If its the latter then our best hope is he was just forced to do some jailtime worst case he was sued into telling them how he did it but the likelyhood of jailtime for this reason is low i would think
[Verizon Samsung Galaxy S 4] gnubian:
I don't believe it's illegal to jtag.
[Verizon Samsung Galaxy S 4] ky5ever:
I have a Samsung SCS-2U01 femtocell on Verizon. While Surge is busy with the TZ and Hashcode works on kexec, Im going to fiddle with the femtocell and look into anything we could exploit. This article on Digitaltrends says its possible to really get into the data handled by a femtocell, letting a hacker do everything from read SMS to record calls to even cloning a phone's device ID and making it think another phone has that ID, which essentially lets the hacker make calls and suck through data but have it accounted to the victims phone, charging them lots of money. This was able to be done despite the femtocell having preventative measures to block data re-routing and device ID cloning.

There has to be something we could use. Whether it is tricking the phone to accept a modified OTA or simply getting some info that is otherwise locked down, this is a viable route to take and Im willing to give it a shot.

Ill let you guys know what I find.
[Verizon Samsung Galaxy S 4] Mistertac:
Keep up the awesome work guys! Wish I could help. Very interesting to read all you're updates everyday though
[Verizon Samsung Galaxy S 4] Nicgraner:
I made a joke about that earlier in the thread... It seems many took it literally.. Oops
[Verizon Samsung Galaxy S 4] Hdhntr23:
Fascinating stuffs here guys.

Thanks for all your efforts.
[Verizon Samsung Galaxy S 4] daredevl99:
It is illegal to modify copywrited material in some cases is what i ment. Probably not for android as it is ment to be modified but it is possible.
[Verizon Samsung Galaxy S 4] gnubian:
To avoid getting off topic again I'll simply state that jtagging a phone into a state that allows STOCK mdk to be flashed, as hellsdroid did, is neither illegal nor involves any modifying of copyrighted material.
[Verizon Samsung Galaxy S 4] pingpong1109:
I don't think it would be illegal because if we jtag mdk than we aren't modifying
[Verizon Samsung Galaxy S 4] ky5ever:
I dont suggest anyone try to mess with a femtocell as of yet. Femtocells use your existing internet to provide signal, but can run temporarily without internet if a nearby tower is available. It will use its stronger antennae (compared to the one a phone has) to boost the signal.

Femtocells use your existing wireless router to connect to the phone, but once connected, the range extends for several hundred feet using the femtocells own antennae.

I have set up a system that allows me to use the femtocell for those brief periods without it authenticating with Verizon. Managing the femtocell software shows a surprising bit of data collected from phones. Phones seem to willingly "trust" the femtocell, but only for a few minutes, then it re-authenticates to prevent the phone from using a hacked or malicious one.

Anyhoo, Im going to see just how "trustworthy" phones think femtocells are, because it seem that, as long as it is done through 3G/4G instead of WiFi, an OTA file (that would fit in the cache partition) could be loaded, if I could just figure out how such files get authenticated. The femtocell does seem to cache network data on my PC its connected to, so, maybe, just maybe, Im onto something.

Please dont put too much faith in this, though, because abusing femtocells apparently can ban the IMEI of your phone.....:crying:
[Verizon Samsung Galaxy S 4] mnasledov:
Maybe you need a Faraday cage for dev/testing :P
[Verizon Samsung Galaxy S 4] zmedhaug:
The Key

I jtag'd my hard bricked phone. It lost its IMEI and could not be jtag'd to MDK. It would only accept ME7 and later. Apparently there's a fuse in the processor that blows after bootloader install. BUT somehow Verizon can write their new bootloader on them so in theory it's possible. If I was smart enough I'd say reverse engineer one of their updates. Find the KEY to how they wrote new bootloader.
[Verizon Samsung Galaxy S 4] Brooklynsour:
Guys leave this post to developers, tell them thanks after they finish the mission, for now just give them ? to avoid filling pages with no real info... Sorry to post this but everyone not developing needs to just read, please guys do this for the people putting time and effort
[Verizon Samsung Galaxy S 4] zmedhaug:
Like your post? Stop being a cop no one cares if you think a post was useful our not
[Verizon Samsung Galaxy S 4] tech_head:
The key is the bootloader needs to be signed.

They (Samsung/Verizon) uses a SHA256 hash to sign.

We aren't going to reverse engineer it. An exploit will need to be found in the kernel or bootloader itself.
[Verizon Samsung Galaxy S 4] KaratemanTJ:
This thread keeps filling up with crap from non-devs and people restating the same wrong ideas. If people want to argue about how stupid they think Samsung or Verizon is do it elsewhere. Just want your bootloader unlocked but don't know how, read this thread, but please refrain from posting unless you're absolutely certain it's useful. Otherwise this thread will cease to be useful and get closed like the rest. /rant
[Verizon Samsung Galaxy S 4] zmedhaug:
That's exactly what I mean, use this signature to sign a MDK bootloader to device with a later bootloader.

---------- Post added at 01:27 PM ---------- Previous post was at 01:25 PM ----------

Yes because THIS was so useful, thanks for restating this.
[Verizon Samsung Galaxy S 4] MehStrongBadMeh:
The private key needed to produce a valid signature can only be discovered either by brute forcing it (which would take a ridiculously large number of years) or by it getting leaked from an official source (which is highly unlikely).
[Verizon Samsung Galaxy S 4] tech_head:
We've been down this road of discussion already. Exploited bootloader is going to be it.
[Verizon Samsung Galaxy S 4] ryanbg:
I believe I found out how the STRAP flags in ODIN mode work. It appears they are Qfuses, but what I find interesting is awhile back I was accidentally able to 'downgrade' my P flag from P1 to P0. AP RAW ANTI ROLLBACK is the name of the QFPROM register. I believe I found the correct memory addresses for these fuses also. The fact one was able to be reset leads me to believe that the shadow register is being used as opposed to actually reading the fuses or if they even 'burned' them. These flags control the SYS VER flags and what files can be flashed depending on their fuse count. Ideally, I could either change the fuse or find the SYS VER flag and change it. Still lots more research to do, but we are getting closer every day.

I'm still trying to figure out what the P flag is for, but I believe it controls Qualcomm Secureboot (separate from the Samsung Root-of-trust) but it certainly helps. It could be PARAMS or another member suggested DBL. Nonetheless, anyone with actual information or evidence supported ideas, feel free to PM me.

---------- Post added at 03:20 PM ---------- Previous post was at 03:16 PM ----------