Hello everyone,
I hopped on Twitter the other day and sent LG Mobile USA a message about AR (Anti-roll back).
They really didn't like me asking such questions.
After going back and forth with them for a better part of the day, their best argument was suggesting that they don't support rooting.
I don't believe that even having AR disabled is supporting the rooting community, well, that's what I told them. After discussing our point of views in a manner they accepted, they forwarded my request to the Research and Development team.
Maybe if we have enough people complain, they'll disable it? Although I don't know much about how the value works, I don't know if it is permanently burned into the hardware, but I asked.
Has anyone else asked, or does anyone know anything further about AR?
Before getting into how ARB works, you need to understand that LG provides the means, but it is the carriers that determine if a certain firmware version increments ARB (unless you have an unlocked phone that you bought from LG).
For example, the H910 on v10p is still ARB version 0, and the H918 is also on v10p is ARB version 1.
With that said, here is the quick and dirty on how ARB works:
Qualcomm CPUs have a section dedicated to QFPROM (Qualcomm Flashing Programmable Read Only Memory). When you write to that area of the CPU, it can never be written to again. They are called Qfuses. When they are blown, they can't be "unblown". It contains several things, the PBL (primary boot loader), the RSA key used to verify the secondary bootloader, the Qfuses that control various aspects of the phone, and a LOT of other settings.
ARB is also stored in QFRPOM. There can be 16 values 0x0 to 0xF -- so lots of room to increment.
When the phone boots, the PBL loads the SBL(XBL) and compares the ARB version number of the SBL to the version that has been blown into the CPU. If the version is less than what is stored in QFPROM, the PBL immediately goes into 9008 mode -- you have a brick (at least with the V20). If the version is equal, it loads. If the version is greater than what is currently in QFPROM, it blows the next Qfuse, and ARB is incremented, and then it loads.
The SBL is signed with an RSA cert. The PBL uses the RSA key that is in QFPROM to verify the signature of the SBL. If the SBL has been modified, or the RSA sig doesn't match, the PBL goes into 9008 mode.
Hope this helped you out. If you want to fire some anger off (trust me *I* have), shoot that anger at the carriers.
At the end of the day though, you can thank Google, and Qualcomm for this implementation. It is really quite ingenious, and without someway to inject code between the CPU and the NAND, it don't see it being defeated.
-- Brian
runningnak3d said:
Before getting into how ARB works, you need to understand that LG provides the means, but it is the carriers that determine if a certain firmware version increments ARB (unless you have an unlocked phone that you bought from LG).
For example, the H910 on v10p is still ARB version 0, and the H918 is also on v10p is ARB version 1.
With that said, here is the quick and dirty on how ARB works:
Qualcomm CPUs have a section dedicated to QFPROM (Qualcomm Flashing Programmable Read Only Memory). When you write to that area of the CPU, it can never be written to again. They are called Qfuses. When they are blown, they can't be "unblown". It contains several things, the PBL (primary boot loader), the RSA key used to verify the secondary bootloader, the Qfuses that control various aspects of the phone, and a LOT of other settings.
ARB is also stored in QFRPOM. There can be 16 values 0x0 to 0xF -- so lots of room to increment.
When the phone boots, the PBL loads the SBL(XBL) and compares the ARB version number of the SBL to the version that has been blown into the CPU. If the version is less than what is stored in QFPROM, the PBL immediately goes into 9008 mode -- you have a brick (at least with the V20). If the version is equal, it loads. If the version is greater than what is currently in QFPROM, it blows the next Qfuse, and ARB is incremented, and then it loads.
The SBL is signed with an RSA cert. The PBL uses the RSA key that is in QFPROM to verify the signature of the SBL. If the SBL has been modified, or the RSA sig doesn't match, the PBL goes into 9008 mode.
Hope this helped you out. If you want to fire some anger off (trust me *I* have), shoot that anger at the carriers.
At the end of the day though, you can thank Google, and Qualcomm for this implementation. It is really quite ingenious, and without someway to inject code between the CPU and the NAND, it don't see it being defeated.
-- Brian
Click to expand...
Click to collapse
Thank you for your overview into Anti Roll Back. As complex as this sounds, you broke it down quite nicely, so thank you for that.
I never took any updates past 10K; with never having a firmware which "blows the fuse", hypothetically, if carrier side reverses their changes for updates going forward, one would be able to skip prior firmwares of ARB1 to jump to latest without having to worry about that value making it irreversible, correct?
Example:
10k currently installed.
10*x has the hex of 0 for ARB.
I, anyone, who hasn't taken a update with ARB1, would be able hop to "10*x" while still having the ability to maneuver back to 10k.
* 'x' being defined as something in the future and not the potential update that may be labeled with 'x'.
If a carrier were to release a newer version (let's say 10s) that was ARB 0, then yes, you could skip 10p and 10q, and jump to 10a, flash it and then still be able to flash back to k, j, c, etc.
When a carrier compiles up the firmware, the ARB version is just a value that gets set in one of the source files. The main reason that they increment it is when there is a big security hole that has been patched. Unfortunately, their good intentions get in the way of us continuing to be able to root.
Once I have bought and paid for a phone though, there should be a method to disable things like roll back checks, and the RSA key check. That would be possible by sending out a KDZ that you could flash that would pop a "this phone is paid for, so the customer can do whatever the eff they want to" qfuse.
-- Brian
runningnak3d said:
snip
-- Brian
Click to expand...
Click to collapse
Wow! Thank you for breaking that down for people that aren't so technical. Actually understood what you were saying because you relayed your message very clear.
Sent from my LG V20 using XDA Labs
Amazing, just a master piece of knowledge. Thanks for this, really useful!
runningnak3d said:
Before getting into how ARB works, you need to understand that LG provides the means, but it is the carriers that determine if a certain firmware version increments ARB (unless you have an unlocked phone that you bought from LG).
For example, the H910 on v10p is still ARB version 0, and the H918 is also on v10p is ARB version 1.
With that said, here is the quick and dirty on how ARB works:
Qualcomm CPUs have a section dedicated to QFPROM (Qualcomm Flashing Programmable Read Only Memory). When you write to that area of the CPU, it can never be written to again. They are called Qfuses. When they are blown, they can't be "unblown". It contains several things, the PBL (primary boot loader), the RSA key used to verify the secondary bootloader, the Qfuses that control various aspects of the phone, and a LOT of other settings.
ARB is also stored in QFRPOM. There can be 16 values 0x0 to 0xF -- so lots of room to increment.
When the phone boots, the PBL loads the SBL(XBL) and compares the ARB version number of the SBL to the version that has been blown into the CPU. If the version is less than what is stored in QFPROM, the PBL immediately goes into 9008 mode -- you have a brick (at least with the V20). If the version is equal, it loads. If the version is greater than what is currently in QFPROM, it blows the next Qfuse, and ARB is incremented, and then it loads.
The SBL is signed with an RSA cert. The PBL uses the RSA key that is in QFPROM to verify the signature of the SBL. If the SBL has been modified, or the RSA sig doesn't match, the PBL goes into 9008 mode.
Hope this helped you out. If you want to fire some anger off (trust me *I* have), shoot that anger at the carriers.
At the end of the day though, you can thank Google, and Qualcomm for this implementation. It is really quite ingenious, and without someway to inject code between the CPU and the NAND, it don't see it being defeated.
-- Brian
Click to expand...
Click to collapse
Are you Neil Degrasse Tyson???? Because you broke it down so we'll to understand in laymen's terms that you left me so enlightened that my third eye opened and I can move on to the 11th dimension.
Even tho this is for older Motorola phones like Atrix, Razr, etc this is a really complementary insight about the Qfuse.
http://blog.azimuthsecurity.com/2013/04/unlocking-motorola-bootloader.html?m=1
Thanks to runningnak3d once again!
Related
I know that the Verizon bootloader is almost impenetrable as is, but would it be plausible to completely go over the head of the firmware and directly write an image with JTAG that would allow for custom software? If so, would it be possible to use the firmware from another carrier like USC or would it have to be a custom image?
EDIT: summary of the method and everything I have thusfar discovered
So, this method after a bit of evolution, got to the point it basically entailed the following: Using the SD Card debrick method (popularized by the galaxy s3 LTE variants) a modified firmware image would be written to an SD Card, and the phone would boot from that image. The main problem I ran into: it would not let me flash anything that could brick the phone, nor was I able to pull the usb cord at the right moment and try and manually brick it. I was able to flash firmware and stock tars from other variants of the phone (such as the one that runs on T-mobile), but what I found out through that is a couple things:
1. The stock tars seem mostly carrier independent, and I was without any modification able to flash a T-mobile bootloader, system image, and pit file, but within recovery and download mode it would show that because of integrated CSC, it would still change back to the original variant. This could have implications for a very simple method of removing bloat from the phone, but I'm not so sure
2. It must have a very low level method of injecting information and file verification that is not located anywhere on eMMC
The latter led me to research a TON, eventually finding that the most likely culprit is the use of Qualcomm Qfuses, non-volatile pre-set memory located directly on the SoC, to check how the bootloader is signed. They consist of a couple blocks of registers, and definitely aren't readily writable. The trusted base of the entire secure system, the same system that KNOX invokes on other systems, is within a series of Qfuses. From what I have deduced, however, they must be at some software level writable, as although the Knox counter is an e-fuse, the others (such as the warrantee bit) have been both changed upon their void and reverted when brought back to a service center. This must mean that the entire block is possible to modify in both directions, unlike a fuse or breaker; It seems to act more like flash memory than a "fuse." This is very good, mainly because if the service center can change it it means that jtag has not been disabled by those flags, and is enabled in at least some form. What this also means is that without another MAJOR exploit within unfortunately simple, clean code or a leak of several RSA keys from verizon, either current workarounds such as safestrap are the answer for the foreseeable future, or a method of manually changing a simgle Qfuse (the one that controls the "Qualcomm Secureboot" flag) could be used.
What I'm hopefully going to start at some point here is research into finding a way of accessing and changing that Qfuse via JTAG. I have no money for a JTAG box at the moment, so it'll have to wait, but if anyone who already has one wants to use it, hopefully this info helps
P.S. I figured out exactly what T-flash does in odin: it flashes the files that you input into odin to the currently inserted SD Card (or so it seems, I could be wrong but that's what it did for me)
P.P.S. Verizon, I respectfully request that...oh never mind, profanity is definitely frowned upon here
Also, I'm in ongoing discussion with the FCC as to block C violations by Verizon of aspects of the regulations that upon research have not really been argued to any substantial extent, so if that comes to fruition hopefully there'll be simple ODIN flashable patches for this stuff :fingers-crossed:
UPON REFLECTION: if the phone could be bricked, either by very subtly corrupted file or by interrupting a flash at the right moment, then could the debrick image from a tmobile galaxy s5 with an unlocked bootloader be used as not a method of flashing the on-board bootloader but as a kind of external boot, so a permenantly installed SD Card that would be permissive of modified kernels and such but still accepted as a boot device by the phone?
I was wondering something similar. It would be interesting to see if we could do something similar to what we did for the droid x.
tr4nqui1i7y said:
I was wondering something similar. It would be interesting to see if we could do something similar to what we did for the droid x.
Click to expand...
Click to collapse
what was done with the droix x? Did they use a direct JTAG patch?
I just realized something. From reading here: http://forum.gsmhosting.com/vbb/f200/how-fix-samsung-galaxy-s5-sm-g900f-dead-boot-1813266/
It seems to show that the S5 has a "alternative boot upon init fault" method similar to that that allows the galaxy s3 debrick to work (I have a guide I made with details) so would it be possible to somehow corrupt a very important part of the bootloader in an official update (would one or two bits still mess with the signature?), apply that, and have an insecure bootloader on a microsd card in the phone allowing it to boot into that, then use that with odin to flash an insecure bootloader to the s5 itself?
Now I have to ask an interesting question somewhere (since he: http://forum.xda-developers.com/verizon-galaxy-s5/help/g900v-hard-brick-t2914847 seems to have done it): "guys how do I brick my sm-g900v?"
They hijacked the boot init by basically using an alternate boot. It was essentially telling the phone to use a different boot method.
Check out koushs bootstrapper for the droid x and droid 2
Koush, birdman, and apex were the three that I remember the most from the beginning. When I remember who got root first, I'll post here. That or I'll try to get in touch with them.
tr4nqui1i7y said:
They hijacked the boot init by basically using an alternate boot. It was essentially telling the phone to use a different boot method.
Check out koushs bootstrapper for the droid x and droid 2
Koush, birdman, and apex were the three that I remember the most from the beginning. When I remember who got root first, I'll post here. That or I'll try to get in touch with them.
Click to expand...
Click to collapse
I think it might actually be easier
So long as a couple conditions are met for it:
1. The bootloader alone determines if an image is "signed" or not (like when flashed in odin)
2. The same UnBrick exploit from the S3 LTE variants works in some form (secondary storage, fault-triggered boot)
3. It is possible to get it to load a modified bootloader from that secondary boot (this is why number 1 is important)
4. KNOX is completely firmware based, and doesn't have any chip based verification
5. I or someone else actually knows how to modify the bootloader such that it will allow unsigned images (even if not removing it all together, then changing the key to one they publicize so people can sign their rom with it)
If all of these are met, then we might actually have free root! Basically all it would involve would be bricking the device badly enough it boots from secondary storage, have that secondary boot have a "back door" that allows a custom image to be flashed, that allows a bootloader image to be flashed that allows for a signed recovery (signed with that publicly available code) to be flashed without having to deal with safestrap or anything like that. Just full root like on any other phone. Anyone want to offer an opinion? Will this work? I would love to try this out, though I'm a bit unwilling to offer my s5 as a sacrifice just yet as I don't have a JTAG unit on site. I know the bounty is probs gone but I'm ok just getting my bootloader unlocked an' $#*+
The bootloader doesn't need to be bricked, it just needs to be bypassed. If we can find the magic words then we'll be golden.
I'm researching tonight. I'll try tests, hopefully tomorrow. Not sure when I'll be able to have the tone for sure.
An unlock isn't likely. A bypass should be possible though.
Bypassed in what way? I understand the thing with safestrap and such, but that doesn't allow custom kernels or anything, so just modified tw roms which is kinda limiting
tr4nqui1i7y said:
The bootloader doesn't need to be bricked, it just needs to be bypassed. If we can find the magic words then we'll be golden.
I'm researching tonight. I'll try tests, hopefully tomorrow. Not sure when I'll be able to have the tone for sure.
An unlock isn't likely. A bypass should be possible though.
Click to expand...
Click to collapse
Have you found anything yet?
dreamwave said:
Bypassed in what way? I understand the thing with safestrap and such, but that doesn't allow custom kernels or anything, so just modified tw roms which is kinda limiting
Click to expand...
Click to collapse
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.
tr4nqui1i7y said:
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.
Click to expand...
Click to collapse
safestrap uses root access in a stock rom to create a temporary recovery image that lasts for one boot, but it can be finicky and no way to boot into it if you can't access the rom
dreamwave said:
safestrap uses root access in a stock rom to create a temporary recovery image that lasts for one boot, but it can be finicky and no way to boot into it if you can't access the rom
Click to expand...
Click to collapse
The Droid X bootstrap was used with the same intent. It didn't allow custom kernels either. It didn't allow pure aosp ROMs because of that. It modified a boot file to boot to the custom ROM, rather than the actual ROM. It wasn't a recovery or anything like that. It was in app form and only needed to be applied manually the initial time. Unless you wanted to switch/update your custom ROM.
I'm wondering if safestrap, in conjunction with the oe1 rooted build, the oe1 tar, and the boot vulnerability could lead to a method that would allow a one time "downgrade".
Something along the lines of applying a pre-rooted tar, leaving the phone in a bricked state since the bootloader can't be downgraded, adb pushing safestrap files into place, thus modifying the bootloader to get passed the bricked state, allowing it to boot into the rooted tar that was applied or even booting into a ROM possibly.
^ Is all an uneducated guess. I haven't done enough research to know how viable of an option that would be.
tr4nqui1i7y said:
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.
Click to expand...
Click to collapse
that's why I'm hoping the debrick image method will work
tr4nqui1i7y said:
The Droid X bootstrap was used with the same intent. It didn't allow custom kernels either. It didn't allow pure aosp ROMs because of that. It modified a boot file to boot to the custom ROM, rather than the actual ROM. It wasn't a recovery or anything like that. It was in app form and only needed to be applied manually the initial time. Unless you wanted to switch/update your custom ROM.
I'm wondering if safestrap, in conjunction with the oe1 rooted build, the oe1 tar, and the boot vulnerability could lead to a method that would allow a one time "downgrade".
Something along the lines of applying a pre-rooted tar, leaving the phone in a bricked state since the bootloader can't be downgraded, adb pushing safestrap files into place, thus modifying the bootloader to get passed the bricked state, allowing it to boot into the rooted tar that was applied or even booting into a ROM possibly.
^ Is all an uneducated guess. I haven't done enough research to know how viable of an option that would be.
Click to expand...
Click to collapse
so far I've been able to downgrade just fine. Don't do anything with knox and it seems odin can flash back to the original Kitkat rom. Also, safestrap didn't do a thing with the bootloader, it was done during kernel init, right after firmware finishes. If a phone is hard bricked then adb won't work, and what I'm getting at is hard bricking it then using the debrick image thing
dreamwave said:
so far I've been able to downgrade just fine. Don't do anything with knox and it seems odin can flash back to the original Kitkat rom
Click to expand...
Click to collapse
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Hm, I'd be really interested in finding a way to get the downgrade to work properly for users that updated. Perhaps packaging the safestrap into a rooted tar. I'm not sure. There has got to be a possibility. We've got all the pieces, we just need to put them together.
When you say you want to hard brick then debrick... Are you thinking that the bootloader might be ignored when it is in a broken state, allowing an older image to be written?
tr4nqui1i7y said:
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Click to expand...
Click to collapse
I don't know, I got it to go back to when root was still possible to get via an app. I don't see why there's a need to downgrade the bootloader if the debrick image thing works
tr4nqui1i7y said:
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Hm, I'd be really interested in finding a way to get the downgrade to work properly for users that updated. Perhaps packaging the safestrap into a rooted tar. I'm not sure. There has got to be a possibility. We've got all the pieces, we just need to put them together.
When you say you want to hard brick then debrick... Are you thinking that the bootloader might be ignored when it is in a broken state, allowing an older image to be written?
Click to expand...
Click to collapse
Exactly. Safestrap is basically useless for flashing bootloader and stuff as it has no firmware involvement. If the bootloader is the part that determines whether or not it's being upgraded or downgraded then if this works it could be downgraded. If they have a hardware counter that determines it, then a modified new bootloader could be flashed probably but not a previous version.
dreamwave said:
Exactly. Safestrap is basically useless for flashing bootloader and stuff as it has no firmware involvement. If the bootloader is the part that determines whether or not it's being upgraded or downgraded then if this works it could be downgraded. If they have a hardware counter that determines it, then a modified new bootloader could be flashed probably but not a previous version.
Click to expand...
Click to collapse
I am not concerned with fllashing a bootloader. I am only trying to find a way to sneak the old exploit into the updated system via an old flaw.
Old System - Check
Root for old system - Check
init tweak - Check
New bootloader - Check
New system - Check
Rooted new system - Check
Old bootloader vulnerability - Check
New bootloader vuln - Missing
This means we either need to find a way to downgrade again, or find a root method for the new system.
What I am interested in is utilizing the init hack to spoof the old bootloader and allow for the new rooted system to boot for users who have taken updates past OE1.
tr4nqui1i7y said:
I am not concerned with fllashing a bootloader. I am only trying to find a way to sneak the old exploit into the updated system via an old flaw.
Old System - Check
Root for old system - Check
init tweak - Check
New bootloader - Check
New system - Check
Rooted new system - Check
Old bootloader vulnerability - Check
New bootloader vuln - Missing
This means we either need to find a way to downgrade again, or find a root method for the new system.
What I am interested in is utilizing the init hack to spoof the old bootloader and allow for the new rooted system to boot for users who have taken updates past OE1.
Click to expand...
Click to collapse
but that has already been done I think, root on a system with any bootloader so long as a root exploit exists for the OS
That's safestrap. It doesn't allow custom kernels or a full custom recovery though, that's why I'm trying to modify the bootloader
I found this post on a blog about a vulnerability with the Qualcomm boot. I can't even begin to explain it but could this help us find a way to root?
LINK: https://bits-please.blogspot.com/20...howComment=1462371232579#c7966216604060424834
Fredo2000 said:
I found this post on a blog about a vulnerability with the Qualcomm boot. I can't even begin to explain it but could this help us find a way to root?
LINK: https://bits-please.blogspot.com/20...howComment=1462371232579#c7966216604060424834
Click to expand...
Click to collapse
This is a trustzone vulnerability that requires root to exploit it. No way to gain root through it
jcase said:
This is a trustzone vulnerability that requires root to exploit it. No way to gain root through it
Click to expand...
Click to collapse
Ah damn. Thanks for letting me know anyways
Not so - this vulnerability requires "mediaserver" permissions to execute and can be used to achieve root (see latest blog post).
Also, I'm releasing another exploit which allows escalation from zero permissions to "mediaserver" which works on all Android versions and phones.
Wow that's an impressive exploit. Congrats for finding it and explaining it in your write up. Have you been able to use it on an unrooted device like ours to gain root? What about the S7 edge that is chained down at the moment? Sounds like you might have an opportunity to cash in on the large bounties for both devices! Once again great work!!
Sent from my LG-H830 using XDA-Developers mobile app
Thanks. I've used the exploit to gain kernel code execution (better than root, since you can disable SELinux, etc.). The QSEE payload I provided should work as-in, since it's symbol-less (finds all the symbols directly in memory). As for the QSEE exploit; you'll need to change the symbols (under symbols.h) to match the Widevine application on your phone. As for the S7 edge - I know nothing about it (have never checked), but I can take a look in a couple of days when I'm at home.
How long did it take to discover and work on this exploit? I'm just a lay person that likes to root phones but I imagine this takes a ton of time to work on. I hope you submit your work and publish a root method and cash in on ~$5000 worth of bounties for all your hard work. And I hope Google implements your fixes soon to patch the holes you have discovered.
Sent from my LG-H830 using XDA-Developers mobile app
laginimaineb said:
Thanks. I've used the exploit to gain kernel code execution (better than root, since you can disable SELinux, etc.). The QSEE payload I provided should work as-in, since it's symbol-less (finds all the symbols directly in memory). As for the QSEE exploit; you'll need to change the symbols (under symbols.h) to match the Widevine application on your phone. As for the S7 edge - I know nothing about it (have never checked), but I can take a look in a couple of days when I'm at home.
Click to expand...
Click to collapse
Wow... This is all some seriously great stuff! If you have some time I would love to talk with you about how to get this working on the Sprint G5
laginimaineb said:
Thanks. I've used the exploit to gain kernel code execution (better than root, since you can disable SELinux, etc.). The QSEE payload I provided should work as-in, since it's symbol-less (finds all the symbols directly in memory). As for the QSEE exploit; you'll need to change the symbols (under symbols.h) to match the Widevine application on your phone. As for the S7 edge - I know nothing about it (have never checked), but I can take a look in a couple of days when I'm at home.
Click to expand...
Click to collapse
If you can modify the kernel, can you disable dm-verity?
If so, I think you might have just found root for our device...
I suggest that you first check if the G5 is even vulnerable to the QSEE vulnerability I disclosed... (extract the "system_" files from the KDZ and the DZ and search for the string "PRDiag"). Since I disclosed the vulnerability a few months ago, it could be patched on the latest version, but might still be vulnerable on previous ones.
Also, as for dm-verity - the QSEE exploit allows full system memory RW (which allows you to patch a running kernel and basically inject arbitrary code). But (!) you probably want to disable dm-verity at boot, which would require a bootloader unlock.
...Which brings me to my last point - If the LG G5 is vulnerable to the QSEE exploit I disclosed, I'm also releasing a QSEE to TZBSP (TrustZone kernel) exploit, which means you can blow any QFuse you like (which is the standard way to disable secure boot).
laginimaineb said:
I suggest that you first check if the G5 is even vulnerable to the QSEE vulnerability I disclosed... (extract the "system_" files from the KDZ and the DZ and search for the string "PRDiag"). Since I disclosed the vulnerability a few months ago, it could be patched on the latest version, but might still be vulnerable on previous ones.
Also, as for dm-verity - the QSEE exploit allows full system memory RW (which allows you to patch a running kernel and basically inject arbitrary code). But (!) you probably want to disable dm-verity at boot, which would require a bootloader unlock.
...Which brings me to my last point - If the LG G5 is vulnerable to the QSEE exploit I disclosed, I'm also releasing a QSEE to TZBSP (TrustZone kernel) exploit, which means you can blow any QFuse you like (which is the standard way to disable secure boot).
Click to expand...
Click to collapse
My god... you are the MAN!!! I'll check for the files ASAP (currently doing mother's day stuff) and report back.
Also, how can I donate to you?
jcase said:
This is a trustzone vulnerability that requires root to exploit it. No way to gain root through it
Click to expand...
Click to collapse
so you are wrong then? this CAN be used to get root?
laginimaineb said:
Not so - this vulnerability requires "mediaserver" permissions to execute and can be used to achieve root (see latest blog post).
Also, I'm releasing another exploit which allows escalation from zero permissions to "mediaserver" which works on all Android versions and phones.
Click to expand...
Click to collapse
Correct, bad wording on my part. However on this phone it really makes no difference, it is actually easier to gain execution as root than it is on mediaserver. This phone is /BAD/ as far as security is concerned. Multiple bootchain backdoors, beyond broke backup system, known kernel vulns left unpatched, heavily (and poorly) modified stagefright as well. We already have root on the phone, root was never the issue, issue was code signing (which was being worked on until someone shared my root knowing i didnt want it shared). LG is enforcing signature validation and dm-verity on this device, just a heads up.
If you release anything compatible with this phone, make sure the users know not to alter laf/recovery/boot/system. They will anyways, and blame you, but at least you warn them.
I sold my G5 after the drama here, so I am no longer working on it.
Syndicate0315 said:
so you are wrong then? this CAN be used to get root?
Click to expand...
Click to collapse
I was technically be wrong, but really makes little difference if the starting point is media server or root. It is honestly easier to get exec as root on this phone than media server. I have already demonstrated that root is not an issue on this device, issue is code signing. This vulnerability does not give you what you guys want, similar to the one of mine that everyone is passing around and emailing me daily about after I put in the read me that it will not do what you want. No one listens.
laginimaineb said:
I suggest that you first check if the G5 is even vulnerable to the QSEE vulnerability I disclosed... (extract the "system_" files from the KDZ and the DZ and search for the string "PRDiag"). Since I disclosed the vulnerability a few months ago, it could be patched on the latest version, but might still be vulnerable on previous ones.
Also, as for dm-verity - the QSEE exploit allows full system memory RW (which allows you to patch a running kernel and basically inject arbitrary code). But (!) you probably want to disable dm-verity at boot, which would require a bootloader unlock.
...Which brings me to my last point - If the LG G5 is vulnerable to the QSEE exploit I disclosed, I'm also releasing a QSEE to TZBSP (TrustZone kernel) exploit, which means you can blow any QFuse you like (which is the standard way to disable secure boot).
Click to expand...
Click to collapse
Blowing fuses is the standard way of enabling secure boot, not disabling. These phones already have that fuse blown. The more recent LG phones have used a signed blob to "unlock" (as far as the ones I've looked at), they are not following the motorola method of blowing a fuse.
The TMobile LG G5 is actually unlocked, all these guys need to do is pack twrp into a TOT (pretty much a raw image with a header) and flash it in download mode.
Fredo2000 said:
If you can modify the kernel, can you disable dm-verity?
If so, I think you might have just found root for our device...
Click to expand...
Click to collapse
He can modify the kernel at run time with this exploit, but not the binary image of it, nor the ram disk that has the settings to enforce dm-verity. It would still need an exploit to get exec in the proper user/context as well as a codesigning exploit
jcase said:
Correct, bad wording on my part. However on this phone it really makes no difference, it is actually easier to gain execution as root than it is on mediaserver. This phone is /BAD/ as far as security is concerned. Multiple bootchain backdoors, beyond broke backup system, known kernel vulns left unpatched, heavily (and poorly) modified stagefright as well. We already have root on the phone, root was never the issue, issue was code signing (which was being worked on until someone shared my root knowing i didnt want it shared). LG is enforcing signature validation and dm-verity on this device, just a heads up.
If you release anything compatible with this phone, make sure the users know not to alter laf/recovery/boot/system. They will anyways, and blame you, but at least you warn them.
I sold my G5 after the drama here, so I am no longer working on it.
I was technically be wrong, but really makes little difference if the starting point is media server or root. It is honestly easier to get exec as root on this phone than media server. I have already demonstrated that root is not an issue on this device, issue is code signing. This vulnerability does not give you what you guys want, similar to the one of mine that everyone is passing around and emailing me daily about.
Click to expand...
Click to collapse
sorry if this is me just being ignorant, but if we gain root on a device with an unlocked bootloader (t mobile), can't we flash root from an app on the phone, boot into recovery, and then flash the disable-dm-verity zip provided on the other thread?
And also, how is gaining root not a problem? Is it through the LAF backdoor?
Syndicate0315 said:
sorry if this is me just being ignorant, but if we gain root on a device with an unlocked bootloader (t mobile), can't we flash root from an app on the phone, boot into recovery, and then flash the disable-dm-verity zip provided on the other thread?
And also, how is gaining root not a problem? Is it through the LAF backdoor?
Click to expand...
Click to collapse
Pack TWRP in tot, flash in download mode. I've said this since day one, you dont need an exploit to root the tmobile variant. Writing an exploit for tmobile lg g5 is a waste of time and resources. Pack TWRP in TOT, flash tot, be done.
Root isn't a problem because the device has multiple publicly known vulnerabilities (and at least one written exploit) that work on it.
jcase said:
Pack TWRP in tot, flash in download mode. I've said this since day one, you dont need an exploit to root the tmobile variant. Writing an exploit for tmobile lg g5 is a waste of time and resources. Pack TWRP in TOT, flash tot, be done.
Root isn't a problem because the device has multiple publicly known vulnerabilities (and at least one written exploit) that work on it.
Click to expand...
Click to collapse
ahhhh OK that makes MUCH sense...
i have the Sprint variant, what would be the best way for me to go about finding a permanent root? would any of these methods work?
Syndicate0315 said:
ahhhh OK that makes MUCH sense...
i have the Sprint variant, what would be the best way for me to go about finding a permanent root? would any of these methods work?
Click to expand...
Click to collapse
Dig through the bootchain, looking for a vulnerability you can use to bypass the secureboot (or otherwise bypass signing requirement of boot.img), or look at LG's code in regards to unlock, i wouldnt be surprised if a route existed there, LG is notoriously bad at "security" features.
jcase said:
Pack TWRP in tot, flash in download mode. I've said this since day one, you dont need an exploit to root the tmobile variant. Writing an exploit for tmobile lg g5 is a waste of time and resources. Pack TWRP in TOT, flash tot, be done.
Root isn't a problem because the device has multiple publicly known vulnerabilities (and at least one written exploit) that work on it.
Click to expand...
Click to collapse
hate to see you've sold your G5. unfortunately, there is no tot for h830. however, sprint has one. I am unsure as to how one can create a tot.
So I've had my S7 Edge for about a month now. Great stuff it is, but I honestly do find it a bit lacking compared to my S6 Edge. You can tell the difference between the Exynos7420 and MSM8996 right away with its responsiveness.
But I've updated my vzw S7 to the G935UUEU4BQD2 Nougat firmware. And I've used the ENG Kernel posted by @jrkruse to root my device no problems at all. Although I've figured out a few tweaks that should be added to your Rooting Batch Scripts. These tweaks include which packages to disable in order to prevent random reboots with the ENG Kernel, and CSC tweaks to fix the UI.
I have some questions & observations I'd really appreciate clarification on though, before I get to work on making some real mods.
****
1.) It is very interesting that my device is/was an SM-G935V, but I've flashed the full G935U firmware and the AT&T ENG Nougat Kernel using ODIN 3.12.5 without a hitch.
1A.) The "ENG-ROOT-USA.zip" for S7e Nougat, is an ENG build of Our Stock Kernel/RAMDisk with this in its "default.prop":
Code:
*#
# BOOTIMAGE_BUILD_PROPERTIES
#
ro.bootimage.build.date=Tue Jan 31 15:03:01 KST 2017
ro.bootimage.build.date.utc=1485842581
ro.bootimage.build.fingerprint=samsung/hero2qlteuc/hero2qlteatt:7.0/NRD90M/G935AUCE4BQA6:eng/test-keys
Do those boot.img properties really say our ENG Kernel is actually just signed with the Android 7.0 Test Keys? Aren't those supposed to be publicly available? Can't we then use them with the aosp signbootimg utility? Carliv's image kitchen says that the ENG Kernel uses an aosp format ramdisk.
I mean, That means our G935V and/or the G935U firmware will accept firmware from any of the carriers. So why couldn't we flash the Canadian W8 Bootloader overtop of the U firmware?* Or is there something I'm missing there?
3.) I've always thought that AT&T and Verizon firmware don't mix. But the G935U Modem carries all the U.S. bands already. Technically my AP is that of Sprint. But my kernel/boot.img is that of AT&T. And my device is originally that of Verizon.
So I ask good sirs & madams, what gives?
4.) I bring up point number 3 because I couldn't Willy Nilly just flash firmware cross carrier on my AT&T Note 5 or My Verizon S6 Edge. So apparently there IS an Obvious difference between the G925 and G935 device platforms in the United States. Then again, I've been without a carrier contract/plan since December. I've only used my devices as Wi-Fi Devices for months and haven't had to worry about GSM/CDMA network services since then. If my device boots, it boots. Go me!
I prefer to have the hardware rooted anyways. It saves me from going and buying a whole laptop for the same price as my mobile phone, when the two sets of hardware are comparable in most ways.
5.) My CSC code is XAS regardless if I flash the HOME CSC or the OYM CSC. I think because I don't have a SIM Card present in the device. When I try to update through Samsung SmartSwitch PC, is tries to download and install the firmware updates for the XAS CSC.
Delgoth said:
So I've had my S7 Edge for about a month now. Great stuff it is, but I honestly do find it a bit lacking compared to my S6 Edge. You can tell the difference between the Exynos7420 and MSM8996 right away with its responsiveness.
But I've updated my vzw S7 to the G935UUEU4BQD2 Nougat firmware. And I've used the ENG Kernel posted by @jrkruse to root my device no problems at all. Although I've figured out a few tweaks that should be added to your Rooting Batch Scripts. These tweaks include which packages to disable in order to prevent random reboots with the ENG Kernel, and CSC tweaks to fix the UI.
I have some questions & observations I'd really appreciate clarification on though, before I get to work on making some real mods.
****
1.) It is very interesting that my device is/was an SM-G935V, but I've flashed the full G935U firmware and the AT&T ENG Nougat Kernel using ODIN 3.12.5 without a hitch.
1A.) The "ENG-ROOT-USA.zip" for S7e Nougat, is an ENG build of Our Stock Kernel/RAMDisk with this in its "default.prop":
Code:
*#
# BOOTIMAGE_BUILD_PROPERTIES
#
ro.bootimage.build.date=Tue Jan 31 15:03:01 KST 2017
ro.bootimage.build.date.utc=1485842581
ro.bootimage.build.fingerprint=samsung/hero2qlteuc/hero2qlteatt:7.0/NRD90M/G935AUCE4BQA6:eng/test-keys
Do those boot.img properties really say our ENG Kernel is actually just signed with the Android 7.0 Test Keys? Aren't those supposed to be publicly available? Can't we then use them with the aosp signbootimg utility? Carliv's image kitchen says that the ENG Kernel uses an aosp format ramdisk.
I mean, That means our G935V and/or the G935U firmware will accept firmware from any of the carriers. So why couldn't we flash the Canadian W8 Bootloader overtop of the U firmware?* Or is there something I'm missing there?
3.) I've always thought that AT&T and Verizon firmware don't mix. But the G935U Modem carries all the U.S. bands already. Technically my AP is that of Sprint. But my kernel/boot.img is that of AT&T. And my device is originally that of Verizon.
So I ask good sirs & madams, what gives?
4.) I bring up point number 3 because I couldn't Willy Nilly just flash firmware cross carrier on my AT&T Note 5 or My Verizon S6 Edge. So apparently there IS an Obvious difference between the G925 and G935 device platforms in the United States. Then again, I've been without a carrier contract/plan since December. I've only used my devices as Wi-Fi Devices for months and haven't had to worry about GSM/CDMA network services since then. If my device boots, it boots. Go me!
I prefer to have the hardware rooted anyways. It saves me from going and buying a whole laptop for the same price as my mobile phone, when the two sets of hardware are comparable in most ways.
5.) My CSC code is XAS regardless if I flash the HOME CSC or the OYM CSC. I think because I don't have a SIM Card present in the device. When I try to update through Samsung SmartSwitch PC, is tries to download and install the firmware updates for the XAS CSC.
Click to expand...
Click to collapse
To answer your first question. You didnt look hard enough at the build properties of the engboot.img. If you notice adb secure=0 this means adb is insecure meaning we can mount the system and data partitions which allows us too push files.
Why do we use an ATT engboot.img? Because its all we have
To answer your other question, you can flash any carrier firmware on your S7 as all carrier phones are the same other than them being carrier locked which verizon is not.
Your csc on Ufirm will not change until a carrier sim is inserted. Thats the only way it knows what csc to install the default csc is XAS so with no sim thats what you get. If you want different on flash csc file only from the carriers firmware you want your csc to be
My real question about the ENG Kernel was if it is actually signed with the Google test keys for the Android 7.0 platform or not. Or are those private AT&T only test keys?
Because if it is signed with Google's keys and the device accepts it, doesn't that mean we can sign kernels with the same keys and get it to flash.
I understand why we are able to have ADB Root.
Delgoth said:
My real question about the ENG Kernel was if it is actually signed with the Google test keys for the Android 7.0 platform or not. Or are those private AT&T only test keys?
Because if it is signed with Google's keys and the device accepts it, doesn't that mean we can sign kernels with the same keys and get it to flash.
I understand why we are able to have ADB Root.
Click to expand...
Click to collapse
It's a Samsung signature not Google. If you can figure out how to sign a custom kernel with a Samsung signature then you would probably be a pretty popular guy
Well I was able to find what I believe to be the Verizon Test Keys for 6.0.1 (the .pem & .pk8) back around new years. But I honestly forget what all I can do with those files. I know MM doesn't help for the N firmware. But it's a start. I've been trying to read up on the related topics, but I won't have internet for a couple more weeks.
Do any of the S7 Edge variants have the Maintenance boot mode present in the G925V?
It may be possible to customize the AOSP 'signbootimg' utility in the same ways people like @osm0sis or Cyanogen modify the AOSP 'mkbootimg' & 'unpackbootimg' utilities to help. I mean Samsung must have already done the same thing.
Delgoth said:
Well I was able to find what I believe to be the Verizon Test Keys for 6.0.1 (the .pem & .pk8) back around new years. But I honestly forget what all I can do with those files. I know MM doesn't help for the N firmware. But it's a start. I've been trying to read up on the related topics, but I won't have internet for a couple more weeks.
Do any of the S7 Edge variants have the Maintenance boot mode present in the G925V?
It may be possible to customize the AOSP 'signbootimg' utility in the same ways people like @osm0sis or Cyanogen modify the AOSP 'mkbootimg' & 'unpackbootimg' utilities to help. I mean Samsung must have already done the same thing.
Click to expand...
Click to collapse
There is no "signbootimg" that I know of, only recently with BootSignature.jar for the May Pixel bootloader, and Xiaomi has been using it as well. There's also a newer avbtool from Brillo AOSP but we're not seeing that one in the wild yet.
Other than that there are a few reverse-engineered signing methods like Bump and SignBlob, but as far as I know all Samsung has really had going on is that SEANDROIDENFORCE string to avoid the bootloader message.
osm0sis said:
There is no "signbootimg" that I know of, only recently with BootSignature.jar for the May Pixel bootloader, and Xiaomi has been using it as well. There's also a newer avbtool from Brillo AOSP but we're not seeing that one in the wild yet.
Other than that there are a few reverse-engineered signing methods like Bump and SignBlob, but as far as I know all Samsung has really had going on is that SEANDROIDENFORCE string to avoid the bootloader message.
Click to expand...
Click to collapse
Well then I'm going to have to go back through some bookmarks, in order to find out where I read that. Because AT one point I read an article about how to use the utility to sign a boot.img using the .pem and .pk8 files.
Delgoth said:
Well then I'm going to have to go back through some bookmarks, in order to find out where I read that. Because AT one point I read an article about how to use the utility to sign a boot.img using the .pem and .pk8 files.
Click to expand...
Click to collapse
You must be thinking about kernel flashing zips? SignApk.jar uses .pk8 and .x509.pem to sign flashable zips and APKs. That's what vendors use for OTA zips.
Google's stock recoveries are always locked to their corporate keys, but often other OEMs' stock recoveries will accept the standard testkeys, which is why Chainfire signs SuperSU's zip with them.
osm0sis said:
You must be thinking about kernel flashing zips? SignApk.jar uses .pk8 and .x509.pem to sign flashable zips and APKs. That's what vendors use for OTA zips.
Google's stock recoveries are always locked to their corporate keys, but often other OEMs' stock recoveries will accept the standard testkeys, which is why Chainfire signs SuperSU's zip with them.
Click to expand...
Click to collapse
A boot.img is the Kernel right? Isn't that why when you unpack the boot.img you get the kernel ram disk and the initial kernel addresses.
So I would say you are correct, that I am talking about signing a kernel zip in a way.
In chainfire's thread about Android Verified Boot, he talks about what I'm talking about I believe.
Our S7 Edge has a keystore.mbn file which Is new to me as is the Snapdragon. But it's also said that the recovery.img houses the otacerts the device/dm-verity uses to authenticate.
In the case of locked bootloader devices, they don't use standard Google keys, but they use their own private carrier keys. As well as Samsung Factory Keys, which is why Combination Firmware files can be flashed on a locked BL no problem.
But unless they've come up with an entirely closed source addition to Android, I would venture to say Samsung spent some time customizing AVB/SecureBoot & bootimg.h the same way they did to The ART runtime to change the signature structure. More so than trying to reinvent the wheel that stock aosp provides.
I know I say that like it's simpler than it really is. But I still feel like there is a way. What seems impossible now, I don't forsee being as big of a problem in the nearish future.
Please supply a boot.img and I'll tell you if it's AVB or something else. A number of vendors have their own closed signing methods, unfortunately.
Edit: I found the engineering kernels you mentioned from @jrkruse's thread. Definitely not AVB. Definitely something proprietary. Kind of like the Samsung/Marvell pxa1088 board signatures described here (specifically the Xcover 3), except those weren't being enforced.
I'm at work right now. I'll give them a closer look when I'm home, but if just re-appending the signature doesn't work then you're likely out of luck.
osm0sis said:
Please supply a boot.img and I'll tell you if it's AVB or something else. A number of vendors have their own closed signing methods, unfortunately.
Edit: I found the engineering kernels you mentioned from @jrkruse's thread. Definitely not AVB. Definitely something proprietary. Kind of like the Samsung/Marvell pxa1088 board signatures described here (specifically the Xcover 3), except those weren't being enforced.
I'm at work right now. I'll give them a closer look when I'm home, but if just re-appending the signature doesn't work then you're likely out of luck.
Click to expand...
Click to collapse
Cool beans! I looked over that first post, and it may actually help me do what I was thinking. The header format they list for those devices looks pretty similar to how the PIT file repartitions the Emmc with ODIN. So with tools like gdisk and the like, I feel it shouldn't be too hard to put 2 and 2 together.
Gotta read that thread some more first. Seems like I was headed in the right direction though.
Maybe I can also find some more information in the Z3X support forums for the Connie Board and safety net stuff to help with the boot image headers.
Delgoth said:
Cool beans! I looked over that first post, and it may actually help me do what I was thinking. The header format they list for those devices looks pretty similar to how the PIT file repartitions the Emmc with ODIN. So with tools like gdisk and the like, I feel it shouldn't be too hard to put 2 and 2 together.
Gotta read that thread some more first. Seems like I was headed in the right direction though.
Maybe I can also find some more information in the Z3X support forums for the Connie Board and safety net stuff to help with the boot image headers.
Click to expand...
Click to collapse
That signature on those engineering images is SEANDROIDENFORCE + 256 bytes just like the Xcover 3. Difference is the header is normal AOSP instead of Marvell/Samsung's crazy version. I'm guessing that reappending the signature doesn't make it valid, but that should be your first test before going any further.
My Android Image Kitchen will do everything but add the signature back on. Do a repack with no changes and add the signature back on with a hex editor to see if it'll boot.
osm0sis said:
That signature on those engineering images is SEANDROIDENFORCE + 256 bytes just like the Xcover 3. Difference is the header is normal AOSP instead of Marvell/Samsung's crazy version. I'm guessing that reappending the signature doesn't make it valid, but that should be your first test before going any further.
My Android Image Kitchen will do everything but add the signature back on. Do a repack with no changes and add the signature back on with a hex editor to see if it'll boot.
Click to expand...
Click to collapse
Thank you for this. I've been moving my house this week, and I'm getting my internet back today. Woop woop. I've been wanting to dive into the topic of signatures for like a month now at least.
I'll see what I can dig up.
As some of you may know, jrkruse has a rom out for the phone, that allows the system to be modified to an extent without tripping knox and such. Can we possibly install the Crom Service apk as a system app, and unlock the bootloader that way? Won't it have all necessary permissions to unlock it?
CyanideHD said:
As some of you may know, jrkruse has a rom out for the phone, that allows the system to be modified to an extent without tripping knox and such. Can we possibly install the Crom Service apk as a system app, and unlock the bootloader that way? Won't it have all necessary permissions to unlock it?
Click to expand...
Click to collapse
I forget where I read on XDA, that the Crom Service APK talks to servers in China in order to send and receive the unlock instructions.
ConsIdering the APP is a first party Samsung Application, I wonder how exactly it goes about turning off the signature verification. Unless the Crom APK actually downloads an unlocked bootloader and flashes it directly to the device itself.
The signatures are stored in the footer of the images. At least in the System Image anyways. Because the fstab file specifically says to mount the system partition with an encryptable footer. That is how ODIN checks if what you are flashing matches the device binary revision.
Using a rooted device on newer builds, or the greyhat root console on older builds, we can pull the stock recovery and find the keystore. Which houses all the signatures the device will accept.
But yes, technically if you can get the APK to load without a Force Close, it should have the needed permissions. It was built using the Knox/Galaxy SDK's.
So Ive been trying to root v20 for some time now. Ive followed instructions up to point of step 4. I type in terminal emulator applypatch /system/bin/atd /storage/emulated/0/dirtysanta. Nothing happens
Next it reads
Filenames may be of the form
MTD:<partition>:<len_1>:<sha1_1>:<len_2>:<sha1_2>:...
to specify reading from or writing to an MTD partition.
Have I done something wrong? Has something changed? any help would be greatly appreciated.
You are patched. No root for you.
ZV5 or earlier only.
Lg v20 vs995
So I"ve been trying to root v20 for some time now. I've followed instructions up to point of step 4. I type in terminal emulator applypatch /system/bin/atd /storage/emulated/0/dirtysanta. Nothing happens
Next it reads
Filenames may be of the form
MTD:<partition>:<len_1>:<sha1_1>:<len_2>:<sha1_2>: ...
to specify reading from or writing to an MTD partition.
I've tried it alot of times again and again but it says same all the time
Please help me
Roll back to a version that has the December 2016 security patch or earlier. There are several threads around here that tell you what version you need to be on (heck I wrote one of them) -- search is your friend.
-- Brian
runningnak3d said:
Roll back to a version that has the December 2016 security patch or earlier. There are several threads around here that tell you what version you need to be on (heck I wrote one of them) -- search is your friend.
-- Brian
Click to expand...
Click to collapse
Can I roll back from ZVD? I SEARCHE AND COULDN'T FIND ANYTHING. Multiple sources have told me its impossible.
rayulove69 said:
Can I roll back from ZVD? I SEARCHE AND COULDN'T FIND ANYTHING. Multiple sources have told me its impossible.
Click to expand...
Click to collapse
No you can't roll back and if you try anyway you will brick. Theres basically no hope of post zv7 ls997 getting rooted ever
runningnak3d said:
It has been confirmed that If you have the engineering bootloader, AND have a fusing device (which AFAIK all LS997 are), AND install firmware that is ARB 1 or greater, it will brick your phone.
If you are ARB 1 or greater, and install the eng. bootloader -- brick.
When I was doing testing on ARB and the engineering bootloader, I was doing it on a non-fusing device, so my results are null and void.
So, we need a method of unlocking the production bootloader -- and there is, just not the LS997 aboot. It would require flashing either the H915 or US996 aboot, and you can't do that due to ARB.
Unless an engineering aboot leaks that is ARB 1 or an engineering boot leaks that has dm-verity disabled, or a flaw is found in the current aboot, I do not see the LS997 getting root.
EDIT: not trying to keep too much hope alive, but if when Oreo is released, they increment ARB on either the H915 or US996 and DON'T increment it on the LS997, then you would be able to flash either aboot and root....
-- Brian
Click to expand...
Click to collapse
Planning to get a refurbed V20 H910.
Can this phone be rooted and bootloader unlocked and TWRP installed??
I read something that this ARB will prevent some or all of these things.
Even having read every thing I am still VERY confused. Thanks.
boowho said:
Planning to get a refurbed V20 H910.
Can this phone be rooted and bootloader unlocked and TWRP installed??
I read something that this ARB will prevent some or all of these things.
Even having read every thing I am still VERY confused. Thanks.
Click to expand...
Click to collapse
Start here - https://r.tapatalk.com/shareLink?ur...share_tid=3664500&share_fid=3793&share_type=t
All H910 are ARB - 0
Sent from my PH-1 using Tapatalk
ARB is LG's implementation of Anti-rollback protection. At a low level, it involves blowing a fuse on the SoC (not as violent as it sounds) when x software version is installed, preventing rollback to an earlier version.
For one or two variants, going past stock v10p (I think) triggers ARB to be incremented to 1 from 0, meaning they can't go back to any stock version earlier than said 10p or a custom ROM that's aware of ARB being tripped.
The linked thread above is a good place to start.
clsA said:
Start here - https://r.tapatalk.com/shareLink?ur...share_tid=3664500&share_fid=3793&share_type=t
All H910 are ARB - 0
Sent from my PH-1 using Tapatalk
Click to expand...
Click to collapse
ALL H910 ARB = 0 Does that mean I don't have to be concerned with it? I may want to UN-root and relock the BL in the future?
clsA said:
Start here - https://r.tapatalk.com/shareLink?ur...share_tid=3664500&share_fid=3793&share_type=t
All H910 are ARB - 0
Sent from my PH-1 using Tapatalk
Click to expand...
Click to collapse
Redline said:
ARB is LG's implementation of Anti-rollback protection. At a low level, it involves blowing a fuse on the SoC (not as violent as it sounds) when x software version is installed, preventing rollback to an earlier version.
For one or two variants, going past stock v10p (I think) triggers ARB to be incremented to 1 from 0, meaning they can't go back to any stock version earlier than said 10p or a custom ROM that's aware of ARB being tripped.
The linked thread above is a good place to start.
Click to expand...
Click to collapse
Thanks.
boowho said:
ALL H910 ARB = 0 Does that mean I don't have to be concerned with it? I may want to UN-root and relock the BL in the future?
Click to expand...
Click to collapse
No problems.
Correct. No need to worry about it on any ARB = 0 variants.
Redline said:
No problems.
Correct. No need to worry about it on any ARB = 0 variants.
Click to expand...
Click to collapse
Thanks.
Still issues.
The phone arrived today and though it was advertised as UNLOCKED, it is AT&T branded.
As a result of AT&T fooling further with their mods I cannot get into recovery mode using the normal VOL DN + POWER button combination.
Any way to get past the AT&T crap so as to unlock BL, install TWRP and root this phone??
Or am I just screwed??
Boowho??
boowho said:
The phone arrived today and though it was advertised as UNLOCKED, it is AT&T branded.
As a result of AT&T fooling further with their mods I cannot get into recovery mode using the normal VOL DN + POWER button combination.
Any way to get past the AT&T crap so as to unlock BL, install TWRP and root this phone??
Or am I just screwed??
Boowho??
Click to expand...
Click to collapse
Doing a quick search online would tell you the H910 is an AT&T branded V20 variant. You'd want something like the H990DS or the US996 which is unlocked for the US market (someone correct me if I'm wrong with this one).
Doing a quick search on the V20 forums will show you multiple guides to get started if you intend to stick with the H910.
Specifically, the DirtySanta bootloader unlock & root guide is what I'd recommend.
Following that will get you on the road to a custom ROM.
If ADB Debugging is enabled and you have ADB installed on your PC, you can plug the phone in and do 'adb reboot recovery' from your computer which will reboot the phone to recovery.
Redline said:
Doing a quick search online would tell you the H910 is an AT&T branded V20 variant. You'd want something like the H990DS or the US996 which is unlocked for the US market (someone correct me if I'm wrong with this one).
Doing a quick search on the V20 forums will show you multiple guides to get started if you intend to stick with the H910.
Specifically, the DirtySanta bootloader unlock & root guide is what I'd recommend.
Following that will get you on the road to a custom ROM.
If ADB Debugging is enabled and you have ADB installed on your PC, you can plug the phone in and do 'adb reboot recovery' from your computer which will reboot the phone to recovery.
Click to expand...
Click to collapse
Dirty santa will only work if his security patch level is prior to Dec 2016, which is doubtful, and you can't downgrade as there are no kdz for the 910
Sent from my LG-H910 using XDA Labs
Well, even though I thought I did, I apparently didn't do my homework well enough.
I can get it into Download mode, but then it just sits there expecting an update. I assume LGUP or something similar needs to be on my PC, right??
Maybe I can salvage this thing yet.
But maybe the EBay seller may be willing for a return; hopefully. Either way I'd be happy.
Changed to US996
I've been able to swap the H910 for a US996. I found it interesting that the bootloader and download screens were exactly the same, since I thought this lock out was done by AT&T.
But I have the same question as before. Will the US996 phone have the ARB = 0 or otherwise??
Then, assuming I decide to unlock BL, install TWRP and root are any certain methods better than others? I't appears to me that there have been more than one technique posted here.
The phone is used so has no warranty from LG, so I figured on using LG's own procedure to unlock BL. Good idea -Bad idea??
Obviously, I don't want to brick this device. I've hacked my old Zenfone 2 until it was "exhaused" and I'd know my way around that phone in the dark.
But I'm breaking all new ground with the V20
Thanks.
Boowho??
H910, H915, VS995 and US996 are identical devices and fully cross-flashable. Use the patched LGUP to flash a US996 KDZ onto the phone, and you'll have an unlocked phone
boowho said:
I've been able to swap the H910 for a US996. I found it interesting that the bootloader and download screens were exactly the same, since I thought this lock out was done by AT&T.
But I have the same question as before. Will the US996 phone have the ARB = 0 or otherwise??
Then, assuming I decide to unlock BL, install TWRP and root are any certain methods better than others? I't appears to me that there have been more than one technique posted here.
The phone is used so has no warranty from LG, so I figured on using LG's own procedure to unlock BL. Good idea -Bad idea??
Obviously, I don't want to brick this device. I've hacked my old Zenfone 2 until it was "exhaused" and I'd know my way around that phone in the dark.
But I'm breaking all new ground with the V20
Thanks.
Boowho??
Click to expand...
Click to collapse
The 996 is arb0
Sent from my LG-H910 using XDA Labs
boowho said:
I've been able to swap the H910 for a US996. I found it interesting that the bootloader and download screens were exactly the same, since I thought this lock out was done by AT&T.
But I have the same question as before. Will the US996 phone have the ARB = 0 or otherwise??
Then, assuming I decide to unlock BL, install TWRP and root are any certain methods better than others? I't appears to me that there have been more than one technique posted here.
The phone is used so has no warranty from LG, so I figured on using LG's own procedure to unlock BL. Good idea -Bad idea??
Obviously, I don't want to brick this device. I've hacked my old Zenfone 2 until it was "exhaused" and I'd know my way around that phone in the dark.
But I'm breaking all new ground with the V20
Thanks.
Boowho??
Click to expand...
Click to collapse
995,996 and 910 does not have arb 1 now,and even you brick your v20, in most case you can unbrick it in 9008 mode