[ROOT ICS] The hard way && Digging for roots

Search This thread
By:
Advanced…
Icewyng

Icewyng

Senior Member
Dec 10, 2010
309
109
Québec
smokku said:
I'm not sure whether digging in the kernel would give us anything.

From what I understand SBK is a Tegra hardware feature and it does not need any OS running to function.
Once you write SBK decryption key to the chip it is used to decrypt APX commands (also a chip feature) and decrypt the bootloader.

So, if the SBK decryption key is the same on all devices, you can distribute an encrypted bootloader in the update.zip and it will work on all devices. This does not need any kernel support.

If the SBK decryption key is different on each device, you need to distribute an unencrypted bootloader, and encrypt it on device before writing it to flash. This also does not need kernel support, besides maybe giving access to some variable used to compute the SBK encryption key.
Click to expand...
Click to collapse

From what I can tell, it is different for each device.

I was wondering since, in the kernel file tegra_fuse.c, there was this:

[SBK] = {
.addr = fuse_info.sbk,
.sz = sizeof(fuse_info.sbk),
.start_off = 0x0A,
.start_bit = 8,
.nbits = 128,
.data_offset = 5,
.sysfs_name = "secure_boot_key",
},

I understand it is a hardware feature but this is at the kernel level so I thought it could direct us to what it could be like.

the aes_generic.c under crypto has 4 tables of variables with 4 subtables. None of what I was able to generate with the CPUID page from Vache is in there, which meand the acer UID would probably not be the number we look for.

Lastly, this string is in the kernel config:
CONFIG_CRYPTO_DEV_TEGRA_AES=y

So, the AES crypto is enabled. We just need to find what it generates.

As stated before, I might be wrong, but these are ideas I think that could be of interest.

Edit: As I stated before too, it seems the number of fuses is indeed 64. So, all the 0s would really mean none were burnt so far in those.
 
Last edited:
smokku

smokku

Senior Member
Jan 15, 2009
416
67
Warsaw
abadcafe.pl
Icewyng said:
the aes_generic.c [...]

CONFIG_CRYPTO_DEV_TEGRA_AES=y
Click to expand...
Click to collapse

Linux supports kernel supported crypto operations.
These may be implemented in software by kernel, or in hardware.

Tegra has AES encryption engine in-hardware. It is used for SBK, but may also be used by software. CONFIG_CRYPTO_DEV_TEGRA_AES enables hardware accelerated in-kernel encryption device.
 
Icewyng

Icewyng

Senior Member
Dec 10, 2010
309
109
Québec
smokku said:
Linux supports kernel supported crypto operations.
These may be implemented in software by kernel, or in hardware.

Tegra has AES encryption engine in-hardware. It is used for SBK, but may also be used by software. CONFIG_CRYPTO_DEV_TEGRA_AES enables hardware accelerated in-kernel encryption device.
Click to expand...
Click to collapse

So, basically, it might or might not have anything to do with the SBK?

I thought the tables in aes_generic would be how they generated it since, further down the file, they show how it encrypts a block of text.
 
Icewyng

Icewyng

Senior Member
Dec 10, 2010
309
109
Québec
smokku said:
Yup.
I checked a non-tegra kernel tree and it also has crypto/aes_generic.c which looks like pure software implementation of AES, for machines without in-hardware accelerator.
Click to expand...
Click to collapse

Did you compare both tables to see if they were the same?

I think Tegra-aes.c would be probably better to get a sense of what it is created somehow. I am still digging to find answers (I am on vacation for a week and got time to spare).
 
smokku

smokku

Senior Member
Jan 15, 2009
416
67
Warsaw
abadcafe.pl
Do we have a partition layout for A100?

So far I see:
Code: 
/dev/block/mmcblk0p1  SS  recovery  (/etc/install-recovery.sh)
/dev/block/mmcblk0p2  LX  boot  (boot.img)
/dev/block/mmcblk0p3  AP  /system  ext4
/dev/block/mmcblk0p4  CC  /cache  ext4
/dev/block/mmcblk0p5  MC  misc
/dev/block/mmcblk0p6  FX  /system/vendor  ext4  (flexrom.img)
/dev/block/mmcblk0p7  AB  APK  (p1 and p2 signatures)
/dev/block/mmcblk0p8  UA  /data  ext4

