▄▄▄▄· ▪ ▄▄▄▄▄▄▄▌ ▄▄ • ▐█ ▀█▪██ •██ ██• ▪ ▐█ ▀ ▪ ▐█▀▀█▄▐█· ▐█.▪██▪ ▄█▀▄ ▄█ ▀█▄ ██▄▪▐█▐█▌ ▐█▌·▐█▌▐▌▐█▌.▐▌▐█▄▪▐█ ·▀▀▀▀ ▀▀▀ ▀▀▀ .▀▀▀ ▀█▄▀▪·▀▀▀▀
2016/09/22 Cecill Etheredge // ijsf
For a while now, I’ve been on the lookout for a proper ruggedized Android phone that doesn’t cost an arm and a leg. Since the low-end and counterfeit spectrum of Android phones seems to be dominated by Chinese MediaTek-based phones these days, and the turnaround time of new phone models is incredibly high over there, it made sense to scout the Chinese markets every once in a while to see what’s new.
Up until about a week ago, my usual searches typically ended up with phones that were either way too expensive (can’t risk too much money) or had poor/outdated specs (e.g. slow SoCs, no 3G/4G connectivity, poor screen resolution, little memory). Fortunately, this time around I did find one that seemed to suit me quite well, the Blackview BV6000s.
The Blackview BV6000s mentions a rating for IP-68, contains a fairly recent MT6735 SoC with 2 GiB of RAM, has support for Dual SIM along with some other good and redundant features and runs on Android 6.x. Though, what’s especially nice is that Blackview maintains its own community forum that contains very recent firmware updates, which seems to become more common these days for Chinese quality vendors.
That’s it for the reviewing part, because there are more important things at hand. Following the infamous practice of “taking it apart before turning it on”, I very much like to find out what my phone is doing while I’m (not) looking, so taking apart the firmware is almost mandatory, and in fact something I believe people should do more often in something as essential as a phone.
Public availability of firmware updates is great if you want to check out whether the stock ROM on the phone is clean, and if the vendor actually cares about its customers in terms of privacy and such. Since I like to know as much as possible about what’s running on my phone, this is a great opportunity to take the firmware apart and figure out any hidden intentions. This shouldn’t be taken too lightly, as some of my previous firmware dissections of Chinese (counterfeit) phones uncovered different types of preinstalled spy/malware.
Let’s start off with the tools to take apart a modern typical Android ROM firmware:
system.imgfile to a (loopback) mountable image, e.g. as available from anestisb/android-simg2img on Github.
system.img, which is typically EXT4 nowadays if you’re using OS X.
These tools should provide enough to unpack the system image file,
system.img, containing all the preloaded Dalvik/Android Runtime applications, and then to reverse engineer each of these. The idea here to figure out for each of these applications if they are original Android applications or whether they have been modified by the vendor for compatibility with the phone, or to possibly add malicious or data leaking code such as “phone home” functionality or ordinary phone spying.
As with most firmwares, the latest available firmware for the Blackview BV6000s is simply a ZIP file containing the various images, including the system image, along with some vendor-specific MediaTek flash configuration files. Mounting the
system.img is therefore quite easy, as it is easily accessible and just needs to be unpacked and mounted:
$ ./simg2img system.img system.img_unpacked $ ./mount -o loop system.img_unpacked /mnt
In case you’re using OS X, you should use the
ext4fuse command to mount the image instead. Doing a simple filename search for .apk and .odex extensions reveals a large collection of about 250 installed applications in the following directories:
/app /framework /priv-app /vendor/operator/app
Prior to writing this article, I had already reverse engineered most of the applications in these folders, including those with unknown and suspicious filenames. Decompiling the .apk and .odex files is in fact quite easy:
$ apktool d -f -o apk FILENAME.apk $ baksmali -x -c boot.oat -d /PATH/TO/framework oat/arm64/FILENAME.odex -o odex
The use of apktool will allow you to inspect the resources of the .apk file, typically the Android manifest (e.g. describing permissions), any images, localization strings and settings. In addition, the baksmali tool will decompile the Dalvik/Android Runtime bytecode into human-readable form for inspection of (a fairly rough form of) the inner workings of the applications themselves. This tool requires the presence of the
boot.oat framework file, which is typically found in the
framework directory of the system image. Furthermore, the smali/baksmali tools also allow you to recompile the app, in case you want to do any modifications such as removing unwanted code or constants.
To summarize the apps I found on the stock firmware, let’s start with the Google apps and any optional non-essential apps that are typically preinstalled on Android phones:
./app/BasicDreams ./app/Exchange2 ./app/FaceLock ./app/Galaxy4 ./app/Gallery2 ./app/GoogleCalendarSyncAdapter ./app/GoogleContactsSyncAdapter ./app/GoogleEars ./app/GoogleTTS ./app/HTMLViewer ./app/HoloSpiralWallpaper ./app/LiveWallpapers ./app/LiveWallpapersPicker ./app/Maps ./app/NoiseField ./app/PhaseBeam ./app/PhotoTable ./app/PicoTts ./app/PrebuiltGmail ./app/Videos ./priv-app/GoogleBackupTransport/GoogleBackupTransport ./priv-app/GoogleFeedback/GoogleFeedback ./priv-app/GoogleLoginService/GoogleLoginService ./priv-app/GoogleOneTimeInitializer/GoogleOneTimeInitializer ./priv-app/GooglePartnerSetup/GooglePartnerSetup ./priv-app/GoogleServicesFramework/GoogleServicesFramework ./priv-app/ManagedProvisioning/ManagedProvisioning ./priv-app/Phonesky/Phonesky ./priv-app/PrebuiltGmsCore/PrebuiltGmsCore ./priv-app/ProxyHandler/ProxyHandler ./priv-app/talkback/talkback ./priv-app/Velvet
In the above list, we can identify apps such as a few live wallpapers, all the usual Google services, along with Google apps such as Google Play (
Phonesky, PrebuiltGmsCore), Google App (
Velvet) and other obvious stuff. Needless to say, these have all been removed (including their libraries and any auxiliary files) in an attempt to get the most barebones stock firmware possible.
Next up are the MediaTek or vendor-specific applications, including any stock Android applications that have been modified. Let’s start off with the apps that were either documented on the internet, or seemed non-essential just by looking at their name:
./app/AdupsFota (adups.cn Firmware-Over-The-Air service) ./app/AdupsFotaReboot (adups.cn Firmware-Over-The-Air service) ./app/MiraVision (Helper app for MediaTek's MiraVision feature) ./app/MtkBrowser (Default browser as supplied by MediaTek) ./app/com.agold.compass (Compass app) ./priv-app/AgoldWallPaper (Wallpaper) ./vendor/operator/app/jks12_facebook (OEM Facebook app) ./vendor/operator/app/jks12_twitter (OEM Twitter app) ./vendor/operator/app/jks12_xender (OEM Xender app)
Again, these applications have been deemed non-essential, and have been removed from the firmware. The following list is more interesting:
./app/AgingTest ./app/Gba ./app/HetComm ./app/MTKLogger ./app/MtkCalendar ./app/MtkFloatMenu ./app/LocationEM2 ./app/NlpService ./app/Omacp ./app/Uicc1Terminal ./app/Uicc2Terminal ./app/VoiceCommand ./app/YGPS ./app/agold.AgoldFactoryTest ./app/eSETerminal ./plugin/DataProtection ./plugin/FwkPlugin ./plugin/PermissionControl ./plugin/PrivacyProtectionLock ./priv-app/ImsService ./priv-app/Launcher3 ./priv-app/MtkMms
For these applications, it was next to impossible to either find out what they are, what they’re doing, or whether they had been modified by the vendor. After a long session of reverse engineering, I was able to document the exact functionality for each of these apps.
In the list below, non-essential applications have been marked in blue, (potentially) essential system applications have been marked in green, and (potentially) essential suspicious applications have been marked in red.
*.google.comhosts, possibly leaking data.
ro.build.characteristicsand implements MediaTek specific Android permissions for apps (e.g.
user@chinaTel.com) and IP addresses (
./com/mediatek/ims/MMTelSSTransport. However, these appear to be test credentials that have been left in.
isms.hissage.com. App appears to be based off “Hissage iSMS”.
127.0.0.1), unknown IP address (
18.104.22.168) and the usual Google AGPS host (
supl.google.com) in com/mediatek/lbs/em2/ui/LbsMisc.
22.214.171.124appears to be a China Mobile AGPS server as an alternative to
To summarize, all non-essential apps were removed from the system image and all other apps have been left in place, as I did not manage to find any malicious code thus far, and I highly doubt I will find any at all (unfortunately). The level of bloatware on this phone is also very acceptable.
If a vendor does have malicious intent, it is most likely that any malicious code would be added at this level of the system, e.g. in any preloaded system apps that come installed on the stock firmware, since these apps normally cannot be removed. Though, a much more sophisticated attempt at preloading spy/malware would involve infecting lower level system files such as binary shared object libraries, system daemons, or even the drivers or baseband processor. The most obvious way of finding malicious agents on this level would be to monitor all in- and outgoing traffic on packet or even radio level.
However, given the transparency and surprisingly good community support of this particular Chinese vendor, the absence of counterfeit branding, along with the relatively very clean stock installation thus far just makes it all the more unlikely that spy/malware is present on this device at any level.
Too bad, but better luck next time!