yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S 4] doubleaykay:
Dude there is no reason to. Its a proven and known phenomena. Save yourself some time!
[Verizon Samsung Galaxy S 4] Sterben Pistole:
Kay is right. It happens when on stock and rooting. Pretty much all custom roms will rid of the problem as soon as they're flashed. I would get Wanam and use the option to set the status to official if you enjoy stock and would like to keep stock.
[Verizon Samsung Galaxy S 4] dmc2359:
If you want to get rid of the padlock and "custom" just use TriangleAway by Chainfire to reset the flash counter. ...
[Verizon Samsung Galaxy S 4] doubleaykay:
OK guys, we should get back to business. I can help out with the kexec testing on a Nexus -- I have a Nexus 7 (2012) lying around. I can also test stuff on my S4 on AT&T, which does have a locked bootloader. Also, has anyone looked into decompiling the current bootloaders and looking for an exploit like that? Or perhaps like the way iOS jailbreak developers do it?
[Verizon Samsung Galaxy S 4] daredevl99:
the problem with decompiling anything that has been compiled is you get assembly code and headers which are all but useless to most and still hard to work with for extremely experienced people. And still they would be encrypted.
[Verizon Samsung Galaxy S 4] Surge1223:
Oh decompiling the current bootloaders is not hard, understanding it is another thing. Me and [MENTION=766721]ryanbg[/MENTION] could have a whole thread discussing the disassembly of bootloaders. We have however made things easier on ourselves as opposed to in the beginning when we'd have to manually take them apart
[Verizon Samsung Galaxy S 4] 06sharpshot:
You have a github with all the kexec progress right? That may be something interesting for some people to look through. I wish I knew enough to help with that, if there's ever anything us inexperienced guys can do that would help you out, be sure to let me know. I'd love to do what I can.
[Verizon Samsung Galaxy S 4] SnyderGuy:
Willing to help out and test things if I'm needed (such as kexec, though that might be a while from what I see)

My device:

VZW SCH-1545 (S4), NC5, 4.4.2, safestrap 3.7.5, hyperdriverls20 ROM, stock kernel, stock recovery, secure bootloader.

I do know how to do odin, so it is okay if testing soft-bricks me.

Hit me up if you wish to have a tester.
[Verizon Samsung Galaxy S 4] doubleaykay:
What exactly would need to be done to understand it? I'm willing to learn and help!
[Verizon Samsung Galaxy S 4] Dhs92:
I'd also be willing to test.

SGH-I337 Rooted, Pure Nexus ROM.

Locked bootloader, NC1.
[Verizon Samsung Galaxy S 4] doubleaykay:
Me too, as I've said before lol!

SGH-i337, NB1 Base, GPe ROM 4.4.4, locked bootleader, SafeStrap
[Verizon Samsung Galaxy S 4] Legitsu:
quit derailing the thread the chances of this happening are basically zero
[Verizon Samsung Galaxy S 4] XxD34THxX:
Why can we not just make the whole storage blank and make it as if IT IS STILL IN THE FACTORY WITH NO DATA. No bootloader, no Crap, like wiping an HDD/SDD on a PC. Then flash the MDK bootloader. The phone won't know since the memory of actually updating has been erased...
[Verizon Samsung Galaxy S 4] Legitsu:
doesn't work like that once the qfuse is blown its permanently tripped there is no way to reset it not with hardware or software
[Verizon Samsung Galaxy S 4] doubleaykay:
What trips the qfuse?
[Verizon Samsung Galaxy S 4] Legitsu:
code in the aboot when you upgrade
[Verizon Samsung Galaxy S 4] doubleaykay:
That means its already tripped for most people... Does the bootloader have to verify the qfuse? Can't a simple code change be made so there is no verification?
[Verizon Samsung Galaxy S 4] Legitsu:
no

jesus people I don't wanna sound rude but people way smarter then you have been though all this