And partition names are not that useful :/
# ls /dev/block/platform/sdhci-tegra.3/by-name/
AB
AP
CC
FX
LX
MC
SS
UA

---------- Post added at 11:11 PM ---------- Previous post was at 10:28 PM ----------
Code: 
shell@android:/ # cat /system/etc/install-recovery.sh                          
#!/system/bin/sh
if ! applypatch -c EMMC:/dev/block/mmcblk0p1:4284672:c39cd091f26a36039f138791106b9a3f9caba265; then
  log -t recovery "Installing new recovery image"
  applypatch EMMC:/dev/block/mmcblk0p2:3682560:b2aecf1cf14cc544b62f99e6f6506cc7083a6334 EMMC:/dev/block/mmcblk0p1 c39cd091f26a36039f138791106b9a3f9caba265 4284672 b2aecf1cf14cc544b62f99e6f6506cc7083a6334:/system/recovery-from-boot.p
else
  log -t recovery "Recovery image already installed"
fi

This script uses applypatch (some docs in the source: http://androidxref.com/source/xref/bootable/recovery/applypatch/main.c) to get 3682560 bytes from mmcblk0p2, patch it with recovery-from-boot.p and write to mmcblk0p1.

So it looks like we have the recovery image on the boot partition. But why is it patched?

---------- Post added at 11:16 PM ---------- Previous post was at 11:11 PM ----------

I found something interesting.
In the ICS update.zip META-INF/com/google/android/updater-script last line states:
Code: 
package_extract_file("bootloader.blob", "/dev/block/mmcblk0p4");

So, it looks like it writes bootloader.blob to cache partition.
Is that the mechanism to update bootloader we are looking for?

The bootloader.blob starts with magic string MSM-RADIO-UPDATE

---------- Post added at 11:26 PM ---------- Previous post was at 11:16 PM ----------

Yup.
I did a quick test:
Code: 
adb push bootloader.blob /data/local/
adb shell

$ su
# stop
# umount /cache
# cat /data/local/bootloader.blob > /dev/block/mmcblk0p4
# reboot

And after reebot I saw:
"Start updating EBT"
"End updating EBT"

So the updating bootloader magic is either in bootloader itself (we're screwed) or in the boot.img :>
Let's see what's in boot.img then... :rolleyes:

---------- Post added 7th March 2012 at 12:00 AM ---------- Previous post was 6th March 2012 at 11:26 PM ----------

Nothing in boot.img.
So it looks like the bootloader is taking care of updating itself.
And I bet the bootloader.blob is signed, to stop us from putting our own there.

---------- Post added at 12:09 AM ---------- Previous post was at 12:00 AM ----------

Looks like I'm rediscovering America: http://xdaforums.com/showthread.php?p=13965134#post13965134
 
Last edited:
Icewyng

Icewyng

Senior Member
Dec 10, 2010
309
109
Québec
We do have the layout with NvFlash & the EUU.

I did check the boot.img before but it is not there. Usually, keys are stored in /res/keys, which is missing in the updates. Were you able to open the bootloader.blob?

Also, like I mention before, part of the blob is probably signed and encrypted as well.
 
smokku

smokku

Senior Member
Jan 15, 2009
416
67
Warsaw
abadcafe.pl
I pulled the recovery partition and extracted the initrd.
There is some interesting stuff there.

Code: 
$ cat etc/recovery.fstab 
/system ext4 /dev/block/mmcblk0p3
/data ext4 /dev/block/mmcblk0p8 length=-1048576
/cache ext4 /dev/block/mmcblk0p4
/misc emmc /dev/block/mmcblk0p5
/flex ext4 /dev/block/mmcblk0p6
/mnt/sdcard vfat /dev/block/mmcblk1p1
/boot emmc /dev/block/mmcblk0p2
/aboot emmc /dev/block/mmcblk0p8
/recovery emmc /dev/block/mmcblk0p1

Code: 
$ cat res/keys 
{64,0xf9b1a029,{3625452519,3014154433,25239958,3125786031,2787601734,1060380815,601797762,3422856421,2896793339,2616770339,3052202571,2391598350,2964017839,2113686593,2234986486,608749767,122889633,3622579481,2744030196,3754608517,409975583,2519866086,4034398557,3827635891,2172126069,2178595612,3007263723,3172604689,175961584,1170379883,1873757869,2661693202,4079049576,3015000215,2904561439,1161512116,2903983863,416235237,2059605259,3517678130,1672204091,3765374570,4069139225,2003406875,3984561879,2035575203,974758593,372558389,927123011,3263877236,2833489717,2974323171,899759249,1153649213,3844989847,1450039965,4289725683,2704096073,96767936,3713570332,1700870198,3397120105,2330240163,3397637341},{1030492796,2540225335,248642653,2130413571,3514267890,748889713,920952483,673403028,1809249578,653886782,2061502351,2672615055,2538494078,917188310,1262061249,2350541870,186788215,2730216360,4253670926,2866685930,1542233780,3854260242,1194481048,2404304426,921321714,833939229,2910776826,904138387,4099754974,2794613795,1386241944,2996207179,3041891949,2972551664,2096062200,4213187156,1630861352,488204971,2891016897,1932808678,1513775258,2972416580,119711021,2022288574,1718748163,3300093713,832710402,4248835922,1801578655,3068124638,2267268119,2546061084,2686744189,2536111409,3126065488,2393884605,4256449848,3747277263,2285658786,1700075051,630803353,2905474543,2286363767,3222513217}}

And there are some interesting strings in sbin/recovery
Code: 
[...]
Opening update package...
/res/keys
E:opening %s: %s
 { %i , 0x%x , { %u
E:key length (%d) does not match expected size
 , %u
 } , { %u
 } } 
E:unexpected character between keys
E:Failed to load keys
I:%d key(s) loaded from %s
Verifying update package...
I:verify_file returned %d
E:signature verification failed
Installing update...
[...]
 
  • Like
Reactions: pablotextoris
Icewyng

Icewyng

Senior Member
Dec 10, 2010
309
109
Québec
Lots of interesting things to ponder about.

/res/keys would be the public key so we would need to find the private key to sign the update. Might be why they encrypt their updates... to prevent us to get the key.

0xf9b1a029
This is interesting... it seems to correspond to one of the SBK components as generated by the EUU... a piece of the puzzle perhaps?
 
Icewyng

Icewyng

Senior Member
Dec 10, 2010
309
109
Québec
Was able to extract the blob and, for ICS, it is the EBT partition that is modified. Of course, since it is encrypted, I cannot see inside it.

Could you dd the boot partition and check inside it?

Btw, here is the info from the NvFlash flash,cfg:

[device]
type=hsmmc
instance=3

[partition]
name=BCT
id=2
type=boot_config_table
allocation_policy=sequential
filesystem_type=basic
size=3145728
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0

[partition]
name=PT
id=3
type=partition_table
allocation_policy=sequential
filesystem_type=basic
size=4096
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0

[partition]
name=EBT
id=4
type=bootloader
allocation_policy=sequential
filesystem_type=basic
size=4194304
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
filename=bootloader.bin

[partition]
name=GP1
id=5
type=GP1
allocation_policy=sequential
filesystem_type=basic
size=1048576
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0

[partition]
name=SOS
id=6
type=data
allocation_policy=sequential
filesystem_type=basic
size=5242880
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
filename=recovery.img

[partition]
name=LNX
id=7
type=data
allocation_policy=sequential
filesystem_type=basic
size=8388608
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
filename=boot.img

[partition]
name=APP
id=8
type=data
allocation_policy=sequential
filesystem_type=basic
size=629145600
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
filename=system.img

[partition]
name=CAC
id=9
type=data
allocation_policy=sequential
filesystem_type=ext3
size=1283457024
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0

[partition]
name=MSC
id=10
type=data
allocation_policy=sequential
filesystem_type=ext3
size=4194304
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0

[partition]
name=FLX
id=11
type=data
allocation_policy=sequential
filesystem_type=basic
size=104857600
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
filename=flexrom.img

[partition]
name=AKB
id=12
type=data
allocation_policy=sequential
filesystem_type=basic
size=10485760
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0

[partition]
name=UDA
id=13
type=data
allocation_policy=sequential
filesystem_type=ext3
size=18432
file_system_attribute=0
partition_attribute=0
allocation_attribute=0x808
percent_reserved=0

[partition]
name=GPT
id=14
type=GPT
allocation_policy=sequential
filesystem_type=basic
size=0xFFFFFFFFFFFFFFFF
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0

Edit: try to DD the aboot partition as well... it might be where the action is.
 
Last edited:
Icewyng

Icewyng

Senior Member
Dec 10, 2010
309
109
Québec
smokku said:
It's /data under normal circumstances.
But yeah, /aboot suggests it may have other use.
Click to expand...
Click to collapse

Sorry, didn't have my notes when I said that. Well... /aboot is an emmc partition on /dev/block/mmcblk0p8... and look at this (coming from bugreport):

[ro.crypto.fs_flags]: [0x00000406]
[ro.crypto.fs_mnt_point]: [/data]
[ro.crypto.fs_real_blkdev]: [/dev/block/mmcblk0p8]
[ro.crypto.fs_type]: [ext4]
[ro.crypto.state]: [unencrypted]
[ro.crypto.tmpfs_options]: [size=128m,mode=0771,uid=1000,gid=1000]

so, I would think the interesting stuff would be in aboot. Looks something similar as uboot...
 
smokku

smokku

Senior Member
Jan 15, 2009
416
67
Warsaw
abadcafe.pl
I wanted to check which number is correct for A100 EUUs, but I can't install it.
The installation wizard does not detect my tablet both in ADB and APX modes :/
 
Icewyng

Icewyng

Senior Member
Dec 10, 2010
309
109
Québec
smokku said:
I wanted to check which number is correct for A100 EUUs, but I can't install it.
The installation wizard does not detect my tablet both in ADB and APX modes :/
Click to expand...
Click to collapse

Using Windows? Did you plug your A100 only when it tries to detect it?

---------- Post added at 12:05 PM ---------- Previous post was at 12:01 PM ----------

I've stumbled across this:

abootimg git

Looks to be useful for reading android boot imgs.
 
smokku

smokku

Senior Member
Jan 15, 2009
416
67
Warsaw
abadcafe.pl
Icewyng said:
Using Windows? Did you plug your A100 only when it tries to detect it?
Click to expand...
Click to collapse

Yes, on Windows. I kept my pre-installed one exactly for these occasions. ;-)

The EUUs installer says something like: "Make sure you have your phone connected before pressing OK". So I entered APX mode and plugged tablet in.

I was sure EUUs operates in APX mode. But after it failed detecting the "phone" it instructed me how to enable ADB in settings.
So I rebooted the tablet, connected it in ADB mode and tried again. It failed detecting the device again.


Icewyng said:
I've stumbled across this:
abootimg git
Looks to be useful for reading android boot imgs.
Click to expand...
Click to collapse

I am using http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images to extract boot.img content and standard mkbootimg tool from Android SDK to rebuild it.
 
oneovakindoldys2

oneovakindoldys2

Senior Member
Nov 27, 2011
70
13
smokku said:
Yes, on Windows. I kept my pre-installed one exactly for these occasions. ;-)

