yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S 4] SamuriHL:
Please don't take this as naysaying. I simply want to point out some challenging realities that locked bootloader users face going forward. I'm partially sorry if this post offends anyone, but, I really do think it's time for a reality check on a few things.

1) A significant amount of phones on 4.4.4 remain unrooted afaik.

2) 5.0 has made root even on unlocked phones far more challenging. For the very moment it's still possible to root locked phones, but, it's really up to Google if that possibility remains. The reason for this is that initially 5.0 could only be rooted by modifying the kernel. That means flashing a patched boot img. Clearly this can't be done on a locked phone as the modified boot img wouldn't be signed. Fortunately, for the very moment, chainfire found another path for root to work on 5.0 that doesn't require patching the kernel. However, it would be trivial for Google to patch this out of existence in a future update. Time will tell if/when they choose to do so.

3) SS uses hooks that very likely will be impacted by the massive amount of security changes Google has made to 5.0. Even if the massive amount of challenges in acquiring root on a locked phone are overcome, getting SS to work on it is not going to be a trivial task. That's for the people who know the code intimately.

I've beat this horse to death so I won't belabor the point, but, buying unlocked is the sane choice going forward if you care about root and roms.

P.S. Sorry to see people like Surge and Beans leaving this effort. You guys are legendary and your efforts are GREATLY appreciated.
[Verizon Samsung Galaxy S 4] tshelby73:
I kinda figured if Verizon ever got a nexus phone we would lose our devs.
[Verizon Samsung Galaxy S 4] xXsquirr3lsXx:
Does this mean kexec development has been discontinued?
[Verizon Samsung Galaxy S 4] RuggedHunter:
Wow... Huge thanks to you guys! I learned a ton while rooting for you all... :beer:

My next device will be nexus. See you there.

