• 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.
can we like pool funds n pay a good developer to spend some real time on this device also wouldnt the current boot loader be a good place to look for a exploit my experience with htc is that rooting requires manipulation of the exiting boot loader i know its not a htc it a lg but w/e i mean how would lg replace the firmware on the device how would a developer for lg tweek or manipulate sys files on test devices im no genius but will = way lets do this
 
jlede said:
http://androidforums.com/spectrum-a...20-bootloader-pwnage-tool-lg-spectrum-4g.html what about this I heard the spectrum 2 and this phone have the same bootloader and they unlocked there bootloader with this so I'm just throwing it out there
Click to expand...

I'd try it but i need the blue tooth. reading through that thread i see thing "This unlock is specifically for the Spectrum and because of software differences between the spec and lucid, it WILL brick any other device that you try to run it on."
 
Ok, so I've been banging my head against the wall trying to get around this seemingly simple permissions error. I'll describe everything I've done if anyone is curious at taking a stab at this. Maybe you'll know/see something that I missed. But first I should say this: All the effort I've been putting in is only to get the LG Motion root method to work for our device. As such, any of the following information is only relevant to getting the Motion method to work for us. To clarify, there isn't a "true" rooting method, so if we can't get this to work, we'll just have to explore other options. I'm only driving this method because it's known to work for a similar device (LG Motion).

This is what I've done so far. I wanted to know how exactly the LG Motion root method works. This is how it does:

1) You install a homemade app (apk) that calls a service that belongs to SpriteMobile's system backup app.
2) When you run the app, it calls an intent on a service called "ISystemService" and uses that to create a file ("/data/local.prop") that contains this property in it:

Code: 
"ro.kernel.qemu=1"
That property gives you root access.
3) You then run a script that uses adb to push all the "perm" root stuff over and viola, you now have root access on your phone.

Sounds simple enough, right? So, why doesn't this work on our phones? Well, the answer is simple, but difficult to get around. The reason why the homemade app force closes is because of this. I pulled off all the framework and backup apks and deodexed them so I could take them apart. This is what I found:

Code: 
<?xml version="1.0" encoding="utf-8"?>
<manifest android:sharedUserId="android.uid.system" android:versionCode="110" android:versionName="1.1.0.110" package="com.spritemobile.system.backup"
  xmlns:android="http://schemas.android.com/apk/res/android">
    <uses-permission android:name="android.permission.SET_PREFERRED_APPLICATIONS" />
    [B]<permission android:label="@string/permission_label" android:name="com.spritemobile.system.backup.USE_SERVICE" android:protectionLevel="signature" android:description="@string/permission_desc" />[/B]
    <application android:label="@string/app_name" android:icon="@drawable/icon" android:debuggable="false">
        [B]<service android:name="com.spritemobile.system.backup.SystemService" android:permission="com.spritemobile.system.backup.USE_SERVICE">[/B]
            <intent-filter>
                <action android:name="com.spritemobile.system.backup.ISystemService" />
            </intent-filter>
        </service>
    </application>
</manifest>
I always expected that the SpriteMobile app had permissions, but without being able to see what an older version of the app looked like, I can't say what was added. What I can say is that whatever permissions were added, it closed the ability to exploit the ISystemService hole.

I've taken the source code and built a new homemade app that should work, but I'm still getting blocked out of exploiting that service. I've added the applicable line to our manifest, but it still ignores me:

Code: 
<?xml version="1.0" encoding="utf-8"?>
<manifest android:versionCode="1" android:versionName="1.0" package="com.example.systembackuptest"
  [B]<uses-permission android:name="com.spritemobile.system.backup.USE_SERVICE" />  [/B]
  xmlns:android="http://schemas.android.com/apk/res/android">
    <application android:theme="@style/AppTheme" android:label="@string/app_name" android:icon="@drawable/ic_launcher">
        <activity android:label="@string/title_activity_main" android:name=".MainActivity" >
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
</manifest>
I'm still combing through the Android documentation to find away around this, but I'm assuming using a user app to piggyback off a system app is quite that glaring hole and any subsequent updates to SpriteMobile's app and Android itself probably closed this weakness.

FWIW, I tried starting the applicable service first before the app calls to ISystemService, but it still ignores me.

Code: 
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
    }

    @Override
    public void onStart() {
        super.onStart();
 [B]       Intent LaunchSysServ = new Intent("com.spritemobile.system.backup.SystemService");
        startService(LaunchSysServ);
        Intent intent = new Intent();
        intent.setAction("com.spritemobile.system.backup.ISystemService");
        bindService(intent, connection, BIND_AUTO_CREATE);[/B]
    }
Like I said, I'm going to keep combing through the docs to find something. Honestly, it's really as simple as getting the service the perms it needs to get it to run. Once we can get that, the rest of rooting would be so simple. However, we should keep looking to see if there's possible any other way of being able to root this phone. I should note that the reason why the "Rooting with restore" method doesn't work is because that exploit was patched in the later builds of ICS. If I'm able to get this working, you guys will be the first to know. ;)
 
Thank you for that. I tore it apart and they do have different permissions. The older version doesn't have:

Code: 
    <uses-permission android:name="com.spritemobile.system.backup.USE_SERVICE" />
It would seem that SpriteMobile added a new permission on purpose.

