Sunday, November 24, 2019

Are you the valet?

Early November I wanted to extract the data I had on my very first TracFone Android device, a ZTE Valet.  It turns out the ZTE Valet is easily temp rooted.  Search for RootMyValet and a github result is the starting point.  Buried under the github lib directory (IIRC) is the roothandler binary.  I mention this because I spent days looking for the cited roothandler binary in su packages as described by the README.

All along I was misunderstanding the README.   The README states to locate my favorite su package, and extract the su binary.  It then instructs to copy the roothandler file in to the same /data/local/tmp directory as where the su binary is dropped, which gave me the impression roothandler is bundled with my favorite su package.  But enter another issue, the Valet is Android 4.1 and all the recent su binaries I extracted required PIE (not to be confused with Android P/pie). 

Eventually I found an old enough su without PIE, but not before taking an alternate path with KingRoot and discovering KingRoot not only failed to root, but successfully installed a bunch of shims to phone home statistics to qq.com and yahoo, and fails to offer the ability to uninstall.

Now I had two problems.  The mostly well mannered "malware" KingRoot -- and -- I still did not have a backup.

First off, the native Android ADB backup didn't produce anything but 504 byte sized file and Move to IOS crashed.  I tried another backup program from the Play Store, but it too, crashed. How bad is KingRoot?  After setting up a hostapd + dnsmasq + tcpdump, I didn't see anything other than small packets headed toward qq and yahoo, but that doesn't mean it didn't lift some data during the initial installation.  I'll save that for some later point in time.

As far as the RootMyValet presence on github, I gather that the RootMyValet.apk is purely a UI to invoke roothandler easily, and the github repo is the wrapper around the whole kit, which includes the apk for the optional UI invocation.

After crawling through the source code and finding a reference to a getroot function, I figured the github repo was an 'apk' that I am supposed to build myself. With that all cleared up and in possession of the roothandler binary, I prepared my own version of the script that roothandler executes.

In my own script, I had it chdir to /data and run 'busybox find | busybox cpio > /sdcard/data.cpio".  This is a simplified version of the actual command as I don't recall the precise flags that the cpio plugin of this busybox required, but it suffices to say it would have been  similar to "ov -H crc" or "ov -H newc".

If you're struggling to follow me up to this point, I used the platform-tools ADB binary, which allowed me to get a shell.  In that shell I was able to invoke roothandler and roothandler, in turn, invokes the shell script (as described in the README) to run as root anything you require during the temp root.

Happy, I got my backup successfully migrated my OTP and organization's Duo multi-factor to different devices.

Update
I dug in a bit more in to the behavior of KingRoot on a Valet.  It does work on the Valet, provided your /data volume is not encrypted.  If you encrypted your Valet using the Android setting, KingRoot will not succeed, but it will install the hooks to ship telemetry.

After it succeeds on an unencrypted Valet, and after installing SuperSU, invoke adb shell and type su. 

In this repeat attempt, I took these steps.
1. install KingRoot and launch.
2. Try Root - it succeeds.
3. install SuperSU
4. Grant SuperSU permission in KingRoot
5. adb shell, and try su, but it failed with Segmentation fault.
6. reboot the phone
7. run KingRoot again, and Try Root
8. adb shell, and try su, this time it worked.

Making the switch from IOS to Android - an iPhone Notes rescue story

In August 2019 I picked up a Pixel XL to replace my soon to be unsupported iPhone 6. I mostly use a phone for jotting down notes, texting, satisfying my curiosity on wikipedia, reading Science Daily, capturing interesting photo moments, navigation, and the weekly phone call. Almost any modern phone satisfies my use case, aside from one requirement: it needs to receive regular security updates.

The Pixel XL received test versions of Android 10, which implied it would receive a full edition. As long as I can tolerate the differences, Android 10

S&D iPhone 7's on a particular Amazon-owned deal site were above $360 and a open box new Pixel XL listed for $210.  The Pixel seemed to be a cost effective way to meet my needs.

I ordered a battery case, which is normal for any phone I pack around. Wearing the battery case, it's not huge -- it's annoyingly "Phabulous," yet I am committed to see this through.

To get my content migrated, I used the Pixel's migration assistant with the Pixel crossover dongle and the lightning cable.  It moved photos, text messages, call history, and a fairly impressive "vis-a-vis" of apps; however, app data for those it located in the Play Store, didn't make the transfer.  For instance, my TracFone app had to set up all over again.  Office Lens lacked any of the associated captures, but that did not bother me.

To my chagrin, my images sent and received via texts were not there.  Add to that, my iPhone notes had no corresponding app to receive them.  Notes were not there.

With Apple's iCloud service, you might be thinking "why is this an issue?  You can access your notes from iCloud."  I could, yes, but my data size is over the free 5GB, and I already have a OneDrive subscription and for reasons, funding iCloud instead of OneDrive is not presently an option.

Linux is all I use, and despite what others might classify as limitations, it has certain applications which make deviation from the trodden path, possible.

Committed to retiring the iPhone 6 and wanting to keep my health trend data from a Viatom app, I tried idevicebackup2. It works and produces an (optionally) unencrypted backup.  The result is a big tree of hex numbered directories under which it stores some number of hexadecimal GUIDish files under the folder tree.  Using

find . -type f -exec file {} \;

is informative and reveals the file type. Common types are Apple binary data, ASCII text, an SQLite database, a JPEG, and PNG. From this information I assembled a pipeline to include a grep for image files.  With image files, I figured I could begin to determine the app-to-image relationship and locate the apps and their corresponding files, like the database or ASCII text, or for that matter, my iPhone Notes.

I opened the Notes app on my iPhone and located a message with a distinct word that is unlikely to be found anywhere in the backup tree.  I used

grep -r "Lincoln" ./*

where the current directory (. and thus the . in ./*) is the parent directory I specified in the idevicebackup2 command line.

I found the file and copied it to a scratch space.  I used the 'file' command on it and it revealed an SQLite DB. 

I installed sqlitebrowser and opened the file.  I found that the note zdata was compressed and a simple online search yielded the syntax I needed to extract the data.  I arrived at this script which extracted everything that I cared about: the text.  I had two notes with attachments.  Upon reviewing them in my iPhone, I still put no value on keeping them.  According to the DB file, I had 473 notes.

This is the command I used. I hope it can be of help to others!

bash% COUNTER=1; while [ $COUNTER -lt 474 ]; do ZCOUNT=${COUNTER}; [ $ZCOUNT -lt 100 ] && ZCOUNT="0${ZCOUNT}"; [ $COUNTER -lt 10 ] && ZCOUNT="00${ZCOUNT}"; sqlite3 ./notes.sql3 "SELECT writefile('/home/mk/Documents/object${ZCOUNT}.gz', zdata) FROM ZICNOTEDATA WHERE z_pk = ${COUNTER};"; zcat /home/mk/Documents/object${ZCOUNT}.gz | strings > /home/mk/Documents/note-${ZCOUNT}.txt; COUNTER=$((COUNTER+1)); done