The EUUs installer says something like: "Make sure you have your phone connected before pressing OK". So I entered APX mode and plugged tablet in.

I was sure EUUs operates in APX mode. But after it failed detecting the "phone" it instructed me how to enable ADB in settings.
So I rebooted the tablet, connected it in ADB mode and tried again. It failed detecting the device again.




I am using http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images to extract boot.img content and standard mkbootimg tool from Android SDK to rebuild it.
Click to expand...
Click to collapse
@smokku, when you install the euus you will need to unpack it and run the pbj upgrade in administrator mode in windows and follow the instructions on the screen. the program will put the tab in apx mode for you. also, in regards to the boot.img, i have already unpacked the boot.img and recompiled it and i have a new image ready to flash if someone can find a way to get it on the tablet. you can check out the deodex thread where i posted several days ago. i will be glad to work with you guys anyway i can if you or icewyng have any ideas. i am glad to see someone else with interest in getting this thing opened up. good luck!

---------- Post added at 12:26 AM ---------- Previous post was at 12:10 AM ----------

when you guys get the boot.img unpacked, you will seperate the kernel from the ramdisk. after you get it opened up have a good look at init.vangogh.rc., default.prop,etc. when you get it broken down you can edit the information and recompile it with the correct settings to get fastboot and nvflash working, but i have yet to find a way to get it back on the tablet. has anyone been able to unpack [[[any]]] acer iconia rom, and then repack it, even [[without]] editing it and get the signature correct to flash it back to the tablet? thanks
 