:(
[Verizon Samsung Galaxy S 4] xXsquirr3lsXx:
Agreed
[Verizon Samsung Galaxy S 4] tshelby73:
I hope at least we get root for lollipop when it comes out. I'm stuck with this phone for probably another year.
[Verizon Samsung Galaxy S 4] skepticmisfit:
not necessarily. there's a few people still working on kexec for us but who knows what's happened to Surge's work
[Verizon Samsung Galaxy S 4] NighthawkXL:
With any luck I'll have a G3, and OnePlus by the end of the year... and rid myself of this S4. Until then I'm content with Safestrap, even with being forced to use TouchWiz for now.
[Verizon Samsung Galaxy S 4] Hashbang173:
Same here, hopefully source for kexec development will be posted (that's up to date)
[Verizon Samsung Galaxy S 4] K-alz:
So, are the nexus devices unlocked even when they're from Verizon and AT&T?

from my note 3
[Verizon Samsung Galaxy S 4] jj22212003:
go figure... great headway gets shot down to a crawl because this or that happens to so and so and 40 to 60 percent of the big players jump ship... sad shame... i do however greatly appreciate all of the people who have gotten us this far and [MENTION=4939386]Surge1223[/MENTION] for starting this thread thats kept things somewhat collaborated up to this point and kept us informed.... my hats off.
[Verizon Samsung Galaxy S 4] RuggedHunter:
Agreed. This is still a very nice device, thanks to so many here, and I am satisfied with my jellybean HD12, very "Tasker-ized" setup for now.

My next device will not inhibit development though.
[Verizon Samsung Galaxy S 4] tshelby73:
Really wish we had a nexus 5 on Verizon. I could afford one of those full price. The 650 for the nexus 6 to keep unlimited is out if my budget.
[Verizon Samsung Galaxy S 4] SamuriHL:
Dev Edition Moto X 2013 for VZW is 219 right now.
[Verizon Samsung Galaxy S 4] scryan:
Been looking at those for a while... purchased.

Too bad they don't use the same sim card size as the S4, would be nice if I could just swap the card back and forth.
[Verizon Samsung Galaxy S 4] SamuriHL:
I used a sim cutter and adapter when I was swapping between my x and s4.
[Verizon Samsung Galaxy S 4] 06sharpshot:
Thanks for all you've done thus far. I know that you're leaving the S4 and its development, but is there still hope for those of us left to unlock the bootloader by picking up where you left off? I'm one of the guys stuck with this phone for almost a year until my contract ends and I'd love to at least start learning what there is to be done to get this unlocked. Is there anything we're able to do?
[Verizon Samsung Galaxy S 4] skepticmisfit:
he already released the source a while ago in this thread. i don't have time to do any serious work but you should probably start there
[Verizon Samsung Galaxy S 4] Surge1223:
I haven't pushed any of the latest commits, I have it stuck at the jump, hardboot semi works but brings up the modified system screen then firmware error. I'll push the latest commits soon.
[Verizon Samsung Galaxy S 4] skepticmisfit:
this is kinda off-topic but you have a nexus 6 now, right? do you still have your s4?
[Verizon Samsung Galaxy S 4] 06sharpshot:
I'm really new to this and more looking to learn than hoping to complete this. What do you recommend starting with? Is there anywhere those of us with little experience should turn to start learning about all of this? I'm sorry to bug you, I'm sure you get asked these questions a lot.
[Verizon Samsung Galaxy S 4] sokrboot:
The current kexec build makes it up to a soft reboot then a call and just hangs. I am FAR from an expert on this but I feel like this is an issue with CPUs not being offlined properly OR some driver(s) involved don't want to play nicely with the soft reboot. This is really a theory only based on my reading and research and where our hang occurs. I could be way off base.
[Verizon Samsung Galaxy S 4] mbabich17:
We should also consider the method used by h311sdr0id to flash MDK over ME7. Im not sure if anyone has explored it thoroughly, at least as far as I've seen .
[Verizon Samsung Galaxy S 4] scryan:
You should probably read at least the first post of the thread?

Long story short, that guy basically was some random guy on a forum asking people to send him their $600 electronic device so he could "hack" it... And he was never willing to discuss or even demonstrate the ability when there was thousands of dollars up for grabs if he could.

Draw your own conclusions.
[Verizon Samsung Galaxy S 4] KaratemanTJ:
As far as getting kexec ported, would it make sense that it would be easier on older firmwares or just as difficult?
[Verizon Samsung Galaxy S 4] sokrboot:
Theoretically older firmwares would be easier (assuming each successive release fixed something broken) but in reality each release could close one door and open another OR close one door and close another then deadbolt lock them both and turn on the burglar alarm. We just don't know...yet.
[Verizon Samsung Galaxy S 4] scryan:
Most of the exploits that were being looked at were still available in NC5... Who knows what they have patched exactly and what they haven't.... Each release it seems like they focus on improving security a bit, but exploits often end up being found through the creative use of some random corner of coding that you would never expect...

Probably marginally better to be on the oldest version possible, but I bet you wouldn't be left out being on NC5.... We will see what lollipop brings (Have they even said the S4 is getting it? )

There is the possibility that they mess up and introduce something new, but its probably a little more likely that they will fix something instead.

Ehh, no one knows. Probably has only gotten more secure but unsigned modules & kexec still seems most likely, and that is available on NC5
[Verizon Samsung Galaxy S 4] mbabich17:
The first page of the thread didnt make that clear at all. If I didn't read the thread I'd have no reason to comment at all. I just thought that since kexec dedevelopment has slowed it may be worth looking into some of the other methods mentioned in the original post.
[Verizon Samsung Galaxy S 4] scryan:
Then your last post didn't make your intentions clear at all, because you wrote:

However the first post clearly demonstrates that the method had already be considered:

So over a year ago what your asking to be considered already was.... Perhaps all of the results were not posted ,mostly because there were none, as it was some wild claim that was not really testable other then being repeatedly verified you can't do it with out knowing something the rest of us didn't.

So again, you say we should consider a method that is THE BASIS of this thread that has been near the top of the forum for over a year.... It should be pretty obvious that it was considered, and from that and the fact that its not being worked on it should be pretty obvious that we didn't abandon something that had merit.... So what exactly are you asking to be considered when you bring up ideas abandoned a year ago? They have been considered... What new angle do you want to take on them?

All I am trying to say is that is where this conversation STARTED, and it lead to here..... unless we have new information or a new perspective, what do you expect to come from it other then repeating this thread?
[Verizon Samsung Galaxy S 4] mbabich17:
Look, I'm not arguing the validity of my post that you've already proved to be redundant, I was simply mentioning it in case in all the kexec development some other methods were neglected, purely because kexec was the most promising. In times like these it can be helpful to go back to the beginning and review any other possibilities, especially since kexec dedevelopment may not continue at all. However I apologize for posting information that you didnt find helpful.
[Verizon Samsung Galaxy S 4] D3Seeker:
So it's doom and gloom from here on out....... Well this stinks, though understandable. :crying:

Especially in Verizon's case I'm sort of surprised you made it this far
[Verizon Samsung Galaxy S 4] sokrboot:
The existence of an exploit hasn't gotten any worse or better but the possibility of finding it has taken a hit since we lost several of the folks leading the kexec research. Someone here could still find what we need...stranger things have happened.
[Verizon Samsung Galaxy S 4] Bright09:
Will we ever see a unlocked i535 again? Miss my og s3
[Verizon Samsung Galaxy S 4] landshark68:
No
[Verizon Samsung Galaxy S 4] xXsquirr3lsXx:
Well when my contract is up im not getting myself into a situation like this.
[Verizon Samsung Galaxy S 4] SnyderGuy:
So can we guarantee no bootloader unlock/bypass for all verizon GS4 variants?
[Verizon Samsung Galaxy S 4] MrGooglesFirst:
Correct me if I'm wrong but I don't believe that there is a guarantee that it won't get unlocked but there is a very slim chance.
[Verizon Samsung Galaxy S 4] PantsFullOfGuns:
This post may be beneath many here but, it seems quite a few people have given up on trying to unlock the bootloader, and i was wondering if the op could put in the first post some pages for nubs like me to read up on to help and understand the basics of trying to unlock the botloader assuming that a degree in software engineering isn't required to not brick your phone.
[Verizon Samsung Galaxy S 4] sokrboot:
This is the post # you want... http://xdaforums.com/showthread.php?p=56440865

If it were easy it would be done by now. Happy tinkering and good luck.
[Verizon Samsung Galaxy S 4] scryan:
One of the biggest hurdles I have had learning about android stuff seems to be that... Your not supposed to learn about android stuff. Linux knowledge helps, the systems are obviously similar... But where there is endless quality resources for building and modifying Linux... The changes that make android android don't seem to be well documented as that's Samsung's job... Not yours. Most sources of info meant strictly for android that I have found are woefully incomplete and/or geared towards documenting one aspect to developers.... So you often only find VERY basic overviews or overly intense studies of a specific area of android... Your sort of left clawing to make up ground in getting from one to another, get good at searching.
[Verizon Samsung Galaxy S 4] Surge1223:
I posted the final changes I have made to the kexec modules for NC5, good luck.

Link

Note: I have no plans to work on NG6 or the newest OTA that just dropped. But I am more than happy to help those who want to continue this project in an advisor role.
[Verizon Samsung Galaxy S 4] skepticmisfit:
so is this more functional or the same in completeness as your previously released code?
[Verizon Samsung Galaxy S 4] h311sdr0id:
Hey Brother. Sorry for the late reply. I have been "unavailable" for some time now.

If you'd like, send me a message or email so webcan discuss things further.

At this time, I cannot make any public statements concerning anything related to what forced my "unavailable" status.

Sounds like a whole lot of crap to me too. But it is what it is.

h311sdr0id
[Verizon Samsung Galaxy S 4] Sir_Eagle:
Hope you guys can get together and maybe figure something out.
[Verizon Samsung Galaxy S 4] Raymondlikesroot:
:D. I don't want to be too optimistic but I like where this is going :D :D :D :D
[Verizon Samsung Galaxy S 4] sokrboot:
Found the following on WIGLE.NET...

h311sdr0id: New Mexico

Postby h311sdr0id » Sun Aug 25, 2013 1:43 am

Hey everyone. I wanted to just say what's up and let everyone know where I am at and where I travel to frequently. This way if anyone needs any specific data, you can hit me up and let me know when/where I will be. Plus, there isn't a whole lot of dots (publicly logged data points) in New Mexico and I want to see what I can do to get it mapped out.

The fastest way to get ahold of me is through:

- Google Talk/Google+ Hangouts

Using my email:

- h3llsdr0id@gmail.com

I am also an active developer for Android devices through XDA and I work for one of the major carriers. So if you have any Android issues or problems, I can more than likely help you out. Don't hesitate to ask.

-h311sdr0id

Based on the last that last paragraph I wouldn't be surprised if he faced a Cease and Desist, a lawsuit, or jail time. Working on contract for a major carrier and bypassing their bootloader is grounds for any of those. Maybe we'll see what really happened...maybe.
[Verizon Samsung Galaxy S 4] NighthawkXL:
Let's not ponder about his personal history, if he wished to share it he would. We don't know the details, and it would be improper for us to assume his absence where in anyway caused by his work with Android as it could have been a myriad of other things as well.

With that said welcome back to XDA h311sdr0id ~
[Verizon Samsung Galaxy S 4] sokrboot:
[MENTION=5155393]NighthawkXL[/MENTION] [MENTION=4181229]h311sdr0id[/MENTION], now that I go back and re-read my post it does sound a bit personal and tabloidy. That wasn't my intention...I was actually trying to highlight his comment of (paraphrase) "yeah I know this whole situation is oddball". And we'll YEAH it is oddball! o_O no offense was intended so I hope none is taken.

Welcome back h311sdr0id

P.S. If you have a portfolio full of helpful info on this friggin' bootloader feel free to leave it lying around. We'll make sure we get it back to you!
[Verizon Samsung Galaxy S 4] ultravioletnanokitty:
that's probably something that should be dealt with now. see here. development for that device has stopped (though i'm attempting to resume it), but the point remains relevant. no correct atags, no boot. of course if we are using device tree that's not the case, but i'm really not sure if we are or not. i've poked around in the kernel but found nothing more interesting than the fact that on our devices the atags procfs entry is disabled (of course) and therefore getting correct atags may be harder. [MENTION=4939386]Surge1223[/MENTION] how did you obtain the atags file you added in this commit? perhaps my concerns are baseless.
[Verizon Samsung Galaxy S 4] Surge1223:
From Hashcode, I asked him about it when I noticed the tags address was wrong, at the time he said it didn't really matter since we weren't far enough to have to deal with it just yet. Also I started writing a module that would extract it from memory until I realized the atags weren't a necessity. You see when we allocate the kernel to be remapped into kernel space before, we can also tell it to dynamically get atags from memory itself prior to booting.

The two main problems that I think most of us arm users run into is the integrity of the address that the relocate_kernel.S is written to since it's hard to tell if it will write the instructions in Arm or if is limited by the method used to remap it.

The other issue is shutting down all but one CPU for the reset
[Verizon Samsung Galaxy S 4] thecensor:
Teensy

I wonder if something like this could work:

http://xdaforums.com/hardware-hacking/chromecast/root-hubcap-chromecast-root-release-t2855893
[Verizon Samsung Galaxy S 4] NighthawkXL:
No dice ~ sorry.

Though it's pretty cool that they finally rooted the Chromecast, though I don't see how they will do anything useful with it.
[Verizon Samsung Galaxy S 4] joshm.1219:
I don't care what happened, I'm just glad to see you back! Thanks for everything you've done for XDA man.
[Verizon Samsung Galaxy S 4] 06sharpshot:
Dude, welcome back. It's great to see you back around these parts and I'm glad you're continuing to contribute. No one will blame you for not being able to share further information, you've already done so much as it is.
[Verizon Samsung Galaxy S 4] Surge1223:
So I have been messing with kexec for awhile lately (you guys telling me to post latest source caused it :sly:) but a few pieces of info.

1. I finally understand what Hash meant by the "cache flush issue"

2. I've started a new module to hijack the ability to shut down secondary CPU's, remap memory, and unmount and shut down devices.

3. I've finally got it remapping the memory in the right area

4. Here's the issue, when I flush cache it invalidates some of the memory I have remapped, I confirmed by dumping memory and tracing back errors with gdb and objdump

5. As it stands on ARM, we need a way to reliably flush cache, shut down secondary CPU's, bring them back up and switch to the new kernel using the relocate kernel code.

No worries. We may have jumped the gun in being too quick to blame, and for my role in that I apologize.
[Verizon Samsung Galaxy S 4] Surge1223:
Im going through the dev tz partition...have to make it readable before we can actually tell whats up.

P.S. if anyone else needs the dev tz itself, let me know. Otherwise its freely availble in the dev firmware package I made over in original development (1.8gb-sh download though)
[Verizon Samsung Galaxy S 4] Smartrobot:
An Exploit Idea

in the past I have used exploits where it uses external files than the ones from the os. In windows to bypass the login you can boot of an external disk and it brings a different kernal and overides the login method. If we can create a symlink to the directory where the certificate that checks what can and can not be flashed to a new directory with our own certificate. Or find a way to override the certificate with one of our own. We can flash what ever we want.
[Verizon Samsung Galaxy S 4] tshelby73:
I'm no developer just casual power user. Just thought I would throw this out their. When I had my Droid X2 we got into recovery trough a modified charge mode, the only way you could get in was to reboot with the charger hooked up. Of course this recovery was not able to flash kernels as bootloader was still locked.
[Verizon Samsung Galaxy S 4] NighthawkXL:
Same here, I left my short lived dev life behind and am in the same boat... a "casual" power user.

I've always wondered what would stop us from essentially taking a modchip approach like on the old game console. If we can't flash anything onto the chips on the board screw them... bypass them by wiring up a separate chip that has the lower firmware on it. Then again, even if this worked the average end user wouldn't be able to do it and it definitely would destroy any insurance / warranty you have on the phone even if you flash back to stock with a Odin image. I know a eFuse is software based, and the qFuse is hardware based... what happens if you replace the qFuse on the board with a non-blown one?
[Verizon Samsung Galaxy S 4] Brooklynsour:
[MENTION=702877]tech_head[/MENTION] that's some crazy **** NSA obviously spying on their own people, but now if what you said is true about Samsung and NSA working together to implement software/hardware into our phones they can hack in at any moment w.out even knowing... I f******hate that spying bull****..

mf3 rooted SHOstock

---------- Post added at 10:16 PM ---------- Previous post was at 10:15 PM ----------

Excuse my language, bad day...

mf3 rooted SHOstock
[Verizon Samsung Galaxy S 4] tech_head:
You didn't say anything I don't feel.
[Verizon Samsung Galaxy S 4] k1mu:
Apparently, from reading the documentation, the certificates and the signatures for the boot components are stored in the "Trust Zone" which can't be accessed from normal software. There's some mechanism to allow a "Defense Department" user to add their certificate to that store, which means that it's not immutable. So that may be an avenue to explore.
[Verizon Samsung Galaxy S 4] hemirunner426:
This could also allow corporations such as newly corp'ed Cyanogenmod to approach Samsung and say, we want Cyanogenmod on your phones. Samsung grants the certificate and Cyanogenmod is now signed for Samsung products that you can download from get.cm

Of course, the one major part missing here is the large sum of money Samsung would ask for to do such a thing...
[Verizon Samsung Galaxy S 4] kalestew:
I know you are all working with me7 but would there be any hope for newer firmwares like MI1 or the new 4.3 MJ7? I know some devices have shipped with higher than me7
[Verizon Samsung Galaxy S 4] jamesd1085:
Seems like some of the work in the possible to downgrade to older bootloader op by kaito may be progressing towards what we need...maybe some combinations of the work here and what they have there Could fill in some of the blanks
[Verizon Samsung Galaxy S 4] jsaxon2:
Do you have a link to that thread?
[Verizon Samsung Galaxy S 4] gunzaa:
You guys are true heroes to people like me, who know nothing about programming/coding. :D
[Verizon Samsung Galaxy S 4] jco897j:
http://xdaforums.com/showthread.php?t=2539904
[Verizon Samsung Galaxy S 4] :
That's for the i9505 variant, we have the i545.
[Verizon Samsung Galaxy S 4] jco897j:
Yeah. That's what he states in the beginning of the thread but I think it has kind of evolved from there.
[Verizon Samsung Galaxy S 4] NighthawkXL:
I thought we had already concluded that swapping certificates wouldn't work because that's not how signing functions. If it where the simply there wouldn't be any point to encryption to begin with. I haven't read that thread in a few days, so unless something changed where still at where we've been outside of Surge's newest work.

Reposting this to garner a response since it was buried under other post and I'm curious about it.
[Verizon Samsung Galaxy S 4] jh64dsb877r:
Well, a lot of the HTC phones have the wire trick for obtaining S-off.

As far as a full mod-chip goes, it seems difficult given the portable nature and smaller size of the device. Or were you thinking of a temporary mod-chip to get everything unlocked?
[Verizon Samsung Galaxy S 4] JLow0214:
Just a thought about the certificate..... If its anything like a network security certificate couldn't we just make our own and use that??? Or do we need some special Sammy software to make certificates??

Sent from my SCH-I545 using Xparent Skyblue Tapatalk 2