Related
Hot off the presses. Get it here.
That file is the crappy "patch" version that tries to patch you from RC29 to RC30.
Here is the full update, which should be much more reliable
Obviously, don't install it unless you want to lose root access
Update for those who are interested: I went ahead and bought myself a new G1. One of the stores in the area had a couple. It still had RC28 (not RC29) on it, so I'm back in business. I'll just unlock my RC30 one and sell it on ebay.
OMG how stupid can they be... look what I see in the update script
# delete unneeded files
delete SYSTEM:system/bin/telnetd
Click to expand...
Click to collapse
Can we patch this like today cause I kinda think there is more to this than just doing that.
neoobs said:
OMG how stupid can they be... look what I see in the update script
Can we patch this like today cause I kinda think there is more to this than just doing that.
Click to expand...
Click to collapse
There is. They added a kernel option "console=null", which I suspect basically makes it so that the physical keyboard no longer sends input to the console device. Note that there is still a root shell running on the console though.. it's just that now there isn't any way to send keypresses to that root shell.
Plus there are a ton of patches to the android apps and framework jars and such. Not sure what all changed there.
I'm in the process of modifying the patch, to apply to my phone without losing root access. More to come
What does the "applypatch" piece do?
That part looks different.
Interesting that it's only a 4 meg update, and that it only contains a new recovery.img and a new boot.img - I wonder what is different in those images. I hope they are keeping the recovery stuff in the open source branch updated - because, well, that's the nice thing for them to to do
Jesus Freke - when you get your patched-up version ready, please post it somewhere for us lazy bastards who want to ride your coat-tails
I just noticed something. This update doesn't wipe the system partition. If you had created a setuid copy of the shell ("su", or whatever), I don't think it will get deleted if you applied the update as-is.
but didn't you say it removes the use of keyboard in shell? If so we would still be up the creek. you know what a notice this update came really fast i never got and OTA until this(fishy) i had to force OTA. Well hope you work your magic JesusFreke.
Arg! dangit. I accidentally applied RC30 and lost my root access. I copied the wrong update file to my sdcard... grrrr!
So I'm out of the game. Sorry.
Oh, btw - I was wrong about the update keeping the setuid shell around. It completely wipes the permissions of the system folder, so if you did have a setuid copy of the shell, it will be set back to normal non-setuid status by the update. duh.
Sh**!! You were the shining hope , one question can you still get root through the adb shell? cuz if so you can save your a**
Nope. Like I said, I'm out of the game. Unless someone wants to trade me for a RC19/RC29 phone. Or until another root exploit is found. *sigh*
DOH! That sucks! Sorry to hear that, and thanks for taking one for the team.
So if an update does try to install do we just need to turn off the phone until a solution is found? I may need to go back to my Dash for a while until this all gets figured out!
The update that you meant to put on the card- was it a test? If the worst that will happen is the update will take maybe someone that doesnt mind the update could test it for you?
JesusFreke said:
Arg! dangit. I accidentally applied RC30 and lost my root access. I copied the wrong update file to my sdcard... grrrr!
So I'm out of the game. Sorry.
Click to expand...
Click to collapse
I'm sorry about that!
Also, I'm confused. Hadn't you updated the keys in your bootloader to prevent an update? Or does that simply prevent the phone from downloading an update?
Can not we flash back that old RC29 File again ????
The update zip contains the boot.img and the recovery.img. so when the update starts it rewrites JesusFreke's mod recovery.img
spoofing
could we spoof the version # on our device? thus ending the nag and the ability to force the upgrade, for the time being?
bhang
RegGuheert said:
I'm sorry about that!
Also, I'm confused. Hadn't you updated the keys in your bootloader to prevent an update? Or does that simply prevent the phone from downloading an update?
Click to expand...
Click to collapse
Yes. But I had accidentally re-signed the full update with the new key and updated my phone with it. I was in the process of modifying the update, and had grabbed the wrong file to sign and update.
JesusFreke said:
Yes. But I had accidentally re-signed the full update with the new key and updated my phone with it. I was in the process of modifying the update, and had grabbed the wrong file to sign and update.
Click to expand...
Click to collapse
Ahh! That's a pain in the arse... the usb mass storage process is running as root, any chance of a buffer exploit there?
JesusFreke said:
Yes. But I had accidentally re-signed the full update with the new key and updated my phone with it. I was in the process of modifying the update, and had grabbed the wrong file to sign and update.
Click to expand...
Click to collapse
koush said:
mount -oremount,rw /dev/block/mtdblock3 /system
You can't remount that directory that unless you have root.
Use the dd command to copy stuff around (the cp command is not available). I should mention I'm a Windows guy, and am pretty clueless with Linux: my coworker figured the rest of this out once I got to a root prompt.
Incidentally, in the /system/bin directory there is a flash_image executable that changes the recovery.img used when you hard reset the device. I've noticed that I can run this without root access from a standard adb shell. Maybe we never needed to root the device after all... I think we can flash it without root access... I'm too scared to mess with that at all though.
Click to expand...
Click to collapse
I found this, you may want to look into it.
syrusfrost said:
I found this, you may want to look into it.
Click to expand...
Click to collapse
Thanks. But you have to have root access for the flash_image command to work. Or more precisely, you have to have write access to the /dev/mtd/mtd# device that you are trying to flash.
I am also the same unlucky guy who had Press Update Button and now we are in RC30
Now what are the chances of our device to get root access or ability to flash Test_Signed code in RC30
well i removed( # delete unneeded files delete SYSTEM:system/bin/telnetd )and replaced the boot.img and recovery.img with jesusfreke's anything else i should edit before i try to resign and update?
Okay, I had ordered another phone from ebay. The guy had just received it and it was new and unused. It has RC28 on it.
fingerprint= kila-user 1.0 TC4-RC28 114235 ota-rel-keys,release-keys
When I launch /system/bin/telnetd from terminal console I am not getting root. I do not see a process running when I run ps afterwards. Also, I tried typing reboot from the contact, and it is not recycling the phone.
Any chance they have updated the init.rc to close the console bug on an older RC for phones just shipping out from tmobile this past week?
I plan to update to the stock RC29 which I manually updated to on my other phone. I'd really like root before I update to the new RC30 modded, so I can back up my files before overwriting them. [Though, last time I upgraded Google did OTAs right away.]
** Anybody want me to explore the phone for any differences to the standard RC28 to see if the cause for the exploit not working?
-oldsk00lz
Just go ahead and install the official RC29 and you should be able to get root access
Are you sure it's not working? IIRC if you don't connect to telnetd fairly fast, it stops running for some reason. I know that I've had to run it a couple times before I could connect.
As for the root console bug, I've also heard that it closes after some time of the phone being on. Did you try it after a fresh reboot?
Updating to RC28 or RC29, the ones that we mirrored, should activate the console bug again, if they are fixing it.
Yeh, it was not working (telnetd/console exploit) on the RC28 I had. I tried hitting enter to clear any previous commands, tried rebooting, tried back to back calls with telnet right afterwards, telneting locally and from several boxes. Was weird.... Much different than another G1 I had. That's why I was surprised.
Only thing I could think of (besides a tweaked RC28) was that my router could have been acting up.
Anyhow, I moved forward with updating to RC29, getting root, updating to modded RC30, and all is good. Just wanted to throw this out there in case any other recent buyers encountered a similar issue.
SIDENOTE: JesusFreak lived up to his name. I was slightly "freaked" out after the recent upgrade. I went to the System settings and looked to be the standard RC30 fingerprint!!! versus the modded xda one. Thought I may have installed the stock update. :O But, everything else is as expected, root, root, and more root. I must have missed a message if he reverted back to the standard fingerprint.
-oldsk00lz
oldsk00lz said:
SIDENOTE: JesusFreak lived up to his name. I was slightly "freaked" out after the recent upgrade. I went to the System settings and looked to be the standard RC30 fingerprint!!! versus the modded xda one. Thought I may have installed the stock update. :O But, everything else is as expected, root, root, and more root. I must have missed a message if he reverted back to the standard fingerprint.
-oldsk00lz
Click to expand...
Click to collapse
Indeed, I thought the same thing, but it is much, much, much better this way. If JesusFreke left the fingerprint to be the same as the old one, Google would be able to target OTA updates specifically for rooted G1s. This way, if they release an update signed with the test keys, they'd have to have millions of non rooted G1s freak out because they couldn't update.
Gary13579 said:
Indeed, I thought the same thing, but it is much, much, much better this way. If JesusFreke left the fingerprint to be the same as the old one, Google would be able to target OTA updates specifically for rooted G1s. This way, if they release an update signed with the test keys, they'd have to have millions of non rooted G1s freak out because they couldn't update.
Click to expand...
Click to collapse
Not quite...
First, I don't think Google cares for those of us having root with RC30 moded recovery and keys. They really only care about patching the "average consumers" phone. They have to do it globaly (I mean in the distribution sense) not to get in trouble, or a BIG bug wich is what was patched.
Second, they only have to do the following if they want to put "us" back to stock (if we don't check the update of course AND don't pay attention and apply the update [BIG IF]):
Script the rewrite of recovery.img from their package (before rebooting in the background) to our phones and apply the update.... ... ... that's it.
This will get a bit of the "unaware" people who have root with RC30. But for the more savey of us, no.
quedijo said:
Script the rewrite of recovery.img from their package (before rebooting in the background) to our phones and apply the update.... ... ... that's it.
This will get a bit of the "unaware" people who have root with RC30. But for the more savey of us, no.
Click to expand...
Click to collapse
And what good would secretly rewriting recovery.img do? Once JF replaces the recovery.img with the modified one, it doesn't matter how many times they write it to flash, it's still modified.
They don't need to use the update package to take away your root. With modified RC30, any dalvik program that knows and wants to can write directly into /system. If they wanted to get draconian about it, they could push code down from Market to reflash whatever they want in /system.
You said "With modified RC30, any dalvik program that knows and wants to can write directly into /system".
Aren't these apps sandboxed? If they do have access to /system, I assume they would only have access if they ran su, assuming you didn't rename it, and was able to remount system as read/write.
Or am I missing something like a different exploit? root on 'my' phone is great for me, but not good for others.
-oldsk00lz
oldsk00lz said:
You said "With modified RC30, any dalvik program that knows and wants to can write directly into /system".
Aren't these apps sandboxed? If they do have access to /system, I assume they would only have access if they ran su, assuming you didn't rename it, and was able to remount system as read/write.
Or am I missing something like a different exploit? root on 'my' phone is great for me, but not good for others.
-oldsk00lz
Click to expand...
Click to collapse
Yeah, by invoking su. Deleting or renaming it is probably the safest bet for now. I doubt any Android devs are actively looking for phones to brick but better safe than sorry.
a new workaround for our very insecure rooted RC30
I just read a post here about a better fix for the issue.
This very smart cat, added a password routine to SU and judging by my read of the post it seems to be well implemented, you do have to type some commands and you could pooch your g1 but it seems better than runnin just about as wide open as goog had us...
Without a decent browser getting the link is a pita, if somebody can't find it ill link it when I'm at the desktop
Bhang
*EDIT*
I found the link its just a pain in the arse while typing a message, to all the helpful folks who will want to tell me how to do it, I know how I just think it could be easier
http://forum.xda-developers.com/showthread.php?t=448775
Hey,
As the title suggested, and the phone is a Galaxy S Fascinate.
I rooted using a technique which did what this does, with some info from here as well.
Arg, it won't let me post URL's, retarded...wow, can't even edit it because that counts as my '5 minute cooldown' between posts...anyway, after 5 minutes, remove the spaces at the beginning to get them to work..
Link 1: http : // rootzwiki.com/index.php/Smartphones/Samsung-Group/Fascinate.html
Link 2: http : // droidforums.net/forum/rescue-squad-guides/80208-multiple-phones-root-them-unroot-them.html
I'd like to unroot my phone manually, but I don't have enough knowledge of how the root actually works to do so. From what I hear, the word on the street is to just reflash with Odin using the OEM platform/application image. I'm not to keen on reflashing.
So I'm trying to figure out a bit more about how the root works, so I can unroot it via command line. (No, I don't want to be pointed in the direction of one-click root/unrooters, been there, done that, got the t-shirt, was pretty damn pissed about it)
So there's 4 elements that go phone side
- su binary
- busybox binary
- Superuser.apk package
- rage image
So first, there's su, the binary most likely already exists on the phone, which means if I'd like to unroot, I'd need the OEM version of the su binary, is this correct?
Same can possibly go for busybox, assuming if it was there. If busybox didn't come on the phone, then there's no need and you can just remove it.
Now from what I understand about the Superuser package, is it isn't quite an application...but it is, or something. It can probably be removed via uninstall, but I'd need somebody to verify that who knows what Superuser actually is.
Now this is where things get really hazy, the actual exploit, the rage binary. Depending on what this does, it may or may not be a complete pain to get it back to the OEM state. Does anybody have any info or know about the actual binary itself, how it works, etc.? I'm assuming if it just replaces a certain piece of a binary, that piece can be put back in there, but with the root the binary is RAN, not dropped in, so it obviously does something more...and I can't seem to figure out what nor how nor why, etc.
Synopsis:
I'm trying to unroot manually and am not sure about a bunch of specifics regarding the root.
I'd definitely appreciate any info on this...and PLEASE don't just say "search" - because while the root aspect has been covered many times, the specifics haven't..
TIA!!
PS:
Reason I want to unroot is b/c my camera is hosed and I need to take it back to the VZW store for replacing..
Bump?
This might be a dumb Q, but is the rage bin src open?
Hello All! I am me2151.
I am here to tell you some kind of good news.
We have achieved a temporary root shell using a modified recowvery script. Originally Recowvery installed a custom "recovery" but I have modified it to instead create a temporary root shell using the System_Server SELinux context and disable the flashing portion of the script. Yes we are still limited until we can get Kernel or Init context but I am working on that as well.
This exploit will be useful down the line because of one major thing. WE CAN INSERT KERNEL MODULES!!! But they need to be signed. So I am releasing this out here so we can take the next step into our full root! We also have rw to the /data partition and changes save over a reboot.
If we can get someone to sign a kernel module that the system accepts we can set SELinux to permissive.
This exploit SHOULD work for all variants.
NOTE: This should only be used by devs who know what they are doing.
Instructions(this should work on MacOS and Linux only!):
Download linked file below.
Extract to either adb directory OR a directory you have adb access in.
Give execute permissions to temp.sh.
Run temp.sh.
When you are all done with your exploring and stuff type "Reboot" to reboot normally.
https://drive.google.com/open?id=0B8CP3g3AqMuHcmNJUUJWLUJUelE
Credit:
@jcadduono - For recowvery, and pointing me in the right direction on IRC.
@brenns10 - Wrote the lsh used in the exploit to spawn the shell.
The group over here for ideas and solutions.
Very cool work! Glad to see people putting my shell (such as it is) to good use. Wish I had a V20 to try it out
I don't think you'll ever be able to sign a kernel module (SHA512 hash). You'd probably have better luck signing your own boot image.
Here's a theory to toy with:
I think the way to do it would be to gain read access to /init binary allowing you to dirtycow /init with the same init binary but change a very specific (but not vital to system integrity) set of instructions to point back to the setenforce code with a value of 0 without disturbing the rest of the binary/instructions. This way, init should continue running without crashing and taking down the whole system, and you can do something that might trigger that specific instruction set - which would then result in selinux becoming permissive.
This is beyond me, unfortunately. This method would also be very device specific until someone also finds an intelligent way to read init, modify instructions, then dirtycow it back.
I think system server context might be able to read init?
Once you get your permissive selinux, you'll also have to deal with Unix capabilities limitations (find a way around them).
jcadduono said:
I don't think you'll ever be able to sign a kernel module (SHA512 hash). You'd probably have better luck signing your own boot image.
Here's a theory to toy with:
I think the way to do it would be to gain read access to /init binary allowing you to dirtycow /init with the same init binary but change a very specific (but not vital to system integrity) set of instructions to point back to the setenforce code with a value of 0 without disturbing the rest of the binary/instructions. This way, init should continue running without crashing and taking down the whole system, and you can do something that might trigger that specific instruction set - which would then result in selinux becoming permissive.
This is beyond me, unfortunately. This method would also be very device specific until someone also finds an intelligent way to read init, modify instructions, then dirtycow it back.
I think system server context might be able to read init?
Once you get your permissive selinux, you'll also have to deal with Unix capabilities limitations (find a way around them).
Click to expand...
Click to collapse
if system_server can read init then thats a serious flaw.... Question for you. you said it would be very device specific. does that mean its unique for each individual phone or each model?
EDIT:Unfortunately we only have access to the init.rc not the binary it self.
@jcadduono I appreciate your input and direction in this matter another idea we have been toying with is
We have the aboot boot recovery and system dump. From the tmob variant would it be possible to make a tot from that for our devices changing the props to match our device, build, and carrier info? We can also pull apks from /system/apps and /privapps to our ext sdcard
@me2151, @jcadduono, @brenns10: Great work guys, keep it up. Good to see some people are trying for root. What model/s are being tested, or should this theoretically work on all models? Whilst you probably aren't doing it for the cash, there is a bounty I hope someone can claim soon, for a functonal root alone (not boot unlock) posted on this board.
RoOSTA
roosta said:
@me2151, @jcadduono, @brenns10: Great work guys, keep it up. Good to see some people are trying for root. What model/s are being tested, or should this theoretically work on all models? Whilst you probably aren't doing it for the cash, there is a bounty I hope someone can claim soon, for a functonal root alone (not boot unlock) posted on this board.
RoOSTA
Click to expand...
Click to collapse
It should work on all models. I personally use a sprint model(LS997). I think it MAY have been tested on VZW as well.
I can confirm that work on H990DS
Sent from my MI PAD using XDA-Developers mobile app
We know from earlier LG phone releases that the laf partition when bypassed in some way (corrupted, etc) aboot will boot to fastboot when going into download mode. It was my thought that the bootloader could be unlocked from there. However corrupting laf eliminates device recovery. Catch-22.
I think the best way to proceed is to get a working .TOT first which is just a waiting game. That would ensure device recovery and replacing the bootloader in the .TOT and signing it with something unlockable.
This is a great way to explore the locked phones in the meantime, thanks.
ATT Pretty Please
me2151 said:
Hello All! I am me2151.
I am here to tell you some kind of good news.
We have achieved a temporary root shell using a modified recowvery script. Originally Recowvery installed a custom "recovery" but I have modified it to instead create a temporary root shell using the System_Server SELinux context and disable the flashing portion of the script. Yes we are still limited until we can get Kernel or Init context but I am working on that as well.
This exploit will be useful down the line because of one major thing. WE CAN INSERT KERNEL MODULES!!! But they need to be signed. So I am releasing this out here so we can take the next step into our full root! We also have rw to the /data partition and changes save over a reboot.
If we can get someone to sign a kernel module that the system accepts we can set SELinux to permissive.
This exploit SHOULD work for all variants.
NOTE: This should only be used by devs who know what they are doing.
Instructions(this should work on MacOS and Linux only!):
Download linked file below.
Extract to either adb directory OR a directory you have adb access in.
Give execute permissions to temp.sh.
Run temp.sh.
When you are all done with your exploring and stuff type "Reboot" to reboot normally.
https://drive.google.com/open?id=0B8CP3g3AqMuHcmNJUUJWLUJUelE
Credit:
@jcadduono - For recowvery, and pointing me in the right direction on IRC.
@brenns10 - Wrote the lsh used in the exploit to spawn the shell.
The group over here for ideas and solutions.
Click to expand...
Click to collapse
At the moment all I am using root for is to add a line within my build.prop to disable Tethering checks, so I can tether at full 4G speed and not get throttled. Would this be possible using the method above, or would build.prop immediately get replaced at the reboot?
Thanks, and keep up the good work!
NRadonich said:
At the moment all I am using root for is to add a line within my build.prop to disable Tethering checks, so I can tether at full 4G speed and not get throttled. Would this be possible using the method above, or would build.prop immediately get replaced at the reboot?
Thanks, and keep up the good work!
Click to expand...
Click to collapse
no. it is a tcp root shell that can only do a few things such as kernel modules.. only section we were able to write to and have it stick was the /data partition which wont help you in this scenario
elliwigy said:
no. it is a tcp root shell that can only do a few things such as kernel modules.. only section we were able to write to and have it stick was the /data partition which wont help you in this scenario
Click to expand...
Click to collapse
So if we can write to data partition then in theory can we adb push to it using this? I ask because I'd like to install some tbo apps that normally would require flashing. But if we could push them we would be solid
markbencze said:
So if we can write to data partition then in theory can we adb push to it using this? I ask because I'd like to install some tbo apps that normally would require flashing. But if we could push them we would be solid
Click to expand...
Click to collapse
Unfortunately its a tcp shell. not a pure adb shell. so we cannot push or pull to those directories
Wow great progress keep up the good work. You guys are helping those assholes from LG sell more phones. Obviously some people have not made the switch because the lack of root. Root users are very influential leaders to get others to try out a new device.
Sent from my LG-LS997 using XDA-Developers mobile app
Works on the LG G5 also...
Hey guys, with the expectation of many that 'root is coming' to the other v20 models...are we likely to see the same type of root format that applied to the LG G4, where you have to (either) download or rip your own image to a PC. Use commands to insert root, then reflash to the device?
Any root is better than nothing, I know...but I ask because with the amount of software updates for the G4 (v10c software through to v10k before MM came out), meant the sheer amount of times you'd have to go through this process to keep your phone up to date whilst maintaining root was extremely frustrating - as it also meant xposed and related settings/apps needed to be reinstalled each time you performed an OTA update and re-flashed root.
Is this going to be a side effect of dealing with a locked bootloader? PS: If I sound dumb, it's probably because I am.
RoOSTA
roosta said:
Hey guys, with the expectation of many that 'root is coming' to the other v20 models...are we likely to see the same type of root format that applied to the LG G4, where you have to (either) download or rip your own image to a PC. Use commands to insert root, then reflash to the device?
Any root is better than nothing, I know...but I ask because with the amount of software updates for the G4 (v10c software through to v10k before MM came out), meant the sheer amount of times you'd have to go through this process to keep your phone up to date whilst maintaining root was extremely frustrating - as it also meant xposed and related settings/apps needed to be reinstalled each time you performed an OTA update and re-flashed root.
Is this going to be a side effect of dealing with a locked bootloader? PS: If I sound dumb, it's probably because I am.
RoOSTA
Click to expand...
Click to collapse
it shouldnt be an expectation as weve made it clear we do not have root and are hitting hurdles.. we have been advised we need to atack selinux and or the bl but at this point were wanting to try to use debug firmware which hoprfully would allow a bl unlock..
unfortunately nobody can creat a .tot with the debug firmware at al and theres no way at all to flash the images..
we need to somehow leverage an exploit to gain a temp adb root shell before we could even attempt anything and this has not been done in a way thats useful to us..
unfortunately we need more experienced devs at this point.
LG Australia (and as such, Taiwan) have effectively confirmed their H990DS v20 mobile phone's bootloader is confirmed as being unlockable. However (and for no apparent reason) they will not confirm why one region have released a variant of the phone with the bootloader unlock and why they are refusing this to others phones/regions. Because of course, they have zero training and information about anything related to their company expect for goods released in a specific region. That comes from a 'product expert'
Titanium Backup
Howdy,
Just reading through the thread, I understand that it's not quite a "full" root, but would it be enough to run Titanium Backup? I'm hoping to move away from root access with my V20 but it would be really helpful if I could do it temporarily, restore some application and data backups, reboot and uninstall Titanium.
Tim
My H918 is what is currently in the shop (and this would not work on the H910 -- they use a different format), so I can't test this myself. WIth that said, this should be completely safe -- it will either work or it won't
I figured I would look to see what kind of security there was on the OTA update process.
As stated in the title, this is only for the H918 for now since I haven't had a chance to look at other models.
T-Mobile uses the regular SignApk straight out of the AOSP sources to sign their OTA zips.
It also turns out that the LGFOTA.apk will look on the SDcard for the update.zip:
Code:
/cache/fota/update.zip
/cache/fota/update_flag
/data/fota/update.zip
/pkg/SoftwareUpdate
/pkg/SoftwareUpdate/
#/storage/external_SD/SoftwareUpdate
/storage/external_SD/SoftwareUpdate/
/storage/sdcard0/SoftwareUpdate
/storage/sdcard0/SoftwareUpdate/
#/storage/sdcard0/SoftwareUpdate/enc
$/storage/sdcard0/SoftwareUpdate/enc/
Those are the paths that it searches -- the one we care about is /storage/external_SD/SoftwareUpdate/
Now when you sign an update.zip, it obviously needs to be verified with a key. The thing is, they include the key in the zip -- otacert -- why?
I don't have my H918 right now, but that isn't stopping me from looking for other attack vectors. This time it is stock recovery.
As near as I can tell, stock recovery uses the otacert in the zip to verify the signature of the zi.p. Which is fine from a VERIFICATION point of view. If the zip is modified in any way, the signature will fail. If the otacert file is not valid, the signature will fail. So, you know you are flashing a good file if the signature passes.
Now, from a security point of view, you don't include the cert that checks the signature WITH the file to be checked. I really think they screwed up here.
I don't have an H918 to test this on till mine gets back, but if someone else wants to, I can talk you through making an update.zip.
-- Brian
I'll give it a shot
From Android's developer website, it states that:
Sideloading does not bypass recovery's normal package signature verification mechanism—before installing a package, recovery will verify that it is signed with one of the private keys matching the public keys stored in the recovery partition, just as it would for a package delivered over-the-air...
...The RecoverySystem API checks the signature against public keys stored in the main system, in the file /system/etc/security/otacerts.zip (by default). Recovery checks the signature against public keys stored in the recovery partition RAM disk, in the file /res/keys.
Click to expand...
Click to collapse
Is this somehow bypassing that?
I haven't spent anywhere near the time decompiling lg_fota and recovery (the two main binaries that handle OTA) as I have lafd, but like I said, it looks like if there is an otacert in the zip it uses that instead.
The only way to find out for sure is to test it, and it looks like we have a volunteer
@storm68 I will craft up the zip for you. Gimme an hour to wake up...
-- Brian
runningnak3d said:
I haven't spent anywhere near the time decompiling lg_fota and recovery (the two main binaries that handle OTA) as I have lafd, but like I said, it looks like if there is an otacert in the zip it uses that instead.
The only way to find out for sure is to test it, and it looks like we have a volunteer
@storm68 I will craft up the zip for you. Gimme an hour to wake up...
-- Brian
Click to expand...
Click to collapse
Take your time. In the middle of an oil change. Lol
Also as long it's safe, no brick.
How'd this go? Home all day today and have a back up phone if need be. If you need another volunteer I'm game
Sent from my LG-H918 using Tapatalk
@runningnak3d
Sorry had an issue come up....
Anyway, here is the zip.
First, your bootloader must be unlocked. If not, you will have to flash the KDZ to fix your phone since it will fail the AVB check.
Your SDcard needs to be formatted vfat. Make a directory called SoftwareUpdate (caps matter -- remember this is Linux).
Download the zip and rename it to update.zip and stick it in that directory.
With the phone booted, get an adb shell.
Type (or copy / paste) this:
Code:
am start -n com.lge.lgfota.permission/com.lge.lgfota.permission.DmcEzUpdateStart
Your phone should reboot to recovery, and (crosses fingers) should start to flash. If so, you will have TWRP.
If it fails, I need to know exactly what the error was. If it says that it can't find an OTA, I have a few more things to try. If it says that the OTA failed signature check (or something to that extent), then this was all for nothing.
-- Brian
At work, will try when I get home some time tonight. If it doesn't work will it reboot back to normal?
I also still need to unlock bootloader. I'm still fresh outta the box. Lol
Yep. If it fails due to not finding it, or failing the sig check, you may have to reboot the phone yourself, but no changes will be made.
-- Brian
@runningnak3d
E: footer is wrong
E: signature verification failed
Also from she'll the phone just kinda blacks out for a sec and then nothing happens had to boot into recovery and try it that way
@whojabacod So you used the adb sideload method from recovery? If so, yes, that will fail because it uses the certs that are included with recovery.
I'll have my 918 back in a couple of days, and it will be on 10r or whatever the latest is, so I will have real incentive to get it rooted
-- Brian
With the last few posts being read I think I'll wait till you get your phone back and do your thing.
runningnak3d said:
Sorry had an issue come up....
Anyway, here is the zip.
First, your bootloader must be unlocked. If not, you will have to flash the KDZ to fix your phone since it will fail the AVB check.
Your SDcard needs to be formatted vfat. Make a directory called SoftwareUpdate (caps matter -- remember this is Linux).
Download the zip and rename it to update.zip and stick it in that directory.
With the phone booted, get an adb shell.
Type (or copy / paste) this:
Your phone should reboot to recovery, and (crosses fingers) should start to flash. If so, you will have TWRP.
If it fails, I need to know exactly what the error was. If it says that it can't find an OTA, I have a few more things to try. If it says that the OTA failed signature check (or something to that extent), then this was all for nothing.
-- Brian
Click to expand...
Click to collapse
I'll try this later today. Can I format the SD card via phone?
Sent from my LG V20 using XDA Labs
After browsing around, related to this process. With in The first couple of files I looked at which were related to fota. I will say I'm 100% positive this is how the malware has root on my phone. Explains why my phone says I have an external sd card installed , when i do not have one in. @runningnak3d . I do appreciate all your time and effort you've put into getting root on this phone, again. And this process will work when implemented properly. ( not saying his process is incorrect ) . reason I say I'm certain. Is because the files in my phone. Look reeeeaal.... Firmiliar. Almost like I have seen the words spoken somewhere before.. **cough** previous posts above **cough**
Is this something that still needs a tester? Assuming it's as safe as estimated, since this is my (new) daily driver, I'd be willing to try it with my stock H918 10q.