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

Root [Avail 2] Root available?

Am glad that you are still trying to find a root exploit i still wouldn't know why its giving that error but we'll keep on trying and to see if there are other ways to do this. Does anyone know how we could get an image of the stock rom for this device?
 
If I can get my hands on one without the worry of bricking it (like borrowing a device, no go there), I could hack on it for a bit...
 
Shameless bump.

Still here and desperately trying to root, have run a couple other methods through, still no luck.. Still not bricked either though. :D
 
I have the ZTE z992 ( Avail2 ) as well and have been attempting to gain root on this device to no avail..... >.>

Sideloading might work however the device drivers that came with my ZTE won't pick up the device when it is in Recovery mode.

I attempted re-installing device drivers, with some minor changes to the .inf files to include my devices specific ID's with no success. Perhaps i did something wrong?

All attempts to move binaries onto the phone seem to work fine.. It just seems all current-known setuid exploits fail. I'll keep poking around maybe i'll come up with something i can smash my way to a shell from.
 
The device itself contains ZTE drivers that function properly when in recovery mode, at least mine did.

But in either case, these should work as well.
http://support.zte.com.cn/support/uploads/ZTE_Android USB_Driver_For_Microsoft_PC.rar

Edit:
Also, http://rootandroid.com/ tech 'James' claims he can do it and they offer a moneyback guarantee, I just don't have the $40 to blow on it at the moment.. If/when I do however, I'll be screencap'ing while they're working so I can report back whatever method they find.
 
As soon as I get my laptop back I will extract the recovery.IMG, boot.IMG, recovery.fstab, graphics.c, and postrecoveryboot.sh from our system with windows then try to compile a working cwm, then hopefully TWRP so we may adb push su, busybox and superuser.apk via a dB or flash_image through terminal. One Click Root HAS verified we are indeed root able so anyone willing to collaborate with me plz feel free.
 
]As soon as I get my laptop back I will extract the recovery.IMG, boot.IMG, recovery.fstab, graphics.c, and postrecoveryboot.sh from our system with windows then try to compile a working cwm, then hopefully TWRP so we may adb push su, busybox and superuser.apk via ADB or flash_image through terminal. One Click Root HAS verified we are indeed root able so anyone willing to collaborate with me plz feel free. First biggest thud I hit was that Windows won't recognize our device in recovery mode. Fudge. So out went ADB code line push. Perhaps something I overlooked concerning FTM mode? Plus I have the update-signature.zip and JAR files to add signature verification to any META-INF and System folders for our OWN update.zip for root, plus the su/busybox binaries & superuser.apk. PM me for any assistance I can provide.
 
]As soon as I get my laptop back I will extract the recovery.IMG, boot.IMG, recovery.fstab, graphics.c, and postrecoveryboot.sh from our system with windows then try to compile a working cwm, then hopefully TWRP so we may adb push su, busybox and superuser.apk via ADB or flash_image through terminal. One Click Root HAS verified we are indeed root able so anyone willing to collaborate with me plz feel free. First biggest thud I hit was that Windows won't recognize our device in recovery mode. Fudge. So out went ADB code line push. Perhaps something I overlooked concerning FTM mode? Plus I have the update-signature.zip and JAR files to add signature verification to any META-INF and System folders for our OWN update.zip for root, plus the su/busybox binaries & superuser.apk. PM me for any assistance I can provide.


you probably dont need busybox as its useless.

so does anyone want to share how they rooted this device or is it some pretend secret?
 
I've been slowly working with misternad on a CWM. So far, it "works" but the graphics needs a lot of tweaking. We do have adb access though :). (device tree is established as well for source building)
 
So, upon further investigation with some leads from others I've managed to come up with the following..


Using Cydia Impactor i dropped su into /system/xbin/.
I installed superuser.apk to grant root permissions to appropriate applications..
Installed ADB Insecure so that i could run adb in root mode...
Installed BusyBox

After poking around in the device a little I realised this device uses the EMMC/Ext4 filesystem.

Pertinent information regarding partition tables and location of boot&recovery
Code:
root@android:/mnt/sdcard # cat /proc/partitions
cat /proc/partitions
major minor  #blocks  name

 179        0    3817472 mmcblk0
 179        1       8192 mmcblk0p1
 179        2       8192 mmcblk0p2
 179        3       8192 mmcblk0p3
 179        4          1 mmcblk0p4
 179        5       8192 mmcblk0p5
 179        6       8192 mmcblk0p6
 179        7       8192 mmcblk0p7
 179        8      16384 mmcblk0p8
 179        9      32768 mmcblk0p9
 179       10      16384 mmcblk0p10
 179       11       8192 mmcblk0p11
 179       12       8192 mmcblk0p12
 179       13      65536 mmcblk0p13
 179       14       8192 mmcblk0p14
 179       15       8192 mmcblk0p15
 179       16      16384 mmcblk0p16
 179       17      16384 mmcblk0p17
 179       18      16384 mmcblk0p18
 179       19     614400 mmcblk0p19
 179       20       8192 mmcblk0p20
 179       21     307200 mmcblk0p21
 179       22    2387968 mmcblk0p22
 179       23     212992 mmcblk0p23
 179       32    7782400 mmcblk1
 179       33    7781376 mmcblk1p1

Proper names for the partitions weren't displayed..more information required..

