LG G5 Root & Recovery Bounty Thread! [Currently $4,875] [T-Mobile DONE! Who's Next?!]

[Honestly Annoying]

running the H850 aboot on a non-H850 phone would still require an unlock.bin file from LG. only real H850's are whitelisted in LG's unlock system.
the unlock.bin would have to be exploited to make your own unlock.bin. not saying it isn't possible.. but flashing the H850 aboot alone won't get you far unless you have the next step covered as well.

Yes, and from looking at past people's work it seems that exploiting the unlock.bin is near impossible. However if you flash an already unlocked aboot, it might work. This is what the LG V20 team did, with the difference being they had a userdebug aboot that came bootloader unlocked, and they do not have any modular pieces to change out.

 

[autoprime]

Yes, and from looking at past people's work it seems that exploiting the unlock.bin is near impossible. However if you flash an already unlocked aboot, it might work. This is what the LG V20 team did, with the difference being they had a userdebug aboot that came bootloader unlocked, and they do not have any modular pieces to change out.

aboot is a static signed img... it doesn't change between lock states. the V20 debug aboot is an img that was built to never check for boot/recovery signatures.. then signed (by LG). the H850 aboot was built to check for boot/recovery signatures.. unless an unlock.bin is used to unlock.. then signed (by LG). once signed... it cant be changed or the sig breaks... and broken sig = broken aboot and no more booting.

if an unlocked H850 user dumped their aboot... it'd match 1:1 to the stock "locked" aboot. and since the unlock.bin stuff is based on unique values stored in fuses... unlock info cant be shared between phones.

 

[BrunoSlivar]

Short=we never root g5 without unlock bootloader

 

[Honestly Annoying]

aboot is a static signed img... it doesn't change between lock states. the V20 debug aboot is an img that was built to never check for boot/recovery signatures.. then signed (by LG). the H850 aboot was built to check for boot/recovery signatures.. unless an unlock.bin is used to unlock.. then signed (by LG). once signed... it cant be changed or the sig breaks... and broken sig = broken aboot and no more booting.

if an unlocked H850 user dumped their aboot... it'd match 1:1 to the stock "locked" aboot. and since the unlock.bin stuff is based on unique values stored in fuses... unlock info cant be shared between phones.

Ahhh okay, so that is why when running "fastboot getvar unlocked" on the V20 userdebug aboot it still shows as locked. So while flashing the unlock.bin it is not actually changing the aboot partition, it is changing fuse states/other things. Got it.

I am aware that the T-Mobile bootloader/bootstack is completely different than all other G5's, but what exactly are the differences? I have seen your comments about this and am just wondering what makes the T-Mobile aboot non-bootable on other devices.

Short=we never root g5 without unlock bootloader

No, this is not correct. The userdebug boot that I provided for Sprint might actually work on all G5's with antirollback v0. Still testing a couple things, but a user has claimed to get it to work.

 

[autoprime]

I am aware that the T-Mobile bootloader/bootstack is completely different than all other G5's, but what exactly are the differences? I have seen your comments about this and am just wondering what makes the T-Mobile aboot non-bootable on other devices.

to put it simply... the way it is signed. similar to the way G5 aboot is signed one way while V20 is signed another... so that they cant be shared. tmobiles bootstack allows unlock w/o unlock.bin so it is signed one way and only works w/ tmobile hw while all the others are signed another way... almost as if they were different models like the G5/V20. And of course you cant mess with the signing stuff or sig check will fail and phone won't boot.

 

[Honestly Annoying]

to put it simply... the way it is signed. similar to the way G5 aboot is signed one way while V20 is signed another... so that they cant be shared. tmobiles bootstack allows unlock w/o unlock.bin so it is signed one way and only works w/ tmobile hw while all the others are signed another way... almost as if they were different models like the G5/V20. And of course you cant mess with the signing stuff or sig check will fail and phone won't boot.

Yeah, that's what I figured :/ Sucks that they did that, guess the search continues!

---------- Post added at 12:49 PM ---------- Previous post was at 12:47 PM ----------

In other news, I got root for all variants on antirollback v0!
Check here
@kchannel9 PLEASE UPDATE THE OP AS ROOT HAS BEEN ACHIEVED

 

[autoprime]

In other news, I got root for all variants on antirollback v0!
Check here
@kchannel9 PLEASE UPDATE THE OP AS ROOT HAS BEEN ACHIEVED

root should have a disclaimer added to it

root only via adb shell... so anyone wanting to run any root apps will have no luck.
but as you mentioned.. hotspot mod can be made.. and hosts could be edited to block ads. this could also have been achieved by patching the system img with those changes then packing it in a TOT.

so for some.. adblock + hotspot mods will be great.. but I think most people were expecting a root that allows apps to run as root.. xposed.. etc.

if people do pay out for this.. I do hope the payout is shared with those who provided the actual files being used to achieve this. tungkick for the debug boot img which is what gives people adb root... and dirtysanta team for the exploit allowing you to flash the debug boot img. it seems the only thing added were the 3 standard commands:
adb root
adb disable-verity
mount -o rw,remount,rw /system

I don't want to downplay your great find.. just want people to understand the full situation first as well as give attention to the others who made this happen. A "thanks" mention at the bottom of the thread does not do justice for tungkick/dirty santa crew... they're equally entitled to split the bounty in my opinion. (I wrote this last "paragraph" prior to seeing the reply below... but glad to see we're on the same page.)

@Honestly Annoying I was also unaware that any changes to dirtysanta were made... thanks for pointing that out. Is there anywhere you have previously noted the changes you made to it? or if not, could you detail the changes made between your edit and the original?

 

[Honestly Annoying]

root should have a disclaimer added to it

root only via adb shell... so anyone wanting to run any root apps will have no luck.
but as you mentioned.. hotspot mod can be made.. and hosts could be edited to block ads. this could also have been achieved by patching the system img with those changes then packing it in a TOT.

so for some.. adblock + hotspot mods will be great.. but I think most people were expecting a root that allows apps to run as root.. xposed.. etc.

if people do pay out for this.. I do hope the payout is shared with those who provided the actual files being used to achieve this. tungkick for the debug boot img which is what gives people adb root... and dirtysanta team for the exploit allowing you to flash the debug boot img. it seems the only thing added were the 3 standard commands:
adb root
adb disable-verity
mount -o rw,remount,rw /system

Yeah I added a disclaimer in the guide, good idea to have one here also.

SuperSU should be able to be installed, but I believe we need @Chainfire to help just like how he helped with the Galaxy S7 and made a custom binary for them. I have tried pretty much everything I found from other guides and none of them work for me, maybe someone else will have some luck though!

If people do pay the bounty (tbh not expecting it, just want to spread the word about root in the OP), it will absolutely be split up. Yes, the guide posted is basically just the V20 guide but the actual dirtysanta exploit has been edited from theirs, so I did actually do my own development to get root. Tungkick provided the userdebug boot and absolutely deserves part of the bounty also. If/When @kchannel9 updates the OP he should include these names as splitting up the bounty.

If anyone has ideas of how to get SuperSU or knows how to get in touch with Chainfire, please do so! It is absolutely achievable we just need the right people working on it.

---------- Post added at 01:36 PM ---------- Previous post was at 01:18 PM ----------

I don't want to downplay your great find.. just want people to understand the full situation first as well as give attention to the others who made this happen. A "thanks" mention at the bottom of the thread does not do justice for tungkick/dirty santa crew... they're equally entitled to split the bounty in my opinion. (I wrote this last "paragraph" prior to seeing the reply below... but glad to see we're on the same page.)

@Honestly Annoying I was also unaware that any changes to dirtysanta were made... thanks for pointing that out. Is there anywhere you have previously noted the changes you made to it? or if not, could you detail the changes made between your edit and the original?

No worries, I didn't take this as downplaying at all. I realize that while having a root shell is helpful for the experienced developers, most people want a full root with SuperSU. I hope that we can accomplish this soon!

Yes, very much so on the same page for splitting the bounty. Would not want to cheat anyone out of their split.

I did not get permission from the devs to post the source code publicly, so I will just explain what I did.
Basically I removed the steps to backup aboot as we do not touch that partition, I found what partitions that the atd command had read/write access to, and switched the target partition from sde1 (aboot) to sde6 (boot). Recompiled and voila! Write to the boot partition.

 

[cloud1250000]

But autoprime, isn't there anyway to force the aboot to bypass verification.. without unlocking the bootloader? I saw some interesting strings about this when looking at the Canadian aboot...

 

[Honestly Annoying]

Ordered the H850 bottom, should be receiving it in about two weeks! Hopefully I can reflash the Sprint firmware from there and everything will be good

 

[Abort Retry Fail?]

It may end up being that way, but as of now I have no way of knowing for sure because I still need to get the part myself and test it. I am going to attempt to do everything I can so that it doesn't end up being this way, but until I get my bottom I can't say anything for sure.

I also still need someone who is running an unlocked H850 to send me their aboot partition. Doesn't matter what software version you are, please just send it my way!

I attached abootbackup.img from my bootloader unlocked H850 to post #10 of the thread in which you made this general request.

 

[Honestly Annoying]

Still waiting for @kchannel9 to update the OP...

 

[kchannel9]

Still waiting for @kchannel9 to update the OP...

I'm not comfortable yet posting that as "Root Achieved", until there are more people chiming in, as I personally very much appreciate what you have achieved but it is not the exact thing we are looking for with the bounty, mainly ease of installation and SuperSU, with lots of people relaying that it works without major issues.

 

[Arunscape]

Wow I may not completely understand what happened recently but it sounds like good news! ????
Great work, devs!
(From what I gather, root technically has been achieved on the h830 but SuperSU isn't working yet, and it may be possible in the future to flash h830 stuff on the h831 but right now it's definitely 100% NOT a good idea)

 

[Honestly Annoying]

Wow I may not completely understand what happened recently but it sounds like good news!
Great work, devs!
(From what I gather, root technically has been achieved on the h830 but SuperSU isn't working yet, and it may be possible in the future to flash h830 stuff on the h831 but right now it's definitely 100% NOT a good idea)

NONONONO

Never ever EVER flash the H830 firmware on any other device. I flashed the H850 stuff on the LS992, and I believe that should boot all the way.

(don't mean to be harsh, just tying to save devices from a brick! )

---------- Post added at 09:57 AM ---------- Previous post was at 09:53 AM ----------

I'm not comfortable yet posting that as "Root Achieved", until there are more people chiming in, as I personally very much appreciate what you have achieved but it is not the exact thing we are looking for with the bounty, mainly ease of installation and SuperSU, with lots of people relaying that it works without major issues.

If you check the main root thread that I PMed you and posted here, you would see that multiple people are confirming this works on ALL G5's. I understand that it may not be a full root yet, but I did achieve root and would like for the OP to be updated with maybe a disclaimer about SuperSU. Check the main thread and maybe you'll feel more comfortable

 

[Arunscape]

Oops I meant h850 lol. Another reason for me to not flash anything at all right now

 

[kchannel9]

If you check the main root thread that I PMed you and posted here, you would see that multiple people are confirming this works on ALL G5's. I understand that it may not be a full root yet, but I did achieve root and would like for the OP to be updated with maybe a disclaimer about SuperSU. Check the main thread and maybe you'll feel more comfortable

If you can provide a concise description with all the relevant info and links and such, I will include it in the op as long as it's very clear what the dangers are and how to go about it.

 

[Asphaltite]

Canadian Variant H831 willing to PayPal $30 cad

Willing to paypal $30 cad for H831 variant.

 

[autoprime]

I've been thinking (but haven't tested).. as an alternative to the current ADB root method... a "safer" and temporary alternative MAY work.
tho it's very possible I have overlooked a detail and something along the way won't work.
be sure you have a KDZ and LGUP working prior to trying anything just in case u need to go back to stock.
might be good to try n backup any data before all this too... I believe you can use LG Bridge for this backup (or just manually pull stuff off internal sd).

again these are just some thoughts/ideas.. and they may need some "polishing" before it works how I'm imagining it.

Instead of using dirtysanta and writing the debug boot.img to the boot partition... you can:
use @jcadduono 's "recowvery" to get a limited root shell...
flash the debug boot.img to the RECOVERY partition (yes recovery not boot)
"adb reboot recovery" which will reboot the phone and "boot recovery"
since the debug boot.img is now in the recovery partition slot..
it will actually boot back into android.. only with the debug boot img instead of stock boot.img. :good:

from here you should now be able to run adb root etc.
potentially make changes to system... install a new HOSTS file for blocking ads... swap some files for hotspot mod... delete some files... etc
do whatever you wanted to run while having root (running root apps.. xposed etc wont work because this is only adb root not a full root)

then after you're done you can just reboot your phone and you'll be back on the stock boot.img (since u flashed debug img to recovery not boot)
but all the changes you made in system will still stick.

flashing to the recovery partition allows us to keep the stock boot.img in the boot partition slot so all it takes is a reboot to get the stock boot.img back.
the debug img is from the US Cellular variant and is rather outdated which I believe is why some find the performance "laggy" while using it.
so my overall idea is just to "get in and get out". use the debug img to make the modifications you want to system.. then go back to stock boot.img

now.. it may be possible that when going back to the stock boot.img... SOME modifications you made to system will cause booting into android to fail.
the trick would be to find out which modifications can be made to system while using debug img but still holds up after switching back to the stock img.
for example... build.prop edits alone would allow the phone to boot.. even on the stock boot.img.
I would think that perhaps the same would be true of a HOSTS edit for blocking ads... possibly a tether/hotspot mod as well.
Where you may run into trouble is if removing apps... stock boot.img may not like that and fail to boot if you delete the wrong file.
So an alternative to deleting apps would be to use adb shell to "freeze" them instead. see here for info on that.

you could potentially "dual boot" with both the debug img and the stock boot img as well.
currently with what I described above... after you reboot into recovery (which loads the debug boot img you flashed)..
the phone boots into android.. but on that boot.. the recovery partition gets reverted to stock recovery.
this is thanks to a patch file in the root of system that checks the hash of the recovery partition and if it ever changes... it restores stock recovery on boot.
this is why when you install TWRP on unlocked phones.. you must also flash supersu etc which also blocks this recovery patching.. allowing TWRP to stick.
anyway.. to STOP android from patching recovery and reverting it to stock... you can edit your build.prop and delete the last line in it:
ro.expect.recovery_id=0xlettersandnumbershere
with that line gone.. android should stop attempting to patch recovery partition.
but since you booted into android with the debug img before you made this build.prop change...
you'll have to reflash the debug.img again to the recovery slot. (use adb root shell to dd the debug img back to recovery partition).
at this point you'd have the debug boot img in the recovery partition slot and still have the stock boot.img in the boot slot.
and you should be able to "boot into recovery" (using the hardware buttons at boot.. or adb reboot recovery) to boot using the debug img...
and just boot normally to use the stock boot.img.

but again.. all this rides on the stock boot.img still booting android successfully after you had made changes to /system with the debug img.
as I said... I know build.prop alone can be changed and stock boot.img still work.. but not sure what happens when you start deleting files. dm-verity could very well "kick in" and stop you from booting. trial and error will most likely be required.


I think I got most of my ideas out above.. possible I left something out.. was typing it all on the fly as I thought of it.
Dont get mad at me if something breaks. but if you can understand everything I wrote you should be able to test it all without too many issues.. and worst case just flash KDZ to get back to normal.

no, I want nothing to do with the bounty.. so thats not why Ive posted this. I just see so many people having issues in the ADB root thread I thought I'd see if we could maybe just use the debug img temporarily to make the changes you want then go back to stock boot.img to get rid of the lag etc from the outdated debug boot img. If anyone gets a bounty it should be tungkick for providing the debug img.. as none of these ideas would be possible without it. and also to jcadduono or the dirtysanta crew (depending on which exploit you used to allow flashing of the boot img).

once again.. it's very possible this wont play out as I've imagined. But for anyone sitting on the sidelines who's capable of understanding what I'm saying.. see if you can work all this out and finalize it for everyone else. A single bat/sh file should be all thats needed to run recowvery and flash the debug boot img to recovery partition then rebooting to "recovery" which then loads the debug boot img instead. then from there.. some manual commands could be used to initialize adb root and remounting system r/w etc. And determining which files can/cant be edited/removed to allow stock boot.img to still work after the modifications.

Hopefully something comes from this.. or at least gives some people some ideas to try something else as I feel the ideal situation with all this adb root stuff is to make some mods with the debug img then go back to the stock img since the debug img is so old and laggy and way behind on security updates etc. :fingers-crossed:

*UPDATE*
Part 2 Here

 

[Honestly Annoying]

now.. it may be possible that when going back to the stock boot.img... SOME modifications you made to system will cause booting into android to fail.
the trick would be to find out which modifications can be made to system while using debug img but still holds up after switching back to the stock img.
for example... build.prop edits alone would allow the phone to boot.. even on the stock boot.img.
I would think that perhaps the same would be true of a HOSTS edit for blocking ads... possibly a tether/hotspot mod as well.
Where you may run into trouble is if removing apps... stock boot.img may not like that and fail to boot if you delete the wrong file.
So an alternative to deleting apps would be to use adb shell to "freeze" them instead. see here for info on that.

First off, this is a fantastic idea and I would be extremely interested to see if something like this does in fact work. I never even considered something like this.

The only part I would be concerned about is missing the ability to run the "adb disable-verity" command, as the stock boot.img will still have dm-verity enabled. If booting from the recovery partition DOES allow you to run the userdebug kernel, I would just make sure that you aren't deleting system files (as you stated above, just reiterating).

Other than that, this looks like a great way to get a more stable use of the root shell! Thanks for your great work as usual