Lenovo S650 with android 4.4.2 and google authenticator

I have finally found some spare hours to upgrade my Lenovo S650 from the 4.2.2 based S650_S119_131014 ROM to S650_S912_VIBEUI_V1.5_1419_5_ST_1F49 which is based on 4.4.2. As a first step, I have studied the contents of the zip file, especially the updater-script at /META-INF/com/google/android/. It quickly became obvious that I would loose my root access after installing this update, which I wanted to avoid.

The rules I have set for myself do not allow rooting the phone via windows based third party applications (some of which are known to install some souvenirs), and the common path of using the windows-only MediaTek flashing tool in the rooting process is also out of scope for me. For private reasons I decided to not publish information on how to properly root the lenovo ROM via command line, without any closed source, suspicious third party app. Rather than that, let us assume that the original JellyBean system already has root access, and our goal is to retain this during the upgrade.

While setting the immutable flag on the su binary via chattr +i /system/xbin/su would retain root access during minor updates, this is useless if the system partition is formatted. In our case, all partition except sdcard{0,1} would be formatted as it can be seen in the updater-script.

Adding the binary to the itself zip and amending the updates-script with a command to set proper SELinux context, ownership and permissions come as an intuitive solution. This can be achieved by the following line:

set_metadata("/system/xbin/su", "uid", 0, "gid", 0, "mode", 6755, "capabilities", 0x0, "selabel", "u:object_r:su_exec:s0")

One should note that the zip file is a singed jar, and any tinkering would cause signature verification to fail. Although there are various approaches for bypassing signature verification, no magic is needed due to the fact that the current system is already rooted. Custom recovery images allow to install updates without a [valid] signature.

Custom recovery

Readers who have familiarized themselves with the previous post should already know how to 'flash a custom recovery' with a single line.

dd of=/dev/block/mmcblk0 if=recovery.img bs=1024 seek=36352

As an alternative, one can use Mobileuncle MTK Tools to install a custom recovery - if one renames the file to recovery.img and places it into the root of the SD card, the app will automatically pick it up.

I have used TWRP recovery 2.7.0.0. The Lenovo S650 come in two variants, which have different partition layouts. When using pre-built recovery images, make sure to use an image compatible with CN (Chinese) or ROW (Rest Of the World) partition layout according to your device.

The first thing after installing the custom recovery was to test it - taking a TWRP backup of the current system. Actually, testing the backup process is only half of the job, since the recovery process is slightly more important...

Superuser application

While this post is not going to cover the process of rooting, the basic concept of how root permission is granted is outlines. The su binary, unlike in traditional Unices, will not ask for credentials but instead, communicate with a graphical application that will display the details of the 'switch user' request and allow the end user to approve or reject the request via the touchscreen.

As any flaw of the su binary or the superuser application, intentional or unintentional, may critically impact the security of the device, one should consider if this capability is needed at all, and if so, which implementation to chose.

While SuperSU and ChainsDD Superuser are common choices, I decided to go with Koushik Dutta's Superuser. Unlike the other two it is open source, so I have taken some time to go through the source of both the native binary and the app. Additionally it features PIN protection and logging, which typically would not be available in the free versions of other alternatives.

I have downloaded the zip file, and studied the updater-script. I modified the 4.4.2 ROM by adding the binary and the application and changing the scripts to ensure proper metadata is set on the binary.

Google apps

I have downloaded a signed intallable zip of minimal Google Apps for 4.4.2 - this only takes a few megabytes and allows me decide which apps fo google to install later.

The point of no return

I have observed that while the ROM updater-script does not replace the recovery, it installs a script that runs on normal boot and patches the recovery. In worst case, this could mean that I end up with a non-rooted system and my custom recovery, that would allow me to alter the system (install unsigned updates), would be erased and replaced by Lenovo's restricted recovery image. That would have been game over for me.

I have copied the vanilla ROM, the superuser installer and GApps installer zips to the SD card, along with my modified "superuser-included" ROM zip and rebooted to recovery. I performed an advanced wipe selecting user data, cache and dalvik-cache to be erased and then attempted to install the modified ROM.

In the middle of the process, I received an error notifying me that update-binary had failed. The second attempt yielded the same results, leaving the system in an unknown state. I payed attention not to reboot a single time until I was sure the system was properly installed and rooted, or at least the custom recovery image was still in place.

I had to fall back to 'plan B' and installed the vanilla ROM, but instead of rebooting, quickly installed the superuser installer zip as well. Once done, I opened a shell and manually checked the presence and metadata of the su binary and the superuser application. Then I rebooted.

Make space and install GApps

On first boot, I realised there was almost no space on the system partition, so I removed some of the apps like Youyue, GameWorld and Baidu, then took the opportunity to uninstall some preintalled non-system apps like Weibo, QQ and Lakala. I intentionally retained many system apps by Lenovo - in some cases they are really useful and feature rich alternatives to some Google components.

If one is concerned about privacy and decides not to go with Lenovo apps, then the very same person should also be worried about installing any Google component onto his device... Instead of engaging in a religious debate, look at what kind of traffic the various components cause, and block according to your findings.

Once there was 100MB free space on the system partition, I installed the minimal google apps package and rebooted - and singed into my google account. Play store services worked fine, and nothing gave me significant headache... until I tried to use google-authenticator...

Read on, the second part of the series is already available.