• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root All Root Suggestions and tries here

Status
Not open for further replies.
I don't knwo much about finding roots and that , just using them after someone finds them. but crazy thought , is it possible that LG took stock recovery an fastboot out? Like i said I don' t know much about getting into the phones pre root, just after.
 
bnb25 said:
I don't knwo much about finding roots and that , just using them after someone finds them. but crazy thought , is it possible that LG took stock recovery an fastboot out? Like i said I don' t know much about getting into the phones pre root, just after.
Click to expand...

Stock recovery and Fastboot exist, just no UI for recovery and Fastboot is only accessible when /system is wiped, which requires root. It has been this way since the Optimus M and beyond.
 
Stock Recovery doing factory reset
 

Attachments

  • Recovery.png
    Recovery.png
    166.2 KB · Views: 85
bnb25 said:
I don't knwo much about finding roots and that , just using them after someone finds them. but crazy thought , is it possible that LG took stock recovery an fastboot out? Like i said I don' t know much about getting into the phones pre root, just after.
Click to expand...


The Optimus M only wiped user data and factory reset the phone when we did a reboot into recovery. Also, we weren't able to manually get into fastboot. I only got into it twice, and that was upon a failed recovery flash.
 
sammyz said:
Stock recovery and Fastboot exist, just no UI for recovery and Fastboot is only accessible when /system is wiped, which requires root. It has been this way since the Optimus M and beyond.
Click to expand...


:p been so long since i had the Opt M, I don't even remember what it looked like
 
Whoa, whoa wait, guys. I totally forgot about this thread and specifically this post: http://androidforums.com/5495890-post1.html

I was wrong before. We do have that Backup application, but Spdfreak34 is correct, we have a newer version. However, I posted the source code for the systembackuptest.apk that the Motion uses to gain root access. If I can decipher the logcat error output that Spdfreak34 posted, I can re-write the systembackuptest.apk and build a new apk that works for us. Hopefully, Spritemobile, the developers behind our backup app, haven't caught on to our naughty ways and patched the holes for good.

So, to clear things up. I'll try:

1) Figuring out why we can't run the Motion's root method (Backup app exploit)
2) Hopefully, re-write the source code to get around the error
3) Build a new apk and use that to gain root access

Judging by the error output, it doesn't seem like Spritemobile patched the vulnerability. It just seems to be a mismatching of UID and service calls. It's possible that this could work. I'll let you guys know if I can get something going once I re-setup my Android development environment.

Once again, here's the source code (in Java) for systembackuptest. If anyone notices something related to the error I linked above, please let me know: http://pastebin.com/Ugd7yfb5
 
isaacj87 said:
Whoa, whoa wait, guys. I totally forgot about this thread and specifically this post: http://androidforums.com/5495890-post1.html

I was wrong before. We do have that Backup application, but Spdfreak34 is correct, we have a newer version. However, I posted the source code for the systembackuptest.apk that the Motion uses to gain root access. If I can decipher the logcat error output that Spdfreak34 posted, I can re-write the systembackuptest.apk and build a new apk that works for us. Hopefully, Spritemobile, the developers behind our backup app, haven't caught on to our naughty ways and patched the holes for good.

So, to clear things up. I'll try:

1) Figuring out why we can't run the Motion's root method (Backup app exploit)
2) Hopefully, re-write the source code to get around the error
3) Build a new apk and use that to gain root access

Judging by the error output, it doesn't seem like Spritemobile patched the vulnerability. It just seems to be a mismatching of UID and service calls. It's possible that this could work. I'll let you guys know if I can get something going once I re-setup my Android development environment.

Once again, here's the source code (in Java) for systembackuptest. If anyone notices something related to the error I linked above, please let me know: [Java] IS11LG_SystemBackupTest source code - Pastebin.com
Click to expand...


if you need someone to use their phone as a guinea pig let me know. that's all I can do, I'm not really familiar with braking down apps and stuff.:rolleyes:
 
