yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S 4] scryan:
The mehtod reffered to in Surge's original post was fairly obviously just trying to scam people into them sending hellsdroid brand new flagship cellphones. It was when the S4 was new, and he never posted ANY information other then that he could do it if you sent him your phone. When people started offering thousands of dollar for the method(well offering him the bounty), he was suddenly in jail and couldn't respond. At some point since then it seems he either admited to not being in jail, or was released... But he never responded to anyone who knew enough to not be bull****ted.

The link is for a thread where 1 person who worked for verizon thought a developer plan was a decent idea, and said he will pass it along. Another employee was later quoted in the same thread as saying VZ would never do it. Even it VZ did, if it started now the S4 would be obsolete by the time VZ finished doing their research and testing and actually unrolled the program.

The only talk about unlock codes in that thread is 1 guy, who claims "his friend" had his phone unlocked because he worked for VZ. Not saying he is lying, but if you read his posts in that thread they are all arguing about how he didn't buy a phone with a locked bootloader, and its everyone elses fault he cannot unlock his... Arguing and fighting with Devs who are explaining why his ideas wont work.

ANYTHING is worth looking into, or at least considering if its realistic... AND I AM NOT SAYING THAT GUY IS A LIRE, but I am saying he seems more worried about being pissed off an arguing then understanding, and I would not be surprised if he had at least a few facts wrong.

Note that that technique was used by the moto x guys... Who have a bootloader that can be unlocked via an unlocking program with codes distributed by VZ. They were using it because VZ and perhaps ATT would not let the codes be given out for their models... So even with way more data points then we will be able to put together, it yielded nothing in that case.

Don't mean to sound like I am saying give up. Just saying realize what your up against and manage expectations... Seems like everytime an idea like this comes up you get a group of people who suddenly think were on the doorstop of an unlocked. We likely haven't even found the walkway upto that doorstep.
[Verizon Samsung Galaxy S 4] toaster22:
Thank you for clarifying that for me. I was a little confused about all the original posts. As well as to why no updates had been given about the Dev Devices being used for unlock (unless I missed it, very well could have). Don't want to say I didn't get it because I'm new, but my reading comprehension does suck sometimes. :p

I'll go back and read all how many ever pages exist in this thread and see if I can't learn something and be more useful :)
[Verizon Samsung Galaxy S 4] MorrisC2010:
Yes I completely agree. Although Surge's find is the best lead we have by far. It's still a ways to go. And it's not really a bootloader unlock, more so a boot sequence hijack. Please read any and all resources before posting. [MENTION=4939386]Surge1223[/MENTION] you said you mixed and matched hash's source with the new addresses you found in nc5?
[Verizon Samsung Galaxy S 4] joshm.1219:
Great explanation, not sure if hellsdroid was really trying to scam people because he was a pretty active developer beforehand, but it was definitely a really weird situation. Oh and "LIRE" was cringeworthy hahah you're too smart for that.
[Verizon Samsung Galaxy S 4] gsciullo17:
I didn't know that that method was kind of forgotten about and you guys moved on. I just saw it and posted it to see if it was any help (I also said that it could very well be useless) haha. But thank you for explaining that to me it sets things straight a bit :p well I'll see if I can find anything that could potentially help you guys. Kepp up the good work.
[Verizon Samsung Galaxy S 4] scryan:
Yeah, I kinda don't mean to outright call the guy a scammer... But **** it I kinda do.

I have to say since day one of his thread, All I read was "send me that $600+ thing you just got..." (ok not his exact words lol)

He had whatever title like "Recognized Something Or Other" and seem respectable so I held my tongue... Then he said he was busy in jail and TBH that didn't help convince me he wasn't scamming. I guess I still feel like its not my place to call him a scammer, you never know and I would hate to alienate someone who has answers... But yeah bull**** detector been screaming pretty loud on that guy since day 1, and he certainly is VERY hard to reach at convent times.

I am border line retarded with speeling (sp?)... I swear spell checker complained at 'liar", the first time... I knew that lire wasn't right, but was at work and that's what spell checker wanted, and well... **** it. I'm OK with being written off, lol.

the method from the OP was actually a little bit different then the method of collecting unlock codes or even directly using images from dev device. JTAG was originally hoped as a way to re-write some of the lower level software without having to use the provided recovery or any other typical official means, mainly so we (lol, they) could get past the issue of security checks that prevent you from even writing your own software to the device. Among other set backs it turned out that even if you get that software written there are enough other checks that the device will refuse to boot.

