yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S 4] traco1:
I did not know it wasn't really unlocked. Huh?

I have a rooted phone & managed to get xposed installed after I de-odexed the stock firmware. I don't think I got much of a gain. The module settings don't all work I have tried a few There's not much you can change on your phone unless you download many. many modules just a waste of storage. After my contracts up I think I'll switch to a different carrier to get a phone I can root.
[Verizon Samsung Galaxy S 4] DeadlySin9:
Get Gravitybox and Wanam Xposed. You might need to try an older version of Gravitybox, but those two and a few other modules I use have made my phone much more efficient for me to use.
[Verizon Samsung Galaxy S 4] skepticmisfit:
This doesn't necessarily pertain to the s4, but i find it really interesting that motorola is giving bootloader unlock codes to 2014 moto x owners on verizon. especially after the phone's entire lifespan of not having it.
[Verizon Samsung Galaxy S 4] jwhistler:
Seeing as how the S4 is now at it's end-of-life support with Big Red, you would hope Sammy would do the same for us. Somehow...I think not. Really a pity....and really a pisser!
[Verizon Samsung Galaxy S 4] wolfen1086:
I wish this Verizon phone was like my old T Mobile phone when 4.4.4 was the new one. Easily rooted cm able to be installed and a custom recovery
[Verizon Samsung Galaxy S 4] skepticmisfit:
well, while the other variants of the moto x got a marshmallow update, the verizon and at&t versions were specifically left out of that, which may explain verizon's decision here (probably one of the less-boneheaded things coming from them lol)
[Verizon Samsung Galaxy S 4] jjppott:
I am not sure if this affects us or not (or if it would lead to a bootloader unlock), but figured I would share anyway - http://gadgets.ndtv.com/mobiles/new...d-android-devices-vulnerable-to-attack-795743
[Verizon Samsung Galaxy S 4] jcase:
Its jsut a root vuln for mediatek, if it was a bootloader vuln i wouldnt have tweeted it out
[Verizon Samsung Galaxy S 4] Legitsu:
keep the non-sense posts out of the thread please unless you are actively working on this DO NOT POST if there is new information out I can assure you the people that need to see it have already seen it
[Verizon Samsung Galaxy S 4] pclov3r:
I don't think it's going to happen now. Only way now is if Verizon and Samsung do something which isn't going to happen as stated.

You have to give them credit for making it nearly impossible to unlock.
[Verizon Samsung Galaxy S 4] doubleaykay:
Any progress? kexec? Anything?
[Verizon Samsung Galaxy S 4] jwhistler:
Nothing. Nada. No joy. I fear all is lost :crying:
[Verizon Samsung Galaxy S 4] Jon8RFC:
Thank you to everyone who was working on this project.
[Verizon Samsung Galaxy S 4] Legitsu:
CVE-2015-1805 may be useful for kexec

it was flagged as non critical but it appears it can be used to any device using K3.4.x and lower to gain root
[Verizon Samsung Galaxy S 4] Samsung love:
http://odste.blogspot.com/2015/05/breaking-samsungs-security.html

maybe this woult be helpfull have no idea : PP
[Verizon Samsung Galaxy S 4] Legitsu:
that writeup is like 6 months old its what people have been using for a reference ... not sure how you got it
[Verizon Samsung Galaxy S 4] npjohnson:
Yeah. Its by me, lol.

LOL. I wrote this. Notice nothing ended in success.

Actually its 3.10 and below, but it won't help with Kexec at all, as we already have a root vulnerability, and loadable module support on OF1 (newest firmware). Kexec progress won't be helped by any exploit. We have the necessary exploits to get Kexec running, just are at a point where not even UART can give us an accurate readout as to what is going wrong.
[Verizon Samsung Galaxy S 4] Surge1223:
Well, we know what's going on and how to fix it, shutting down the cpus and device drivers cleanly and setting them up for hand off just has to be tweaked. For me, it's just not worth the time partly because of the state of the community.

What I mean is literally no one is even trying. I bet there are literally 0 people working on kexec for the s4. I would probably work on it if I knew that it was going to benefit the community, but I feel like it would only hurt the community because people would only use it, not understand it for future purposes.

For example if I made a kexec research thread, I can guarantee maybe at most 3 people would have meaningful discussion in the thread, 10 people would post links they found on the Internet that they think might help, but are really just annoying and irritating that they had the confidence go post a link and not research it. I'm also not counting the 50 posts that say they appreciate our effort, or asking if it would be possible to do xxxx for yyyy device.