Isaac i remember you you used to build for the adcend by the way thanks for joining to us and for putting your time here sir
 
quechon said:
Isaac i remember you you used to build for the adcend by the way thanks for joining to us and for putting your time here sir
Click to expand...

So that's why he doesn't understand how the LG phones work :rolleyes:

I'm just joking :p

Seriously though, I believe Isaac may be on to something :):D:thumbup:
 
quechon said:
Isaac i remember you you used to build for the adcend by the way thanks for joining to us and for putting your time here sir
Click to expand...

No worries! Yeah, that was a loooonng time ago. The Ascend is what got me interested in Android in the beginning!
 
sammyz said:
@isaac, it's not odd that reboot recovery causes factory reset. Every phone uses that command even when not rooted. :p
Click to expand...

incorrect, all it does is issue a reboot command.

isaacj87 said:
So, I tried a couple more things to try and get root.

I've been thinking... Back in the day when I first start messing around with Android, most Android devices had hardware key presses to get to different parts of the Android "rescue" areas (i.e. Stock recovery, fastboot mode, etc.)

I'm using ADB to drop into the phone's shell. I tried using:

Code: 
adb reboot-bootloader

...which will reboot the phone and then restart normally.

I also tried:

Code: 
adb reboot recovery

...which I found only factory resets my phone (which is very, very odd why LG would do that).
Click to expand...

because lg's logic is teh only time you need to be in recovery is when doing a reset. there is a flag set in the misc partition that tells teh phone what needs to be done, each flag having special meaning. a postrecoveryboot.sh is used to ensure that flag gets wiped out (so that on teh optimus m+ and connect/lucid people dont leave cwm getting formatted :)

My thinking is that if I can access recovery, fastboot, or bootloader modes, I can use ADB to manually push the su binary and superuser.apk files because in those modes we'll have root access.
Click to expand...

youll have root access in none of those modes actually, if you could get fastboot all you could do is flash an img which then would also have to pass the whole bootloader is locked issue.

Like I said, I'm able to drop into the shell and look around the filesystem:

Code: 
isaac@isaac-g4:~/Android/o4xr$ sudo ./adb-linux shell
shell@android:/ $

...but I'll need temporary root access to be able to push the "root" stuff over. If we can access temp root, we can do a number of things:

1) Flash a new recovery image (e.g. CWM)
2) Manually push and gain root access

If I'm able to gain some sort of temp root access (like I used to do with SuperOneClick), we'll be good to go. If I can find a rooting method for the phone, I'll go ahead an build a CWM recovery image. From there, we can start building up our new device folder and build CyanogenMod like I've done here: https://github.com/ikarosdev/android_device_motorola_triumph

I'll keep experimenting and see if I can find some kind of backdoor LG didn't pay attention to.
Click to expand...

unfortunately what most people dont realize is that getting "temp root" is the hard part. keeping root is as easy as copying 3 files over meanwhile finding a vulnerbility and using it to escalate to an exploit is worlds harder.

isaacj87 said:
Whoa, whoa wait, guys. I totally forgot about this thread and specifically this post: http://androidforums.com/5495890-post1.html

I was wrong before. We do have that Backup application, but Spdfreak34 is correct, we have a newer version. However, I posted the source code for the systembackuptest.apk that the Motion uses to gain root access. If I can decipher the logcat error output that Spdfreak34 posted, I can re-write the systembackuptest.apk and build a new apk that works for us. Hopefully, Spritemobile, the developers behind our backup app, haven't caught on to our naughty ways and patched the holes for good.

So, to clear things up. I'll try:

1) Figuring out why we can't run the Motion's root method (Backup app exploit)
2) Hopefully, re-write the source code to get around the error
3) Build a new apk and use that to gain root access

Judging by the error output, it doesn't seem like Spritemobile patched the vulnerability. It just seems to be a mismatching of UID and service calls. It's possible that this could work. I'll let you guys know if I can get something going once I re-setup my Android development environment.

