Skip to main content

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.


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

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

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:


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:


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.


  1. I'll give this a try on my ZTE Majesty. I've scoured the entire web looking for a way to obtain root access. I have remedial Linux knowledge so wish me luck.


Post a Comment

Popular posts from this blog

Guide to Compiling Android on Ubuntu 16.04 (Xenial Xerus) -- OpenJDK7 Installation on 16.04

Another Ubuntu release, another set of instructions to get Android source to compile. This only applies to the x64 (64 Bit version). It will not compile on the i386 (32 Bit version). Ubuntu has opted to dump OpenJDK7 in the Xenial Repositories. This just means we will need to add a custom PPA to install JDK7. Why go with OpenJDK7 and not OpenJDK8? Well, OpenJDK7 is required to build most popular AOSP 6.0.x ROM Sources as of right now, some examples include: DU, PN, Any Specific AOSP Tag, OmniROM, and Android-x86. In order to build anything >=4.4.x you will need Oracle Java 6. The only use case for OpenJDK8 would be those who only build CM (13+), PacROM (or any other CM derivative for that matter), or the 'master' branch of AOSP. Follow these instructions exactly (don't just throw 'sudo' around either, it is only to be used in specific cases): 1) Remove all traces of Java: sudo apt-get remove openjdk-* icedtea-* icedtea6-* 2) Add Xenial

A rant about OEM lazieness as it pertains to Proprietary Files

Ever wondered why x device slowed down after an upgrade to the newest android version? Or why y doesn't work on a source built ROM? A BIG part of the issue is OEM's laziness. The bigger part however, is proprietary binaries. Quite often, proprietary binaries are not updated for feature inclusion, or improvements, and are only updated for the purpose of making the hardware WORK, not WORK WELL. They often go out of their way to actually update the HAL's/RIL's/Proprietary Blobs. A great example of this is the RIL. The RIL (Radio Interface Layer) is updated EXTREMELY infrequently. Android's RIL interface is versioned. The current AOSP revision of it is 11. Now, the ril-daemon (Android component that communicates with the RIL) allegedly supports any RIL revision 6=<. A great example of these components not being updated is in the Nexus S (crespo). It was upgrade to JellyBean, which natively includes RIL version 7. Instead of updating it to get all the perk

Breaking Samsung's Security

Problem: The Verizon Galaxy S4 is bootloader locked. Well, what exactly is a Locked Bootloader? A locked bootloader checks for a digital signature on certain images/partitions on the device. This prompted me to begin to research ways to work around this. The Verizon Galaxy S4 (hereon referred to as VZW S4) checks the integrity of signatures on all of the following partitions; -           Boot (boot.img) -           TrustZone (TZ.img) -           Aboot   (aboot.mbn) -           RPM (RPM.mbn) -           SBL1 (sbl1.mbn) -           SBl2 (sbl2.mbn) -           SBl3 (sbl3.mbn) -           The Partition Map (JFLTE_USA_VZW.pit) -           Recovery (recovery.img) -           Modem -           NON-HLOS   Partitions not checked: -           System (/system, only checked during OTA Update) -           Persdata (/Data) -           Cache (/cache) -           Hidden.img Basic Understanding of the boot sequence: PDF: https://drive.go