Inside ElcomSoft Lab. Part 1

January 20th, 2017 by Oleg Afonin
Category: «General», «Hardware»

Staying on the bleeding edge of today’s technologies requires constant work. ElcomSoft lab is one of the busiest places in the company. Last year, we had dozens of devices passing through our lab. This publication opens the series of articles in which we’ll share insider’s information on what we do, what we are about to do, and how we do that. So let’s shed some light on what’s going on inside ElcomSoft lab.

Android

ElcomSoft doesn’t do Android. Or, rather, we didn’t do Android until very recently. The sheer variety of Android hardware, versions and OEM customizations are driving us crazy. However, we did our best to get a grip on what’s happening on the dark side. Last year (and early this year), we purchased a multitude of devices to research their security model. Just a small sample of devices we have on our shelves:

LG G Flex 2

We purchased this phone for a number of reasons. First, it’s an LG, and it comes with LG service mode. The LG UP mode is designed to facilitate firmware updates in a case of a bricked device. However, the protocol was promptly reverse-engineered by independent researchers. It so happened that the service mode works in both directions, allowing experts to actually download the full content of the phone’s storage in a matter of minutes and with very little effort. Granted, full-disk encryption helps in this regard, but this phone was released with Android 5.0 out of the box, meaning that encryption is not active out of the box.

Another thing was LG Backup, the built-in app to back up the content of the device without root access. This works even if full-disk encryption is active. LG Backup saves all sorts of data it shouldn’t be saving, including data from apps whose developers explicitly disabled backups. For one, we were able to extract Google Authenticator secrets, which allowed us to bypass Two-Factor Authentication in several cases.

Did I mention there was more than one reason for getting this phone? It’s curved! 🙂 The highly unusual shape and its unorthodox POLED display could be its unique selling points should’ve LG decided to not cripple this model. Unfortunately, the 16GB of storage and only 2GB of RAM in the international model made this Snapdragon 810 phone an overheating midranger.

We featured this phone in our book, Mobile Forensics: Advanced Investigative Strategies. These days, it serves us for testing LG software and cloud backups. We have all sorts of troubles trying to make Google back up the phone to Google Drive.

A very interesting and unique device. They don’t make it anymore.

ASUS ZenPad S 8.0

It’s a tablet. We wanted one with an Intel chip to check out Android x86, or Android-on-Intel. We were amazed to discover that this tablet shipped with exploitable, semi-unlocked bootloader. We were able to boot into a custom CWM recovery and image the device even with bootloader being “locked”. This did not trigger a data wipe (it normally should). Full-disk encryption should help here, but this tablet did not come with encryption enabled out of the box.

ASUS also had a proprietary backup tool bundled with its Android 5.0.2 ROM. Similar to LG, this tool made backup copies of data it should not have touched. Interestingly, ASUS disabled backup functionality in Android 6.0 update. The Marshmallow update also fixed the bootloader exploit, which existed unpatched for over a year.

We showed its backup structure in our book. Nowadays, Intel scaled down its Android efforts significantly. This little tablet mostly sits unused in our lab.

Gigaset ME and ME Pro

A very interesting device and a classic Android. Built by Gigaset, a German company, these phones were marketed as flagship devices and carried corresponding price tags. Faced with slower than expected sales, Gigaset abandoned these phones and halted updates. As a result, these devices still run their original firmware based on Android 5.1.1.

This phone is equipped with a fingerprint reader, and this was exactly the reason why we wanted one in the lab. Android 5.x does not have a fingerprint API. OEMs did their best (or their worst) trying to integrate fingerprint readers in their devices. We investigated fingerprint unlock in this model, and discovered it’s a complete disaster. If fingerprint unlock is enabled, bypassing it is a matter of a few simple manipulations.

Once we started working with this device, we couldn’t miss the Qualcomm HS-USB 9008 mode. This mode is the lowest-level unbrick solution for select Qualcomm chipsets. In this phone, a factory unbrick image leaked, allowing us to image the entire storage of the device with a single command in a terminal window. That’s all I wanted to say about security of self-proclaimed Android “flagships”.

This phone didn’t make it to our book (if only we could have it earlier!), but we still featured this phone in the blog: Fingerprint Readers in pre-Android 6 Smartphones: A Call for Disaster

Motorola Nexus 6

While working on Android, we couldn’t do without a Nexus device. While we do have an old Nexus 5, a single old-timer was not nearly enough for a research. So we bought a Nexus 6. And another Nexus 6. Four of them, in fact. Its unlockable bootloader, up-to-date Android with published source code and a large community of developers made this a no-brainer.

Nexus 6 was the first Android smartphone to have full-disk encryption enabled (and enforced) out of the box. Unfortunately, Google didn’t make it right. If they wanted to promote full-disk encryption, they should’ve used the Qualcomm dedicated cryptographic co-processor instead of forcing the main CPU do encryption. Something didn’t work as planned in Google’s land, and this phone received the slowest storage performance ever.