Once again, here's the source code (in Java) for systembackuptest. If anyone notices something related to the error I linked above, please let me know: [Java] IS11LG_SystemBackupTest source code - Pastebin.com
Click to expand...

the problem is at that point it will be running as a user app and not system :/

not saying that will cause it to fial but i dont believe they have the same permissions allowed
 
sammyz said:
adb reboot recovery
???
Always factory resetted any LG phone I've messed with...
Click to expand...

rigth and as i explained to issac why it does this. that command on any normal android device doesnt. its simply lg's way of screwing with crap because they can
 
sammyz said:
adb reboot recovery
???
Always factory resetted any LG phone I've messed with...
Click to expand...

Well, that's "non-standardized" behavior. On all phones I've developed on or modified (Motorola Triumph, Huawei Ascend, LG Optimus V, Nexus S), issuing the reboot command with the recovery flag should drop you into recovery (whether it be stock, CWM, etc.)

Kind of makes me wonder how LG expects to update this phone if all the recovery wants to do is wipe all of our data. :mad:
 
isaacj87 said:
Well, that's "non-standardized" behavior. On all phones I've developed on or modified (Motorola Triumph, Huawei Ascend, LG Optimus V, Nexus S), issuing the reboot command with the recovery flag should drop you into recovery (whether it be stock, CWM, etc.)

Kind of makes me wonder how LG expects to update this phone if all the recovery wants to do is wipe all of our data. :mad:
Click to expand...

Oh trust me, when you get an OTA, it still works. Not Optimus m though, it never did OTAs...
 
Shabbypenguin said:
youll have root access in none of those modes actually, if you could get fastboot all you could do is flash an img which then would also have to pass the whole bootloader is locked issue.

unfortunately what most people dont realize is that getting "temp root" is the hard part. keeping root is as easy as copying 3 files over meanwhile finding a vulnerbility and using it to escalate to an exploit is worlds harder.

the problem is at that point it will be running as a user app and not system :/

not saying that will cause it to fial but i dont believe they have the same permissions allowed
Click to expand...

That's not always the case. Drop into shell when in recovery. You'll see you have root access. I only wanted to use fastboot as a means to flash a new (CWM) recovery in order to be able to flash a zip package containing the root stuff.

Temp root is only a means to an end. On the Optimus V, we used SuperOneClick to obtain temp root. This allowed us to flash a new recovery (using flash_image) and then subsequently install the root files via a flashable package. This is what I was hoping to do with the Spirit. That way I can kill 2 birds with 1 stone. Get CWM flashed on the phone and gain root access.

The dummy backuptest apk is installed as a user app. That's the whole point. It doesn't need to be a system app because it's exploiting LG's backup app to be able to add this one line:

Code: 
ro.kernel.qemu=1
...inside the local.prop file thus allowing us to have root. From there we can mount and copy the applicable root stuff over.

Like I said, I'm sure lots of things changed since I was knee-deep in developing. Admittedly, I never had the (dis)pleasure of dealing with a locked bootloader. The only device I had that had a locked bootloader (Nexus S), Google allowed users to easily unlock it. CM7 (http://androidforums.com/triumph-al...ersion-cm7-triumph-09182011-discontinued.html) and MIUI (http://androidforums.com/triumph-al...-1-11-25-triumph-113011-2-gb-2-3-7-based.html) were the last things I ever worked on, so it's safe to say I have a lot of catching up to do.
 
This bootloader is locked. You'll brick flashing a recovery. We use a bootstrap, 2nd init recovery on the motion.

Key combo boots stock recovery , an app is required to boot into recovery....so if you ever get in a bootloop, stock recovery won't help you much :(
 
isaacj87 said:
That's not always the case. Drop into shell when in recovery. You'll see you have root access. I only wanted to use fastboot as a means to flash a new (CWM) recovery in order to be able to flash a zip package containing the root stuff.

