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.
Related
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
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
Ok so at first it wouldn't let me in until I plugged it into a computer or a fancy USB outlet. And it wouldn't let me go T the home screen. Now it wont let me on at all, after the home screen suddenly swooped in and ate this post on my Apollo, thus ****ing it. So now I can't get in at all. And I just rooted after I suddenly got this update, the newish one, and I renamed ota and ota contracts on accident. Is that a problem? Please help me...
Leafen said:
Ok so at first it wouldn't let me in until I plugged it into a computer or a fancy USB outlet. And it wouldn't let me go T the home screen. Now it wont let me on at all, after the home screen suddenly swooped in and ate this post on my Apollo, thus ****ing it. So now I can't get in at all. And I just rooted after I suddenly got this update, the newish one, and I renamed ota and ota contracts on accident. Is that a problem? Please help me...
Click to expand...
Click to collapse
Renaming OTA contracts is a problem! Given device is rooted it may be fixable via ADB. Also possible you can go further and unlock bootloader which yields complete control to repair/replace FireOS. I am travelling today and can not immediately help with details. Will check back later (24 hours) to see if help is still needed.
Thanks for the reply. However, I am unsure how to do what you suggested since its on a bootloop because I renamed the file apparently.
Thanks for the reply. However, I am unsure how to do what you suggested since its on a bootloop because I renamed the file apparently.
Leafen said:
Thanks for the reply. However, I am unsure how to do what you suggested since its on a bootloop because I renamed the file apparently.
Click to expand...
Click to collapse
Bootloop further complicates matters. How much time passes before the device restarts? Does it ever make it to the login screen?
While there is still a glimmer of hope the situation is dire. Pretty good chance the device can not be recovered. I say that not to be negative but rather recognizing Apollo is not a cheap gadget. Amazon crippled native recovery capabilities making simple fixes impossible to apply. Akin to making tires a non replaceable item (brilliant). Just want to prepare you for an unpleasant outcome...
Davey126 said:
Bootloop further complicates matters. How much time passes before the device restarts? Does it ever make it to the login screen?
While there is still a glimmer of hope the situation is dire. Pretty good chance the device can not be recovered. I say that not to be negative but rather recognizing Apollo is not a cheap gadget. Amazon crippled native recovery capabilities making simple fixes impossible to apply. Akin to making tires a non replaceable item (brilliant). Just want to prepare you for an unpleasant outcome...
Click to expand...
Click to collapse
Oi. Uh. It's normal procedure up to the colored Kindle logo. Goes off the same amount of time as usual. And it never makes it to the put in your password screen. Not yet anyways.
Scratch that I'm in. Changing Ota contracts back
It worked. I'm able to get back in the home screen. But now I need safestrap again for the ROM I already have partitioned on this device.
Leafen said:
It worked. I'm able to get back in the home screen. But now I need safestrap again for the ROM I already have partitioned on this device.
Click to expand...
Click to collapse
Great! Assuming a factory reset did the trick (I didn't immediately suggest that course of action as it can sometimes make things worse; other things to try first).
If you install Safestrap v4 choice of ROMs is limited to Fire Nexus and CM11 - both KitKat based. Unlocking the bootloader opens the door to a wider selection of Lollipop and Marshmallow based ROMs. Unlocking is not risky but does require a bit of technical knowledge and some patience. An unlocked device is also easier to recover in the event of a ROM crash or bootloop.
Assuming you want to proceed with Safestrap download the app from here. Make sure you get the build appropriate for your device. Install/launch the app and then select the option that installs Safestrap recovery. Please note this is not a true recovery environment and has none of the special powers associated with TWRP. Its singular purpose it to support the two custom ROMs noted above on a locked device. Unlocked devices do not need to use Safestrap.
Once Safestrap recovery is installed reboot your device. After the grey Amazon logo you will be presented with a 'robot' screen where you can choose to continue booting into FireOS or enter Safestrap recovery mode. Choose the latter. After a few moments device will enter Safestrap recovery which emulates TWRP.
Do you know what to do from here?
Warning: Once Safestrap v4 recovery is installed you should NEVER perform a factory reset via the stock recovery menu. Doing so will brick the device.
Oh! Well. Id like to know about unlocking my boot whatever. Now Marshmallow and lollipop are Android 4. S.omething right? Oh um. Do you mind telling me how to do it, especially since I got jammed into the new update, breaking my safestrap I already had and leaving the slot out to dry? That would be appreciated!
Leafen said:
Oh! Well. Id like to know about unlocking my boot whatever. Now Marshmallow and lollipop are Android 4. S.omething right? Oh um. Do you mind telling me how to do it, especially since I got jammed into the new update, breaking my safestrap I already had and leaving the slot out to dry? That would be appreciated!
Click to expand...
Click to collapse
Well you got "jammed" into a FireOS update because Safestrap was improperly configured. Details matter. Suggest proceeding with reinstalling Safestrap and forget about unlocking the bootloader thingy. Do not create or attempt to use a secondary slot. Custom ROM overwrites FireOS in the stock slot. Lots of posts outlining Safestrap best practices that apparently were not read or ignored.
Bootloader unlock thread: http://forum.xda-developers.com/kindle-fire-hdx/general/thor-unlocking-bootloader-firmware-t3463982
No the reason I was booted out was because i was having to be stuck on the FireOS because I have to have it for well.. Showing reasons. Don't worry about that. But Safestrap was done perfect, I had it going on for A long while. I successfully used two or more ROMs with perfect functionality.
Leafen said:
I successfully used two or more ROMs with perfect functionality.
Click to expand...
Click to collapse
If using multiple/secondary slots worked well enough for you, great!
Full functionality can not be achieved in secondary slots with Safestrap v4 which is an adaptation specific to this device and was never intended to support dual boot capability. Issues impacting ROMs operating in secondary slots:
- restricted BT/WiFi radio functionality (less of an issue w/CM11)
- only 2 of 4 CPU cores available (other two disabled)
- the two active cores run at 100% regardless of load
- device will not enter deep sleep when secondary slot is active
- poor performance and lousy battery life resulting from above
If you only use the secondary slot on occasion and radios work then it's obviously a personal call if the limitations are problematic.
Davey126 said:
If using multiple/secondary slots worked well enough for you, great!
Full functionality can not be achieved in secondary slots with Safestrap v4 which is an adaptation specific to this device and was never intended to support dual boot capability. Issues impacting ROMs operating in secondary slots:
- restricted BT/WiFi radio functionality (less of an issue w/CM11)
- only 2 of 4 CPU cores available (other two disabled)
- the two active cores run at 100% regardless of load
- device will not enter deep sleep when secondary slot is active
- poor performance and lousy battery life resulting from above
If you only use the secondary slot on occasion and radios work then it's obviously a personal call if the limitations are problematic.
Click to expand...
Click to collapse
I only had the battery thing. Otherwise I used my secondary rom pretty much all the time.
Leafen said:
I only had the battery thing. Otherwise I used my secondary rom pretty much all the time.
Click to expand...
Click to collapse
And ½ the CPUs disabled. So why not install the custom rom in the stock slot?
Davey126 said:
And ½ the CPUs disabled. So why not install the custom rom in the stock slot?
Click to expand...
Click to collapse
I have o keep up appearances pretty much. The reason why I dont really need to tell you. But its for appearences sake
Leafen said:
I have o keep up appearances pretty much. The reason why I dont really need to tell you. But its for appearences sake
Click to expand...
Click to collapse
Yep - I get it. Not specifics (obviously) but understand optics. As an aside unlocking the bootloader offers no significant benefit given your situation. Enjoy.
Davey126 said:
Yep - I get it. Not specifics (obviously) but understand optics. As an aside unlocking the bootloader offers no significant benefit given your situation. Enjoy.
Click to expand...
Click to collapse
Crap. Safestrap isnt working for this update. Dang. Gotta wait for ggow or someone to make it.
Leafen said:
Crap. Safestrap isnt working for this update. Dang. Gotta wait for ggow or someone to make it.
Click to expand...
Click to collapse
Must be on FireOS 4.5.2.0 or 4.5.5.1 to run Safestrap v4. Rollback/upgrade options are available but ugly. Pretty sure Safestrap won't be receiving any further updates now that the HDX bootloader can be unlocked on any rooted 3rd gen device.
Follow the instruction of your OS (GrapheneOS or CalyxOS) as normal, then just before locking the bootloader back follow the guide here. The end result is a OS with Magisk and root, but the bootloader can not be lock again (because of the root process).
So, if you would like to be able to record call, block advertisement and enjoy your device because it is your freedom to do with your device what ever you want, root your OS.
PS, if security is more important then privacy, rooting is not the way to go, at the moment I didnt find how to maintain both
Old news.
And technically, you CAN relock the bootloader if you wanted to, by resigning everything. There's links (somewhere, you'll have to search for it) to a program on git that someone wrote to do this, but I haven't tried it.
The reality is that locking the bootloader really doesn't do much for you. It might protect you a BIT if you lose physical control over it, but when you lose physical control over a device, you have to assume that its been compromised anyway.
Locking the bootloader will be essential in the future when Google enforces Hardware Backed attestation for those who use contactless payments.
This is good to know.
shoey63 said:
Locking the bootloader will be essential in the future when Google enforces Hardware Backed attestation for those who use contactless payments.
This is good to know.
Click to expand...
Click to collapse
Source?
96carboard said:
Source?
Click to expand...
Click to collapse
It's all in This thread
Edit: More reading Here
shoey63 said:
It's all in This thread
Edit: More reading Here
Click to expand...
Click to collapse
Your links seem to be showing something about current issues that people are having, not about something "in the future" regarding enforcement of locked bootloader.
Edit: what I'm looking for is some statement from gooble that they intend to make some changes with respect to this, otherwise it appears to be just speculation.
Edit 2: The subject is also pretty off topic, since there's a good chance that it doesn't come into play at all with graphene or calyx, both of which do NOT include integrated binary gooble services. Graphene goes to a lot of trouble to make it installable, but strongly isolated from everything else, which includes restricting hardware status flags from being readable by it. Calyx promotes microG.
96carboard said:
Old news.
And technically, you CAN relock the bootloader if you wanted to, by resigning everything. There's links (somewhere, you'll have to search for it) to a program on git that someone wrote to do this, but I haven't tried it.
The reality is that locking the bootloader really doesn't do much for you. It might protect you a BIT if you lose physical control over it, but when you lose physical control over a device, you have to assume that its been compromised anyway.
Click to expand...
Click to collapse
It may be old news for you, I didnt find it anywhere. That is why I posted it here, just in case there are people like me that looking for that answer.
Asking in the GrapheneOS chats, I only got an answer that rooting is not supported and not recommended.
Since I'm using call recorder to my work and will be glad to block advertisements locally, and god forbid, I also would like to use either Graphene or CalyxOS.
I dont see other way around it unless using root.
Can you please send your links for looking back the bootloader? that will be awesome. Thanks!
HQwarp said:
Can you please send your links for looking back the bootloader? that will be awesome. Thanks!
Click to expand...
Click to collapse
Use the search bar at the top of the screen, or read through all the other threads in the 6 and 6pro forums, that's what I would have to do to find it for you.
96carboard said:
Use the search bar at the top of the screen, or read through all the other threads in the 6 and 6pro forums, that's what I would have to do to find it for you.
Click to expand...
Click to collapse
Very sad respond from you. You can be helpful and point me to the right direction and with less arrogance attitude of yours...
XDA is a place to share knowledge, not to show your arrogance on how good you are to type in google search.
FYI, if anyone want to sign the bootloader after using Magisk this is probably the way
Rooting Graphene/Calyx/LeOS/DivestOS/eOS/CopperHead completely defeats t he purpose as now it gives potentially a malicious app root abilities.
As the head of Graphene's Twitter once said "but why... that opens so many security risk doors"|
You can't re-lock the bootloader with root unless you create a new avb-key. Don't bother rooting security roms, its pointless.
Yes, you are right, it is lowering the security of the phone. But, that's ok, each one with his use case of attack. If it is ok for you to use your phone without sudo, good for you. Since I'm not Edward Snowden and I'm not afraid to use sudo on my machines, and when I do, I know enough when and how to use it.
Therefore, I don't see why I can't use sudo on my phone. Especially when some of us do need our phone to perform tasks that currently are not supported by Security oriented OS as you mentioned, AND also do want to lower our information footprint on the net. For this case using sudo on the formation ROMs seems ideal.
HQwarp said:
Very sad respond from you.
Click to expand...
Click to collapse
Very sad that you expect to be spoon fed when you have the capacity to search for yourself.
to make it easier for people who may look for it (I was one of those people)
this is that script mentioned earlier which will allow you to resign the rom to allow you to lock the bootloader with Magisk https://forum.xda-developers.com/t/...s-and-add-adb-root-and-other-changes.4440367/
This is exactly what I needed https://github.com/chenxiaolong/avbroot
I believe so anyway, still actually trying to get it to work, just need to setup android studio as far as I can make out
then you can easily patch the rom with magisk and sign it with your own keys
And this information could be useful as well https://forum.xda-developers.com/t/signing-boot-images-for-android-verified-boot-avb-v8.3600606/
FireRattus said:
to make it easier for people who may look for it (I was one of those people)
this is that script mentioned earlier which will allow you to resign the rom to allow you to lock the bootloader with Magisk https://forum.xda-developers.com/t/...s-and-add-adb-root-and-other-changes.4440367/
Click to expand...
Click to collapse
So how would this work? Would I have to unlock and wipe after every update
cammykool said:
So how would this work? Would I have to unlock and wipe after every update
Click to expand...
Click to collapse
I have been working on this when I have had time, I have been able to successfully flash Graphene with Magisk and lock the bootloader, turning what I learned into this guide https://forum.xda-developers.com/t/lock-boot-loader-magisk-root-grapheneos.4510295/
I believe there is a way to update with signed OTA files that are patched with Magisk, using AVBRoot that I use in the guide
I haven't figured this part out yet. it took me long enough just to work it out for the firmware/system rom but I will definitely be trying and updating the guide as I learn more about the process
FireRattus said:
I have been working on this when I have had time, I have been able to successfully flash Graphene with Magisk and lock the bootloader, turning what I learned into this guide https://forum.xda-developers.com/t/lock-boot-loader-magisk-root-grapheneos.4510295/
I believe there is a way to update with signed OTA files that are patched with Magisk, using AVBRoot that I use in the guide
I haven't figured this part out yet. it took me long enough just to work it out for the firmware/system rom but I will definitely be trying and updating the guide as I learn more about the process
Click to expand...
Click to collapse
That sounds extremely promising.
Since proton is obsolete now, I'm searching for a rom with sandboxed google play that I can root. Rooting GrapheneOS seems to be the only way for that.
Locking bootlaoder doesn't really matter to me, but rooting graphene and then being able to dirty flash updates later (I don't care about OTAs, even if it's cool and comfortable) is important.
How would you update graphene right now when you're rooted? Just dirty flash the new rom, then flash patched boot.img?
Spl4tt said:
That sounds extremely promising.
Since proton is obsolete now, I'm searching for a rom with sandboxed google play that I can root. Rooting GrapheneOS seems to be the only way for that.
Locking bootlaoder doesn't really matter to me, but rooting graphene and then being able to dirty flash updates later (I don't care about OTAs, even if it's cool and comfortable) is important.
How would you update graphene right now when you're rooted? Just dirty flash the new rom, then flash patched boot.img?
Click to expand...
Click to collapse
If you don't care about locking the boot loader you do lose some physical security advantages of it
but it does make the process easier, I believe you should just be able to use AVBRoot as it's intended
GitHub - chenxiaolong/avbroot: Maintain Android Verified Boot using a custom key while rooted with Magisk
Maintain Android Verified Boot using a custom key while rooted with Magisk - GitHub - chenxiaolong/avbroot: Maintain Android Verified Boot using a custom key while rooted with Magisk
github.com
Once you have completed all the initial steps then updates are as simple as
Follow step 6 in the previous section to patch the new OTA (or an existing OTA with a newer Magisk APK).
Reboot to recovery mode. If stuck at a No command screen, press the volume up button once while holding down the power button.
Sideload the patched OTA.
Reboot.
Click to expand...
Click to collapse
FireRattus said:
If you don't care about locking the boot loader you do lose some physical security advantages of it
but it does make the process easier, I believe you should just be able to use AVBRoot as it's intended
GitHub - chenxiaolong/avbroot: Maintain Android Verified Boot using a custom key while rooted with Magisk
Maintain Android Verified Boot using a custom key while rooted with Magisk - GitHub - chenxiaolong/avbroot: Maintain Android Verified Boot using a custom key while rooted with Magisk
github.com
Once you have completed all the initial steps then updates are as simple as
Click to expand...
Click to collapse
If updating is that easy with a locked bootloader I'm gonna try this. Thanks for your efforts man
Anyone know if I can I expect the same procedures to work for GOS installed on a Pixel 5 or 4?