How a $30 Phone Caused Me a Headache & Write Protection Woes.

How a $30 Phone Caused Me a Headache & Write Protection Woes.

A few months ago while I was playing cards in my Physics class, my friend Quincy Jones comes up to me and said

“Hey, I have a crappy old ZTE phone my grandma gave me, and I know that you like messing around with this kind of stuff. You want it?”

Heck Yeah! Should be fun. Quick/Easy to root, then work on getting TWRP ported, etc. Right? No.

To begin, this phone runs ZTE’s (in my opinion horridly ugly) Jelly Bean 4.1.2. It is labeled Z796C, which, after a quick google search, is called the ZTE Majesty on Straight Talk Wireless (The carrier would later cause me multiple headaches, but we’ll get to that. Upon googling “ZTE Majesty Root” I was greeted by a SINGLE thread about the phone. No big surprise, it’s not a well sold device. The thread was about 8 pages of people complaining about how it hadn’t been rooted. They all said they had tried “every method”, which, at the time, I didn’t believe.

This phone runs 4.1.2, which means that, in theory, this device is vulnerable to hundreds of different local (and even some remote) code execution (root) exploits.

To begin, I tried SafeRoot (originally intended for 4.3), which seemed to succeed, but upon reboot, no root. Huh.

Onto attempt two, Cydia Impactor (Master Key Bug), and although it seemed to work, upon reboot, no root. This should have keyed me off to the problem, but it didn’t.

Onto what should have been my go to for attempt one, TowelRoot. Downloaded the APK and installed, Bang. Root. Or so I thought.

After TowelRoot displayed its success message, I left the app and jumped over to SuperSU, which said that the SU Binary needed to be updated. Sure. I click “Yes”, and left to go for a run.

Got back about 30 minutes later, and it still displayed the “Installing…” prompt! I closed the app, and plugged it into my Surface Pro 3, and pulled up an ADB Shell.

shell@android$

Wow. That’s painfully generic.

I then ran “SU” which returned:

/system/bin/sh: su: not found

Huh? I thought I had root? Maybe I was wrong. Reran TowelRoot, and it rebooted, which is TowelRoot’s way of telling you you aren’t vulnerable/it failed. What the Heck?

I then rebooted the device. Pulled up TowelRoot, and ran it. It reported success. Popped open SuperSU and decided to not update the binary, and just use the one that TowelRoot installs. Seemed like everything was fine. I opened that same ADB shell and ran SU. To which I was greeted with an SuperSU prompt, to which I agreed. Boom.

root@android:/ #

Wow. That’s still painfully generic.

Started surfing around to find where the different partitions lie.

root@android:/ # cat /proc/partitions

Returns: http://pastebin.com/bynNr5b7

root@android:/ # ls -al /dev/block/platform/msm_sdcc.3/by-name

Returns: /dev/block/platform/msm_sdcc.3/by-name: No such file or directory

What? No “By-name” function on a JB era device? That sucks.

root@android:/ # cat /proc/mtd

Returns: dev:    size   erasesize  name

Ugh. No partition listing that sucks.

I tried a few more common methods that I won’t waste time outlining, all you need tt know is that none of them worked.

Next plan of action for me would normally be to examine the Recovery.img and get an fstab, which displays all of a devices mount points. Bad news… after a search, there are no fastboot images for this device! No problem, I’ll just dump the recovery.img from Fastboot. Here we go:

PS C:\Users\Nolen> adb reboot bootloader

I then waited, the ZTE splash screen came up, and then it came up with the Android Boot Logo! What the Heck? I then found out from a quick google search that all Straight Talk phones have Fastboot disabled. This particulat phone also lacks a “Download Mode” to replace Fastboot like what LG does. Wow. This not only prevents disaster recovery, but just made a seemingly easy job much, MUCH harder.

Where to go from here? Not sure honestly. So, I set to work researching it. Couldn’t really find anything relating to the topic.

About 30 minutes into brainstorming, the device randomly rebooted.

When it rebooted, I got back on an ADB shell:

root@android:/ # su

Returned: /system/bin/sh: su: not found

This means war.

Huh!?!?!?! We had Root! Ugh. What’s going on!

For those who haven’t figured it out yet, it was now apparent that not only the phone has Write Protection on /system (prevents writing to a live system, can only be written to from recovery), but also has some form of temp root detector that shuts down root after a certain period of time.

So, I gained temp-root via TowelRoot again, and began brainstorming how to get a partition map again.

Then it hit me.

Recovery knows how to mount the partitions! So, I need to get it to mount all the partition in recovery… Factory Reset!

root@android:/ # reboot recovery

Then, from recovery, I initiated a cache wipe, and then a Factory Data Reset.

After they completed, I reboot to system.

root@android:/ # cat /cache/recovery/last_log

Returns: http://pastebin.com/pyv5qhq6

Yay! A partition map!

Now to use an old trick found by Justin Case (@Jcase) to help temporarily remove Write Protection.

We write the boot partition to the recovery partition, and then reboot to recovery, because the recovery partition (when booted) has permission to mount /system read-write. 

Well, now onto the fun stuff.

We back up our boot partition:

root@android:/# dd if= /dev/block/mmcblk0p8 of=/sdcard/boot.img

Now we back up our recovery partition:

root@android:/# dd if= /dev/block/mmcblk0p16 of=/sdcard/recovery.img

Now we write the contents of the boot partition to the recovery partition

root@android:/# dd if= /dev/block/mmcblk0p8 of=/dev/block/mmcblk0p16

Here we go! *crosses fingers*

PS C:\Users\Nolen> adb reboot recovery

Upon reboot, it seems completely normal. All data is intact, and system is booted sucessfully as expected.

Now to test it. We have to first regain temp-root with TowelRoot, then ADB Shell:

root@android:/# mount –o remount,rw /system

Returns: mount –o remount,rw /system

Success! We have RW access to /system!

Now onto perma-root.

Just open up SuperSU and it will ask to Update the SU Binary, select yes, and wait. About 30 seconds later, it displayed the “Success! It is recommended you reboot now.” Message, I then went in and converted SuperSU to a /system app. Then I rebooted to the normal boot image.

I expected the following; to have root access, but to be unable to remount /system due to write protection.

However, upon reboot:

shell@android$su

root@android:/# mount –o remount,rw /system

Returns: mount –o remount,rw /system

What? How are we still able to remount system RW? To make sure I wasn’t still booted to the recovery partition, I ran:

root@android:/# dd if= /sdcard/recovery.img of=/dev/block/mmcblk0p16

root@android:/# reboot

Now to test again:

shell@android$su

root@android:/# mount –o remount,rw /system

Returns: mount –o remount,rw /system

What? Now I am really confused… but I can live with it! We defeated ZTE Write protection permanently! Even if by accident.