Temp root is only a means to an end. On the Optimus V, we used SuperOneClick to obtain temp root. This allowed us to flash a new recovery (using flash_image) and then subsequently install the root files via a flashable package. This is what I was hoping to do with the Spirit. That way I can kill 2 birds with 1 stone. Get CWM flashed on the phone and gain root access.

The dummy backuptest apk is installed as a user app. That's the whole point. It doesn't need to be a system app because it's exploiting LG's backup app to be able to add this one line:

Code: 
ro.kernel.qemu=1
...inside the local.prop file thus allowing us to have root. From there we can mount and copy the applicable root stuff over.

Like I said, I'm sure lots of things changed since I was knee-deep in developing. Admittedly, I never had the (dis)pleasure of dealing with a locked bootloader. The only device I had that had a locked bootloader (Nexus S), Google allowed users to easily unlock it. CM7 (http://androidforums.com/triumph-al...ersion-cm7-triumph-09182011-discontinued.html) and MIUI (http://androidforums.com/triumph-al...-1-11-25-triumph-113011-2-gb-2-3-7-based.html) were the last things I ever worked on, so it's safe to say I have a lot of catching up to do.
Click to expand...

i dont have this phone, but if ANY OEM is making you get rooted shell in recovery that would be a huge security concern. if it were possible on lg devices then they would be under a lot of fire from the press (you want proof of this google search "shabbypenguin ZTE backdoor")

the problem is on this device you have signature checking on boot for both kernels. you arent flashing anything to them but the exact stock ones. even then btw superoneclick is just a wrapper, the exploits used vary, its one of teh biggest issues with superoneclick is everyone thinks it does all the rooting yet dont realize all the hard work is done by people they have never heard of.

yes having that line inside local.prop will allow you to have a rooted shell (it makes your phone think its the emulator, which runs as root). is there any way to edit the backups made? and my point is even if you compile it teh program is already installed to system its not like you can remove/replace it.
 
The backups are made in sbf format, so I was hoping the software to edit the Motorola sbf's would work.
 
Shabbypenguin said:
yes having that line inside local.prop will allow you to have a rooted shell (it makes your phone think its the emulator, which runs as root). is there any way to edit the backups made? and my point is even if you compile it teh program is already installed to system its not like you can remove/replace it.
Click to expand...

My understanding is the backuptest app is simply a dummy app that hijacks LG's Backup (made my SpriteMobile) app. It's not looking to replace anything. We're not trying to touch anything in /system, yet. You run the dummy app, it uses LG's backup app to facilitate temp root access, then run a script that simply adb pushes everything into place. Somehow, the dummy app piggybacks the LG backup app to let it open and write into the prop file:

Code: 
                public void onServiceConnected(ComponentName name, IBinder service) {
                        svc = ISystemService.Stub.asInterface(service);
                        try {
                                ParcelFileDescriptor pfd = svc.setFile("/data/local.prop");
                                FileDescriptor fd = pfd.getFileDescriptor();
                                FileOutputStream fos = new FileOutputStream(fd);
                                fos.write(new String("ro.kernel.qemu=1").getBytes());
                                fos.close();
                        } catch (RemoteException e) {
                                e.printStackTrace();
                        } catch (IOException e) {
                                e.printStackTrace();
                        }
                }
From there we can use our newly gained root shell access to copy over the root stuff. I'm looking at the error Spdfreak34 left, and it doesn't look like it's necessarily a showstopper. Just looks like misplaced uids.

sammyz said:
This bootloader is locked. You'll brick flashing a recovery. We use a bootstrap, 2nd init recovery on the motion.

Key combo boots stock recovery , an app is required to boot into recovery....so if you ever get in a bootloop, stock recovery won't help you much :(
Click to expand...

Thanks for the heads up. I didn't know this... :( Looks like there goes our only hope of running overclocked kernels. Why do manufacturers do this...
 
Status
Not open for further replies.
Back
Top Bottom