Code:
root@android:/mnt/sdcard # cat /cache/recovery/last_log
cat /cache/recovery/last_log
Starting recovery on Tue Sep 10 18:19:05 2013
framebuffer: fd 4 (320 x 480)
recovery filesystem table
=========================
  0 /tmp ramdisk (null) (null) 0
  1 /boot emmc /dev/block/mmcblk0p16 (null) 0
  2 /cache ext4 /dev/block/mmcblk0p21 (null) 0
  3 /data ext4 /dev/block/mmcblk0p22 (null) -16384
  4 /zteforatt ext4 /dev/block/mmcblk0p5 (null) 0
  5 /recovery emmc /dev/block/mmcblk0p17 (null) 0
  6 /splash emmc /dev/block/mmcblk0p18 (null) 0
  7 /misc emmc /dev/block/mmcblk0p20 (null) 0
  8 /sdcard vfat /dev/block/mmcblk1p1 /dev/block/mmcblk1 0
  9 /system ext4 /dev/block/mmcblk0p19 (null) 0
  10 /amss emmc /dev/block/mmcblk0p13 (null) 0
  11 /oemsbl emmc /dev/block/mmcblk0p3 (null) 0
  12 /emmcboot emmc /dev/block/mmcblk0p15 (null) 0
  13 /cefs emmc /dev/block/mmcblk0p11 (null) 0
  14 /qcsblhd_cfgdata emmc /dev/block/mmcblk0p1 (null) 0
  15 /qcsbl emmc /dev/block/mmcblk0p2 (null) 0

Adequate amount of information for locating the proper partition for the boot/recovery

Just some additional partition information from FDISK

Code:
root@android:/mnt/sdcard # busybox fdisk /dev/block/mmcblk0
busybox fdisk /dev/block/mmcblk0

The number of cylinders for this disk is set to 477184.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p
p

Disk /dev/block/mmcblk0: 3909 MB, 3909091328 bytes
1 heads, 16 sectors/track, 477184 cylinders
Units = cylinders of 16 * 512 = 8192 bytes

              Device Boot      Start         End      Blocks  Id System
/dev/block/mmcblk0p1   *        1025        2048        8192  4d Unknown
Partition 1 does not end on cylinder boundary
/dev/block/mmcblk0p2            2049        3072        8192  45 Unknown
Partition 2 does not end on cylinder boundary
/dev/block/mmcblk0p3            3073        4096        8192  46 Unknown
Partition 3 does not end on cylinder boundary
/dev/block/mmcblk0p4            4097      477184     3784704   5 Extended
Partition 4 does not end on cylinder boundary
/dev/block/mmcblk0p5            5121        6144        8192  b1 Unknown
/dev/block/mmcblk0p6            6145        7168        8192  b1 Unknown
/dev/block/mmcblk0p7            7169        8192        8192  b1 Unknown
/dev/block/mmcblk0p8            8193       10240       16384  b1 Unknown
/dev/block/mmcblk0p9           10241       14336       32768  b1 Unknown
/dev/block/mmcblk0p10          14337       16384       16384  83 Linux
/dev/block/mmcblk0p11          16385       17408        8192  4a Unknown
/dev/block/mmcblk0p12          17409       18432        8192  4b Unknown
/dev/block/mmcblk0p13          18433       26624       65536   c Win95 FAT32 (LBA)
/dev/block/mmcblk0p14          26625       27648        8192  5d Unknown
/dev/block/mmcblk0p15          27649       28672        8192  47 Unknown
/dev/block/mmcblk0p16          28673       30720       16384  48 Unknown
/dev/block/mmcblk0p17          30721       32768       16384  60 Unknown
/dev/block/mmcblk0p18          32769       34816       16384  d1 Unknown
/dev/block/mmcblk0p19          34817      111616      614400  83 Linux
/dev/block/mmcblk0p20         111617      112640        8192  63 GNU HURD or SysV
/dev/block/mmcblk0p21         112641      151040      307200  83 Linux
/dev/block/mmcblk0p22         151553      450048     2387968  83 Linux
/dev/block/mmcblk0p23         450561      477184      212992  83 Linux

Command (m for help):

After dumping the boot,recovery and system partitions I moved these images over to my Ubuntu VM.
Once there i used BootImage Tools to extract the boot.img.
The image extracted properly and i have a valid Kernel Image and Ramdisk image.

According to previous posts you guys seemed to have all this information already and are working on a CWM for this device..
Props to you guys! I could always use the signature files to sign a custom update.zip if anyone wants to share that information!


Thanks to everyone who's worked on this!

A few names worth mentioning.
Misternad for dropping the Cydia Impactor link here.
Motorhead for all of his hard work.
and some guys over at XDA.

Posted from my rooted z992
 
Seems my post didn't make it to the thread...Anyway.

Awesome, Motorhead!

Once i extracted the recovery.img and started poking around the ramfs I naturally located the recovery.fstab and releasekey.x509.pem, no pk8 file that i can locate..not surprised it is the secret part of the key anyway...maybe there's a place i haven't looked..

I'm proficient enough with *nix to perform maintenance, builds and a few other nifty tricks xD. However, i'm no guru and tend to steer clear
of kernel related matters... I did look over the config file you dropped anyway and found a few areas that peeked my interest
specifically concerning RNDIS and some drivers..

I'm assuming you'll use that information in compiling a custom kernel for CWM and any future ROM's. Not really my area of expertise.

I'm interested in how you're flashing the recovery partition for testing CWM are you simply using a signed zip? Or is there another attack vector you're using
such as FTM mode which...i'm not really that familiar with, if you have any documentation on FTM/Diag mode that would be spectactular!.

Finally, i come to the bread & butter of this response..

I'm interested in testing!! If you're up for that kind of thing ^_~ i understand the risks involved but the tinkerer in me
just can't resist!
 
is everyone working on custom roms and attempting cwm or is this a dead page? btw thanks to everyone who has made rooting this device possible. looking forward to see what else is possible with this device
 
Back
Top Bottom