yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S 4] Surge1223:
Just copy and paste this into terminal

su
mount -o remount,rw /system
cp /system/bin/reboot /sdcard/reboot
rm /system/bin/reboot
cp /sdcard/reboot /system/bin/reboot
chmod 755 /system/bin/reboot
rm /sdcard/reboot
exit 0
/
[Verizon Samsung Galaxy S 4] Walter.White:
Anyone who wants to learn more about the way BL's work and how they have been exploited in the past (on Note 2 and other devices etc). Watch this video by [MENTION=2918486]Ralekdev[/MENTION]

It's pretty interesting and I think most people on here will be able to follow/understand what they are talking about.

https://archive.org/details/ShmooCon2014_Arms_Race...Bootloaders
[Verizon Samsung Galaxy S 4] ky5ever:
Yeah. Samsung can push updates to the KNOX bootloader via security policy updates. This is located in the Security tab of the settings menu.

Another thing to note, in previous versions of Android, you could make the KNOX bootloader only protect against what it knows about in the current version of security policy, or you can set it to high protection mode and it would block anything that just looked suspicious.

In Kit Kat, however, that option was removed, and it now always runs in policy mode, but the policies are updated more often. Policy updates happen silently, but you have to give your phone permission to do the updates. However, it usually asks you early when you have your phone and most people probably accepted it without thinking.

You should be able to just wipe back to ME7 with ODIN and disable policy updates. Or better yet, use a custom ROM, that has KNOX already cut off. Surge's port of Baja ROM is really good, doesnt add all kinds of crap, but looks good and is very very light on RAM.
[Verizon Samsung Galaxy S 4] E:V:A:
There are probably simpler ways to disable SELinux OTA updates. One is to disable the Security Policy Updates client, SPDClient.apk.

But the question is, if it's possible to revert the SEL policy, manually? And what would be the proper way to do it? Apparently, the older version, after a policy update is retained, in a different place. (Probably in /data/security/spota/ ?)
[Verizon Samsung Galaxy S 4] ky5ever:
You are right about disabling policy updates, but about reverting them, I have yet to find a way. Hence why I said you should wipe with ODIN to remove all the policy updates.

Policy updates are indeed stored in /spota, and can be removed with root access, but its best to just wipe. If you dont wanna lose your apps or stuff, buy the makers of Titanium Backup a cold one and get the Pro version, and set a schedule to batch copy all your stuff every night. Its worth it.
[Verizon Samsung Galaxy S 4] E:V:A:
[MENTION=5687468]ky5ever[/MENTION]: Well, completely wiping the policies is perhaps not the best way, since there is no telling what would happen if you then accidentally put your phone in Enforcing mode. Moreover, all policy updates are not necessarily bad, but can improve previously bad policies (as I have experienced) with debugged ones. In other cases a policy update may prepare the system for up coming and new applications or functions. I do not recommend removing these, unless you're absolutely sure you will never again want to use SELinux based functions. Also as new applications are developed, they will conform to having SELinux enabled, so there is no telling what would happen to a new application expecting to see SELinux policy/functionality behavior.

That's why we have to know how to revert these,

even if not possible at the moment.
[Verizon Samsung Galaxy S 4] Surge1223:
Yep, and as the title alludes to thats one reason why...we are serious about unlocking the bootloader :sly:
[Verizon Samsung Galaxy S 4] ky5ever:
You say its not good to remove these, but isnt SELinux one of our obstacles? SELinux isnt even being added to a lot of new phones. I mean, I totally understand the importance of figuring out how to work with these policies, I didnt mean to sound ignorant. It just seems like itd be better to avoid anything to do with SELinux for the time being, because I fear its possible to do something permanent and then wed just be out of luck.

Still, since your labeled as a recognized developer, Id rather people listen to you. I just cant help but worry about that. SELinux seems like more of a burden than anything. I was happy to realize you could even delete those policies.
[Verizon Samsung Galaxy S 4] E:V:A:
No you're wrong, and need to read Chainfires Blog (in lack of other good sources):