Now contrast this to if I made a thread about android pay, or layers/cmte. Everyone would come there, make minor contributions, offer help and then praise and declare anyone who contributed some minor shell script be immediately promoted to senior recognized dev.

Yeah, this is why development on xda is non existent. Go look at the Android hacking and development developers only thread. There are literally no development discussions, and the forum is mainly scripts and guides that give instructions instead of explain the process. If you are a developer, you KNOW how to write scripts...smh...

Sorry for the rant. I normally post development related things, but lately I've stopped because there's no point in having my messages constantly fall on deaf ears.

Ffs note3, s5, and probs note4 could have loadable modules on locked bootloaders, [MENTION=2471504]jeboo[/MENTION] even posted a verbose guide. But if it's not theming, Xposed, android pay or viper4android then it might as well just not be posted on xda.

We need a xda assist... For developers...

/rant
[Verizon Samsung Galaxy S 4] Legitsu:
I walked away from the S4 for similar reason yea it would be a great device if you could get it running pure ASOP and you are right 80% of the threads are people asking is it done yet and god forbid you actually try and bounce dev ideas around
[Verizon Samsung Galaxy S 4] Samsung love:
lol :D btw i was about to ask ... i dont know much about but is there any hope for this device ? i mean maybe soon coult someon bypass the bootloader that we can downgrade this device as it really got me sick the battery life and i hate that i bought this phone .... so pls tell me there is a hope i just wanna know that it is possible right ?

---------- Post added at 01:42 AM ---------- Previous post was at 12:59 AM ----------

hey bruh just saw you post ... soory i am new here im not an deve but i can understand you thats right ... i noticed that tho also the community here is not as i thinked i was in other xda forum of my previous device it was not that messed up just worked as a team but here some guys doesnt even give a proper instruction lol ... i only can agree with you but good to know also that there is a hope bruh ... if i coult i woult help you to work for this doesnt matter what .... i really wish you guys woult group up and work together to bring our device back :good::good: i hope i will wait for it :) PEace bruh
[Verizon Samsung Galaxy S 4] Legitsu:
[MENTION=4939386]Surge1223[/MENTION] well lets talk numbers what would people need to pay you to get it working because clearly everybody wants it but nobody is willing to sit down and do it

I am sure we could do what one xda's famous bounty threads lol ;)
[Verizon Samsung Galaxy S 4] Sterben Pistole:
I've been interested in helping development with kexec, but I don't know what to do/where to start. Are there any links that I can learn the basics and what programs I would need to help out?

Since I have a break 1 week from now I'd be able to do some testing and such since I wouldn't need to use my phone for that week. Any link that would help me learn this would be appreciated, thanks.
[Verizon Samsung Galaxy S 4] Samsung love:
SAD