As far as "unlock codes" and compairing them... I can't think of really hearing ANYONE trying this, at least for the S4. They were doing it on the moto X and were not able to get anything from it. I think it is written off in the same way that brute force attacks are written off, Because the possibilities are so great it could be decades of guess and check.

That thread was actually the first time I had heard of "unlock codes" for Samsung. In fact when Dan released his trusted zone exploit and demonstrated it on the Moto X, part of the reason it was said to not be that promising for Samsung is because while the Moto X contains a mechanism to unlock the bootloader based on a code, the Samsung had no single point that would unlock it.
[Verizon Samsung Galaxy S 4] Surge1223:
[MENTION=766721]ryanbg[/MENTION] and I spent an extensive amount of time reversing the function that determines if a device is a developer edition or not. For the time being, an unlock code would not be enough. That and it's highly risky to rest anything because the value resides in aboot memory.
[Verizon Samsung Galaxy S 4] KaratemanTJ:
What kind of checking goes on in that function? Also, when you say memory do you mean RAM or flash?

Oh, one more question. Is the kernel source on Samsung's site the exact same as what's running on our phones or are there differences?

Thanks!
[Verizon Samsung Galaxy S 4] Surge1223:
I wish, we need to report Mr. dpi for violating GPL

I'll post a bit of that function in a few minutes
[Verizon Samsung Galaxy S 4] Deliquified:
Not sure if this will help you guys, but I do remember AdamOutler was responsible for the bootloader unlock for the GSIII. Perhaps he could help with this one as well? As I recall, JT1134 also was very active in kexec implementation. Here is a research thread that went on during their findings.. Perhaps it can lead to a breakthrough or help implement kexec. If it's not helpful at all, my apologies. Have a look.

http://xdaforums.com/showthread.php?t=1769411 [R&D unlock bootloader]

http://xdaforums.com/showthread.php?t=1756919 [bootloader research and news]

http://www.epiccm.org/2012/07/kexec-and-proof-of-concept-source-built.html?m=1 [TeamEpic Kexec stuff for research]
[Verizon Samsung Galaxy S 4] broomstickmop:
Damn good sh*t! Making alot of head way.

You got watchdog disabled which is a driver that reports malicious attempts I believe?

Then you had a couple of successful TIMA passes.

alarm_set_rtc failed to bet set so time will be lost on reboot.

There was a kernel panic while deleting a list which was recovered from.

Not sure what 'seC_debug_set_upload_magic' is all about, but the line after makes it do something.

tz and 'trustzofe' memory load up, a RPM at sbl2 is loaded & executed upon, but canceled.

Another image is loaded from a different point in memory and loads successfully.

Then android loads up and everything seem to boot.

A Roll back is started and then you get a msg 'Welco-e to LK'

Couple things boot, (LCD, USB, HW registers, etc)

Skip, Skip, Skip,, Buffer overflow executed (taking note of 'HTML content 2708247' for now), and then there is now no "Trustzone" memory.

A couple of mages are loaded, Skip, Skip, Skip.

'Welcome to Lk' and linux & android load up

Also note the following for now ""

[1460] check_ramdump_mode :: k_param.debuglevel[0x47494844]

[1460] Do checksum V2

[1470] Not Need Movinand Checksum""

Skip, Skip, Skip, (now im getting lazy lol)