You must log in or register to reply here.

Similar threads

Z
Full root for A10x and A5xx ICS. Simple method.
Replies
363
Views
315K
M
manjulapra
vache
[LEAK][ICS 4.0.3] Acer_AV041_A100_1.012.00_WW_GEN1
Replies
453
Views
243K
Hussainch
Hussainch
A
[ROOTED] Rooting An Acer Iconia A100
Replies
224
Views
148K
O
onuris
Z
[Stock Rom] [ICS 4.0.3] Acer_A100_AV041_1.014.00_COM_GEN1
Replies
103
Views
115K
pio_masaki
pio_masaki
civato
[ROM]ICS-"FLEX-A100-REAPER-RELIX_Rev2 (15-Sep-2012)ntfs-3Gusb-GoogleNow,.......
Replies
527
Views
137K
Y
yazyazoo

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 9
    C
    crossix
    Here's my attempt at a "double click" root for ics. I've included everything you might need including the usb drivers. It doesn't need anything special to run, just the usb driver installed and your tab with USB debugging enabled (go to settings -> developer options and check USB debugging.)

    Download:
    http://db.tt/77NSAPDs

    Extract and install the usb driver if needed. Plug your tab in to your pc & Double click the .bat file. Check to see if your device id is listed, if its not close the window out and check that your device is connected and recognized by windows (also check that you have the drivers for the tab installed and that USB debugging is enabled).

    If it is listed (should display a series of numbers) press any key to start the rooting scripts. It will load su and busybox to the loop mount for you. Once the script is done you may need to restart the tab and run the .bat file again to be able to write to the looped system (while the loop system is mounted you can modify the build.prop file and other files within /system by going to /data/local/rootme/loop/ but /system itself isnt r/w mounted. )

    This was a pain to get working and it still may not work right, if it does work for you though, you can re-run the .bat file each time you reboot your tab to be able to write to the looped system. Eventually I'll integrate the commands into the install-recovery.bat file along with some sdcard tweaks so you won't have to re-run the bat file after reboot.

    Thanks to eww245 for providing the commands initially (I used a variation of his and ones from the post on the toshiba forums to get this to work).

    Sent from my MB860 using XDA App
    View
    4
    E
    eww245
    For anyone that doesn't want to root the hard way crossix has come up with a double click root for Windows xdaforums.com/showpost.php?p=23052186&postcount=105

    Update 2/26/12
    /system can now be mounted writable see the bottom of this post.

    So the old Honeycomb exploit has now been patched in ICS. But there was an exploit found in the newer ICS kernels. Written by saurik,: called mempodroid

    There is an offset needed as an argument to the binary, for the a100 we'll use what has worked for the a200 as noted in sauriks github linked above.

    The issue with this is mounting /system as writable. I'm not sure if it's something in ICS, but it appears to be write protected. As noted here and here we will loop mount the system partition.

    The tools needed are:

    1. mempodroid under Usage Instructions, download pre-compiled
    2. busybox 1.20 snapshot 3-10-12
    3. su the latest from androidsu.com, extract from system/bin
    4. mount.txt script

    After downloading and extracting place them all in a folder called tools.
    This must be done with adb. Issue the following from cmd or a terminal:
    Code: 
    $ adb shell mkdir /data/local/tools