there is no *unlocking the bootloader" baring a major breakthrough, KEXEC is the only hope and its very slim most because as far as I know one person is still kinda sorta working on it and he doesn't have time

at least now we have a ASOP rom for the S4 that is usable
[Verizon Samsung Galaxy S 4] Sterben Pistole:
Just like Legit is saying and had said many times, no true Bootloader unlock will happen. The only way it Kexec. For all those thinking there's a way around the blown qFuse, please read up before posting. Its an extremely small piece of hardware that is in the device. Its practically impossible to fix because of the size. Now that you know what a qFuse is you need to understand that since its a hardware mechanism, there is even a smaller chance of finding a way around the Bootloader trying to figure out the qFuse stuff. We are set on Kexec right now. It's the easiest and probably the only method of getting around the BL for us.

I hope I helped out for those who didn't understand :) Oh and if any of my info is wrong, please correct me.
[Verizon Samsung Galaxy S 4] XxD34THxX:
Well, I feel like an idiot as I thought it was software. Too bad there isn't a BIOS battery-type thing here. I'm gonna google KEXEC now and feel like I know something.

EDIT: You'd think I'd know what KEXEC is after working with Linux for a few years. Guess not.
[Verizon Samsung Galaxy S 4] npjohnson:
Well, that "barring a major breakthrough" part, a great example to be brought to light would be the Razr Bootloader Unlock by Dan Rosenberg here: http://blog.azimuthsecurity.com/2013/04/unlocking-motorola-bootloader.html

It relied on a TZ exploit (which we partially have), as well as finding the mapping in memory where the [is_unlocking_allowed()] (pseudo-code), and realizing that, while one QFuse had been blown to disable unlocking, blowing a strategic set of other QFuses causes it to return a [is_unlocking_allowed()] status, and in reality, isn't the end goal here to just set the KNOX Kernel Lock Flag to 0x1? So, its not that strange an idea.

Now, I realize that this exploit will not work, as it is a completely different bootloader implementation, but similar methods /Most likely/ can be applied. I'm not at a level of understanding to state that such a vulnerability exists, but it is most definitely a possibility.

Kexec is one of the options we have, other tools are available, such as kGraft & kSplice (Dynamically splices in kernel security patches/patches). Another one being Kernel Modules, Surges Modload is sorely underused. Kernel modules can do so much, like enabling Quick-Charge, and a variety of other things, but I've often wondered why we haven't tried to use a Malformed Kernel Module from an exploitation point of view, as a kernel level process seems like it should be able to at least view where important flags are set into the memory.
[Verizon Samsung Galaxy S 4] Legitsu:
I brought the issue up of experimenting with modules awhile ago nobody seemed interested other then surge

most of the people capable of getting such a exploit to work have long abandoned the vzw s4 or are to busy with other devices to dedicated any real time toward it

http://xdaforums.com/galaxy-s4-verizon/help/binary-kernel-patching-runtime-via-t2994572

personally cpu and gpu overclocking are something I would really like to see even if its on the stock kernel I do a lot of multi-tasking with charts and mobile cad and the s4 just doesn't have enough power somedays
[Verizon Samsung Galaxy S 4] Surge1223:
I've done a lot with kernel modules and overclock and custom governors are possible, I know because I have made them but the thing is releasing things like this would lead to 5000 questions that I just don't feel like answering lol. Aosp mtp issues on s4 could prob be solved pretty easily.
[Verizon Samsung Galaxy S 4] Legitsu:
so don't release them yourself and don't answer the questions if you aren't smart enough to figure out how to use insmod you should't be running a custom rom in the first place :P

source would be nice tho then we could see about getting them to work on kitpop ASOP its better than nothing

he was working on using UMS to replace MTP for 1.3 last I heard

I agree it should be possible to make it work native tho
[Verizon Samsung Galaxy S 4] doubleaykay:
I agree with Legitsu -- you should rease at least source code. That would be really helpful in getting as complete an AOSP experience as possible.
[Verizon Samsung Galaxy S 4] SamuriHL:
Hey Surge, let me rephrase what the others are ASKING FOR. Would it be possible for you to release the source AS-IS so that the community could benefit from it while keeping you out of the support path? THANK YOU.

