yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S 4] npjohnson:
Yes and no.

[MENTION=3755964]tulth[/MENTION] and I got ModLoad up and running on NK1 with SE Enforcing. (There is a thread for it in the Dev. Section if you want to take a look, but don't just go loading modules willy nilly, they can cause issues if used improperly.)

That allows to continue work on Kexec development, which I think we intend to continue working on for a MultiROM/SafeStrap Multi-Boot solution whether or not TestBit goes through. [MENTION=3755964]tulth[/MENTION] also compiled kexec for NK1, and we are debugging it now, but that could take a couple weeks, or years, we won't know until we do with kexec [emoji14]

We have found TestBit, but that doesn't help us much, as we need a TZ vulnerability to blow TestBit. As by design, TZ won't blow a fuse just because the kernel orders so.

This is an update, but please don't hound for updates in the future, as there may likely not be much to give, unless there is something huge, then everyone will know, I promise. [emoji14]

This is the collaborative effort of the Telegram group we have going, and if anybody wants to join (that can actually contribute and won't just spectate) just PM me, Surge, Jaw20, or Tulth.

Edit: Please don't ask about Dan's TZ vulnerability, it won't work here, we have looked into it.
[Verizon Samsung Galaxy S 4] ryanbg:
Anyone have an S4 available for cheap? I need a research device.
[Verizon Samsung Galaxy S 4] octantcomp:
I'm sorry I hope this will help :

I have new S4 verizon about 8 days ago. when i see about phone :

Model number : GT-i9500

Android ver : 4.4.2

Baseband ver : I9500OLBFNB4

Kernel : 3.4.0-989434

Build number : DONGCHAO.612

Secure boot status : Type : samsung

Hardware ver : 1.06

Security soft ver : MDF v1.0 release 2

After success root with kingo root, Then i install "my device" app from playstore, i got this :

Model : GT-I9500

Hardware : qcom

Board : MSM8960

Bootloader : I545VRUFNC2

Device : jfltevzw

Brand : verizon

Build : KOT49H.I9500XXUFNB7

Then I install "phone info" from playstore, i got this :

Brand : Verizon

Model : GT-I9500

device type : jfltevzw

product name : jfltezc

Bootloader : I545VRUFNC2

Baseband : I545VRUFNC2

PDA : I9500XXUFNB7

CSC : I545VZWFNC2

The seller got info from the distributor, said that this i545 phone is original (I check the IMEI with swappa, it shows that this is verizon s4 i545) but modded with i9500 ROM so it can be use normally in my country..

The bootloader is locked, so how can the distributor change the baseband or build to GT / i9500 including the model number?? And that DONGCHAO612 cannot be found anywhere when i search in google..

Anyway the phone now flashed with I545VRUFNC5 (not mixed with i9500 again).. Maybe i will sell this phone..
[Verizon Samsung Galaxy S 4] NighthawkXL:
Most likely it's one of several options... check the version status in Download Mode (Power + Home + Volume Down) and check its actual hardware version.

The device is a i545 that was exploited using the original bootloader exploit before it was patched, and was flashed with a i9500 ROM albeit unrooted. If this is the case the hardware status in Download Mode will be lower then NC2. Also, check to see if your Recovery (Power + Home + Volume Up) is custom (Philz, TWRP,CWM). If it is, congrats on having a loki device.

The device is a i545 running Safestrap, and has a GT-i9500 ROM flashed to it. (This is most likely)

The device is a i545 running stock and had it's build.prop edited at some point. (This is unlikely)

The device is a GT-I9500 that was improperly flashed with Verizon firmware via Odin. (Even less unlikely)

Anyway, none of this has any bearing on unlocking the bootloader in the sense of the the topic at hand. Your phone should fit one of those categories, if not then you might have a anomaly , but it's unlikely.
[Verizon Samsung Galaxy S 4] bryantjopplin:
He is from Indonesia I believe and odined to nc5, no mdk bootloader.
[Verizon Samsung Galaxy S 4] octantcomp:
No I guess it doesnt have safestrap because it booting normal without safestrap screen... I guess your option number one is possible.. but the recovery is standard - no custom, but i didnt take a look at download mode when its normal until i brick it because i install twrp from twrp manager, then i see the download mode write this :

PRODUCT NAME: SCH-I545

CURRENT BINARY: Samsung Official

WRITE PROTECTION: ENABLE (GREY font color)

eMMC BURST MODE Enabled (GREY font color)

Start [224, 1440] (RED font color)

Unsupport Dev_type (RED font color)

But i already flash it with I545VRUFNC5 and now running hyperdrive with safestrap (because i cannot make it back like the first time and his distributor wouldnt tell me how..:()

Yes i am.. thank you for your support the other day..

Anyway i will not discuss this again because its OOT.. Please go on.. Thank you..
[Verizon Samsung Galaxy S 4] XxD34THxX:
-Edit-

Sorry, accidental post, wrong thread. Please delete
[Verizon Samsung Galaxy S 4] mdneilson:
Define cheap. Would one with a broken lcd be of use? (pm me)
[Verizon Samsung Galaxy S 4] daredevl99:
as long as it boots it should be of use.
[Verizon Samsung Galaxy S 4] mdneilson:
Yep, boots fine. It is fully stock, not sure what version though.
[Verizon Samsung Galaxy S 4] daredevl99:
wont be hard to figure out. definitely pm ryan.
[Verizon Samsung Galaxy S 4] mdneilson:
We're already messaging. I'm a T-Mobile customer, but have a pair of Verizon phones (one good, one broken). Mostly for backup, but I strapped one for trying roms and now I'm prepping it for my wife. I just figured I could help you guys out with the spare.
[Verizon Samsung Galaxy S 4] scristopher7:
Since testbit was found could jtag be a possibility as mentioned in this post? jtag/change testbit/roll back to MDK?

Sorry if this is derailing or not related - I'm just curious as it was previously posted.

Edit:

NM I see further back that theres some additional missing info preventing changing it. Sorry for the interruption, I'd like to help normally I would be useful in this type of situation - however I barely have time to post this edit.
[Verizon Samsung Galaxy S 4] RuggedHunter:
It got tucked away in this post by [MENTION=5848265]npjohnson[/MENTION] , they're trying to work out how to change it, now that it's been located.

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

Tasker-ized
[Verizon Samsung Galaxy S 4] npjohnson:
Correct. (:

Well, JTAG can change the value of TestBit in memory, but can't physically blow the necessary value to the fuse (it is an increment fuse). But, we can already change the shadow of the fuse (TestBit) that is stored in memory, this is the one that is checked by everything else after TZ reads the TestBit's value into memory very early in the boot sequence. So, yes, sort of, JTAG can set the Fuse value in memory, and if you could find a way to JTAG the TestBit value into memory early enough in the boot sequence (Pre-SBL3), then you could /theoretically/ boot an MDK Aboot, but I doubt that could be done in the short (nano-seconds) of time you would have.

Our issue is that the shadow in RAM is reset on every device reboot (excluding SoftBoot :p), so the only option is to set TestBit in memory, and then find a way to re-execute aboot without rebooting the device (no way to do so as of yet, but looking into it).

Kexec is, as always, a viable option, but progress is slow, as it requires a large amount of trial & error/debugging, and the hard part is that, at times, we can't get a log, because the system hangs! Haha.

There are many other paths to be followed, but we haven't scraped the surface on many of them yet :p
[Verizon Samsung Galaxy S 4] Chevelle1768:
I have one with MK2 bootloader, no issues. Upgraded to a LG G3, so no need for it anymore. LMK.
[Verizon Samsung Galaxy S 4] tshelby73:
Could we get weekly updates on progress please. Might stop posts like mine sorry.

Sent from S4 using the better than it was Tapatalk
[Verizon Samsung Galaxy S 4] daredevl99:
probably not. progress is very slow.
[Verizon Samsung Galaxy S 4] crhylove:
Just found out from work I have this pos phone for another year. Kill me now! My wife's note 2 is way better because of cm12.
[Verizon Samsung Galaxy S 4] jaw20:
Can we try to stay on topic? Also, someone said something about updates, and...
[Verizon Samsung Galaxy S 4] skepticmisfit:
not sure if this is even helpful or has been discussed, but both versions of the Sprint s4 (there's the l720 and then a triband version of that) have an unlocked bootloader. would a different carrier s4 be useful or are their boot files radically different?
[Verizon Samsung Galaxy S 4] ryanbg:
The signatures and keys for authentication are different, but still something I'm looking into at the moment.
[Verizon Samsung Galaxy S 4] dmt010:
I have I believe a non triband sprint s4 as well if u need anything (Knox tripped this one though) :(
[Verizon Samsung Galaxy S 4] npjohnson:
Was this meant for testing, or for purchase?
[Verizon Samsung Galaxy S 4] dmt010:
Not for purchase but if you need anything from it sure.
[Verizon Samsung Galaxy S 4] saantiago:
Wrong thread.
[Verizon Samsung Galaxy S 4] rp1226:
New bootloader causing more issues?
[Verizon Samsung Galaxy S 4] jaw20:
Work is continued to be focused on nk1/nc5 unless anything big comes up because of oc1
[Verizon Samsung Galaxy S 4] G.moe:
Perhaps you should look into NK4 as well.

Also, now that MultiSystem is coming around the corner, I can't stress enough how useful kexec can be for this device. Considering that MultiSystem is so close, I think significant efforts should be directed toward kexec, and I would highly suggest that the telegram group gets in contact with [MENTION=5868929]hsbadr[/MENTION] ! I'm currently testing MultiSystem on NK4/OC1, and I will be evaluating the next testing version with NC5, NK1, and NK4/OC1. Let me know if you would like any info from me/my device about this. I'm available on telegram as well (different username, PM me if necessary).
[Verizon Samsung Galaxy S 4] Legitsu:
people have been hard at work with kexec and they are making "some" progress

can mutli-system install to the "stock" slot or does it require a microSD-card

I really don't like the idea of loading the OS on a microsd card

a microsd is always gonna be slower then internal storage I don't care what he claims hes dead wrong ...

the note3 may have substandard internal storage but most devices don't suffer from that

even the s4 has a healthy 170+MB/s read 40MB+/MBs write
[Verizon Samsung Galaxy S 4] G.moe:
MultiSystem can install to the stock slot, but I believe virtual systems can only run from the SD card. Regardless of performance, this opens up several possibilities, and performance can be looked into later.

Also, I should note that [MENTION=5868929]hsbadr[/MENTION] is also working on kexec for a VZW device, and that MultiSystem does work with kexec (if it works on the device in the first place): http://xdaforums.com/galaxy-note-3/devs-only/kernel-kernel-execution-loading-custom-t2812650

Even if you guys have opposing view points, I really think it would be in everyone's best interest to be sharing information with each other, especially at a point that is so critical to future development on this device. Honestly, without kexec working for the VZW S4, development for the device will soon start to rapidly decline unless there's a breakthrough vulnerability in stock LP.
[Verizon Samsung Galaxy S 4] Legitsu:
I know I know I was just pointing it out because he claims otherwise I made a post in the multisystem thread explaing why

also that thread is very old and seems abandoned nothing we don't already know(we already have kexec for the note3 btw)
[Verizon Samsung Galaxy S 4] scryan:
Was actually going to PM you.

I remember you asking about posting some documents here earlier, and was wondering if that just never happened or if you were trying to keep it to PM.

If it is going up publicly, is there a decent place we can consolidate them for everyone to look through? Someplace that would allow adding info either by anyone or at least by a few different people (so who ever is doing work can add what they may find?)

A central place would be nice to refer to, as a list of links in a post is likely to get buried quickly.

Not sure how much would be over my head, but I'd like to take a look as well.
[Verizon Samsung Galaxy S 4] Surge1223:
I dont know what it is but im liking the vibe around here recently. Ive been getting quite a few pms about this and some other stuff. Ill look into how we can get something like this going, I have a folder in my pc called "Samsung/Qualcomm pdfs" im not at home to upload this to my dropbox or elsewhere (visiting fam for holidays) but Friday I get back and ill ask some individuals I know about the best way about doing this.

(Watch I get home and all of a sudden that folder along with some others go miraculously missing, lol)
[Verizon Samsung Galaxy S 4] coolsilver:
Just an idea. I know sometimes methods are found through jtag or another method to get into a programmable flash mode. Thinking back to PSP hacking, anyway the battery/interface with battery has say a backdoor? Considering it has NFC data also going through it.... Wonder if there is any documents that have been leaked in that regard. I know original PSP's had battery firmware hack that could help downgrade the device.
[Verizon Samsung Galaxy S 4] Surge1223:
Actually had a similar idea. I posted a pic a couple pages back to see if anyone could identify anything useful in that regard. The documentation we have says theres a t-flash, sdcard mode, and ramdump available but so far I havent been able to activate any of the 3. Though I should mention im not an expert on the hardware side of this.
[Verizon Samsung Galaxy S 4] k1mu:
I've been looking into kernel module loading and how the Knox framework blocks custom kernel modules.

Several have said that only signed kernel modules can be loaded, but that's actually not the case.

The key is that Trust Zone again. Whenever you try to load a module into the kernel, the trustzone is called and asked to verify the hash of the module contents. If the hash value is known, then the module is allowed to load. This isn't a digital signature, just a hash. For practical purposes, the difference isn't important as we really can't hack a file to make it match the original hash any easier than we can hack a digital signature.

The hash is validated using a Trust Zone application called tima_lkm. That's executed out of the trust zone, and can't be accessed by normal kernel processes.

However, I have a couple of pretty good ideas for ways to allow kernel modules to load. I seem to recall that's needed to allow kexec to work and allow arbitrary kernels to be executed. Can someone point me to information on what needs to be loadable to make this work?

I'm willing to risk the "Knox Warranty Void" flag if this will end up with with removing some of the Safestrap limitations.
[Verizon Samsung Galaxy S 4] Surge1223:
I get what you're saying but sorry cant understand your question are you asking whats needed for kexec to work? Or?
[Verizon Samsung Galaxy S 4] k1mu:
Simply stated, what module do I need to install into the MJ7 kernel to enable kexec. If that's all, then I'll see if I can get it to load.
[Verizon Samsung Galaxy S 4] Surge1223:
Maybe Im rusty on what exactly is needed to get kexec working but from my understanding I thought it would need to run at boot by hijacking the kernel during the boot process, so we'd need something to either bypass or mimic the signature. Also this is complicated by the fact that aboot has to verify the boot.img. Maybe my understanding is wrong though...
[Verizon Samsung Galaxy S 4] hemirunner426:
I believe kexec loads a module into the currently running kernel allowing another kernel image to write itself to memory.

It skips the bootloader stage completely, where all our issues are.

You can run kexec ant any point in the init process of the default kernel.

The only problem is the kexec module will need the correct hash or the Samsung kernel wont load it.
[Verizon Samsung Galaxy S 4] scryan:
Not sure how it works on android...

But just in general from what I have read about, Kexec is.... Well lets just go to the source of all true knowledge...Wikipedia.

:cowboy:

So not sure how it works with android, or how it is even called/executed/invoked/whatevered in general... But the general idea of kexec is allowing the kernel to be loaded into memory on top of the booted one.

I would guess that its not a native part of the stock kernel and he needs to know what would need to be added to the kernel to support Kexec?

Is my understanding correct that if we can get Kexec, we can then effectively update everything needed to keep the phone up to date with out taking anything directly from Verizon? That is all I want :)
[Verizon Samsung Galaxy S 4] hemirunner426:
You can currently regulate your update process from Verizon. Safestrap will give you the ability to run custom roms based on the TW(default) kernel which are debloated and won't take OTA updates from Verizon. You can even disable/freeze the firmware upgrader apks on MJ7/MK to disable OTAs. The update process will be in your hands then. That means, you will have to manually install an updated default kernel/baseband/bootloader, etc.

kexec is a different animal. kexec can be built as a module for any kernel. It all depends on what you select before you start the kernel build. What we would do here with the default Samsung kernel is attempt to load a pre-built kexec module into it. We can then run a kexec command to load a custom unsigned kernel image. This totally bypasses the bootloader of the phone because the bootloader process has already happened while booting the default kernel. The only obstacle is the fact that the default kernel will try to verify the kexec module is trusted before loading it.

If the verification process can be worked around, the next step would to build a custom kexec kernel for the S4. I know there are quite a few already, but kexec is a different animal once again. The hardware on the phone is already initialized when booted to the default kernel. There could be quite a few obstacles to work around as some devices may not react well to be reinitialized on the fly outside of the normal boot process. Not saying that this can't be done, but its going to take time.

EDIT:

In fact, this is a major security issue with kexec. This ability does allow an unsigned image to run on a system that would otherwise verify images before loading them. The workaround was to implement module trust verification... which is what we are facing now.
[Verizon Samsung Galaxy S 4] ryanbg:
TrustZone/TIMA are preventing us from inserting any kernel modules. Unless we can get inside TrustZone with a new exploit, kexec will most likely be not happening.
[Verizon Samsung Galaxy S 4] hemirunner426:
Exactly. this is the problem we are facing with the current safestrap implementation and kexec.
[Verizon Samsung Galaxy S 4] scryan:
You have to match the base kernel with safestrap, you have to use an update from verizon to officially update your phone to update the kernel, you cannot just flash new updates yourself. I will not be able to use anything past 4.2 roms with out taking the MJ7 update given the currently available tools. I'd love for you to prove me wrong though :P

Appreciate your input, but you largely just quoted my post and then repeated the fact that we would have to build a kexec module and add that to the kernel for the phone to have kexec support.

That was what we were just talking about. K1mu asked what in particular needed to be added to the kernel as he had some ideas on how to accomplish it.

Do you have any ideas on what that pre-built module would be?
[Verizon Samsung Galaxy S 4] hemirunner426:
That's right. I reiterated you're post to further explain the process. I wanted to add further explanation to what was already known.

As far as kexec, a module built for the kernel version, perhaps from the tw kernel source will work fine. The problem is getting it through verification on load.

Edit: lots of people have questions on what all this means. My only intent was to lay those questions to rest. I see where what the direction is and where the problems lie. I just want to answer those questions so the devs can spend their time doing what they do best.
[Verizon Samsung Galaxy S 4] jeboo:
What you need to do is bypass the verification checks in the stock kernel. If you look at the source, I believe they lie in /kernel/module.c (there may be some newer ones related to SELinux). To bypass them we need to use an exploit that allows for kernel memory overwriting. I believe the get/put_user exploit recently discovered *can* do that. Finding the addresses to patch in memory should be pretty trivial.
[Verizon Samsung Galaxy S 4] Surge1223:
Ah never thought about using the same exploit to bypass verification. Have you been working towards this on the AT&T end?
[Verizon Samsung Galaxy S 4] jeboo:
I'm going to update my other S4 to MK2 today, then see how it goes.
[Verizon Samsung Galaxy S 4] k1mu:
That's what I'm looking at.

The kernel module loader (kernel/module.c) makes a Trust Zone call to verify the hash of any module that you try to load. The question that I'm hoping to answer is if there are any other checks done. The TIMA (Trust Zone-based Integrity Measurement Architecture) stuff checks the integrity of the kernel in real time, and shuts the device down if the kernel is found to be tampered with. The question that I'm hoping to answer is if we can slip a new module into the kernel without tripping the integrity check.
[Verizon Samsung Galaxy S 4] JLow0214:
Maybe we could just remove the lines that tell it to check and verify the kernel all together

Sent from my SCH-I545 using Xparent Skyblue Tapatalk 2
[Verizon Samsung Galaxy S 4] npjohnson:
Well, a lack of ability to downgrade and get root, yes. :p we need root to work on *almost* any of these methods.
[Verizon Samsung Galaxy S 4] 06sharpshot:
Are we safe to use the method posted by muniz_ri to update to OC1 since it keeps the boot loader on NK4 or would NK4 not be applicable to the work you guys are doing?
[Verizon Samsung Galaxy S 4] Legitsu:
thats fine because it still allows you to downgrade to NC5 just don't take a ota ... evercheck

[MENTION=639326]CalcProgrammer1[/MENTION] 's repo for all relevant kexec codez

https://github.com/CalcProgrammer1?tab=repositories
[Verizon Samsung Galaxy S 4] 06sharpshot:
That's what I thought, just wanted to be extra sure as I'd hate for another MDK scenario where I miss an opportunity for a more unlocked device :p. Thanks for the speedy response!
[Verizon Samsung Galaxy S 4] Legitsu:
so apparently mutlisystem already supports kexec now all we need is for somebody to build a working module used with the nc5 modload patch

last time I played with it it was encountering a hang I could't seem to debug I think some kind of hybrid approach using multisystem as a base todo a sudo hard-boot by flushing as much of the core system is possible before (re)continuing init I need to ask [MENTION=631273]Chainfire[/MENTION] exactly what flash-fire does to prep for install as I have a feeling that may be the ticket the hang is most likely caused by some failing sanity check ...
[Verizon Samsung Galaxy S 4] G.moe:
Sounds like a good idea! MS is much more than just MultiROM
[Verizon Samsung Galaxy S 4] Legitsu:
just thinking outloud here I have no idea what progress has been made and what has been tried since people seem to be discussing this behind closed doors