"""[3950] SECURE magic check passed...

[3960] SEAndroid magic check passed...

[6030] [TIMA trusted boot]: Boot-time measurement successful""

And everything seems to pass boots && checks.

So where to now? :cool:
[Verizon Samsung Galaxy S 4] jayyskittles:
Any news on this? I actually have a Verizon S5 and was wondering if there is anything I can do to help. I'm currently running the newest NHA OTA, rooted and SS. Anything at all, just lemme know!
[Verizon Samsung Galaxy S 4] V0latyle:
Wait, there's a newer OTA than NC5?
[Verizon Samsung Galaxy S 4] joshm.1219:
He has an s5
[Verizon Samsung Galaxy S 4] V0latyle:
Woop...yup. I'm a dumbass
[Verizon Samsung Galaxy S 4] jayyskittles:
Ah, my friend, there are no such things as stupid questions. xD
[Verizon Samsung Galaxy S 4] scryan:
Hugely wrong btw.

Infact, there are infinitely many more stupid questions then smart ones... Particularly because it takes no thought to put together a stupid question.

The upside to all this is that while there may be stupid questions, its still entirely better to ask a stupid question and in doing so be smarter then to just hold it in and continue to be stupid yourself.
[Verizon Samsung Galaxy S 4] V0latyle:
Not always...has anyone died from holding in a fart?
[Verizon Samsung Galaxy S 4] Neontc:
I did once..
[Verizon Samsung Galaxy S 4] :
Any more progress yet surge?
[Verizon Samsung Galaxy S 4] Surge1223:
Nope, haven't tried to do much lately though. Between rom'ing, the NFL, investigating some up coming 4.4.4 issues we will face etc I have been busy but more than half of this is research so it'll likely be some time before you see real world results.
[Verizon Samsung Galaxy S 4] saantiago:
probably a dumb question, but apparently i was one of the last people to have mdk before i upgraded my bootloader without knowing i couldnt go back.

im on 4.3 with mk2 at the moment, and have tons of backups for 4.3 on mdk. if i restore any of those backups with safestrap will i be able to get back to mdk? thank you.
[Verizon Samsung Galaxy S 4] Thr33-F0ur:
No. The backup you have is only the system and data partitions. Once you upgrade from mdk, the bootloader can't be rolled back.
[Verizon Samsung Galaxy S 4] Surge1223:
I believe you'd get more help in Q&A..
[Verizon Samsung Galaxy S 4] drake90001:
If you need any help from an AT&T user now or later, I'd be more than willing to help. I have the i537 running the newest release rooted and ready to go. Just PM me if you do.
[Verizon Samsung Galaxy S 4] ahmed.zubair:
Me Too . Verizon user i9545. :D
[Verizon Samsung Galaxy S 4] gsciullo17:
I know this has probably been discussed at some point in the 100 pages of comments, but have we tried attempting to transfer all of the device specific files from a developer edition device and attempt to convert it? In the OP it says that #2 is still a possibility. I came to this thought after safestrapping my S4 to the GPE ROM that was made compatible for us. The ROM, at default, was setting our phones to GSM mode (I know this is because it was built for AT&T and someone figured out a way to get it working for Verizon), and we were able to change our radio to look for CDMA/LTE. After this, people started finding out ways to move to another carrier with either this method or the other ones brought about. I'm not saying that the antenna settings have anything to do with the bootloaders, but I was in hopes that if we are able to convert a Verizon phone to AT&T, could we somehow use a Developer Edition ROM built for Developer Edition S4's to get the method that is used to tell whether the S4 is a retail or Developer Edition? Just a thought. If this is possible, I am totally willing to help.
[Verizon Samsung Galaxy S 4] SamuriHL:
It won't work. Each developer edition device has their aboot partition signed with a key that's created by using some of the device information.
[Verizon Samsung Galaxy S 4] toaster22:
Post 1472 on page 147 gives some light on #2. As to if it remains possible, it could be. But it sounds like some extra protections remain on the Dev Editions so it would be more unlikely.
[Verizon Samsung Galaxy S 4] gsciullo17:
Thanks for pointing that out to me I couldn't find where it was. But in the OP it is stated that the Dev Edition ROM is bootable and the only part that doesn't actually work is when trying to boot into recovery. Question, is the recovery updated with the boot loader each time or does it stay the same? I was just wondering if maybe the recovery was an older version (I dont know if there are different recovery versions) but if so, could it be the same one that we could use the Loki exploit with? Or is that a boot loader restriction? This is all theoretical, and may bnot even be correct. Just an idea that someone with more knowledge could chime in or correct me on.
[Verizon Samsung Galaxy S 4] DeadlySin9:
The recovery has been updated, but the Loki exploit isn't in the recovery. It's in the bootloader to allow a custom recovery.

Sent from my SGH-I337
[Verizon Samsung Galaxy S 4] Surge1223:
The checks on recovery and kernel reside in aboot, and as Samuri already said there are checks there we can't fake or bypass. Hope that helps.
[Verizon Samsung Galaxy S 4] gsciullo17:
Yeah thanks for explaining that. I know that kexec is a possibility now but I was hoping that maybe what I said would spark something. But like I said, just a theoretical idea :p but I do hope that kexec works out and we are able to use that to almost have the same abilities of an unlocked bootloader. I've been living with this locked device for a year now and I'm definitely willing to do anything to contribute. I'll try to test some stuff out myself and do some research. Hopefully we can get this thing unlocked or exploited.

---------- Post added at 04:56 PM ---------- Previous post was at 04:53 PM ----------

And also, in the OP it says that converting a retail to a Developer Edition is still a possibility. What has and has not been tried? What is still possible to research? Like I said I'm willing to contribute to whatever research is needed. I'm not super experienced like some of the Devs on here but we all have to start from somewhere.
[Verizon Samsung Galaxy S 4] SamuriHL:
I guess you missed my reply on that. A developer edition is only different from a retail edition by virtue of having a specially signed aboot partition. This is not something you're just going to "figure out". You have to know exactly what device information they pull, have their private key to sign it, and then append it to a block at the end of the aboot partition before flashing it. I assure you, that's not a "simple" process.
[Verizon Samsung Galaxy S 4] gsciullo17:
I never said it was simple, if it was simple, it would be done. I guess the wording I used wasn't good. When I said I hope we "figure it out" I meant a way to exploit the bootloader in general. It was brought to my attention before my second reply that my idea wasn't possible. I was pertaining to helping contribute to the Devs who are working on this, and I wanted to help. And I also didn't know you posted that about the aboot partition and the private key, well those exact ideas anyways. But bare with me, I'm not super experienced, like I said, I'm just trying to spark some ideas :p
[Verizon Samsung Galaxy S 4] SamuriHL:
What I'm saying is, that without knowing what information they pull and having the private key to sign it, creating a signed aboot partition that turns a retail phone into a dev edition is impossible. The likelihood of finding that private key is almost 0. The mechanism for determining secure boot vs non-secure boot (i.e. locked vs unlocked) is fairly straight forward. If aboot contains the signed certificate then it'll boot up non-secure so you can overwrite things like the recovery partition. If aboot does not contain a signed certificate, it boots up in secure mode with all the fun security checks that go with it. You can't take aboot from one phone and flash it on another as it won't match. This is also why dev editions don't receive updates. There's no way to individually sign new versions of aboot for each device to keep it unlocked.
[Verizon Samsung Galaxy S 4] Hashbang173:
Was the private key included in the qpsa stuff leaked? I know it was taken down. Sorry for asking a question that's kind of stupid.
[Verizon Samsung Galaxy S 4] SamuriHL:
I honestly don't know but I SERIOUSLY doubt it. But I can't answer that definitively.
[Verizon Samsung Galaxy S 4] Surge1223:
No
[Verizon Samsung Galaxy S 4] Surge1223:
Also, the developer function also goes more in depth than that. Not sure if this is OK to post but whatever

at 0x88E08174 it checks ddi value in case anyone is wondering

And yes I did cut out info for the sake of space.
[Verizon Samsung Galaxy S 4] SamuriHL:
Nice info!
[Verizon Samsung Galaxy S 4] V0latyle:
Pardon my ignorance here, but...Surge found a way to load insecure modules into the kernel while running. The question in my mind is...would it be possible, with such an insecure module, to access kernel residence and change it at whim while the kernel is running?

I honestly dont know what much about Linux so again pardon me. Also I assume that since aboot verifies kernel integrity, any changes would brick the device.

Seeing as we have whole flashes available for ODIN, this could also be possible through reverse engineering a bootloader then flashing it via ODIN...question is, where do the integrity checks stop? How low can we go?
[Verizon Samsung Galaxy S 4] DeadlySin9:
As far as your first suggestion, that sounds similar to kexec the way you explained it. A kexec module would allow loading a kernel over the existing one, which is exactly why we wanted unsigned modules in the first place (mostly anyways, devs may have other benefits). It would replace it after those checks. As far as whole ODIN flashes, the checks prevent that and getting it properly signed is a whole ordeal.

Sent from my SGH-I337
[Verizon Samsung Galaxy S 4] Surge1223:
By disabling some TIMA checks we can modify the live kernel. We can't flash a bootloader that has been patched because it would fail since this would alter it's hash. The integrity checks don't stop... Everything (in the bootchain) is checked until the system is booted.

I have been Modifying the live kernel with insecure modules, but it's not as easy as writing a module that says "shut down everything then reboot a custom kernel and dont panic while I pwn you" lol. I have however been able to shutdown the cpus and drivers for the most part and bring them back up without a hard reboot, with custom modules still loaded so that's a plus.
[Verizon Samsung Galaxy S 4] SamuriHL:
That's definitely progress!
[Verizon Samsung Galaxy S 4] TheLoonyRebel:
That's huge news Surge. I'm curious but how far off is that compared to the Kexec work that's been done on the Verizon Note 3?

http://xdaforums.com/galaxy-note-3/devs-only/kernel-kernel-execution-loading-custom-t2812650

It would be amazing if something from either you work on the S4 or the work [MENTION=5868929]hsbadr[/MENTION] has done on the Note 3 can get Kexec closer to working on both devices but I dunno how far off things are on either device when comparing one to the next. Regardless if you need me to guinea pig my S4 (or Note 3) let me know I'll do my best to help test things on my end.
[Verizon Samsung Galaxy S 4] Bright09:
Glad to see some work improvement hopefully can have i535 unlocked again js
[Verizon Samsung Galaxy S 4] V0latyle:
It almost sounds as if running AOSP might be possible in a virtual machine, enabled via an insecure module...
[Verizon Samsung Galaxy S 4] KaratemanTJ:
Running anything in a virtual machine will be painful due to all the overhead. I'm sure it could be done though.
[Verizon Samsung Galaxy S 4] ryanbg:
I know it's been awhile, but I've finally discovered the mechanism that sets the Developer edition flag in aboot. There's two hard-coded hashes/signatures/keys (not sure which yet) that are 208 bytes, or 1664 bits. The first hash is used to verify the boot.img hash on the kernel, and the second is the Developer mode hash. That second hash is verified against the second signature in aboot seen on Developer devices. My question here now is what key are they using to sign these signatures (since it differs from the secure boot private key, and boot image key), what is the signature hashing in that second Developer signature, and why/how is it universal since it's in every copy of aboot.
[Verizon Samsung Galaxy S 4] SamuriHL:
The developer signature is created by signing a copy of the cid partition and appending it to the aboot. It's not the same for every device...it's quite unique per device. I have no idea what key they sign it with. I'm quite sure we don't have it and aren't likely to get it.
[Verizon Samsung Galaxy S 4] ryanbg:
What partition is the CID? Is it an eMMC hardware partition? I've seen no reference to a 'CID Partition', but the CID itself. Perhaps this is SHA256'd then encrypted? Please elaborate :D
[Verizon Samsung Galaxy S 4] SamuriHL:
I sent you some info.
[Verizon Samsung Galaxy S 4] Surge1223:
Have made quite a bit of progress on kexec, i figure ill post sources and the community can help from here.

Currently, its failing to shutdown the system drivers properly so the device becomes slow after exection, i have fixed a lot of the earlier panics though.
[Verizon Samsung Galaxy S 4] broomstickmop:
Come a long way. Seem's like kexec will be the way to go. Still need Safestrap updated?
[Verizon Samsung Galaxy S 4] ICSthunder27:
Excited!

Are we close any sort of loki or bootloader unlock hacks? Can't wait til I can run AOSP or Cyanogenmod
[Verizon Samsung Galaxy S 4] Walter.White:
You have no idea, how hard I'm rooting for you and [MENTION=766721]ryanbg[/MENTION] to crack this thing wide open with either kexec support or an exploit. *$#%^ hate ATT and Verizon.
[Verizon Samsung Galaxy S 4] biglil1:
+1
[Verizon Samsung Galaxy S 4] Surge1223:
Right now im just just trying to pinpoint why it hangs when it does. Usually i can trace panics using strace and objdump...but considering im not getting panics too often anymore ill have to set up the module sources so that lots of debug and error messages will be printed

+1 Exactly how I feel as well
[Verizon Samsung Galaxy S 4] skeezer308:
So, is all of this still building off of the re-exploitation of bypasslkm? Also how you you run kexec? I don't know much about it, but do you run a script along with insecure kernel modules and that's it basically? Just getting it to co-operate well and keep the kernel from going into panic.
[Verizon Samsung Galaxy S 4] Walter.White:
Verizon has to be douche in every opportunity it gets. SMH.

https://plus.google.com/+AlexWiesen/posts/8eGA2JDpBFM
[Verizon Samsung Galaxy S 4] Surge1223:
In case anyone wants before I upload to git,

jfltevzw-kexec-source

heavily influenced from sources from Hashcode, Tassadar, Xperia devs etc.

Kexec-tools 2.08 is compiled from source for android, I tried to bring all the features from all versions of kexec tools together, including atags, dtb, and hard boot support

Directions are in module readme folder, Instead of explain every stupid aspect of how to make it, I figured id just copy and paste my environmental variables, along with what I actually typed in to build everything. I can make it easier to understand later if needed

Yep, exactly thats the idea.