$ adb push tools /data/local/tools ; adb shell
$ cd /data/local ; chmod 755 tools/*
$ cd tools ; ./mempodroid 0xd9f0 0xaf47 sh
    If all went well you should be at a hash # prompt. This is temp root.

    mount /system rw the new way:
    Code: 
    # PATH=$PWD:$PATH
# sh mount.txt -o remount,rw /system

    Copy su and busybox to /system
    Code: 
    # ./busybox cp busybox /system/xbin; ./busybox cp su /system/xbin/
# chmod 6755 /system/xbin/su

    Install busybox
    Code: 
    # cd /system/xbin
# for i in $(busybox --list); do ln -s busybox $i; done; sync
    Copy the mount script
    If busybox is updated this step must be run again
    Code: 
    # cp /data/local/tools/mount.txt /system/bin/mount
# cp /data/local/tools/mount.txt /system/xbin/mount

    Done your a100 should be rooted

    the old way:

    Now lets loop mount /system
    Code: 
    [b]This is no longer needed[/b]
# ./busybox losetup -o $((512 * 51200)) /dev/block/loop7 /dev/block/mmcblk0
    Code: 
    # ./busybox losetup /dev/block/loop7 /dev/block/mmcblk0p3
# mkdir loop ; mount -t ext4 /dev/block/loop7 loop

    Copy su and busybox to the new mount point.
    Code: 
    # ./busybox cp su loop/xbin/ ; ./busybox cp busybox loop/xbin/
# chmod 6755 loop/xbin/su ; sync
    If it worked your a100 is fully rooted. Make sure to install SuperUser from the Market.
    Either get busybox installer from the market, and install it to /data/local/tools/loop/xbin
    Or:
    Code: 
    # cd loop/xbin
# for i in $(busybox --list); do ln -s busybox $i; done; sync
    The mount point won't survive a reboot so in order to write to /system again run:
    Code: 
    # busybox losetup /dev/block/loop7 /dev/block/mmcblk0p3
# mount -t ext4 /dev/block/loop7 /data/local/tools/loop

    [update 2/26/12]
    To mount /system as writable do the following from adb. We'll just make a directory called /data/loop for easy access.
    Code: 
    $ adb shell
$ su
# stop
[b]your screen will go black[/b]
# mkdir /data/loop
[b]skip this if the loop is already set up
# busybox losetup /dev/block/loop7 /dev/block/mmcblk0p3[/b]
# mount -t ext4 /dev/block/loop7 /data/loop
# mount -o bind /data/loop /system
# start
    You can write to /system with any app but /system can't be remounted ro then back to rw.

    This can be added to /etc/install-recovery.sh to make it permanent
    Code: 
    busybox losetup /dev/block/loop7 /dev/block/mmcblk0p3
mount /dev/block/loop7 /data/loop
mount -o bind /data/loop /system
    Thanks to crossix as the first to get temp root, and Icewyng for pointing out the exploit and helping with the magic number.
    View
    3
    D
    deadpieface
    I got root using this method. http://xdaforums.com/showpost.php?p=22862959&postcount=306


    I used quick boot app and selected 'Bootloader'. May be useful?

    got this:
    View
    2
    C
    crossix
    eww245 said:
    Not sure why the files aren't showing up. Maybe try busybox sync after copying them.

    [edit] I asssume you can get root manually and it's just a problem with your script?
    Let me know, hopefully the instructions are all correct now. I updated them several times yesterday.
    Also, there might be an easier way than what I posted, if you find one post it here or shoot me a PM.
    Click to expand...
    Click to collapse

    Thanks, I'm having to use a slightly different method since I can't pass arguments through adb shell and mempodroid. It's copying all the files to the tab and executing shell scripts for each step in the process based off a combo of your root method and the one found for the toshiba tab. Hopefully I'll get it figured out soon..
    View
    2
    E
    eww245
    eww245 said:
    Thought that might happen, have to get some more ideas.

    [edit] So maybe using 'stop' will help, from adb

    # stop
    # mount -o bind /data/local/tools/loop /system
    # start

    There probably won't be a bootanimation, but if it gets to the lockscreen it should be ok without FCs. If it bootloops just hold in the power button or use the pinhole reset.

    I should just suck it up and upgrade just don't think I'm ready.
    Click to expand...
    Click to collapse

    bumping this^ could someone try it.


    Looks like the a500 got rooted with the same method. xdaforums.com/showpost.php?p=22862959&postcount=306 There's one difference with the loop mount. So can someone try this and see if it mounts writable. Just trying to make things simpler, Thanks

    busybox losetup /dev/block/loop7 /dev/block/mmcblk0p3
    mount -t ext4 /dev/block/loop7 /data/local/tools/loop

    Also looks like they ran memopdroid on the tablet, so maybe I can refine it some more.
    View

New posts