I tried adding all the perms to the manifest and I still get stuck...

Code: 
[2013-02-17 00:10:17 - SystemBackupTest] Uploading SystemBackupTest.apk onto device 'LG-MS870-2aa127c'
[2013-02-17 00:10:17 - SystemBackupTest] Installing SystemBackupTest.apk...
[2013-02-17 00:10:19 - SystemBackupTest] Success!
[2013-02-17 00:10:19 - SystemBackupTest] Starting activity com.example.systembackuptest.MainActivity on device LG-MS870-2aa127c
[2013-02-17 00:10:20 - SystemBackupTest] ActivityManager: Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.example.systembackuptest/.MainActivity }
 
isaacj87 said:
Thank you for that. I tore it apart and they do have different permissions. The older version doesn't have:

Code: 
    <uses-permission android:name="com.spritemobile.system.backup.USE_SERVICE" />
It would seem that SpriteMobile added a new permission on purpose.

I tried adding all the perms to the manifest and I still get stuck...

Code: 
[2013-02-17 00:10:17 - SystemBackupTest] Uploading SystemBackupTest.apk onto device 'LG-MS870-2aa127c'
[2013-02-17 00:10:17 - SystemBackupTest] Installing SystemBackupTest.apk...
[2013-02-17 00:10:19 - SystemBackupTest] Success!
[2013-02-17 00:10:19 - SystemBackupTest] Starting activity com.example.systembackuptest.MainActivity on device LG-MS870-2aa127c
[2013-02-17 00:10:20 - SystemBackupTest] ActivityManager: Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.example.systembackuptest/.MainActivity }
Click to expand...


wish I knew this stuff I'd try and help out.
 
isaacj87 said:
Thank you for that. I tore it apart and they do have different permissions. The older version doesn't have:

Code: 
    <uses-permission android:name="com.spritemobile.system.backup.USE_SERVICE" />
It would seem that SpriteMobile added a new permission on purpose.

I tried adding all the perms to the manifest and I still get stuck...

Code: 
[2013-02-17 00:10:17 - SystemBackupTest] Uploading SystemBackupTest.apk onto device 'LG-MS870-2aa127c'
[2013-02-17 00:10:17 - SystemBackupTest] Installing SystemBackupTest.apk...
[2013-02-17 00:10:19 - SystemBackupTest] Success!
[2013-02-17 00:10:19 - SystemBackupTest] Starting activity com.example.systembackuptest.MainActivity on device LG-MS870-2aa127c
[2013-02-17 00:10:20 - SystemBackupTest] ActivityManager: Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.example.systembackuptest/.MainActivity }
Click to expand...

Maybe there are libs?
Just guessing.
 
No, but I did make some progress last night. I tore apart our new version of the Backup app and disassembled the smali code back to "java". And I found something very interesting:

Code: 
.class public final Lcom/spritemobile/system/backup/Manifest$permission;
.super Ljava/lang/Object;
.source "Manifest.java"


# annotations
.annotation system Ldalvik/annotation/EnclosingClass;
    value = Lcom/spritemobile/system/backup/Manifest;
.end annotation

.annotation system Ldalvik/annotation/InnerClass;
    accessFlags = 0x19
    name = "permission"
.end annotation


# static fields
.field public static final USE_SERVICE:Ljava/lang/String; = "com.spritemobile.system.backup.USE_SERVICE"


# direct methods
.method public constructor <init>()V
    .locals 0

    .prologue
    .line 11
    invoke-direct/range {p0 .. p0}, Ljava/lang/Object;-><init>()V

    return-void
.end method

Which then roughly "translates" back into this in java:

Code: 
package com.spritemobile.system.backup;

public final class Manifest
{
  public static final class permission
  {
    public static final String USE_SERVICE = "com.spritemobile.system.backup.USE_SERVICE";
  }
}

Now, if I can write a new class into our homemade app that follows the same process that allows the Backup app to use that permission, we should be able to exploit the service and gain temp root! I just have to figure out how exactly this "check" in the Java code hooks into the original Backup app.
 
Mmazz said:
Issac, this is a method developed by bin4ry on xda. Maybe it can help you.
http://forum.xda-developers.com/showpost.php?p=31963526&postcount=532
Click to expand...
Good find. ;)

Just to add to that... in the link below is the original script in case you need it. The link Mmazz posted is supposed to be a fix for the runme.bat which always fails in the original.

http://forum.xda-developers.com/showthread.php?t=1886460

We tried the original script by bin4ry and did not work, but have not tried it with this fix.
 
GameTheory said:
Good find. ;)

Just to add to that... in the link below is the original script in case you need it. The link Mmazz posted is supposed to be a fix for the runme.bat which always fails in the original.

http://forum.xda-developers.com/showthread.php?t=1886460

We tried the original script by bin4ry and did not work, but have not tried it with this fix.
Click to expand...

My apologies, I was wrong. Manifest.java is an auto-generated file that is created when you build your apk. I even have one for my fake app (com.example.systembackuptest). I tried creating my own permission (copy-cat) to try to get the service to run with no joy. It would appear we need to look for another exploit. :(
 
What about if we use a back up already made by the backup apk in the spirit and tweak it that when you restore it can get temp root

Does this make sense???
 
Status
Not open for further replies.
Back
Top Bottom