:rolleyes:
[Verizon Samsung Galaxy S 4] Legitsu:
what is there to support one of three things happens

1. it works: YAY

2. it doesn't: DRATS

3. it causes your phone to implode and create black hole sucking you and everybody else into the abyss: NooooooooooooooooooooooooooooooooooOOOooo

at any-rate I am gonna fork his gitreapo and see what can be done,when I have time
[Verizon Samsung Galaxy S 4] doubleaykay:
Do you have a link to his git repo? I'd like to take a look at it.
[Verizon Samsung Galaxy S 4] Legitsu:
https://github.com/Surge1223/kernel_samsung-jfltevzw-VRUFNC5
[Verizon Samsung Galaxy S 4] doubleaykay:
Thanks.
[Verizon Samsung Galaxy S 4] npjohnson:
I'm 100% in agreement about public overclock methods. Bad idea waiting to happen XD.

I was speaking from an exploitation perspective.
[Verizon Samsung Galaxy S 4] Legitsu:
not at all

1. the rom would need to be rooted

2. the rom would need to have the modload patch installed

3. a malicious person would need r/w access to /system or the user would need to flash said modules

4. its frankly nobody's fault but the users if they go installing strange modules or flashing .zips of unknown origin

the gains outweigh any possible downside

when I have time ill re-setup my build environment later and see what needs to be done to spit out some NC5 modules that allow some basic CPU/GPU clock control

id rather not repeat work that's already been done
[Verizon Samsung Galaxy S 4] npjohnson:
No no, you misunderstood my post. That would have been better as two separate posts. I meant that when I referred to modules, I meant using the modules as a potential injection vector/window into the boot loader/secure memory.

When you brought up the over clocking ideas, I agree with overclocking (for very advanced users), I, however, agree with surge that public release of such modules is a bad idea. Too many people saying "does it b normel for ma phones to get so hotz it burn my hand?" Or "My phone no longer turns on, its your fault!" Too many variables. I however, would appreciate an open source overclocking/underclocking module, and I've begun to recently learn about kernel development and module development, so I'd be more than willing to help with such a project, but I'd probably end up being more of an observer due to my experience level.

On a note of NC5 modules, [MENTION=4939386]Surge1223[/MENTION], is modload open source? If not, would getting it running on NK1 be a matter of remapping the static memory location? Or would more be involved?
[Verizon Samsung Galaxy S 4] doubleaykay:
Would modifying the modules/modload involve the same process for us AT&T users? I'm more than willing to help out with that, especially with the MTP and Overclocking modules.

Edit: Furthermore, can we use modload and a module to attempt to get kexec working? We could bundle kexec as a module...
[Verizon Samsung Galaxy S 4] npjohnson:
Modload is necessary to load potential MTP modules. From my understanding, it wouldn't be to duper hard, but I could easily be very wrong. The issue at hand may be NK1's lack of SELinux Permissive status, and I believe that modload requires permissive status.
[Verizon Samsung Galaxy S 4] doubleaykay:
I'm lucky in that sense. AT&T 4.4.2 (NB1) has full SELinux Permissive. I'm willing to test if need be as I have permissive set on my device.
[Verizon Samsung Galaxy S 4] npjohnson:
I know that NC1 for you guys has a modload ready made :p
[Verizon Samsung Galaxy S 4] Legitsu:
ahah sorry
[Verizon Samsung Galaxy S 4] doubleaykay:
Yep I just found that, looks like it works pretty well too. I may upgrade to NC1 from NB1. Question is, can I compile kexec from whatever Surge has done as a module for this? (I doubt it).

Also, is there a module I can load in to actually make MTP work on AOSP? Or is there one I can compile?
[Verizon Samsung Galaxy S 4] Legitsu:
http://xdaforums.com/galaxy-s4-verizon/development/mod-enable-insecure-modules-nc5-nc1-t2877403