SELinux has been present in stock Android since 4.3 (API Level 18, JELLY_BEAN_MR2) in permissive mode,	and was switched to enforcing mode in Android 4.4 (API Level 19, KITKAT).
​

SEL is not the obstacle, it is Google who's the obstacle by smashing SEL in our faces without giving us easy access tools to deal with it. Obviously SEL was not developed by Kernigan and Richie type of people, who actually spent some time thinking also about the consequences of its use and implementation. It's seem to have been created by a bunch of egotistical and antisocial nerds at a blog meeting. (NSA kids?) With little forward thinking, apart from their own paranoia. That said, its excellent at preventing pretty much any external attack, when setup correctly, which it never will be, and also equally excellent at preventing any developers from continuity their normal work, at a rate of 2008-10, or as in the old days of ubuntu su-from-the-box. The intro of SEL in AOS have just kicked advanced AOS App development down to what it was before GB days.

So if you're happy with writing 1984 "Hello World!" apps for big-bro, you won't notice a thing.
[Verizon Samsung Galaxy S 4] bennyboy78:
I read somewhere that Android L will now have some sort of implementation of Samsung Knox incorporated by Google. Wonder how that's gonna be [emoji21]
[Verizon Samsung Galaxy S 4] NighthawkXL:
If that ends up being the case we might as well consider Android to be no different in terms of being locked down as iOS. For a project that claims to be "open source" Google is really going against the spirit of open source software in the first place.
[Verizon Samsung Galaxy S 4] Addiso:
I believe it's because they want to win the hearts of Enterprises and I'm sure they'll make serious money with them. Money hungry like Google isn't already....
[Verizon Samsung Galaxy S 4] jgrubbs:
Yup. Its all about the Benjamin's. They don't give a what!
[Verizon Samsung Galaxy S 4] JLow0214:
Yea I could see that, but doesn't Google make **** tons of money everyday

Sent from my SCH-I545 using Xparent Skyblue Tapatalk 2
[Verizon Samsung Galaxy S 4] ShimaMiku:
"[They're] not doing it for the money; [they're] doing it for a ****LOAD of money!"
[Verizon Samsung Galaxy S 4] npjohnson:
Idea/possible vuln?

