Find file
Fetching contributors…
Cannot retrieve contributors at this time
79 lines (47 sloc) 4.95 KB

You can read here somewhat more explanatory text if you feel that this one is a bit too brief for you.

Exploiting NEC Terrain mobile

Introduction and terroot

The pre-story can be found in

Many useful scripts, links and the unlocking app, terroot, can be found in

The latter is an easily traceable app which implements the method presented here and outlined first in (also few posts before and all way down)

The bootable images used in terroot are from here as well.

Exploit terminology

  • boot - normal boot via the image on the boot partition (number 9). The stock kernel in this image blocks read-write access to the vital system areas, i.e. system, boot, recovery, sbl1,2,3, aboot, rpm, tz partitions. You cannot write there even if you are root. You moreover cannot remount those partitions rw. The physical area of the internal memory where these partitions are is also write-protected by the kernel.
  • recovery - recovery boot (via vol-down+power) via the recovery partition (number 11). The kernel there turned out to be free of the write-blocks.
  • system (or ROM) - your actual operating system, all inside /system directory

Each bootable image has kernel and the initramdisk to kick-off the system. In our story stock kernels in boot and recovery are different, clearly due to presence/absence of blockages but the config.gz (the file containing parameters with which the kernel was compiled) for both kernels is identical.

In order to root the phone permanently we need to place the su binary inside /system/bin (or /system/xbin) and the goal is to open the latter directory for write. Since even root cannot do it, the new goal is to modify the boot image where all mountings happen. But re-flashing of an image is not possible.

So, the goal is to flash a modified image to a new place and instruct the system about this.


  • GPT - is the table which is located at the beginning of a disk and describes where on the disk each parition lies. A verification copy of the table is at the end of the disk. Those copies must match. Also some specific checksums inside these tables must be correct.

Two facts turned out to be true in this phone:

  • Out of the sudden the gpt table itself is not protected from writing.
  • There are holes between partitions.
  • Those holes are not write-protected

Therefore, we can try to modify the table and change the position of a bootable partition to be inside a writable hole. Then write the new image there and try to boot it. However ...


The bootloader is located in the partition 7 on this phone. It is named aboot. The main danger is that sometimes bootloaders refuse to boot wrong images. Wrong means those w/o security keys or with a wrong checksum or both. The images are "wrong" for the original phone system. However they are perfect for you. In an extreme case the bootloader can in principle soft-brick your phone. I.e. write internally some data which indicate the attempt to boot a wrong image and refuse any further booting.

A detailed reverse-engineering of the boot locker showed however that it is just a joke. It exists, it checks certificates, hash, etc, but its logic is like that:

start booting of an image from boot or recovery
if (some_special_byte is set to 1) boot whatever you have w/o verification
else if (image is wrong) write some_special_byte as 1 AND boot what you have

Originally that some_special_byte is set to 0. So you see, the first time you give a wrong boot image the system checks it, understands that it is wrong, alters some_special_byte to 1 and boots your wrong image. Next boots, since some_special_byte is already set to 1 the wrong image is just booted even without verification.

Good for us, less work. As long as you can flash a modified image. It seems that this some_special_byte is used for the warranty purposes to reject your phone just in case from the repair.

The idea

The idea is to make use of the facts that GPT can be altered and has non-write-protected holes.

  1. The location of the recovery partitioin is remapped to such a hole.
  2. A new better recovery image is written to this hole.
  3. After this we should use this new recovery environment to alter the other parts of the system. Write new boot image for the normal boot or write new system programs like su in the proper place.

Naturally these steps require at least a temporary root access and this luckily can be done thanks to run_root_shell binary (present in recovery/ folder here) wich utilizes a hole in the kernel.

Naturally, new boot is better to be equipped with the kernel from original recovery image, as the latter kernel has no security limitation.

You should read here what are the strict requirements to implement the exploit.