so sad that no one is really interested to bring our device back ... nothing we can do with it even the older devices has more action in their forum than our here :( an that means we can only dream about ... pff :rolleyes:
[Verizon Samsung Galaxy S 4] npjohnson:
Message me on Telegram.
[Verizon Samsung Galaxy S 4] PalmCentro:
Here's the latest news from firewater devs how the exploit works.

It's a PDF

http://theroot.ninja/disclosures/SAMDUNK_1.0-03262016.pdf
[Verizon Samsung Galaxy S 4] Legitsu:
deleted
[Verizon Samsung Galaxy S 4] PalmCentro:
He writes; possibly every device containing a Samsung eMMC controller....
[Verizon Samsung Galaxy S 4] EdrickMG:
Deleted
[Verizon Samsung Galaxy S 4] doubleaykay:
Hey [MENTION=4939386]Surge1223[/MENTION] I notice you are participating in the VZW S5 booloader unlock thread that uses the method being discussed right now. After looking at that code myself I see no reason why it could not be adapted for the S4, could you provide some input on the matter?
[Verizon Samsung Galaxy S 4] Legitsu:
stop asking about it

if/when something is found it will be posted

/quote

R&D threads were reserved specifically for developers to discuss and work through code, not a cheerleader/"teach me bootloaderz code & hax plz" thread for people. That or maybe if that's not the threads intention have the R&D tag removed? Thanks

~surge1223

tl:dr anyone volunteering for 'testing' or begging for more info is likely to result in nothing getting released
[Verizon Samsung Galaxy S 4] npjohnson:
We tried. The exploit doesn't work in the S4.

The S4 uses a Toshiba eMMC. Meaning those vendor commands don't apply, and the chance Toshiba will mess up like Samsung did and drop theirs is null.
[Verizon Samsung Galaxy S 4] Legitsu:
thats what I kind of figured there was some documentation for the toshiba emmc around (in the CM repo ( at one point I am not sure where it got off too

not that it matters because I highly doubt there is a similar exploite path to be had .. at least not on this generation of devices
[Verizon Samsung Galaxy S 4] Surge1223:
I haven't tried, and while beaups exploit written as is won't work, it doesn't mean the idea/concept won't. It's clear that there are more than one way to achieve the result.

What I think some people are missing, either by not understanding how the unlock/dev conversion sequence works, or just laziness is that while the emmc chip vendors are different, the mechanism for the unlock is the same on the other end. You can think of it as similar the state function in thermodynamics.

Just because beaups took x applied y and ended up with z doesn't mean that we cant get to z.

It's the idea that's the real exploit, I sincerely hope more people realize this sooner.

The changed CID results in a variable, this variable is then read by aboot. So finding a way to achieve the variable, independent of using the same method beaups used for his CID right seems feasible. Load aboot in ida, them load a signature file (you can generate a generic lk on by compiling lk and using the our non-stripped elf symbols as symbols for the sig) it should show you some mmc functions as lk has mmc_init functions in it.
[Verizon Samsung Galaxy S 4] Legitsu:
unfortunately the only people that care about such things are you and a handful of others the majority of users simply want there instant-gratification

I agree his research has opened a lot of doors particularly more info on way variables are checked but sadly I doubt anybody has the motivation to take it where it needs to go everybody seems to want there exploited handed to them on a silver platter,and seem to forget the work that was done to get there or who even did the work
[Verizon Samsung Galaxy S 4] npjohnson:
You are correct, in saying that IF we can find a way to change our CID, this will apply. Though, previous to this, we've never been able to prove CID change would be the only factor that would allow us to use that devices aboot. Now we know that CID write single handedly can allow us to use the Developer Edition aboot on production devices.

You are right about it being completely in our hands at this point... thought it has been for all these years. Now we just have a little bit more knowledge than before.
[Verizon Samsung Galaxy S 4] Legitsu:
well then theoretically if you could connect to the EMMC directly via jtag it should be possible to write whatever CID you please ,provided you know the correct vendor commands
[Verizon Samsung Galaxy S 4] npjohnson:
Yeah. But if we knew the vendor commands, we can execute them like Beaups did, No need for JTAG.
[Verizon Samsung Galaxy S 4] Legitsu:
the commands are documented(in the datasheets) It was my understanding that the SOIC had logic to prevent registers from being writen without the correct signing/qfuses

so if you simply solder right to the pads on the EMMC that bypasses all that and allows access

the i545's(and other variants) should all use Toshiba 016G94,
[Verizon Samsung Galaxy S 4] npjohnson:
No. They aren't documented. We have looked. At least, not the functions we need.

And, no, with the correct commands, there is no write protection.

They all do use that eMMC, but even a direct solder would require the vendor commands to write to the CID area.

Imagine it like this (this is a crude explanation), write protection is enabled on your USB drive. There is a command to turn it off, but you don't know what it is, or what the syntax is.

Two options: It gets leaked, you dig through aboot enough using LK sigs to find the mmc functions you need.
[Verizon Samsung Galaxy S 4] Legitsu:
then that confirms what I suspected OTHER devices you can manipulate the NAND as you please with a direct connection to the chip and a good jtag box
[Verizon Samsung Galaxy S 4] Samsung love:
Guys, I have no idea... but I am still following you: P wish I could be helpful ^^ ...
[Verizon Samsung Galaxy S 4] ryanbg:
I hate to burst your bubble guys, but I'm one of the two researchers who published that disclosure. The Toshiba eMMC doesn't use those vendor commands, and will not work on the Galaxy S4.
[Verizon Samsung Galaxy S 4] doubleaykay:
Correct. The goal right now is to find similar commands for the Toshiba eMMC that will allow us to write our own CID as per the method being used for the S5.

---------- Post added at 05:33 PM ---------- Previous post was at 05:19 PM ----------

Also, I was reading the S5 thread where this is being discussed, and we may have some issues. Regardless of a CID change or not, we can't flash the aboot from another carrier. This means that we could not, for example, change the CID to a T-Mobile one and flash a T-Mobile aboot... ODIN and the device itself would not accept it as the carrier also signs the aboot and the signature would not verify. For us, there is no "developer edition" of our device, so we would need to use the S4 Google Play Edition's aboot, which is unlocked. Now the question is, can we flash the GPe aboot on the S4? Based on my research the GPe version is GSM not CMDA, meaning it may work on the AT&T version (GSM) not the VZW version (CMDA)... "may" is the key word here
[Verizon Samsung Galaxy S 4] XxD34THxX:
I'm pretty sure there is a Verizon variant for the GPE S4.
[Verizon Samsung Galaxy S 4] Legitsu:
chasing bootloader unlocks is a waste of time kexec has the greatest chance here

./thread
[Verizon Samsung Galaxy S 4] doubleaykay:
Alright, but we can't even get logs from a failed kexec run attempt... and nobody knows the progress on it (at least publicly). Obviously I take this with a grain of salt, but people over in the S5 thread are most likely looking for the Toshiba eMMC commands, which if/when found would most likely apply to the S4 as well. It doesn't hurt to leave options open...

Heck, Surge said it himself, he thinks that there are no people working on kexec. We should be riding this sudden surge of interest and seeing how we can profit from it, as well as working on kexec.
[Verizon Samsung Galaxy S 4] Legitsu:
everything is in place if what surge said is correct all thats left is too get the hardware in a sane state for the hand off to the new kernel
[Verizon Samsung Galaxy S 4] doubleaykay:
Dropping this here in case anyone wants to help with the effort to find the commands for Toshiba chips, it's a link to the thread that was set up with that purpose: http://xdaforums.com/verizon-galaxy-s5/development/toshiba-11-series-bootloader-unlock-t3349346
[Verizon Samsung Galaxy S 4] Legitsu:
pages 160+ contain info on CID and various registers

it doesn't look good the JDEC spec says most of those registers are write once read only

what I wanna know is where in the boot process does it check the CID registers and is there anything we can do to manipulate it to read whatever value we feed it
[Verizon Samsung Galaxy S 4] Legitsu:
[MENTION=5868929]hsbadr[/MENTION]

whatever happened to multisystem ?
[Verizon Samsung Galaxy S 4] killer5000:
That not true because if I am not mistaken the s5 is should be write once to but they were able to write to it and as all bios chips for computer are write one back in the day but we were able to write to them to
[Verizon Samsung Galaxy S 4] genax:
New s4 pre paid is 129 dollars at Wal-Mart for those who want a second device for tests
[Verizon Samsung Galaxy S 4] Sonichedgehog360:
Would this backdoor or one quite similar happen to exist for our device?

http://xdaforums.com/note-4-verizon/general/note-4-verizon-bootloader-unlock-t3358913
[Verizon Samsung Galaxy S 4] afaneh92:
This is for users with*15 Sasmung eMMC's not users with*11

Im on OC1 and my CID start with 11 any one on OF1 can check CID on "/sys/block/mmcblk0/device/cid"

Maybe we can modify the code to run CID start with 11
[Verizon Samsung Galaxy S 4] Matthew M.:
Of1 is 11 as well
[Verizon Samsung Galaxy S 4] afaneh92:
As I think this related to eMMC not bootloader.

Also tried to change the cid but did not success.

The only way is try to implement a patch to the samsungcid-unlock.
[Verizon Samsung Galaxy S 4] XxD34THxX:
For a patch too beeups code, the equivalent Toshiba command would need to be found, and the samsung one was leaked only, and I am 98% sure the toshiba one has not been leaked.
[Verizon Samsung Galaxy S 4] Sonichedgehog360:
If I understand correctly from the forum buzz (relevant link below), it has been finally uncovered for the S5 by a few XDA members but they have chosen to not release it yet for general usage. It appears they are now running closed group testing and will share their findings once everything is good and ready.

http://xdaforums.com/showpost.php?p=66333197&postcount=144
[Verizon Samsung Galaxy S 4] Legitsu:
you people don't have a clue ... stop bringing up every random post you find

YOU ARE NOT HELPING

what you are doing is cluttering the thread and unnecessarily making it longer then it needs to be

trust me if there is new information, then the people that need to know already know ...
[Verizon Samsung Galaxy S 4] tshelby73:
I could bet money this bootloader will never be unlocked so what's the harm in people posting thoughts ideas. The phone is dead and outdated and pretty much all the devs have moved on. I had a Moto droid X2 that never got unlocked. I've learned to live with the fact if you want unlocked bootloader get phone that's unlock able to begin with.
[Verizon Samsung Galaxy S 4] Sonichedgehog360:
Removed. Thank you for the tip below!
[Verizon Samsung Galaxy S 4] RuggedHunter:
I used to have that misunderstanding of the general forums too...until a moderator posted this:

http://xdaforums.com/showthread.php?p=60882828

[emoji4]
[Verizon Samsung Galaxy S 4] ccrusher1:
To anyone that still has this phone, don't give up hope. The note 4 just got unlocked. Check it out. http://xdaforums.com/note-4-verizon/general/note-4-verizon-bootloader-unlock-t3358913

There may be hope for the S4.
[Verizon Samsung Galaxy S 4] Samsung love:
well i hope so much .... :(
[Verizon Samsung Galaxy S 4] Legitsu:
and again you people post stuff we have already known/been talking about for the past 3 weeks
[Verizon Samsung Galaxy S 4] supdog:
...and again you people whine.
[Verizon Samsung Galaxy S 4] ccrusher1:
Three weeks? Check the date on the post man. This was just released. Maybe instead of dissing others, someone can contact the people responsible for that and see if they can find a way to help.
[Verizon Samsung Galaxy S 4] doubleaykay:
Known exploit. People are already working on applying it to hardware similar to ours. Legitsu has a point... exploit has been known for 3+ weeks, I was the one who initially brought news of it here (in a helpful way I might add...).

Look man I get that you're annoyed but there is absolutely no need for foul language. I know what it is like for people to not appreciate what you are doing, to not respect you, to not respect the rules. But please don't resolve to foul language. I for one appreciate your efforts.

---

To everyone else: please try to simply watch this thread. The more you pester the devs -- who donate their FREE TIME for you -- the less you will get out of them. These people are working very hard and the least you could do is respect their only request: to stay quiet and wait for updates instead of bothering them.

I don't want to see any irrelevant posts after this. Let this be the point where useless posts stop. Please.
[Verizon Samsung Galaxy S 4] ryanbg:
Samsung never leaked the vendor command to change the CID. Beaups reversed it. Toshiba is a ***** to work with, I'd imagine this route is not feasible right now for the S4.
[Verizon Samsung Galaxy S 4] TheLoonyRebel:
The S4 did get a developers edition. And the Note 3 also has the same method now available for it. I'm assuming Beaups or someone else do they need to physically have the developers edition in their possession or can they just use the firmware files that are available to pull off the reversal of the CID? I'm not too overly familiar with the process.
[Verizon Samsung Galaxy S 4] ryanbg:
The issue is that the S4 uses Toshiba eMMC, and the backdoor is for Samsung only. Long time no see [MENTION=2440946]AngryManMLS[/MENTION]
[Verizon Samsung Galaxy S 4] TheLoonyRebel:
I'm assuming because the Toshiba eMMC uses a different encryption (or something like that) compared to the backdoor method being used on the Samsung eMMC? I'm also assuming the Verizon Note 2 also uses Toshiba eMMC as well which would rule out using this method for any Verizon Note 2's that have the 4.4.2 bootloader?

And yes long time no see to you [MENTION=766721]ryanbg[/MENTION] as well. Enjoying my LG G3 greatly these days but I might be moving to T-Mobile by the end of this summer since my contract ends with Verizon and we all know about the increase in fee on UDP once that contract ends. At that point I might as well jump to T-Mobile since I can actually save a bit while still having UDP. :highfive:
[Verizon Samsung Galaxy S 4] Surge1223:
Idk what Toshiba does but it'd annoying learning about their vendor commands. That and its spread throughout kernel, aboot, sbl2/3 and tz. I dabbled through some of this cluster F when trying to figure out what about the Safestrapmenu framebuffer hijack was causing CMD52 to spam in last_kmsg when debugging safestrap for lp. I eventually stopped trying but safestrap hijack is hindered by the code changes to libpng and framebuffer in lp. I recompiled it after making it compatible with the newer android sources for libpng, etc but at this point I don't want to have to support safestrap for lp.

^^ tip to the ambitious: concentrate on the Safestrapmenu code instead of e2fsck, the e2fsck hijack does work fine after editing the sed scripts to mount sdcard for the init.target.rc and other init.rc files that e2fsck sed patches. The problem is that the driver for touch and fb in early init have new selinux contexts (confirmed you can get around this by loading a new policy $(load_policy /path-to-patched-sepolicy) but the Safestrapmenu code needs a new hook.
[Verizon Samsung Galaxy S 4] afaneh92:
Good find, I will look into it soon.

Thanks for hint ?
[Verizon Samsung Galaxy S 4] dhplap:
Just checking to see if any progress has been made on unlocking the bootloader yet. I'm on verizon s4
[Verizon Samsung Galaxy S 4] ATGkompressor:
If it happens you're gonna know about it. The s4 section will explode.