In our blog article Smartphone Encryption: Why Only 10 Per Cent of Android Smartphones Are Encrypted we researched Android encryption using this phone as a glaring example. There is a terrible drop of storage performance, with encrypted sequential read speeds being more than 5 times slower comparing to unencrypted sequential reads.

AnandTech measured the following numbers:

In our own benchmarks, we can only confirm their findings:

While Google wanted to be like Apple, Nexus 6 storage performance was 6.7 times slower comparing to then-current Apple iPhone 6 because of the terrible implementation of encryption.

In addition, we featured this phone in the Understanding and Bypassing Reset Protection research.

Amazon Fire Phone

Amazon Fire Phone is an odd duckling in the world of Android smartphones. Equipped with Snapdragon 800 and either 32GB or 64GB of storage, this phone introduced a highly innovative gimmick. It has four IR cameras tracking the user’s face to draw animated 3D-like interface that would follow the user’s eyes. A long list of LTE bands made this little device a perfect traveling companion.

Running Fire OS, Amazon’s Android fork, this phone did not have support for Google Cloud Messaging platform. Without Google certification and with no Google services running or even available, this phone never sold well, was quickly discounted and discontinued.

We purchased a bunch of these phones to research Amazon mobile ecosystem and cloud infrastructure. However, with Amazon discontinuing its entire phone branch, we never made any real advances in this direction. Still, with Amazon tablets making record sales, we’ll be investing more into Amazon, but this time we’ll do tablets.

Oppo Find 7

Practically unknown in the Western world, Oppo (along with its sub brands Vivo, BBK and OnePlus) is the largest smartphone manufacturer in China. We wanted to test one of their devices. As is the case with most Chinese smartphones, the Find 7 comes with unlockable bootloader. The company published full kernel sources, boosting third-party development. There are also tools for unbricking the phone via Qualcomm HS-USB 9008, so we could dip into that mode when researching physical acquisition.

Currently, Oppo Find 7 is the only non-Nexus device running the latest (unofficial) version of Android 7.1.1. We are using it to test things such as cloud SMS backups.

Xiaomi mi4c

China is a huge market, and Xiaomi is one of the major players. We wanted a phone that would natively run MIUI, a popular Android ROM. MIUI has its very own cloud services offering comprehensive backup capabilities (much more comprehensive and much less secure compared to Google backups), and has a tool for making local backups without root access. All this is invaluable for a researcher.

LeEco Le Max 2

One of the most affordable Snapdragon 820 devices, this phone features unlockable bootloader and has the complete source code. At this time, we’re using it for testing SMS cloud backups and fingerprint security. The latter issue is extremely interesting, as it clearly shows the differences between Google-certified and non-certified firmware. This phone works with a custom version of Android 6.0.1 the company (LeEco) calls EUI. There a several versions of EUI, each targeting a certain regional market. While the obvious difference of the Chinese ROM is the absence of Google Play Services and Google Play Store, we didn’t expect to see the other difference. The Chinese version of EUI allows using fingerprint unlock immediately after cold boot. This in turn means that fingerprint data is not encrypted (the phone does not ask for passcode). In addition, the Chinese ROM does not force encryption.

On the other hand, properly certified versions of EUI such as those made available for the Indian market come with full set of Google Play Services, have encryption activated and enforced out of the box, and adhere to Google’s published security guidelines. Once you boot a phone with the Indian ROM, you will have to enter a passcode before you are able to use fingerprint unlock.

This is most interesting considering we’re talking about exactly the same device running what’s basically is the same ROM with different regional settings.

Google Pixel

Google Pixel is our last acquisition. It was purchased to test the new and unique iOS > Android migration mechanism that works over the (included in the box) USB-C to Lightning cable. The migration process is extremely interesting and for us well worth the (massive) investment.

Migrating data from an iOS device is only possible when initializing the Pixel. Interestingly, when initializing another Android 7.1.1 smartphone, we’ve also received the prompt to transfer data from “an “iPhone” or “iPad” device”; however, this works through the iOS version of Google Drive (instructions at https://android.com/switch). If you’ve got the Pixel, you’ll be able to transfer data from your iPhone directly into the Pixel via the supplied cable.

In order to perform the transfer, the phone downloads a special migration app from Google. We could not locate that app in the phone after the setup.

Once the iPhone is connected to the Pixel via the USB-C to Lightning cable, the iPhone starts charging from the Pixel. On the iPhone, you are requested to unlock and confirm the “Trust this computer” prompt. In addition, you’ll have to disable iMessage (because the Pixel cannot receive iMessages). If you skip that step, the messages will still be transferred.

Once everything is set up, the Pixel will pull contacts, calendars and messages; pictures and certain types of attachments.

To our amazement, the migration tool analyzed apps installed on the iPhone, and produced a list of apps available in the Play Market. We could simply tap to select, and those apps automatically installed at the end of the process. Application data is not migrated. We are going to research this mechanism in more detail; a report will follow in near future.

Final Words

This is just the beginning of Inside ElcomSoft series. We’ll follow the series with more publications on specific devices, little known features we discover in Android, iOS and Windows 10 Mobile. We’ll talk about some weird issues we face, and we’ll talk more about times when things don’t go according to the plan. Stay tuned!