http://forum.xda-developers.com/showthread.php?t=2578566
I don't know if you guys know about this... This allows unsigned kernel modules to be loaded on the equivalent of MI1. If anyone wants to take the steps described by the OP and build for NC5, this would open the ability to work on Kexec and AOSP via Safestrap (with the actual AOSP Kernel!).
npjohnson said:
http://forum.xda-developers.com/showthread.php?t=2578566
I don't know if you guys know about this... This allows unsigned kernel modules to be loaded on the equivalent of MI1. If anyone wants to take the steps described by the OP and build for NC5, then work on Kexec and AOSP via Safestrap (with the actual AOSP Kernel!).
Click to expand...
Click to collapse
So are you basically making this thread not to offer anything new, just to tell people to do more work for you?
Most of the S4 devs already saw that 8 months ago and did what they could with it...
scryan said:
So are you basically making this thread not to offer anything new, just to tell people to do more work for you?
Most of the S4 devs already saw that and did what they could with it...
Click to expand...
Click to collapse
Wow. Way to overreact dude. NO I am not telling you or anyone to do work for me. The ATT and Verizon forums find different things, and therefore, sometimes there is a delay in the info being transferred back and forth. Did anywhere in my post did I say/insinuate that I was forcing people to do work for me? NO, I did not, I just shared some info from the other forum, and you replied by complaining about me cross posting. Thanks for that.
I know that they have probably seen the initial post, but there are some helpful posts later in the thread that seemed interesting about building for later firmwares.
I then even proceeded to try and have been debugging it for the last hour or so...
Update
I tried to follow the steps in the OP of the mentioned thread, but loading an unsigned test module on NC5 fails, although BypassKSLM is loading... More work required.
I think that the fix should be somewhere in the:
if (krsp->ret == 0) {
pr_warn("TIMA: lkmauth--verification succeeded.\n");
ret = 0; /* ret should already be 0 before the assignment. */
As I failed to get ret=0 before assignment.
npjohnson said:
Wow. Way to overreact dude. NO I am not telling you or anyone to do work for me. The ATT and Verizon forums find different things, and therefore, sometimes there is a delay in the info being transferred back and forth. Did anywhere in my post did I say/insinuate that I was forcing people to do work for me? NO, I did not, I just shared some info from the other forum, and you replied by complaining about me cross posting. Thanks for that.
I know that they have probably seen the initial post, but there are some helpful posts later in the thread that seemed interesting about building for later firmwares.
I then even proceeded to try and have been debugging it for the last hour or so...
Click to expand...
Click to collapse
Cross posting from 8 months ago, after the maker of safestrap (who has accepted a job and recently abandoned further development) has tried and moved on from getting a working kexec...
Its great your working on it. But before bringing it to the main forum and getting people worked up it might be good to make even some progress, otherwise we are just looping back to where we were 8 months ago.
Beyond that.... Hasn't this been patched?
jeboo said:
I got this idea after reading about CVE-2013-6282 and seeing the source for it.
Click to expand...
Click to collapse
Its based on get get_user put_user exploit yes?
Surge hints at the same fact later, when he discusses whether or not it could be run on a S3
Surge1223 said:
This depends on whether or not you are able to root using saferoot or not (since its dependent on the get/put_user exploit) and whether your stock kernel was compiled with support for loading modules. You can check your kernel source config file to see.
Click to expand...
Click to collapse
Mentioning being able to run saferoot as an easy method to check and see if the exploit is still avalible, which on NC5 it wasn't right?
scryan said:
Cross posting from 8 months ago, after the maker of safestrap (who has accepted a job and recently abandoned further development) has tried and moved on from getting a working kexec...
Its great your working on it. But before bringing it to the main forum and getting people worked up it might be good to make even some progress, otherwise we are just looping back to where we were 8 months ago.
Beyond that.... Hasn't this been patched?
Its based on get get_user put_user exploit yes?
Surge hints at the same fact later, when he discusses whether or not it could be run on a S3
Mentioning being able to run saferoot as an easy method to check and see if the exploit is still avalible, which on NC5 it wasn't right?
Click to expand...
Click to collapse
My apologies for the misunderstanding on the NC5 part, I am using Surges Downgrade to 4.3, which (4.3) still has the get_user put_user exploit. Still NC5 BL, but 4.3 on /system. Plus if we got kexec working on downgraded 4.3, it wouldn't matter that it was 4.3 because we could just load a 4.4 kernel and rom.
My goal was to try to revive (restart from scratch) the project and see where it got to. I currently got a test module loading (what others have already gotten to), now I want to take my own crack at kexec. It probably won't bear fruit, it could though, and thats the idea... but regardless it is a good learning process.
Plus kexec isn't out only option... It works well with safestrap, but there are many other pieces that when put together can function alike kexec, one being ksplice.
npjohnson said:
My apologies for the misunderstanding on the NC5 part, I am using Surges Downgrade to 4.3, which (4.3) still has the get_user put_user exploit. Still NC5 BL, but 4.3 on /system. Plus if we got kexec working on downgraded 4.3, it wouldn't matter that it was 4.3 because we could just load a 4.4 kernel and rom.
My goal was to try to revive (restart from scratch) the project and see where it got to. I currently got a test module loading (what others have already gotten to), now I want to take my own crack at kexec. It probably won't bear fruit, it could though, and thats the idea... but regardless it is a good learning process.
Click to expand...
Click to collapse
I think part of the issue was something along the lines that the kernel is checked and if it does not pass the phone is shutdown/crippled/set into some mode.
Kexec may be slightly more relevant now that there is some access to the trusted zone, but I really have no idea what I am talking about on that one.
But before you worry too much about "Kexec" make sure you are aware of and understand checks on the kernels validity, if they are performed by the tz, and what/how much access to the tz there is now with Dan's latest... at least that my 2 cents.
It seemed the whole kexec thing kind of dead ended because the issue is a bit deeper then just getting a working kexec module and loading a new kernel.
scryan said:
I think part of the issue was something along the lines that the kernel is checked and if it does not pass the phone is shutdown/crippled/set into some mode.
Kexec may be slightly more relevant now that there is some access to the trusted zone, but I really have no idea what I am talking about on that one.
But before you worry too much about "Kexec" make sure you are aware of and understand checks on the kernels validity, if they are performed by the tz, and what/how much access to the tz there is now with Dan's latest... at least that my 2 cents.
It seemed the whole kexec thing kind of dead ended because the issue is a bit deeper then just getting a working kexec module and loading a new kernel.
Click to expand...
Click to collapse
I know. The main reason I posted this was to work in tandem with Dan's new TZ Exploit. It allows running unsigned code at TZ level, and the possibility of turning off TIMA almost altogether, with TIMA disabled, and low level unsigned code, writing a kexec module would the be the next step.
scryan said:
Cross posting from 8 months ago, after the maker of safestrap (who has accepted a job and recently abandoned further development) has tried and moved on from getting a working kexec...
Its great your working on it. But before bringing it to the main forum and getting people worked up it might be good to make even some progress, otherwise we are just looping back to where we were 8 months ago.
Beyond that.... Hasn't this been patched?
Its based on get get_user put_user exploit yes?
Surge hints at the same fact later, when he discusses whether or not it could be run on a S3
Mentioning being able to run saferoot as an easy method to check and see if the exploit is still avalible, which on NC5 it wasn't right?
Click to expand...
Click to collapse
Well back when I typed that the get_user/put_user exploit was the only exploit we had that could overwrite kernel memory. Now that we have towelroot its also theoretically possible to re-implement bypasslkm on NC5 depending on how they mightve patched it.
I tried doing this but since not many cared or even tried to make use of bypasslkm the first time around I didnt post my findings, nonetheless this info might be useful to future individuals trying to do the same. I really hope someone makes use of what im about to type.
So the first time around jeboo had an error log and was able to find the address to patch since we had kernel source and he probably decompressed the zimage and found the relevent lkmauth address.
There is another way to enable insecure module loading (using the same approach and address as bypasslkm) by using objdump on the vmlinux produced from compiling the kernel from source, then finding the following
1a000002 bne <copy_and_check.isra.22+xxx>
then by doing some math, and guess checking you can use devmem2 to write 0x0 to whatever address returned the ARM opcode 1a000002, for mk2 this address is 0x802c9d58 (may seem familiar if you have looked at bypasslkm.c)
I confirmed by manually writing writing 0x0 at 0x802c9d58 = modules verified and returning the value to 0x1a000002 = modules modified.
I tried to find <copy_and_check.isra.22+xxx> in NC5 kernel source however it is non-existant. I have not yet tried to decompress the zimage and search for the relevant lkmauth messages to see if bypasslkm is still able to be implemented or to see how it may have/may not have been patched. This is probably the first step I should have done, so anyone starting now should start with that step, decompressing the zimage and searching for the lkmauth messages and see how the check is implemented.
Surge1223 said:
Well back when I typed that the get_user/put_user exploit was the only exploit we had that could overwrite kernel memory. Now that we have towelroot its also theoretically possible to re-implement bypasslkm on NC5 depending on how they mightve patched it.
I tried doing this but since not many cared or even tried to make use of bypasslkm the first time around I didnt post my findings, nonetheless this info might be useful to future individuals trying to do the same. I really hope someone makes use of what im about to type.
So the first time around jeboo had an error log and was able to find the address to patch since we had kernel source and he probably decompressed the zimage and found the relevent lkmauth address.
There is another way to enable insecure module loading (using the same approach and address as bypasslkm) by using objdump on the vmlinux produced from compiling the kernel from source, then finding the following
1a000002 bne <copy_and_check.isra.22+xxx>
then by doing some math, and guess checking you can use devmem2 to write 0x0 to whatever address returned the ARM opcode 1a000002, for mk2 this address is 0x802c9d58 (may seem familiar if you have looked at bypasslkm.c)
I confirmed by manually writing writing 0x0 at 0x802c9d58 = modules verified and returning the value to 0x1a000002 = modules modified.
I tried to find <copy_and_check.isra.22+xxx> in NC5 kernel source however it is non-existant. I have not yet tried to decompress the zimage and search for the relevant lkmauth messages to see if bypasslkm is still able to be implemented or to see how it may have/may not have been patched. This is probably the first step I should have done, so anyone starting now should start with that step, decompressing the zimage and searching for the lkmauth messages and see how the check is implemented.
Click to expand...
Click to collapse
I lack the knowledge to even attempt this but I do hope another tries at least. I miss aosp. I'm coming from a HTC with s-off and I'm not used to the restrictions placed on such a locked down phone. I do hope that some work around for running an unsecured kernel will be found at least. Thanks for the information and hopefully it will be put to good use
Sent from my SCH-I545 using Xparent Skyblue Tapatalk 2
Surge1223 said:
Well back when I typed that the get_user/put_user exploit was the only exploit we had that could overwrite kernel memory. Now that we have towelroot its also theoretically possible to re-implement bypasslkm on NC5 depending on how they mightve patched it.
I tried doing this but since not many cared or even tried to make use of bypasslkm the first time around I didnt post my findings, nonetheless this info might be useful to future individuals trying to do the same. I really hope someone makes use of what im about to type.
So the first time around jeboo had an error log and was able to find the address to patch since we had kernel source and he probably decompressed the zimage and found the relevent lkmauth address.
There is another way to enable insecure module loading (using the same approach and address as bypasslkm) by using objdump on the vmlinux produced from compiling the kernel from source, then finding the following
1a000002 bne <copy_and_check.isra.22+xxx>
then by doing some math, and guess checking you can use devmem2 to write 0x0 to whatever address returned the ARM opcode 1a000002, for mk2 this address is 0x802c9d58 (may seem familiar if you have looked at bypasslkm.c)
I confirmed by manually writing writing 0x0 at 0x802c9d58 = modules verified and returning the value to 0x1a000002 = modules modified.
I tried to find <copy_and_check.isra.22+xxx> in NC5 kernel source however it is non-existant. I have not yet tried to decompress the zimage and search for the relevant lkmauth messages to see if bypasslkm is still able to be implemented or to see how it may have/may not have been patched. This is probably the first step I should have done, so anyone starting now should start with that step, decompressing the zimage and searching for the lkmauth messages and see how the check is implemented.
Click to expand...
Click to collapse
I though about TowelRoots ability to do the same as get_put, but understanding exactly how it (TR) works is tough due to llvm-obfuscator. After reading a theoretical writeup of TR, I found this:
Source: http://tinyhack.com/2014/07/07/exploiting-the-futex-bug-and-uncovering-towelroot/
I thought that due ti the nature of the Futex bug that our best bet was a 4.3 downgrade... though what you are saying makes sense... So, your saying that the memory address to be written to 0x0 has merely changed location? (Im probably misunderstanding you...) I thought that they they had moved that flag out of memory to prevent writing...
How are you decompressing zimage? I tried using instructions like these https://github.com/xiaolu/galaxys2_kernel_repack (obviously changed for our model), but I am having some issues..
npjohnson said:
I though about TowelRoots ability to do the same as get_put, but understanding exactly how it (TR) works is tough due to llvm-obfuscator. After reading a theoretical writeup of TR, I found this:
Source: http://tinyhack.com/2014/07/07/exploiting-the-futex-bug-and-uncovering-towelroot/
I thought that due ti the nature of the Futex bug that our best bet was a 4.3 downgrade... though what you are saying makes sense... So, your saying that the memory address to be written to 0x0 has merely changed location? (Im probably misunderstanding you...) I thought that they they had moved that flag out of memory to prevent writing...
How are you decompressing zimage? I tried using instructions like these https://github.com/xiaolu/galaxys2_kernel_repack (obviously changed for our model), but I am having some issues..
Click to expand...
Click to collapse
Do you have the kernel compiled?
Surge1223 said:
Do you have the kernel compiled?
Click to expand...
Click to collapse
I am doing what you were talking about first to learn... Im doing it from an MK2 JB device. So I have the kernel compiled for that one. But I haven't begun on my NC5 KK device yet. We don't have kernel source for NC5 yet, do we?
npjohnson said:
I am doing what you were talking about first to learn... Im doing it from an MK2 JB device. So I have the kernel compiled for that one. But I haven't begun on my NC5 KK device yet. We don't have kernel source for NC5 yet, do we?
Click to expand...
Click to collapse
http://opensource.samsung.com/reception/receptionSub.do?method=search&searchValue=SCH-I545
I've been reading articles on kexec being used for Linux fast reboots, which sounds a lot like our Fastboot. BUT, I have a Fast Reboot option on my phone. Can someone ELI5 the difference bw Linux Fast Reboot, Android Fastboot, and Android Fast Reboot?
FYI, I *know* the S4 doesn't support Fastboot that's why I'm asking about fast reboot and if it is different.
sokrboot said:
I've been reading articles on kexec being used for Linux fast reboots, which sounds a lot like our Fastboot. BUT, I have a Fast Reboot option on my phone. Can someone ELI5 the difference bw Linux Fast Reboot, Android Fastboot, and Android Fast Reboot?
FYI, I *know* the S4 doesn't support Fastboot that's why I'm asking about fast reboot and if it is different.
Click to expand...
Click to collapse
I'll let someone more experienced explain any relevance, if there is any, but as far as the "fast reboot" or "hot reboot" option in your power menu... its a method of rebooting that only restarts the GUI.
http://www.xda-developers.com/windows-mobile/reboot-the-shell-only-with-hot-reboot-for-android/
sokrboot said:
I've been reading articles on kexec being used for Linux fast reboots, which sounds a lot like our Fastboot. BUT, I have a Fast Reboot option on my phone. Can someone ELI5 the difference bw Linux Fast Reboot, Android Fastboot, and Android Fast Reboot?
FYI, I *know* the S4 doesn't support Fastboot that's why I'm asking about fast reboot and if it is different.
Click to expand...
Click to collapse
Fastboot and fast reboot are in no way related, or even similar.
RuggedHunter said:
I'll let someone more experienced explain any relevance, if there is any, but as far as the "fast reboot" or "hot reboot" option in your power menu... its a method of rebooting that only restarts the GUI.
http://www.xda-developers.com/windows-mobile/reboot-the-shell-only-with-hot-reboot-for-android/
Click to expand...
Click to collapse
@RuggedHunter thanks for replying with helpful information, I appreciate it.
Surge1223 said:
http://opensource.samsung.com/reception/receptionSub.do?method=search&searchValue=SCH-I545
Click to expand...
Click to collapse
Kernel Compiled
Related
Sure something will come up soon but it's 3 am and I wanted to throw a few spitballs at this topic.
Word I've been reading on XDA this early am is that Verizon and ATT have an update that broke root.
I'm not going to touch the bootloader issues since that's above my skill set at the moment.
I think we need to break it down into two parts:
1) Fixing the update to work without breaking current root methods.
Looks like Aou's "neutered" ATT update may pull it off for them. Not sure it needed to remove all that he did but that's a separate topic.
If so then the process just needs to be duplicated for Verizon.
My only concern from trying this with Sprint's N2 is that when we tried this (tweaking the zip) we broke the CSC data.
Minor inconveniences and easily fixed by flashing the last cache.img from a Samsung tarball (minus the data wipe).
Odin may be doable so long as the Sprint MF9 modem tar creation process can be duplicated to others.
The only thing I haven't resolved is the CSC update. You'd have to use an older version as mentioned above.
2) Finding a way to get folks rooted that have already applied the update.
My initial thought is this: Since ATT is already ahead, have someone who has kept root and SuperSU to dump system.img. Repack into Odin tar and see if bootloader will let it flash.... and if it does, will it restore root? Adjust as necessary and duplicate the process on Verizon.
If this is possible it should get those folks who wanted root and already applied the update at least rooted. Won't do much else for them though until the bootloader issues are solved.. but it would be movement in the right direction.
Side note: I can't speak for other leaks but with Sprint we saw leaks (unreleased/test builds) between OTAs may have different behaviors than what was released. Might be worth poking previous leak sources and see if they have any such ones between the last Loki-able build and the new OTAs - and if they might be able to share those with devs for further analysis. I did the same but got nothing so far... not surprising though since it's not Sprint.
OK, minor update.
Both now seem to have gone OTA and Voodoo seems to keep it even after for both. So that's good news.
VZW definitely has a new pattern for Loki and it's got to be found.
I'm trying to resolve the addressing Bliss put in the logic versus a hex editor.
I might see if I can get Eclipse running and then run it in debug and see if that will get us closer.
If we can get that far it should be possible to re-test Loki under the new aboot.
(I've removed after a brief discussion with Bliss. I'll still study aboot more but this is now out after that discussion.)
I'm also checking on a hail mary of rolling back. No promises though.
garwynn said:
OK, minor update.
Both now seem to have gone OTA and Voodoo seems to keep it even after for both. So that's good news.
VZW definitely has a new pattern for Loki and it's got to be found.
I'm trying to resolve the addressing Bliss put in the logic versus a hex editor.
I might see if I can get Eclipse running and then run it in debug and see if that will get us closer.
If we can get that far it should be possible to re-test Loki under the new aboot.
(I've removed after a brief discussion with Bliss. I'll still study aboot more but this is now out after that discussion.)
I'm also checking on a hail mary of rolling back. No promises though.
Click to expand...
Click to collapse
Definitely interested in the hail mary of rolling back. I'll be experimenting with the bootloader updates a bit more once I get my device JTAGed (hopefully next week). I'll let you know how it goes.
Meanwhile, I've uploaded the system and kernel that I had working - over in the neutered thread.
garwynn said:
OK, minor update.
Both now seem to have gone OTA and Voodoo seems to keep it even after for both. So that's good news.
VZW definitely has a new pattern for Loki and it's got to be found.
I'm trying to resolve the addressing Bliss put in the logic versus a hex editor.
I might see if I can get Eclipse running and then run it in debug and see if that will get us closer.
If we can get that far it should be possible to re-test Loki under the new aboot.
(I've removed after a brief discussion with Bliss. I'll still study aboot more but this is now out after that discussion.)
I'm also checking on a hail mary of rolling back. No promises though.
Click to expand...
Click to collapse
If you are interested, a poster figured out how to edit the MF3 update to work through ODIN. Maybe, if the same edits are applied to the existing AMDL firmware, ODIN can then be used to rollback phones that already have MF3 on them back to AMDL? Here is a link...
http://forum.xda-developers.com/showthread.php?t=2360859
scott14719 said:
If you are interested, a poster figured out how to edit the MF3 update to work through ODIN. Maybe, if the same edits are applied to the existing AMDL firmware, ODIN can then be used to rollback phones that already have MF3 on them back to AMDL? Here is a link...
http://forum.xda-developers.com/showthread.php?t=2360859
Click to expand...
Click to collapse
In short, this will not work. If it did work, it would appear that the result would be a hard brick. It seems that once the device is fused to MF3+, the device will not only reject the older firmware and refuse to install it (regardless if the Odin software accepts it), the device will actively refuse to boot outdated bootloaders - regardless of how they are applied to the device (dd, recovery, or even JTAG).
However, it might be possible to inject root into a system image and fool both the PC and the phone into flashing it... If not root itself, then maybe whatever method these "OTA rootkeeper" apps use (a hidden root?)?
Once we have a Kies/Odin image of MF3, I'm wondering what would stop us from tampering with the included system image and attempting to write that to the device?
From the sounds of it, Samsung may not be releasing a Kies version of MF3 any time soon.
As for the continuing research of a root for the MF3 update, I've got an excellent testing ground, ready to flash as a rom:
http://forum.xda-developers.com/showthread.php?t=2378946
The purpose and hope for the new rom is to make it easier and safer for any Dev to begin researching a new root method for the MF3 firmware. Best of luck to us all.
So we just got the oc1 update recently, lollipop is upon us and we are able to update to lollipop and keep root. But. How will we flash roms? I found a solution over in the AT&T Galaxy S4 forums (if no one has seen it).
Basically you will have to have NOT taken the ota to oc1. You'll have to follow the guide on how to update to lollipop and retain root (I HIGHLY RECOMMEND UPDATING FROM NK1). After that, update your super su binaries if need be, then after that you'll check "Enable super su at boot" in the security section of the super su app. Then you'll install the safestrap 3.72 apk and install the recovery. After that is all said and done, download the nk1 stock kernel.tar.md5 and reboot into download mode and flash that in the ap slot. Now you can reboot into the safestrap recovery and install any rom that (may) be available soon and then reboot into download mode again and flash the oc1 stock boot.tar.md5.
Ill be putting up links asap
Does WiFi work with this method?
I know it doesn't work when using the other keep root methods.
Would this method allow Safestrap to dual-boot between a rooted OC1 Lollipop in the stock slot, and a custom Kitkat Rom in slot 1? (with working wi-fi on both)?
I get the error:
MD5 error
Binary is invalid
-Lawless said:
I get the error:
MD5 error
Binary is invalid
Click to expand...
Click to collapse
PMac10000 said:
Would this method allow Safestrap to dual-boot between a rooted OC1 Lollipop in the stock slot, and a custom Kitkat Rom in slot 1? (with working wi-fi on both)?
Click to expand...
Click to collapse
No, unfortunately, as Safestrap doesn't allow ROMs to use separate kernels, even if they are signed...
PMac10000 said:
Would this method allow Safestrap to dual-boot between a rooted OC1 Lollipop in the stock slot, and a custom Kitkat Rom in slot 1? (with working wi-fi on both)?
Click to expand...
Click to collapse
npjohnson said:
No, unfortunately, as Safestrap doesn't allow ROMs to use separate kernels, even if they are signed...
Click to expand...
Click to collapse
If kexec is figured out for this device, MultiSystem would allow you to do that just fine! Testing out MultiSystem now.
G.moe said:
If kexec is figured out for this device, MultiSystem would allow you to do that just fine! Testing out MultiSystem now.
Click to expand...
Click to collapse
I, Surge and a couple others are working on Kexec, but I dont see it happening in the near future... we are way off.
As for multisystem, it runs great! But would take some extra work to get it running with a functional kexec build when/if we get kexec to work.
npjohnson said:
I, Surge and a couple others are working on Kexec, but I dont see it happening in the near future... we are way off.
As for multisystem, it runs great! But would take some extra work to get it running with a functional kexec build when/if we get kexec to work.
Click to expand...
Click to collapse
hsbadr told me if he gets kexec working on the Note 3 he will make sure it works with MultiSystem. You guys should consider working together with him; I'm sure much of the info is transferable between the S4/N3, and with MultiSystem around the corner there might be new angles to take for finding exploitable regions.
EDIT: Maybe I misinterpreted him; kexec may already work with MultiSystem, with the N3 at least.
G.moe said:
hsbadr told me if he gets kexec working on the Note 3 he will make sure it works with MultiSystem. You guys should consider working together with him; I'm sure much of the info is transferable between the S4/N3, and with MultiSystem around the corner there might be new angles to take for finding exploitable regions.
Click to expand...
Click to collapse
Well, it would be great if he did, and I wish him the best luck, but work has been pretty stagnant for a reason... at the point we are at, debugging is not simple, pulling logs is fairly hard, and figuring out what they mean/how to fix the issue is even harder.
He is welcome to join our telegram chat on the matter of kexec/bootloader work, I told him that a day or two ago.
I don't think multisystem will add anything extra to kexec progress... but if we can get kexec working, then Multisystem will be a platform to execute it from!
npjohnson said:
Well, it would be great if he did, and I wish him the best luck, but work has been pretty stagnant for a reason... at the point we are at, debugging is not simple, pulling logs is fairly hard, and figuring out what they mean/how to fix the issue is even harder.
He is welcome to join our telegram chat on the matter of kexec/bootloader work, I told him that a day or two ago.
I don't think multisystem will add anything extra to kexec progress... but if we can get kexec working, then Multisystem will be a platform to execute it from!
Click to expand...
Click to collapse
Perhaps you can use MultiSystem to make an img from Stock, add a binary to this image that can use an old kexec exploit, and attempt? It is my understanding that old kexec exploits don't work because the vulnerable parts were removed completely (neutered instead of corrected), and that new firmware prevents adding older, vulnerable pieces. So with a clean, signature-passing Stock slot, I don't see why MultiSystem couldn't load these vulnerable parts on a virtual system. Am I making sense at all? I'm not a kernel developer, and I don't know the history of kexec on android or this phone specifically, but I am a man of ideas!
npjohnson said:
Well, it would be great if he did, and I wish him the best luck, but work has been pretty stagnant for a reason... at the point we are at, debugging is not simple, pulling logs is fairly hard, and figuring out what they mean/how to fix the issue is even harder.
He is welcome to join our telegram chat on the matter of kexec/bootloader work, I told him that a day or two ago.
I don't think multisystem will add anything extra to kexec progress... but if we can get kexec working, then Multisystem will be a platform to execute it from!
Click to expand...
Click to collapse
MultiSystem has some hidden features including kexec, 2nd-init ramdisk hijack & Linux chroot. So, it's now ready to load kexec module & execute kexec if you were able to build a working kexec module (I'll just add kexec binaries to /MultiSystem/bin & add the module to /MultiSystem/lib/modules >>> Then, select kexec on boot options, which is removed in the current version b/c it's not working for any of the supported devices). I was working on kexec for Note 3 as well, with incomplete success. Based on the intial testing results, S4 will be supported in the next version of MultiSystem. I'd be glad to help.
BTW. I plan to add kexec support anyway for the unlocked devices (to execute kernels for AOSP-based ROMs) & I'll start with the VZW Note 4 I own. So, kexec is a possibility with MultiSystem anyway.
hsbadr said:
MultiSystem has some hidden features including kexec, 2nd-init ramdisk hijack & Linux chroot. So, it's now ready to load kexec module & execute kexec if you were able to build a working kexec module (I'll just add kexec binaries to /MultiSystem/bin & add the module to /MultiSystem/lib/modules >>> Then, select kexec on boot options, which is removed in the current version b/c it's not working for any of the supported devices). I was working on kexec for Note 3 as well, with incomplete success. Based on the intial testing results, S4 will be supported in the next version of MultiSystem. I'd be glad to help.
BTW. I plan to add kexec support anyway for the unlocked devices (to execute kernels for AOSP-based ROMs) & I'll start with the VZW Note 4 I own. So, kexec is a possibility with MultiSystem anyway.
Click to expand...
Click to collapse
Shoot me a PM with your telegram username, and I'll hook you up with the other guys working on kexec. Thanks for your work on Multisystem!
---------- Post added at 02:25 AM ---------- Previous post was at 02:22 AM ----------
G.moe said:
Perhaps you can use MultiSystem to make an img from Stock, add a binary to this image that can use an old kexec exploit, and attempt? It is my understanding that old kexec exploits don't work because the vulnerable parts were removed completely (neutered instead of corrected), and that new firmware prevents adding older, vulnerable pieces. So with a clean, signature-passing Stock slot, I don't see why MultiSystem couldn't load these vulnerable parts on a virtual system. Am I making sense at all? I'm not a kernel developer, and I don't know the history of kexec on android or this phone specifically, but I am a man of ideas!
Click to expand...
Click to collapse
Nope. Unfortunately, the kernel doesn't control that function. LOKI attacks a crytographic signatures flaw, it definitely is not kexec. And we can't use Multisystem to reload a vulnerable bootloader, as the QFUSE that the bootloader checks has been blown to a value that would cause I to fail to boot, and we can't unblow the QFUSE.
npjohnson said:
Nope. Unfortunately, the kernel doesn't control that function. LOKI attacks a crytographic signatures flaw, it definitely is not kexec. And we can't use Multisystem to reload a vulnerable bootloader, as the QFUSE that the bootloader checks has been blown to a value that would cause I to fail to boot, and we can't unblow the QFUSE.
Click to expand...
Click to collapse
Ahh okay. Forgive my ignorance, I'm not a programmer/engineer, but I did some research toward QFuse. It is my understanding that the bootloader does NOT individually check Qfuse's; rather, it checks the QFPROM which acts as a register for the Qfuse values. If this is true, is it possible for QFPROM to hold a value for a QFuse that isn't actually accurate? For example, is it possible for QFPROM to store FORCE_TRUSTED_BOOT as 0 even though the physical QFuse is tripped to 1? If it is possible for this situation to exist, how can QFPROM be modified or spoofed? If QFPROM can be spoofed, maybe the read location of FORCE_TRUSTED_BOOT can be changed to the location of another QFuse which is valued at 0?
Have you guys captured a full system using LiME? Or is physical location identical on all MSM8960 devices? Has anyone tried decompiling ./drivers/misc/qfp_fuse.c and creating a driver that would write to QFuse, even if they are OTP?
I've seen this thread, but there's a lot of information for me to read and understand to really be of any help. I'm just listing questions that come to mind after an initial skim.
Do you guys have the documents which were (at one point) posted here? Would those documents help with progression?
G.moe said:
Ahh okay. Forgive my ignorance, I'm not a programmer/engineer, but I did some research toward QFuse. It is my understanding that the bootloader does NOT individually check Qfuse's; rather, it checks the QFPROM which acts as a register for the Qfuse values. If this is true, is it possible for QFPROM to hold a value for a QFuse that isn't actually accurate? For example, is it possible for QFPROM to store FORCE_TRUSTED_BOOT as 0 even though the physical QFuse is tripped to 1? If it is possible for this situation to exist, how can QFPROM be modified or spoofed? If QFPROM can be spoofed, maybe the read location of FORCE_TRUSTED_BOOT can be changed to the location of another QFuse which is valued at 0?
Have you guys captured a full system using LiME? Or is physical location identical on all MSM8960 devices? Has anyone tried decompiling ./drivers/misc/qfp_fuse.c and creating a driver that would write to QFuse, even if they are OTP?
I've seen this thread, but there's a lot of information for me to read and understand to really be of any help. I'm just listing questions that come to mind after an initial skim.
Do you guys have the documents which were (at one point) posted here? Would those documents help with progression?
Click to expand...
Click to collapse
Mostly correct in your first paragraph... except you're missing one (sad) part of it, it is an INCREMENT QFUSE, meaning that the value can not be blown back down to a 0.
Also, QFPROM is protected by TrustZone, and much, much more, no real hope of touching the value in there, lest maybe a JTAG? But the TRUSTED_SECURE_BOOT flags isn't the only one that locks the bootloader. There are other FUSEs that are checked... your welcome to join the telegram chat on the matter if you want.
EDIT: Worth noting, we can write QFUSEs using Dan R's TZ vuln... that's not the problem. The problem is that the only fuse we care about is (in this case) blown in a way which cannot be reverted.
Deep talk, I love the brainstorming. I would sell a toe to see this bootloader get handed to Samsung in a casket
Sent from my SCH-I545 using Tapatalk
npjohnson said:
The problem is that the only fuse we care about is (in this case) blown in a way which cannot be reverted.
Click to expand...
Click to collapse
So in this case, the ideal solution is a patched bootloader that jumps the check of that (these) fuse(s), but our device signature-checks the bootloader so this is not possible, correct? Are you guys still trying to solve how they sign bootloaders for specific devices, like for dev edition devices?
G.moe said:
So in this case, the ideal solution is a patched bootloader that jumps the check of that (these) fuse(s), but our device signature-checks the bootloader so this is not possible, correct? Are you guys still trying to solve how they sign bootloaders for specific devices, like for dev edition devices?
Click to expand...
Click to collapse
Several fuses are blown that prevent us from going into a dev edition state...
But as for the algorithm that signs it, we could figure that out with some work, the issue is that we would need Samsung's RSA and Private Key to sign it with even if we figured that out.
I'm also getting md5 errors, saying that the binary is invalid.
Link broken.
NOTE: This thread is for the discussion of kernel development. If you don't recompile kernels, please don't post/reply.
After a couple years playing with nexus devices, I'm coming back over to Samsung (until I get bored) and I'm seeing that no one has managed to root a Note 5 device without a recompiled kernel. Why? Because using the stock kernel seems to result in just boot loops.
From what I've been able to observe, the custom kernels all have one thing in common in regards to allowing root to work: They are all changing sepolicy to run permissive instead of making modifications to allow 'su' to work in enforcing mode.
Why?
I have to be honest in saying that I haven't studied how @Chainfire had managed to get su working on the nexus devices while retaining sepolicy in enforcing mode, but it seems that this would be a far better solution than just neutering sepolicy all together.
Has anyone yet attempting to get a sepolicy enforcing kernel working with root? If so, are you willing to share what you tried and how things worked out?
My end-goal is probably to throw together a "as stock as possible" kernel that's root-able. If at all possible, I'm hoping that just some modifications to the ramdisk would be enough to get things working. However, I'd like to take advantage of any previous work done (if any) to get this working.
Thanks
Gary
Edit:
FOR CLARIFICATION. THIS THREAD IS NOT FOR GENERAL USER DISCUSSION. THIS IS FOR DEVELOPERS TO DISCUSS SELINUX, THE NOTE 5 KERNEL, AND METHODS BY WHICH ROOT CAN BE ACHIEVED WITHOUT CHANGING SELINUX TO PERMISSIVE.
Reminder,
Read the OP and stay on topic.
Thanks.
The_Merovingian
Forum Moderator
I have to ask my friend. Since I'm back to Samsung at the same time as you it seems. I see very little advantage of running root atm but I see none of running Selinux non permissive. Also these devices being exynos you will not find much support for it.
I may be wrong but Selinux non permissive has been a problem on samsung custom roms from day one guys just disabled it and be done with I've never seen anyone complain ;p
DAGr8 said:
I have to ask my friend. Since I'm back to Samsung at the same time as you it seems. I see very little advantage of running root atm but I see none of running Selinux non permissive. Also these devices being exynos you will not find much support for it.
I may be wrong but Selinux non permissive has been a problem on samsung custom roms from day one guys just disabled it and be done with I've never seen anyone complain ;p
Click to expand...
Click to collapse
I'm in the process of trying to modify the sepolicy in the stock boot image ramdisk to see if that allows root to work with the stock kernel (modified ramdisk.)
Wish me luck.
Dammit - all of my tools are out of date. Have to recompile mkbootimg, unpackbootimg, etc.
Okay, so I'm finding out all kinds of Fun Things that Samsung has done with this device...
First, at least some versions of this phone (mine is a 920i) have something in the stock firmware kernel(?) that restores factory recovery on first boot. This is my first sammy device in several years, but I seem to remember reading that other samsung devices have done this as well. (This is the reason that people are having to not allow ODIN to auto-reboot the phone.)
What's really pissing me off, however, is that if I allow TWRP to modify the system partition (based on the prompt on the initial boot) and don't actually make any system changes, the normal stock kernel won't boot... it gets stuck in a boot loop. (pre-bootanimation)
This is similar to the reports people are having of boot loops if they install root without changing the kernel. I'm starting to think it has nothing to do with actually being rooted, but that ANY system partition change is causing the bootloop. (Surprise!)
So, I decided to try something a bit different: I restored stock firmware (tar.md5 via odin) and after the reboot, I went back into ODIN mode. This time, I flashed TWRP and rebooted immediately back into ODIN and a flashed kernel with a modified sepolicy in the ramdisk. I then booted normally. My kernel loaded. I used adb to reboot to recovery. TWRP loaded. From TWRP, reboot normally.. it worked. Good start. adb reboot recovery, and this time I uncheck the option to "only mount system R/O." (It's in the "mount" section of TWRP.) Reboot system... and... BOOTLOOP.
(This has nothing to do with root. I'm not installing root... )
Time to start digging in the kernel ramdisk to try and figure this one out...
Tried the same as above, but with Philz compiled by @arter97. This time, I was stuck in a bootloop after the first time recovery ran. I'm guessing that this particular recovery will ALWAYS touch the system partition without first asking? Not sure... Philz did ask if I wanted to install root when I chose the option to reboot, but I declined.
Note to self:
http://forum.xda-developers.com/showpost.php?p=61542104&postcount=433
Just remove support_scfs,verify from the fstab and altering system will work.
Click to expand...
Click to collapse
I have NFC what "support_scfs" is, but I'll have to spend some time with google to figure it out. Perhaps a bit of SourceDiving. Won't have a chance to test this until tomorrow evening.
I love replying to myself. The truth is, I'm probably one of the few people who could stand talking to me. Of course, even I feel like killing me every now and then. It gets complicated.
Oh.. anyway.. I got it. A stock kernel with a modified ramdisk running selinux in enforcing mode and root-able. I want to spend a day running tests, but will post results of the results in about 20 hours. (assuming I get to sleep tonight...)
As well as gaining the enforcing selinux security (somewhat degraded by being rootable), this also ensures all hardware is working even if samsung "cheats" in posting source code.
(see attached screenshot... it's really the stock kernel and still enforcing SE for Android. )
Edit:
Then again, there's no harm in posting the boot image now. This is from a n920i device using the N920IDVU1AOH6 firmware. I'm attaching a file that can be unzipped and flashed with ODIN (AP slot.) Someone fluent should be able to pull the boot image out of the tarball and flash it directly with TWRP or even via 'dd' (assuming you're already rooted.)
(If you try to flash the .zip file directly, you deserve whatever horrible things happen to your phone.)
THIS IS NOT A RELEASE. THIS IS FOR DEVELOPERS WHO KNOW WHAT THEY ARE DOING TO FIND FLAWS WITH IN REGARDS TO ROOT AND SELINUX. I can't claim this would work for any device without the above mentioned firmware. If you don't know exactly how to recover from Bad Things, don't even download the attachment.
No support. No help. If you have to ask how to flash this or anything of the sort, this isn't for you.
Changes from stock ramdisk:
1. Modify sepolicy as @Chainfire documented (ironically using an unrooted note 5) to allow supersu to work it's magic.
2. Modify fstab to remove support_scfs,verify from the mount options for the system partition. (this solves the boot loops)
That's IT.
One warning, though: This is using supersu beta 2.51. That's not released. Actually, I think it's flagged as a work in progress.
garyd9 said:
Changes from stock ramdisk:
1. Modify sepolicy as @Chainfire documented (ironically using an unrooted note 5) to allow supersu to work it's magic.
2. Modify fstab to remove support_scfs,verify from the mount options for the system partition. (this solves the boot loops)
That's IT.
One warning, though: This is using supersu beta 2.51. That's not released. Actually, I think it's flagged as a work in progress.
Click to expand...
Click to collapse
Please, publish original boot.img from N920IDVU1AOH6
svadev said:
Please, publish original boot.img from N920IDVU1AOH6
Click to expand...
Click to collapse
Did you not bother to read any of the posts in this thread? There are known locations for stock images. This thread isn't one of them.
Read the very first line in the first post.
I made it for my SM-N9208, and it is really works with supersu 2.50 .
Thanks!
garyd9 said:
Changes from stock ramdisk:
1. Modify sepolicy as @Chainfire documented (ironically using an unrooted note 5) to allow supersu to work it's magic.
2. Modify fstab to remove support_scfs,verify from the mount options for the system partition. (this solves the boot loops)
That's IT.
One warning, though: This is using supersu beta 2.51. That's not released. Actually, I think it's flagged as a work in progress.
Click to expand...
Click to collapse
Hi
Could you please post a more detailed guide ? I want to do it myself for my n920c.
Thanks
geek78 said:
Could you please post a more detailed guide ? I want to do it myself for my n920c.
Click to expand...
Click to collapse
yeah. well, at least assuming you know how to unpack and repack boot images... (Because this stuff is very experimental at this point, and still very much a work in progress, you should have a certain level of proficiency before mucking with it. I can't and won't hold anyone's hand for this stuff at this point.)
you need to unpack the boot image. Get the boot.img and unpack. Open the ramdisk. In the ramdisk is a file called 'sepolicy.'
Start with this post to figure out how to change it:
http://forum.xda-developers.com/showpost.php?p=63190351&postcount=2071
Find the reply to that post from Chainfire to see how it can be done without a "reference" device.
You'll also have to change the proper fstab as I documented already in this thread.
Then pack up the ramdisk and repack the boot image.
Thanks. Perfect !
DAGr8 said:
I have to ask my friend. Since I'm back to Samsung at the same time as you it seems. I see very little advantage of running root atm but I see none of running Selinux non permissive. Also these devices being exynos you will not find much support for it.
I may be wrong but Selinux non permissive has been a problem on samsung custom roms from day one guys just disabled it and be done with I've never seen anyone complain ;p
Click to expand...
Click to collapse
I'm trying to place your name. Do I know you from SGS2 days or Note2 days?
Anyway, I'm not happy with settling. Never have been...
Edit:
Note or Note 2. Must have been Note2. You were doing smali edits for enabling tablet mode. That was pre-xposed days.
Edit 2:
To answer the question: enforcing selinux adds a layer of security on the device and blocks many security infractions. Basically, if you haven't been given permission to do something, you can't do it. Even as root. In theory, selinux could block the stagefright security issues. When a device is in "permissive" mode, selinux is there, but isn't actually blocking anything. It just logs violations and then ignores them.
In other words, permissive mode completely negates having the se extensions at all. Permissive was a mode that devs could run in to see what might break and what might not.
"root" access is, of course, a hole in the scheme. Chainfire, with supersu, has done quite a bit to ensure that the hole is controlled, but it's still a hole. However, a rooted device with an enforcing selinux kernel is still significantly more secure than a non-rooted permissive selinux kernel.
Another edit:
Here's some links:
https://su.chainfire.eu/#selinux
http://linux.die.net/man/8/selinux
<sarcasm> Wow, I almost forgot how much JOY and FUN it is working with Samsung sh!t kernels. </sarcasm>
So, in testing this (yes, I really DO test things.. imagine that) I found that my device wasn't going into deep sleep. Wow. How interesting. Oh, and not a single wakelock. WTF?!
Instead of google'ing first, I reverted to being a kernel dev (that is now trying to debug a kernel that he hasn't even compiled.) The first thing a kernel dev looks at: "dmesg" So, I copy dmesg to a file and transfer it my PC. (BTW, Notepad++ is God's gift to windows editors.) I search for various strings like "error" and "fail" and "suspend." What I end up seeing is a crapload of messages like this:
Code:
[0: system_server: 3858] PM: Device 0:0:0:x failed to suspend: error -5
(replace x with 1, 2, or 3)
Huh? So, before I dive into the code (because I really don't believe that samsung actually shares the kernel code that they use for themselves), I decided to google around a bit. I finally had enough search terms to hopefully narrow down the search results.
Guess what I found? People having the exact same problem on another samsung device: the S6 (and edge.) Here's the best of the threads:
http://forum.xda-developers.com/galaxy-s6-edge/help/deep-sleep-t3079705
It gets into some interesting detail around page 4 and 5. You'll have to skip past all the clueless people preaching about turning off wifi, downloading snake oil, and worshipping recycled NiCad batteries.
To make a long story short, the stock kernel (or perhaps the bootloader? That shouldn't be possible...) marks a few block devices as read-only if you're using a modified device. (If it's rooted, it's modified. If KNOX is tripped, it's modified, etc.) The kernel from Sammy is trying to flush caches to those devices (which is ironic when you consider they are marked read-only) before going into the suspend. The flush fails, so the entire suspend process fails. It seems that on the SGS6, there were only two devices like this. On the Note5, it seems to be 3 (everything except sda)
In that thread, @HomerSp not only tracked down the problem there, but also (thankfully) figured out that writes to a file in the /sys tree could work around the issue. Thankfully, because the entire point of THIS thread is to use the stock compiled kernel (with a modified ramdisk) to make life Happy. With 3 writes to the /sys tree, magically the device goes to sleep.
(Yes, I'll be taking care of it... and documenting it better...)
What a pain... for some reason, I couldn't write to the cache_type files from within the init.rc structure. No clue why not. Ended up having to add a "service" to the init structure
Anyway...
If you're following along at home, add the following lines to the bottom of init.rc:
Code:
service fix_cache_types /system/bin/sh /sbin/fix_cache_types.sh
class core
user root
oneshot
Then add a new file in the ramdisk's sbin directory called (I bet you guessed this already): fix_cache_types.sh
That file should have perms of 0750 and contain the following:
Code:
#!/system/bin/sh
echo 'temporary none' > /sys/class/scsi_disk/0:0:0:1/cache_type
echo 'temporary none' > /sys/class/scsi_disk/0:0:0:2/cache_type
echo 'temporary none' > /sys/class/scsi_disk/0:0:0:3/cache_type
If you're using the same kernel as I am (n920i), I've attached an updated image. Same rules, conditions, instructions as the last one I posted earlier in this thread. Except this one lets the device take naps. It helps the battery life.
Tomorrow (or Sunday) I'll see if this all works with xposed or not. (I seem to remember something about xposed not working with selinux enforcing kernels, but I could be wrong.) After that, if nothing prevents it (or me), I'll repackage this stuff again, and also throw together an n920c kernel (based on N920CXXU1AOH6) for general use.
BTW, at least on my n920i, I've confirmed that I don't reboot when getting a call (or making one), that NFC works, that bluetooth works, that I can wirelessly charge and quick charge. I'm trying to ensure all the "common" complaints with non-stock boot images are non-issues before giving this out... The whole purpose of using the stock kernel is to retain enforcing selinux and retain completely functional hardware.
garyd9 said:
yeah. well, at least assuming you know how to unpack and repack boot images... (Because this stuff is very experimental at this point, and still very much a work in progress, you should have a certain level of proficiency before mucking with it. I can't and won't hold anyone's hand for this stuff at this point.)
you need to unpack the boot image. Get the boot.img and unpack. Open the ramdisk. In the ramdisk is a file called 'sepolicy.'
Start with this post to figure out how to change it:
http://forum.xda-developers.com/showpost.php?p=63190351&postcount=2071
Find the reply to that post from Chainfire to see how it can be done without a "reference" device.
You'll also have to change the proper fstab as I documented already in this thread.
Then pack up the ramdisk and repack the boot image.
Click to expand...
Click to collapse
Hi
I have unpacked my boot.img. So I can see my sepolicy file in ramdisk/, I have patched it with my rooted Nubia Z9 but I don't understand next steps. Do you have time to explain a little more ?
For the fstab mods I have done it in fstab.samsungexynos7420 and fstab.samsungexynos7420.fwup. Is it ok ?
Thanks.
garyd9 said:
No support. No help. If you have to ask how to flash this or anything of the sort, this isn't for you.
Click to expand...
Click to collapse
garyd9 said:
I can't and won't hold anyone's hand for this stuff at this point.)
Click to expand...
Click to collapse
garyd9 said:
Same rules, conditions, instructions as the last one I posted earlier in this thread.
Click to expand...
Click to collapse
geek78 said:
Do you have time to explain a little more ?
Click to expand...
Click to collapse
Need I say more?
READ ON!
I HAVE SUCCESSFULLY BYPASSED VERIZON/ATT OF4 SECURITY ON THE OF4 BUILD for the SM-S975L and have succeeded in downgrading the bootloader by hex editing. I reach the Samsung Galaxy S4 logo. This is quite the accomplishment for me.
However, I need help with unpacking the system image and reworking it to an ATT-based ROM. Knox flat out tells me "No Verizon." when I try the flash. Because you know, aboot knox and all...
Merely hex edit the version number inside your custom boot image to match the system currently installed as you flash to stock. Search for any build number strings inside mbm files and edit accordingly. My documentation is below. Screw you verizon! I just saved myself $200.
Files to keep in Odin tar with matching build number name to pass check:
Changed
S975LUDUANB1_S975LTFNANB1_S975LUDUANB1_HOME.tar.md5
to
S975LUDUAOF4_S975LTFNAOF4_S975LUDUAOF4_HOME.tar
Hex edited version numbers into:
aboot.mpm
rpm.mbm
sbl1.mbm
sbl2.mbm
tz.mbm
boot.img
Guide update: Bootloader error "No Verizon. I suppose thats the CSC?"
deleted other files from that archive.
Made new archive name of:
S975LUDUANB1_S975LTFNANB1_S975LUDUANB1_HOME.tar
Placed system files in it. Rebooted and flashed. WORKED!
It will flash in Odin 3.07. Then reboot into download mode and flash the other ones with the same, you'll be downgraded and bypass the security check since you have the downgraded bootloader.
Give me credit and donate. I just saved the Verizon users' butts. As well as the tracfone ones.
If I can figure out how to unlock the straight talk bootloader I shall do. And make a flashable Odin image.
:laugh::laugh::laugh::laugh:
WORKING! -> SM-S975L Straight Talk on locked down firmware. http://forum.xda-developers.com/galaxy-s4/unified-development/root-sm-s975l-straight-talk-variant-of4-t3279890/post64511525
Documentation
I need a reliable way to edit mbm files I've extracted from the stock NB1 image. OF4 bootloader won't let old versions flash, so I'm going through a hex editor after removing md5 check to see what I can do as far as hex editing the version number to be newer than OF4 from the binaries. We get a fail on aboot.mbm. We are compatable, however Knox says we cannot downgrade.
Documentation on Odin flashable .tars and correct Samsung official mpm formats?
Help unpacking/repacking mpm files and root injection?
Documentation on Qualcomm Snapdragon machine code.
Update: aboot.mpm, modem, and system.img.ext4 version numbers changed, there is some kind of pattern, I see in system.img.ext: NB1 scattered throughout the code pages. I'm wondering if this is safe to change. It looks part of the code, so I'd assume no. I am seeing their routines for checksum as well there too, near there. So to the requests goes documentation on ARM assmelber, machine code. I hope this helps people like for example loki_tool. Would be nice if we had one to patch samsung images. I can make one that searches for the strings in the code in C for all the phone models, it sure would help bypass Verizon's crap. I'm so mad at them, rant rant rant onwards... Towelroot apk is going to need modified to support this build number (OF4, it is rootable since its NB1, but towelroot just checks the build number)
UPDATE 2: Flashed. Successful Nand write start. aboot is write protected even at Download mode level. Will try documented successes on Odin 3.07 for bootloader aboot flashes. Flashing it fails with a security lockup. Odin 3.09 sits there, but Odin 3.07 might work.
Update 3: Hacking the version number to current out of the Samsung Verizon images produces successful NAND write start. Developers, please note this when unlocking boot loaders. I have discovered a compromise which will allow flashing of unofficial aboot and system data. Provided the flashed bootloader does not contain checksum code.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Found in codepages of aboot.mpm Don't know if changing this plain text string is enough to make it match, I have a feeling CSC is going to fail which is going to require another hack. Plus half the code pages of aboot are SA1 encrypted. Going to search through mpm packages to make them all match.
In system.img.ext4 NB1 is scattered throughout the codepages. I found it several times but not going to change until I know if it will causes a system boot failure.
Build number hex edited to OF4 to bypass CSC check. Original post updated.
Bump. OP updated with link and working results.
I apologize for my ignorance since I don't fully understand the OP, so allow me to ask: does this wotk on USA AT&T GS4?
If it does work, and even if it doesn't, I think you should re-make the OP because I think the majority of people won't be able to understand what you did. Just an advice, I think it would be great!
Good job btw, you are giving us a little bit of hope!
Could this be reworked to downgrade firmware on the GS4 VZW (SCH-I545) ?
you can't downgrade bootloaders if the qfuse is blown
period end of discussion
you tamper with the bootloader by hexediting its a one way ticket to brick town on qfuse-blown vzw devices
Legitsu said:
you can't downgrade bootloaders if the qfuse is blown
period end of discussion
you tamper with the bootloader by hexediting its a one way ticket to brick town on qfuse-blown vzw devices
Click to expand...
Click to collapse
Unless of course, you have no idea what you're doing.
Does this or my guide look like I know what I'm doing? I'm root, now with disabled knox. So please don't insult me. You can flash modified loki'd aboot no issues. As long as signature matches you're gold. No qfuse. You insult someone who spends hours in a hex editor with this kind of thing, sir. I'm not technically downgrading. I'm tricking it into passing the code the downgraded kernel provides.
Bootloader screen
Verification Check: OK
0x0 KNOX Kernel Lock: Off
0x0 Verification Lock: Off
Warranty bit: 0x1 (Void)
Kernel lock and verification lock where on last night then some more tinkering got them off.
This stuff is to help people. So please mediocre responses like that are not necessary. Makes me not want to share my work sometimes.
rena14 said:
I apologize for my ignorance since I don't fully understand the OP, so allow me to ask: does this wotk on USA AT&T GS4?
If it does work, and even if it doesn't, I think you should re-make the OP because I think the majority of people won't be able to understand what you did. Just an advice, I think it would be great!
Good job btw, you are giving us a little bit of hope!
Click to expand...
Click to collapse
Thank you. I appreciate it. It works on the new Straight Talk / ATT GS4 with the corrected JB 4.3 and locked kernel. But as stated the flash will blow qfuse. But I'm not sure on that one, because I blew qfuse when I tried to flash TWRP, not during my tinkering.
Current issue is that Wi-Fi freezes in the OF4 firmware because the NB1 kernel does boot the OS, but OF4 is for JB 4.3 and NB1 is for JB 4.2. I have not encountered any FCs thus far. Recovery can't be flashed yet, but modified aboot with matching build number hex hacked into it OF4 does not throw a security check fail. I got nand write start, and pass.
Best I can say is try this hack method for your device. Find a sacrificial lamb you where going to throw away with a cracked screen. Ebay works. As long as the device is fully functional. All of my dev phones are old phones I'm getting rid of. So I never wreck a daily driver and a replacement is so cheap because of a damaged model I might only pay $50-100 for a device with a cracked screen.
Samsung's root certificates are in plain code in system.img.ext4. So sign your builds with the root certs, Sha256 pack, hex hack build number, gold.
The best explanation I can offer:
You are passing downgraded code. But Knox thinks you're just re flashing the current build.
LupineDream said:
Thank you. I appreciate it. It works on the new Straight Talk / ATT GS4 with the corrected JB 4.3 and locked kernel. But as stated the flash will blow qfuse. But I'm not sure on that one, because I blew qfuse when I tried to flash TWRP, not during my tinkering.
Current issue is that Wi-Fi freezes in the OF4 firmware because the NB1 kernel does boot the OS, but OF4 is for JB 4.3 and NB1 is for JB 4.2. I have not encountered any FCs thus far. Recovery can't be flashed yet, but modified aboot with matching build number hex hacked into it OF4 does not throw a security check fail. I got nand write start, and pass.
Best I can say is try this hack method for your device. Find a sacrificial lamb you where going to throw away with a cracked screen. Ebay works. As long as the device is fully functional. All of my dev phones are old phones I'm getting rid of. So I never wreck a daily driver and a replacement is so cheap because of a damaged model I might only pay $50-100 for a device with a cracked screen.
Samsung's root certificates are in plain code in system.img.ext4. So sign your builds with the root certs, Sha256 pack, hex hack build number, gold.
The best explanation I can offer:
You are passing downgraded code. But Knox thinks you're just re flashing the current build.
Click to expand...
Click to collapse
Thank you for taking time the to answer my question, I really appreciate the time and effort you are spending on this.
Since you are still working on this, I'll just wait until you finally get all the things together and fully unlock bootloader. My GS4 is also my daily driver so, following your advice, I better don't attempt to do anything until I can fully understand the whole thing.
Wish you the best of luck on this project, and thanks again for your work, dude!
Regards.
LupineDream said:
Unless of course, you have no idea what you're doing.
Does this or my guide look like I know what I'm doing? I'm root, now with disabled knox. So please don't insult me. You can flash modified loki'd aboot no issues. As long as signature matches you're gold. No qfuse. You insult someone who spends hours in a hex editor with this kind of thing, sir. I'm not technically downgrading. I'm tricking it into passing the code the downgraded kernel provides.
Bootloader screen
Verification Check: OK
0x0 KNOX Kernel Lock: Off
0x0 Verification Lock: Off
Warranty bit: 0x1 (Void)
Kernel lock and verification lock where on last night then some more tinkering got them off.
This stuff is to help people. So please mediocre responses like that are not necessary. Makes me not want to share my work sometimes.
Click to expand...
Click to collapse
This sounds very promising. Thank you
This is absolutely huge news to read. I am assuming once recovery is working (ie: TWRP) that perhaps could AOSP ROMs like CM13 be usable on all Verizon S4's once the downgrade is done? I'll be keeping track of the progress on this for sure.
yes you can spoof 'minor' version numbers(pretty sure somebody already did this a awhile back) but it's never going to boot(unless the op has discovered something new and magical that lets you remove the checksum/qfuse + chain of trust checks it most certainly will never get you back to VRUMDK or to a loki-exploitable base,which is what we need to run real custom roms and kernels
when the op demonstrates a working method to get a loki-able aboot flashed and working then I will be impressed until then status-quo remains because this looks extremely dubious from what we know of qualcomm's qfuses and knoxs bootloader shenanigans ...the status-quo has always been you so much as `touch` the aboot and its a automatic no-boot because its cryptographically signed and and there are hard-wired integrity checks in the cpu
the i545 is a completely different beast then all the other variants
@npjohnson ?
Legitsu said:
yes you can spoof 'minor' version numbers(pretty sure somebody already did this a awhile back) but it's never going to boot(unless the op has discovered something new and magical that lets you remove the checksum/qfuse + chain of trust checks it most certainly will never get you back to VRUMDK or to a loki-exploitable base,which is what we need to run real custom roms and kernels
when the op demonstrates a working method to get a loki-able aboot flashed and working then I will be impressed until then status-quo remains because this looks extremely dubious from what we know of qualcomm's qfuses and knoxs bootloader shenanigans ...the status-quo has always been you so much as `touch` the aboot and its a automatic no-boot because its cryptographically signed and and there are hard-wired integrity checks in the cpu
the i545 is a completely different beast then all the other variants
@npjohnson ?
Click to expand...
Click to collapse
Said documentation on CPU integrity checks?
In that case, I'll most likely need more hardware than I currently have... Like a JTAG debugger. At least something thar can get me low level enough to reverse engineer and find out what the CPU I'd trying to verify. And match an aboot to it.
Legitsu said:
yes you can spoof 'minor' version numbers(pretty sure somebody already did this a awhile back) but it's never going to boot(unless the op has discovered something new and magical that lets you remove the checksum/qfuse + chain of trust checks it most certainly will never get you back to VRUMDK or to a loki-exploitable base,which is what we need to run real custom roms and kernels
when the op demonstrates a working method to get a loki-able aboot flashed and working then I will be impressed until then status-quo remains because this looks extremely dubious from what we know of qualcomm's qfuses and knoxs bootloader shenanigans ...the status-quo has always been you so much as `touch` the aboot and its a automatic no-boot because its cryptographically signed and and there are hard-wired integrity checks in the cpu
the i545 is a completely different beast then all the other variants
@npjohnson ?
Click to expand...
Click to collapse
Right know I have a few tools that are providing useful, IDA decompiler being one of them. But I need the documentation on the instruction sets of the CPU and hardwarespec
Going to do some digging. I'm an it student though not enrolled at Penn State. There's a campus local. I'm going to do some asking around (quite cautiously) to find any equipment needed. I need this functional model to work with. I am getting a new DD next month
Shout out to any Penn state students. This is a project that's worth the bounty. Because if a JTAG won't give me access on POST, yeah, that's a disassembly and a chip mount. And that's not something I have the funds for. At all. Even though the most backwater of websites will take an auto deskffile and 3D print me a mount for pennies on the dollar.
Im realizing where there is a bounty on this unlock.... Again. Got to do some digging. If I become neglectful of this thread I am sorry. Its because quite honestly I'm probing for assistance.
Legitsu said:
yes you can spoof 'minor' version numbers(pretty sure somebody already did this a awhile back) but it's never going to boot(unless the op has discovered something new and magical that lets you remove the checksum/qfuse + chain of trust checks it most certainly will never get you back to VRUMDK or to a loki-exploitable base,which is what we need to run real custom roms and kernels
when the op demonstrates a working method to get a loki-able aboot flashed and working then I will be impressed until then status-quo remains because this looks extremely dubious from what we know of qualcomm's qfuses and knoxs bootloader shenanigans ...the status-quo has always been you so much as `touch` the aboot and its a automatic no-boot because its cryptographically signed and and there are hard-wired integrity checks in the cpu
the i545 is a completely different beast then all the other variants
@npjohnson ?
Click to expand...
Click to collapse
I feel like an idiot but this might help: I was I of1(the latest lollipop build) and I Odin'ed oc1(the first lollipop build). Here's the the part that is interesting: I got a soft brick and could fix it through Odin. Sorry if you guys already knew this, just wanted to help.
LupineDream said:
Right know I have a few tools that are providing useful, IDA decompiler being one of them. But I need the documentation on the instruction sets of the CPU and hardwarespec
Going to do some digging. I'm an it student though not enrolled at Penn State. There's a campus local. I'm going to do some asking around (quite cautiously) to find any equipment needed. I need this functional model to work with. I am getting a new DD next month
Shout out to any Penn state students. This is a project that's worth the bounty. Because if a JTAG won't give me access on POST, yeah, that's a disassembly and a chip mount. And that's not something I have the funds for. At all. Even though the most backwater of websites will take an auto deskffile and 3D print me a mount for pennies on the dollar.
Im realizing where there is a bounty on this unlock.... Again. Got to do some digging. If I become neglectful of this thread I am sorry. Its because quite honestly I'm probing for assistance.
Click to expand...
Click to collapse
everything you wanna know is in this thread http://forum.xda-developers.com/showthread.php?t=2500826
pay close attention to the bits at the bottom and the posts about TZ aka trust zone
there has been a pretty massive effort at this for sometime with only sporadic progress
basicly focus shifted from unlocking to getting kexec working,which is just as good
for the record please nobody attempt this on a vzw device you will blow a qfuse or cause a hard brick
Legitsu said:
for the record please nobody attempt this on a vzw device you will blow a qfuse or cause a hard brick
Click to expand...
Click to collapse
i was about too anyone tried it anyways though?
Awesomeslayerg said:
i was about too anyone tried it anyways though?
Click to expand...
Click to collapse
.... why would anyone try it when its a 100% guarantee to hard brick on vzw
Envoyé de mon SM-G903F en utilisant Tapatalk
DEPRECATED
This firmware is old and deprecated.
See the below link for new firmware and a better root method.
https://forum.xda-developers.com/galaxy-s8/development/root-partcyborgrom-aqi6-deodexed-t3702988
You can just flash the BL_ tarball if you don't want to install a new system
but want the better screen and modem drivers.
PART 2: FIRMWARE RELOADED
I have done extensive research into the issues reported by those of you who are still experiencing screen issues.
I was unable to reproduce the screen issue on my then-current firmware with this update.
Not being content to leave people with buggy screens, I learned as much as I could about the s8 firmware.
This is what I did with that information.
Flashable Custom Firmware Package For ALL SM-G950U/U1 ON US CARRIERS
If you have a non-us G950U and want to install this pm me or ask in the thread and ill make one. Its very simple but I wanted to get this out to everyone else ASAP
NOTICE!
This an UPDATE (and More) to the Green/Garbled Screen Issue firmware.
There is NEW firmware to download below, and everyone who is rooted should read on, even if you installed the previous version.
Background
At the core of the issue with the garbled screen, modem panics, and sd card issues are two central themes: Bugs, and Incompatibilities. The S8 family of phones was fraught with issues early in its release, including the infamous "Red Tint', Fingerprint scanner malfunctions, mysteriously poor battery life, and surely a bunch of smaller others. Many of these bugs were caused by issues in the device's underlying firmware. Like most devices, Samsung has worked to fix these bugs and improve device performance throughout the phones lifetime for sale in public.
Root Bugs
The problem was unfortunately worse for users of one of the rooting methods for the S8. The biggest reason for this is that in order to relax security constraints enough to make rooting possible, a "non-user oriented", "factory" combination firmware was used. This firmware, being designed apparently for configuration/repair processes inside a factory, was not tuned to the normal level as the public firmware, likely did not go through the same testing, and ultimately any bugs unique to this "Combination" firmware that did not directly affect basic functionality or also stock were probably largely initially ignored.
This is where most of the issues that you all have had come from.
Finding a Solution
As I was unable to reproduce the issue on my device without resorting to the original firmware shipped out with the root method I used, I decided to think about what made my device different than the other devices reporting these issues. While sure we may have slightly varying hardware and that may contribute to these issues as well. What I am absolutely certain of is that most of us have different releases of software from each other. Not only have people essentially ad-hoc upgraded from the original firmware they rooted with until now, many have not upgraded at all or, only partially upgraded (such as with the pervious version of this).
While I could have simply packaged up my firmware/bootloader flashfire backup, I decided to take it a step further.
THE GOODS
Without further ado, I present to you:
S8Root Improved: A SM-G950U1 Custom Firmware Package for Root Users
This package contains a custom mix of the latest AQH3 STOCK (not combination) firmware used wherever possible with the Necessary boot/kernel images from the combination firmware necessary to keep root working with permissive SELinux. It contains all of the improvements from the previous version, and many more.
RESULTS
I can only speak for myself, but the results I experienced were amazing:
- Better UI Responsiveness.
Things surprise me how they move
- Sharper/brighter screen colors
I thought it couldn't get better than the last version but it has! Everything just looks crisper and are super bright without being oversaturated like with the Adaptie Mode.
- POSSIBLY Improved LTE network connectivity.
Note I said POSSIBLY. I personally regularly experienced 8-10Mb/s download bumps and 2-3Mb/s upload bumps in LTE while moving back and forth from this new firmware. I have my LTE radio locked to a specific channel (there are two i pick up at my place and one is terrible) and I carefully measured -107 to -112 dBm RSRP and -13 to -14 dB RSRQ prior to each measurement. I almost left this out but I figured it would be better to give you the information with no conclusion either way. It ABSOLUTELY could be Atmospheric changes, Traffic level changes, or any other of a million thins. YMMV
- Could POTENTIALLY still any remaining fix long-standing SDCard issues
I did not experience this, but had a few reports from users that did. The same pieces used in that version that would touch SDcard usage are used here, so that fix/improvement will carry over.
DISCLAIMER
Unfortunately proving beyond any shadow of a doubt that this package fixes the issue was impossible . I have TRIED AND TRIED AND TRIED to trigger the screen issues, including tweaking on and off every setting (auto brightness, multiple DPIs, different graphs modes, etc) I could get my hands on and it just was not happening. I used every software/systems trick I could think of to break this again, and I was completely unable to tickle the bug on this firmware, despite being able to reliably trigger it almost on command using my previous firmware.
The only thing left to do is either:
- Get the source from samsung, fix the bug myself, and get them to sign my new kernel image with their key so our locked bootloaders would allow it (HAHA I DOUBT IT)
- Acquire a large fleet of S8s (and S8+s) to run distributed integration testing (like the kind Android use at Google). Well if someone wants to buy me a few dozen s8s and s8+s (each) sure I'll take a month off work and squash this, but otherwise not gonna happen either.
If it STILL happens for you, I'm sorry.
I have done everything I can think of, and if it happens to you and you have suggestions, I'm all ears.
BUT HEY, but this is XDA right? Land of mods like Xposed which will brick one persons device and work flawlessly on the identical one next to it. And we love Xposed don't we?
Despite absolutely hilarious comments to the contrary, this package absolutely meets the (aka "BugFix") as well as just about any android update ever does, given the wide variety of environments, usecases and software configurations out there. I surely hope that this works for you.
Instructions
1) Download the package from the link above.
- Here it is Again for good measure.
2) Reboot into download mode and flash using Comsy Odin
Thats it! I packaged this in a way to make the process as smooth as possible.
There is NO reinstall, NO wipe of any kind, nor ANY further work on your part needed to install and use this.
The file size is small so the download is fast, and again, there is NO WIPE or config change needed.
if (for some inexplicable reason) you want to roll back, or go to 100% stock sans root, that process should not be made any more difficult as well.
Legacy Information
If you were here before and either looked at or downloaded the previous version, AND YOU HAVE NO QUESTIONS you can skip this part.
If you have questions, please read through to the end of the post before asking them, as I tried to answer as many as I could before hand and all of this information still applies.
WHAT IT IS NOT:
I wanted to outline a few things it is NOT about, to make a valliant effort to stem off the flow of questions before they begin (ha!):
NOT: A new Stock ROM for Your Phone
THIS IS NOT A FULL OS BUILD! DO NOT DOWNLOAD THE WHOLE THING AND FLASH IT EXPECTING AN ENTIRELY UPGRADED OS.
There is no full stock AQI1 image I have found. Believe me I looked a bunch of places after I found it
NOT: Oreo Early Preview
Given the predictions that the next release from Samsung would likely be Oreo, there was some initial over excitement. This wound up being NOT the case and if you read at least current Samsung Oreo projections they are predicting AQB now.
NOT: A Fix for the 80% Battery Issue
I know this is completely futile to hope for but:
THIS DOES NOT FIX THE 80% BATTERY ISSUE!!!!
NO WE DO NOT HAVE A FIX FOR THAT OR ONE COMING ANY TIME SOON!
YES SOME PEOPLE ARE STILL TRYING!
PLEASE DO NOT ASK! OFF TOPIC FOR THS THREAD
NOT: Currently Tested by ANYONE but ME
Since the moment I installed this I have not had ONE SINGLE screen issue, where previously I would have them several times throughout the day (at least 3 sometimes upwards of 6). For the case of ME and MY device, I am confident in declaring that this boot ROM does not have the same kernel bug that was causing the issue on the boot.img provided as part of your traditional root method.
NOTE: This is for the s8 G950 US Snapdragon models ONLY! Do NOT Flash this on your exynos, your Chinese/HK S8, your N8, your MOTO RAZR flip phone, whatever else you have. Kernels/boot.img files are very device specific and you will surely break it if not completely brick it.
DISCLAIMER:
YOUR WARRANTY IS ALREADY VOID if you are paying attention and are doing this to fix bugs with the existing sampwnd root.
HOWEVER IT IS EVEN VOIDER NOW. FLASH THUS TO YOUR DEVICE AT YOUR OWN RISK!
and if you break it I AM NOT RESPONSIBLE! FLASH AT YOUR OWN RISK!
As I said I have not tested this anywhere but my phone as I dont have any other s8s nor do I have access to any locally. I hope it works for you as well as it has for me.
STEPS
Download Boot Image
Use the URL here to Download the AQI1 boot.img file: Go Download the New Hotness
Prepare Phone for Flashing in FlashFire
If you did not download it on your phone, copy it somewhere FlashFire can see it.
Flash it
Open up FlashFire
Hit the "+" button
Select the "Flash Firmware Package" option, NOT the "Flash Zip or OTA" option!
You should see a popup window thing that has a checkbox next to the word BOOT, with "boot.img, 22MiB" underneath.
Make sure the checkbox is checked.
Make sure that it says BOOT above boot.img.
I have no idea if its possible for this to get messed up, but BOOT implies flashing the BOOT partition so if it says something else you are headed towards brick town, abort immediately.
Press the Check mark at the top right corner once you have confirmed the two things above.
MAKE SURE EVER ROOT IS DISABLED!!!
Click on the "Reboot" box, and choose "Recovery". MAKE SURE PRESERVE RECOVERY IS NOT CHECKED!
Back at the main menu, click the lightening bolt next to the word FLASH. Confirm.
Wait for FlashFire to do its thing. Sometimes it takes a minute for FF to wake up and start flashing. Occasionally for me it never happens, if this happens DO NOT PANIC ITS FINE. Hold down power+volDown until you eventually wind up in upload mode, then just reboot normally and everything will come back fine.
When FlashFire finishes (it will go really fast, the image is only 22MB we arent flashing a 5GB system here), it will auto-reboot your device into the recovery men
Select Wipe Cache and Confirm
This will wipe cache which is fine and safe. Again maybe not needed, feel free to skip if you know what you are doing. If you mess up and accidentally click factory reset instead, please tell me so I can laugh at you.
Reboot into a Clear New World
Select reboot and boot the system normally. If you formatted the cache partition above, it will take a little longer to start your phone. This is just the first time per normal.
Thats it! Welcome to the world of clear screens and bright colors. It could be a total placebo effect but I actually think this kernel drives the display better sometimes.
Please let me know what you think, and if this works for you. I wi;; be here for a while to answer questions or fix anything i typoed above or whatever.
FYI: A s8+ thread is coming too, as I sprung for purchasing both downloads to be an equal opportunity XDAer (at least with US flagship Samsung devices lol) but since I have an s8 and thus had the files locally already I made this one first
@jhofseth for nerding out with me the last few nights on trying crazy **** to get a bootloader unlock which prompted me to dig at this in the first place
Most of all, all of the tons of you who have made so many aewesome mods, themes, apps, what have you that I use every day and that make me enjoy my device all the more. I could not be happier to have the opportunity to give back a little.
Here is the restof the s8 combo firm if you are interested, but don't just flash this as its not a full OS:
EDIT: DOWNLOAD THE NEW ONE ABOVE
Can I Get The Link To The S8+ Boot im willing to try it
Mark805 said:
Can I Get The Link To The S8+ Boot im willing to try it
Click to expand...
Click to collapse
Coming very soon I promise! 10m max
Ok thanks
Mark805 said:
Can I Get The Link To The S8+ Boot im willing to try it
Click to expand...
Click to collapse
Its up now! https://forum.xda-developers.com/ga...sampwnd-root-green-screen-corruption-t3673815
whats the bootloader verison? it can be found by booting into download mode manually.
Cameron581 said:
whats the bootloader verison? it can be found by booting into download mode manually.
Click to expand...
Click to collapse
This isn't a bootloader change, it's boot.img which is the kernel and root filesystem essentially
Hey, btw this does not void warranty. I understand it's a standard disclaimer but it doesn't void it. It doesn't trip knox, so warranty is still very intact.
mweinbach said:
Hey, btw this does not void warranty. I understand it's a standard disclaimer but it doesn't void it. It doesn't trip knox, so warranty is still very intact.
Click to expand...
Click to collapse
Uh just because their service does not catch you does not mean that technically you are not violating your warranty contract thus making using technically illegal
That would be like saying "it's not murder if you leave no forensics!" Lol
wildermjs8 said:
Uh just because their service does not catch you does not mean that technically you are not violating your warranty contract thus making using technically illegal
That would be like saying "it's not murder if you leave no forensics!" Lol
Click to expand...
Click to collapse
i mean legally a warranty can not be void through software modifications unless it causes physical damage to the device. Since the efuse was not tripped no physical damage has been caused and no warranties have legally been void.
I had the green screen/graphics corruption after flashing this still...
goliath714 said:
I had the green screen/graphics corruption after flashing this still...
Click to expand...
Click to collapse
Apparently this happens to some people. I am fairly certain it is a firmware combination issue but I haven't been able to track it down. One thing you can do to eliminate it if you have the issue still (please let me know if this does not work) is to disable auto brightness.
wildermjs8 said:
Apparently this happens to some people. I am fairly certain it is a firmware combination issue but I haven't been able to track it down. One thing you can do to eliminate it if you have the issue still (please let me know if this does not work) is to disable auto brightness.
Click to expand...
Click to collapse
I have auto brightness off and still get it here and there.
goliath714 said:
I had the green screen/graphics corruption after flashing this still...
Click to expand...
Click to collapse
Please check out the OP again and download/flash the new version. Rather than just a few files, its a whole new entire bootloader/kernel package that I assembled piece by piece to have as much latest stock firmware as possible while maintaining what we need for root.
My primary suspect for why some people experience this regression is having older parts of their system. Rather than push everyone to upgrade, I made a painless upgrade process for all of their firmware instead
This includes the Radio drivers and bootloaders, kernels and flash layer libraries. Its all either latest stock or its AQI1 Combination because it was absolutely necessary.
wildermjs8 said:
Please check out the OP again and download/flash the new version. Rather than just a few files, its a whole new entire bootloader/kernel package that I assembled piece by piece to have as much latest stock firmware as possible while maintaining what we need for root.
My primary suspect for why some people experience this regression is having older parts of their system. Rather than push everyone to upgrade, I made a painless upgrade process for all of their firmware instead
This includes the Radio drivers and bootloaders, kernels and flash layer libraries. Its all either latest stock or its AQI1 Combination because it was absolutely necessary.
Click to expand...
Click to collapse
We flash the tar in the AP slot correct?
CloudyxVision13 said:
We flash the tar in the AP slot correct?
Click to expand...
Click to collapse
Yep
---------- Post added at 08:29 PM ---------- Previous post was at 08:28 PM ----------
Seems to be running better to me. Thanks bro
CloudyxVision13 said:
We flash the tar in the AP slot correct?
Click to expand...
Click to collapse
It actually does not matter, as Odin will do the right thing no matter what.
Sorry I should have made that clear. I will update the op to make that clear
Just wanna make sure of something. First, I flash the first download files through modded doin, then afterwards, flash the second file in ff?
AngelIsL33T said:
Just wanna make sure of something. First, I flash the first download files through modded doin, then afterwards, flash the second file in ff?
Click to expand...
Click to collapse
Nope, only need the tar file bud. The old boot.img file is just basically the previous version of this.
AngelIsL33T said:
Just wanna make sure of something. First, I flash the first download files through modded doin, then afterwards, flash the second file in ff?
Click to expand...
Click to collapse
The old image is actually part of the new tar, do you will have it anyway . I packaged it in Odin this time because there are some pieces of firmware FF either can't or warns against using it for. Plus one clean simple tar seemed easier, no?
Do you see the boot.img in the op? I thought I nixed all the instances of the link but I may have missed one.
I almost rewrote all the old text to reflect now but it felt like editing history so I tried to preserve what made the most sense still. It sounds like it's still a little confusing sobrskr another crack at it shortly.
Please let me know if you have any trouble! I'll be here to help all evening