Hey All, This is my first post in this thread, so please be nice (: I have been following this thread for a while and had an idea...

I know that we want/need kexec to load a different kernel, and that is almost impossible for our device

My question is, what would prevent us from using a safestrap like program to hijack the boot process and symlink the stock kernel to a new kernel (AOSP), thus eliminating the need for kexec?, and when the phone is powered down, the symlink is destroyed, so the bootloader sees the stock samsung kernel, but then directly after the bootloader finishes, the boot process is hijacked, kernel symlink, etc. Does this idea have any merit whatsoever? If not, why?

Thanks ahead of time.

---------- Post added at 07:17 PM ---------- Previous post was at 06:54 PM ----------

Wasn't NC2 an officialy signed Bootloader that read off unofficial (not signed by samsung)? It allowed downgrading to MK2 and or upgrading to NC5, what would prevent us from relabeling MDK say NC3 and flashing it? If NC2 has an MD5 requirement of some kind then never mind.

Also, on what physical chip is the BL stored? Has anyone successfully replaced said chip with an MDK stock one?

Another question, also, why is it that Googlie was able to make modified tar files to downgrade Kitkat to Jellybean... (I know it left the bootloader where it was at to begin with), but if he can use unsigned/modified files in ODIN, why can we not just make our own unofficial build that contains the Loki exploit but is not MDK?

Please excuse my ignorance, I read through this thread, but had a couple questions.
[Verizon Samsung Galaxy S 4] Jackelope:
You should watch this video: The Story of (In)-Secure Bootloaders

They talk about how they've used bugs in bootloaders to install custom kernels. The S3 is one of the phones they talk about. They talk

about where the bootloaders are installed. One of the methods they've used was using an officially signed bootloader that loaded an unsigned piece of code which allowed them to load a custom kernel.
[Verizon Samsung Galaxy S 4] Hashbang173:
So can we use this with the S4?
[Verizon Samsung Galaxy S 4] Jackelope:
The Bugs\Exploits they are showing have already been patched. As of right now there is no known bug\exploit for the S3 4.3 to 4.4.2. So we just have to wait to see if someone comes up with one. Until then the bootloader is locked.
[Verizon Samsung Galaxy S 4] Surge1223:
Safestrap operates at system level, not kernel level and also aboot verifies the kernels integrity before booting android. We cant hijack the kernel with an aosp kernel because of Samsungs implementation of TIMA which does real time monitoring of the kernel among other things.

We can downgrade to MK2 from NC2/NC5 because Samsung didnt blacklist the MJ7/MK2 kernel. We cant use unsigned/modified files with Odin. Lastly, different parts of the bootloader exist in different areas.
[Verizon Samsung Galaxy S 4] npjohnson:
Thanks!!!

Thank you for the reply. (:
[Verizon Samsung Galaxy S 4] Brooklynsour:
I think we were before the otas rolled out and patched the opening for it....
[Verizon Samsung Galaxy S 4] LiLPurP:
So currently the roadblock here is that we dont have an exploit that can help us do anything to the bootloader, and we cant change it with a bootloader of our own becuase we cant get around the signatures, is that correct?

AT&T Galaxy S4 4.3 MK2 rooted with saferoot, safestrap recovery installed, Running Hyperdrive ROM, Praying for unlocked bootloader lol
[Verizon Samsung Galaxy S 4] Kole_Ackerson:
From my understanding. Yes.
[Verizon Samsung Galaxy S 4] kirbee213:
Yeah this is off topic, but bless you for the awesome quote.
[Verizon Samsung Galaxy S 4] aznjosh:
I know the tmobile s5 has a bootloader unlock for kitkat even though it trips knox. Is it not possible to use the same exploit on our s4?
[Verizon Samsung Galaxy S 4] DeadlySin9:
Where did you see anything about a bootloader unlock? Last I checked it was already unlocked and all they needed was root, which worked with CF Auto Root for them, and searching didn't turn up any unlock for any variant. If there actually was an exploit there's a chance it might work as long as it wasn't hardware specific, but there's no guarantees in any case.

There hasn't been an opening since MDB/MDL with the exception of the possibility that Saferoot opened up with modifying kernel memory, which all depends on Hashcode getting kexec working. Besides that, it's all possible leads and investigation.

Unfortunately most speculative ideas at this point are nothing new, and unless someone comes in with a new and different idea then it's all up to research and investigation.
[Verizon Samsung Galaxy S 4] coolsilver:
Too bad there wasn't an NFC hook or battery data hack to make it assume the device is taking an ODIN flash from a Samsung diag station or official repair tool. Then an hacked unlocked bootloader can be forced on the device.
[Verizon Samsung Galaxy S 4] NighthawkXL:
Well it's not out of the realm of possibility to force a image onto the device. The problem is it likely wouldn't run... and it's not user friendly for others if it did work. The idea of bypassing the security on a hardware level has been brought up before sorta like a modchip for a gaming console. But unless someone is willing to trace the entire circuitry of the S4 motherboard it's a moot point, and even then we go back to it being unfriendly to the vast majority of users.
[Verizon Samsung Galaxy S 4] coolsilver:
True. My point was mostly that it is a data point that if actually used some how that a simple NFC tag could bypass some check because they might think no one would try it. Modchips and the sort would kill all warranties and have much more risk.

Just throwing crazy ideas out there.
[Verizon Samsung Galaxy S 4] Jackelope:
While JTAG isn't the most user friendly can it be used? I thought I heard someone say that JTAG will no longer work to overwrite the bootloader.
[Verizon Samsung Galaxy S 4] joshm.1219:
Doesn't work
[Verizon Samsung Galaxy S 4] tanishq.dubey:
OK, this does relate to the unlock (If there every will be one). Would you guys say that there is a better chance of getting a unlock on a older firmware (4.3 MK2, 4.2, ect) or do you think the chances will be the same for the NC5/NC2 firmwares? This topic has kept me on the fence with upgrading to NC5 using Surge's method, but I just wanted to confirm here.
[Verizon Samsung Galaxy S 4] DeadlySin9:
If an unlock happens, there's a chance that Samsung may have not noticed the exploitable code and it may be present in multiple bootloader. If kexec is ever made to work, we know that from 4.4 we can get the MK2 kernel back and run custom modules so that should work for us. The chance of an unlock working decreases with each update, but there's no telling by how much.

Sent from my SGH-I337 running GPE
[Verizon Samsung Galaxy S 4] Surge1223:
So this is a somewhat difficult question to answer. Most of us/those that look at this stuff always look at the newer and/or newest firmware available. Are the chances better on an older firmware? Sure. But there is also less if not any looking at older firmwares. Choice is yours, have you ever danced with the devil in the pale moonlight? I sure have.
[Verizon Samsung Galaxy S 4] Zooandbio4me:
So I'm completely aware that this information is 200% subjective.... But I was on the phone yesterday with a Verizon "Samsung specialist tech" (forced to *228 due to new number, so called to see if I could regain 4g without the hour long wait @ the local store) And while I was waiting I asked him: "So, any chance you guys will be unocking this phone's bootloader any time soon? and he was like actually yeah we really might.. I was like WTF!? lol and he was like yeah they've been talking about it for quite some time, it seems to be a consensus that users don't mind he warrantee void etc... I was like dude... lol
[Verizon Samsung Galaxy S 4] LiLPurP:
Tbh if he said that, i think they may have given Dan R. Permission to release his trustzone exploit in august, could that maybe be what the "tech guy" was referring too? Juss being real, i want this thing to be dev unlocked just as a nice FU to the carriers who think they own our devices, not sure how you guys feel, but they def dont deserve "praise" if the carrier unlocks the bootloader, its their fault in the first place, but that doesnt bring a secondary chance of hope, i guess

AT&T Galaxy S4 4.3 MK2 rooted with saferoot, safestrap recovery installed, Running Hyperdrive ROM, Praying for unlocked bootloader lol
[Verizon Samsung Galaxy S 4] JLow0214:
Well there's that and Sammy just released phones with their new Tizen OS too and that may have an effect on this also

Sent from my SCH-I545 using Xparent Skyblue Tapatalk 2
[Verizon Samsung Galaxy S 4] LiLPurP:
Oh wow, actually ive been pretty ignorant to anything not S4 currently, i started messing with my samsung infuse again but can flash anything :/ but my S4 is amazing, and i cant wait to see what it can really do with with more options available, and ill look into that thanks

AT&T Galaxy S4 4.3 MK2 rooted with saferoot, safestrap recovery installed, Running Hyperdrive ROM, Praying for unlocked bootloader lol
[Verizon Samsung Galaxy S 4] Surge1223:
I wanted to comment on this now that ive had time to sit through and watch the whole thing. Its really informative for those who are interested in the topic of bootloaders and have not investigated how previous exploits were made/found. Of particular interest is a comment Kang Li makes about the TrustZone, and although he didn't divulge into it, he clearly showed interest in it.

Also of interest is how they go over how Ralekdev's PIT exploit worked and how they found it, unfortunately to learn or find these kinds of vulnerabilities it requires background knowledge on reverse engineering. Ive gotten somewhat decent at it, and we all know jeboo's skill as he has already demonstrated his ability to find and exploit a vulnerability (bypasslkm).

Some additional info on reverse engineering: most of what you need to get started is available on the internet and xda (and this thread for that matter) also include a lot of good info/links if you have to ask how to get started then your prospects seem gleem at best. Not trying to put anyone down, just telling it how it is.
[Verizon Samsung Galaxy S 4] Hashbang173:
What if we write to the efuse something like .1?

Sorry if this is stupid idea.
[Verizon Samsung Galaxy S 4] Kole_Ackerson:
If it was that simple wed be unlocked by now
[Verizon Samsung Galaxy S 4] tanishq.dubey:
I think that won't work since the efuse probably only accepts int values, not doubles or floats. Also, Samsung probably has a simple check to see if the efuse is out of expected range. Don't take my word for the second part, the devs know more about that than I do.
[Verizon Samsung Galaxy S 4] KaratemanTJ:
I believe the fuses are binary. Blown or not blown. 0 or 1. Each fuse is a bit and can be read as part of a block or on its own.
[Verizon Samsung Galaxy S 4] ahmed.zubair:
Is There Any Any Any Any Any Any Any Any Any Any Any Any Any Any Any Any Any Any Any Any Possiblity oF ****in bootloader unlocking ??? Just Curious to know .... :silly:
[Verizon Samsung Galaxy S 4] Mistertac:
Anything is possible but if you glance through this thread you'll see what these guys are up against. It's a ridiculously hard task. But no one can really answer your question with a solid yes or no
[Verizon Samsung Galaxy S 4] decaturbob:
More than likely.... No. The level of security is leading edge.

sent via safestrap 3.72 and echo v25.1! !
[Verizon Samsung Galaxy S 4] tanishq.dubey:
Yep, you are correct. Each fuse can only hold a value of 1 or 0, however, the fuse can be - manufacturer dependent - incremented a certain number of times, leading to different eFuse values.

For those still wondering what a eFuse is, the Wikipedia entry for the topic was pretty good:

What type of changes could be made? As discussed previously, a big change would be increment a chip for version control, making it easy for companies to check the version of user software.
[Verizon Samsung Galaxy S 4] V0latyle:
Probably from "it works" to "aww dang, it don't work no more"
[Verizon Samsung Galaxy S 4] Surge1223:
If you're wondering why theres nothing being posted lately its probably because posting anything here has no direct benefits and has potential negative consequences, but this isnt to say that anyone has given up. In the interest of those that are still learning/trying themselves Im posting some info that might be helpful regarding some changes in 4.4.2+. Also lets keep the unproductive questions/comments to a minimum, I check this thread daily and the amount of useful/productive posts have gone down.

1. Viewmem, readmem, devmem2 and other binaries requiring access to /dev/kmem and/or /dev/mem will not work without making sure selinux is set to permissive. You can manually do this with the command "setenforce 0" but since I use it more often than most, I just add "setenforce 0" to the end of init.qcom.post_boot.sh or you could add a script in /system/etc/init.d that says "setenforce 0" (no quotes) with the right permissions. This will allow you to use viewmem, readmem, and devmem2 again.

2. Samsung changed the way that lkmauth verifies kernel modules and I haven’t been able to figure out a way to re-enable using unauthorized kernel modules. If you are able to figure out a way to do so please let me know (this is mostly directed towards those familiar with kernel source and related tasks like objdump, xxd, readelf, etc)
[Verizon Samsung Galaxy S 4] sokrboot:
Why would they change it ...?
[Verizon Samsung Galaxy S 4] DeadlySin9:
Because we exploited it probably. They're not going to leave them open as we saw with Loki.

Sent from my SGH-I337 running GPE
[Verizon Samsung Galaxy S 4] Brooklynsour:
2. Samsung changed the way lkmauth verifies kernel.

Did that happen during the mf3 ota?
[Verizon Samsung Galaxy S 4] DeadlySin9:
No, he said those changes were in 4.4.2+.

Sent from my SGH-I337 running GPE
[Verizon Samsung Galaxy S 4] tshelby73:
Guess it might be a good thing I kept mk2 bootloader when I upgraded to nc5.
[Verizon Samsung Galaxy S 4] LiLPurP:
In our current situation, staying on as low a version of the bootloader as possible will be helpful, if an exploit is found for an older bootloader than you dont want to have the updated 4.4.2 bootloader

AT&T Galaxy S4 4.3 MK2 rooted with saferoot, safestrap recovery installed, Running Hyperdrive ROM, Praying for unlocked bootloader lol
[Verizon Samsung Galaxy S 4] Bad Bimr:
Hoping you guys succeed in getting this device fully bootloader unlocked. About a month ago I bought an HTC M8. So far I miss the AWESOME S4 screen but I don't miss the super slow touchwiz interface that would take several seconds for the dialer, messaging or other app open. Keeping the S4 (still on ME7) because I have faith that you guys will unlock it! Keeping my fingers crossed that one day I will again enjoy my S4 with a light AOSP ROM. Keep up the GREAT work!
[Verizon Samsung Galaxy S 4] Walter.White:
[MENTION=4939386]Surge1223[/MENTION]

Not sure if you've seen this...

https://github.com/ralekdev/mbn_ida_loader
[Verizon Samsung Galaxy S 4] Surge1223:
Yep I have, in fact I used some of his code for my ida loader I made and I edited it to load more than 1 file and to add more functions to the database, also created a bunch of sigs to flirt idbs with, including sigs for lk which I had to compile a generic 8960 lk to get. It maps 30 or functions in lk, the other sigs I made map a lot more in the sbl partitons and pbl. I will email him soon and send him what I used of his/the edits I made but I cant post it publicly because if you ever read anything I write you'll notice I swear a lot in the comments and I refuse to remove them. (The name I gave the ida loader alone wouldn't allow me to post it here).
[Verizon Samsung Galaxy S 4] scryan:
http://www.vidarholen.net/contents/wordcount/

You'll be fine :P

(Wanted to post this... But the link wont even make it, lol. http://jann.is/daily/archives/350-****-Linux!.html )

Anyone who wants to complain can go read Linus's old mail list replies, lol.
[Verizon Samsung Galaxy S 4] Surge1223:
Can someone please send me a link to what patch qcom implemented for this?

https://www.codeaurora.org/projects...arsing-during-boot-image-authentication-leads

Their link to their patch is broken.
[Verizon Samsung Galaxy S 4] Hashbang173:
This: https://www.codeaurora.org/cgit/qui...r&id=f39085971c8c4e36cadbf8a72aabe6c7ff538ffa

?

I fixed the link
[Verizon Samsung Galaxy S 4] eragon5779:
This won't work on any Samsung device.
[Verizon Samsung Galaxy S 4] NighthawkXL:
He was replying to Surge's question, not suggesting that we look at it for a means to unlock our devices with.
[Verizon Samsung Galaxy S 4] eragon5779:
Ya. My bad. Sorry.
[Verizon Samsung Galaxy S 4] Walter.White:
Looks like they have found a way to unlock G3 bootloader...Here is to hoping that same method works on Sammy devices. (Kinda like Loki worked on both LG G2 and S4)

https://i.imgur.com/SRdldWc.jpg (by [MENTION=3878912]th3g1z[/MENTION])

http://xdaforums.com/lg-g3/general/bounty-lg-g3-d855bootloader-unlocking-t2807900/post54030443

http://xdaforums.com/lg-g3/general/bounty-lg-g3-d855bootloader-unlocking-t2807900/post54032698

https://twitter.com/TeamAndIRC/status/487028915559735296

https://twitter.com/utoprime/status/486969514299760641
[Verizon Samsung Galaxy S 4] eragon5779:
Hopefully it works on S5.