^^
[Verizon Samsung Galaxy S 4] npjohnson:
1. Yes, but it is not in a ready working state, it hangs at a specific call.

2. Nope. That's what we are talking about trying.
[Verizon Samsung Galaxy S 4] doubleaykay:
Right. Which call is it? I have some experience in the Linux kernel, maybe I can help.

2. And yeah I did realize that after posting lol... This is something I'm really waiting for :p
[Verizon Samsung Galaxy S 4] npjohnson:
I'd look back through this thread a bit, then if you have further questions, PM Surge, as he's the goto guy for that on this forum (:.
[Verizon Samsung Galaxy S 4] Legitsu:
last I heard the problem with getting KEXEC Working was lack of DEBUG output something that is going to need hardware hacks to resolve (serial connection soldered in)
[Verizon Samsung Galaxy S 4] doubleaykay:
Ouch, lack of debug must be tough. I know Surge is trying kexec on a nexus for this reason, but had anyone attempted to run it on an S4 with a more friendly bootloader/kernel (GPe, I'm thinking)?

Plus do we really need the debug output? Is it not possible to work around it, as in compile the code specifically that we know it should work?

I know I'm asking tons of questions lol but I'm just trying to get a sense of whats up and if I can help.
[Verizon Samsung Galaxy S 4] Surge1223:
It's not much if I remember right, I think it was acpuclock, vhs.h and board-8064.c edits. The most obvious edit being #include <linux/module.h>
[Verizon Samsung Galaxy S 4] Legitsu:
yea beat you to it infact I was looking at those sections last night

just a matter of me getting time and getting off my fat ass and doing something productive
[Verizon Samsung Galaxy S 4] XxD34THxX:
I assume we cannot physically move this qfuse back? Or is it just that small or made in such a way to be impossible to move back.
[Verizon Samsung Galaxy S 4] npjohnson:
To smaller, as well as it is a fuse and would require a microscopic replacement.
[Verizon Samsung Galaxy S 4] Legitsu:
assuming you could even locate it ...

you are talking about sub-micron level stuff
[Verizon Samsung Galaxy S 4] XxD34THxX:
Ouch. Way too small.
[Verizon Samsung Galaxy S 4] sokrboot:
Wonder if we could get kpatch working instead of kexec? From my research it seems to be a better way to manipulate functions without having to use machine_shutdown...and I believe the take down and power up of the CPUs is part of what's killing our kexec. I've read that our cpus aren't fond of certain shutdown/restart protocols...not off lining and onlining them in the right way can cause data/memory corruption possibly causing the hang at that stack call. Just my 2 cents and I'm far from an expert.
[Verizon Samsung Galaxy S 4] Legitsu:
Mm intresting idea but a lot of work has already been done with KEXEC As far as I know nobody has messed with kgraft or kpatch

it would be basically starting from scatch
[Verizon Samsung Galaxy S 4] npjohnson:
I mentioned this a while ago. And actually, much of the work done on kexec would apply to kpatch. Referring to atags and stuff
[Verizon Samsung Galaxy S 4] Legitsu:
gl finding somebody todo that tho, pretty much everybody has given up on the S4 I don't blame them, samsung seems to be going out of there way to kill off custom roms over there relatively useless knox security

my next device is either gonna be a HTC or a Nexus unfortunately I am stuck with this s4 until my contract is up

at this point I am betting most will be happy when kitpop get's to a state where everything is plug-n-go ;)
[Verizon Samsung Galaxy S 4] npjohnson:
Ugh be careful with HTC. Getting SOFF isn't always easy, and that is necessary to disable write protection. I went nexus and haven't looked back. (Excluding for kitpop.... XD, and this.)
[Verizon Samsung Galaxy S 4] Surge1223:
cpufreq_conservative.ko

cp to /system/lib/modules

chmod 644 /system/lib/modules/*.ko

insmod /system/lib/modules/cpufreq_conservative.ko

Use your favorite cpu settings apk to load it
[Verizon Samsung Galaxy S 4] Legitsu:
what kernel is that for NC5 ?

edit: NC5 indeed WHOOHOO
[Verizon Samsung Galaxy S 4] sokrboot:
[MENTION=5417447]Legitsu[/MENTION] [MENTION=5848265]npjohnson[/MENTION] re:kpatch I haven't compared but there has to be a great deal of similarity between kpatch and kexec. I was thinking that sometimes you have to take a step backwards to continue moving forward. (I sound like a fortune cookie).

Ok so it just clicked that what we REALLY want to do is replace our kernel not just modify it, so maybe kexec is our only answer...unless ...If we can already get AOSP running (which we can, sort of) maybe we could kpatch the current kernel to be more friendly to that change. So we'd be layering kpatch on top of Safestrap to allow more native use of AOSP.

Edit: add bb code. FAIL. (What did I do wrong?)
[Verizon Samsung Galaxy S 4] Sterben Pistole:
Can this be made for NB1 (AT&T 4.4.2)? Also, does this allow over clocking to 2.2 GHz?
[Verizon Samsung Galaxy S 4] Legitsu:
no it doesn't allow overclocking its a Governor
[Verizon Samsung Galaxy S 4] Sterben Pistole:
Which governor? Is it one if the custom ones?
[Verizon Samsung Galaxy S 4] Legitsu:
replies like this are why he was hesitant to release it

it adds the "conservative governor" to a existing NC5 Based kernel assuming you have the modload patch installed

ffs people read the thread before asking questions that where answered 4 posts up hell even the file-name tells you what it does
[Verizon Samsung Galaxy S 4] doubleaykay:
So looking around the /system/lib folder on my S4, I found a bunch of libraries pertaining to MTP:

-libmtp.so

-libmtp_samsung.so

-libmtp_samsung_jini.so

Would porting these to AOSP help mitigate the MTP issues on SafeStrap AOSP ROMs?
[Verizon Samsung Galaxy S 4] Legitsu:
its more then just porting iirc there are some issues with the way ASOP handles MTP vs touchwizz
[Verizon Samsung Galaxy S 4] doubleaykay:
Right... that is really strange, why would Samsung even change MTP? Such a strange thing to change....
[Verizon Samsung Galaxy S 4] scryan:
The kernel loads before safestrap, before anything else really. That we have "asop" roms is kinda a lie as far as I understand. Its closer to a tw rom with a theme... Its a modded version that runs of a stock kernel, because the kernel is loaded before we can choose whats being loaded... So running an "asop" rom wont make things any easier, its the same kernel your dealing with behind the scenes.
[Verizon Samsung Galaxy S 4] Surge1223:
I know modload looks like a binary, but it's actually just a script, like any other .sh script. You can view what it does by opening it in a text editor :)

Well the mtp driver shouldn't be difficult to make into a loadable module, considering the source for it is already in the drivers folder in kernel source.
[Verizon Samsung Galaxy S 4] Legitsu:
thats incorrect kitpop is a ASOP rom though and though there is a bunch of scripts and symlink trickery to get it to work on safestrap/stock kernel

the stock kernel isn't really a issue the lack of overclocking and custom governors are where you pickup a good chunk of performance you + can do a lot with binary patching
[Verizon Samsung Galaxy S 4] scryan:
I guess thats opinion/semantics... Hard to call it asop through and through when its running on a tw kernel, just basically an aosp gui for tw....
[Verizon Samsung Galaxy S 4] Legitsu:
a kernel has nothing todo with what rom is running they merely need to be "compatible" the official Samsung kernel is not all that different from something like ktoonz a kernel is a kernel a rom is a rom

our problem is that we need to use safestrap which means we are stuck with certain limitations when it comes to the file-system and partition layout because we can't touch anything in \boot or \datadata it also means we are stuck with the default "initramfs/initrd" and the various .rc scripts which is where 90% of the issue running ASOP or AKOP or even CM is requiring you to patch the rom so everything works, its entirely within the realm of possibly to get CM11 to work

it would just require a fair bit of work

http://www.kpbird.com/2012/11/in-depth-android-boot-sequence-process.html
[Verizon Samsung Galaxy S 4] Legitsu:
interesting commit today in the kernel mainline looks like the upstream main line linux kernel is getting live patch support

https://git.kernel.org/cgit/linux/k.../?id=1d9c5d79e6e4385aea6f69c23ba543717434ed70
[Verizon Samsung Galaxy S 4] Zibri:
Excuse me for barging into this thread, but I think a few people here is not thinking out of the box. Forget the Qfuse itself.

Let's focus on sbl1 and aboot. Aboot is the one containing the "knox warranty" which is printed at boot time. All we need to do is:

1) patch aboot so it always shows 0x0.

2) patch the calls that return the know bit status (probably in aboot itself or in sbl?!)

After reading this "http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html" and the related comments, I believe there could be many more coding errors like this one lurking in sbl1 or aboot.

I also believe that much could be accomplished via the QCOM interface (radio interface diag mode) as setting engineering mode or other nice things.

Sorry again if I said something stupid or useless, I'm just brainstorming out loud. I didn't study all this so deeply as I did with the iPhone at the time.

At the moment I have a note3 n9005 with Android 4.3 stock, no root and knox 0x1 for a stupid mistake during my first tests, but who cares.
[Verizon Samsung Galaxy S 4] npjohnson:
Patching Aboot/sbl1? Good luck bypassing the signatures to get the partitions to flash, then after you've gotten to that point, a unmodified sbl1 won't boot with a modified Aboot.

As for patching the calls, we have no injection vector to change said values, best of luck finding one.

QCOM mode has always been an interesting topic, and as stated in the OP, pushing a modified Debrick IMG to QCOM mode could be a potential way to unlock, but then even a modified debrick wouldn't boot from my understanding due to the qfuse implementation.
[Verizon Samsung Galaxy S 4] Legitsu:
once the qfuses trip there is nothing you are gonna do the debrick image must be the same version as the current bootloader level flagged in the aboot counter

even with a jtag you can't downgrade so qcom mode isn't gonna do you any good either
[Verizon Samsung Galaxy S 4] npjohnson:
I complete agreement with you. I was just responding to the previous poster.
[Verizon Samsung Galaxy S 4] RuggedHunter:
This is my post number 420 and I can't think of a thread I'd rather bump.

:D

Here's to hoping this garbage post will bump the thread and catch the attention of our next guru genius with time to kill.

AT&T S4 i337 > SafeRoot > SafeStrap 3.71 > HyperDrive RLS12

Tasker-ized
[Verizon Samsung Galaxy S 4] Walter.White:
[MENTION=974229]Cobaltikus[/MENTION] is taking a crack at N3 bootloader. Lets hope and pray that he succeeds at it :)

http://xdaforums.com/showpost.php?p=58988582&postcount=25
[Verizon Samsung Galaxy S 4] tshelby73:
I'm starting to think the s4 is like a slipknot song that starts with all hope is......

Sent from S4 using the better than it was Tapatalk
[Verizon Samsung Galaxy S 4] Cobaltikus:
It's easy to patch aboot and sbl. But then the signature verification fails and breaks the boot process. So if you patch the code, you also have to patch the signature. I'm thinking we can forge a signature without access to the private key.
[Verizon Samsung Galaxy S 4] tulth:
I have an s4 and would really like to help get it unlocked.

I have some basic questions.

I do not understand the signature check. is it special hardware? if it is done in software, couldn't we just patch the compare and branch machine instructions to bypass all failures even with a bad signature?
[Verizon Samsung Galaxy S 4] Legitsu:
if you don't understand what the problem is don't post