Demystifying Android Physical Acquisition

Demystifying Android Physical Acquisition
May 29th, 2018 by Oleg Afonin

Numerous vendors advertise many types of solutions for extracting evidence from Android devices. The companies claim to support tens of thousands of models, creating the impression that most (if not all) Android devices can be successfully acquired using one method or another. On the other side of this coin is encryption. Each Google-certified Android device released with Android 6.0 or later must be fully encrypted by the time the user completes the initial setup. There is no user-accessible option to decrypt the device or to otherwise skip the encryption. While this Google’s policy initially caused concerns among the users and OEM’s, today the strategy paid out with the majority of Android handsets being already encrypted. So how do the suppliers of forensic software overcome encryption, and can they actually extract anything from an encrypted Android smartphone locked with an unknown passcode? We did our own research. Bear with us to find out![…]

https://blog.elcomsoft.com/2018/05/demystifying-android-physical-acquisition/

Android bootloader flow documentation published

Alex Deymo notes that the Android project has more documentation on their boot process, and posted about it on the U-Boot mailing list:

“Just an FYI, earlier this month the team spent some time polishing and publishing in source.android.com documentation about the flows the bootloader goes through in Android, specially true for stock Android like in Pixels phones or other devices based of recent AOSP versions. This documentation includes the interaction between userspace and the bootloader such as the properties userspace expects when booting A/B devices, the whole A/B flow, the bootloader message in the misc partition (BCB), how they interact with the “recovery mode” in Android and much more.

https://lists.denx.de/pipermail/u-boot/2018-May/329886.html

https://source.android.com/devices/bootloader/

Intel reboots Android-IA as Project Celadon

We are excited to let you know about the refresh of the Android-IA project called Celadon. Celadon is the open sourced Android reference stack for Intel architecture that you are already familiar with, but now with more added to the stack. What started with a few open source drivers support including Mesa i965, I915 Linux Kernel Graphics Driver, and Video Acceleration API last year has since grown into a feature-rich Android stack for IA. Celadon will continue to be dedicated to driving Android support and innovation on IA in addition to providing a place for collaboration. We believe Celadon can help you enhance validation, debug and accelerate development across Android implementations on IA platforms.

https://lists.01.org/pipermail/celadon/2018-May/001235.html
https://lists.01.org/pipermail/celadon/2018-May/001237.html
https://01.org/projectceladon
https://github.com/projectceladon

GLitch: a remote Rowhammer exploit on ARM Android devices

What is GLitch?

GLitch is one part of our series of Rowhammer attacks. We started by breaking the EDGE browser and the cloud. Then we moved towards Android devices showing how to root them with bit flips. This time we wanted to show that also mobile phones can be attacked remotely via the browser.
Meet GLitch: the first instance of a remote Rowhammer exploit on ARM Android devices. This makes it possible for an attacker who controls a malicious website to get remote code execution on a smartphone without relying on any software bug.
You want to know what makes this attack even cooler? It is carried out by the GPU. This is the first GPU-accelerated Rowhammer attack.[…]

https://www.vusec.net/projects/glitch/

 

copperheadOS: Samsung missing security features needed for Android Verified Boot

Tweets from CopperheadOS, a security-centric Android-based distribution, are a good source of Android security news, since they’re stretching the boundaries of the open source android release.

postmarketOS: liberating bootloaders and cellular modem firmware of MediaTek phones

Liberating Bootloaders and Cellular Modem Firmware of MediaTek Phones

As a community project, and one that encourages contributors to work on what they like, we have attracted people with a broad range of interests and skill levels. Recently a small hacking group #postmarketOS-lowlevel has emerged, and its masterminds @McBitter and @unrznbl are eager to introduce you to the madness that awaits when digging deeper and deeper in the embedded hardware and software stack. But before we get started, please keep in mind that these are moon shots. So while there is some little progress, it’s mostly about letting fellow hackers know what we’ve tried and what we’re up to, in the hopes of attracting more interested talent to our cause. After all, our philosophy is to keep the community informed and engaged during the development phase! For those new to postmarketOS, we are a group of developers, hackers, and hobbyists who have come together with a common goal of giving a ten year life cycle to mobile phones. This is accomplished by using a simple and sustainable architecture borrowed from typical Linux distributions, instead of using Android’s build system. The project is at an early stage and isn’t useful for most people at this point. Check out the newly-updated front page for more information, the previous blog post for recent achievements, and the closed pull requests to be informed about what’s going on up to the current minute. Let’s dive in!

https://postmarketos.org/blog/2018/04/14/lowlevel/

https://github.com/postmarketOS/
https://wiki.postmarketos.org/wiki/Devices

 

Google introduces Android Enterprise Recommended program

https://www.android.com/enterprise/recommended/requirements/

https://www.android.com/enterprise/recommended/

https://androidenterprisepartners.withgoogle.com/#!/results/browse-all/2

CopperheadOS on Android Verified Boot 2.0 docs

https://android.googlesource.com/platform/external/avb/#device-specific-notes

https://android-review.googlesource.com/c/platform/external/avb/+/582100

oppo_decrypt – Oppo/Oneplus .ops Firmware decrypter

oppo_decrypt – Oppo/Oneplus .ops Firmware decrypter

Tested with “MSMDownloadTool V4.0” for Oneplus 5, Frida 10.4 and Windoze
backdoor.py : Enables hidden “readback” functionality
decrypt.py : Decrypts any part of the firmware
Based on Frida.re and python 3.6
Windows only, sorry folks !
Oneplus 5 QD-Loader decryption: ‘python decrypt.py “MsmDownloadTool V4.0.exe” 0 0x92880’
Enable readback mode: ‘python backdoor.py “MsmDownloadTool V4.0.exe”‘

https://github.com/bkerler/oppo_decrypt

http://www.oppo.com/
https://oneplus.net/

 

dump_avb_signature: dump/verify Android Verified Boot signature hash

Dump/Verify Android Verified Boot Signature Hash
For researching Android Verified Boot issues
To exploit TZ image verification 🙂

python verify_signature.py boot.img

Issues: Might not work with AVB Version 2.0 or higher

https://github.com/bkerler/dump_avb_signature

 

Halium for Android-IA/Clovertrail+

Ilya Bizyaev posts on the Intel Android-IA mailing list about working to get Halium port of the ASUS ZenFone5:

I am writing to announce that I am working on a Halium (halium.org) port for ASUS ZenFone 5, a Clovertrail+ based phone. Porting Halium base to this Intel platform enables numerous open-source projects, including Ubuntu Touch (ubports.com), Plasma Mobile (plasma-mobile.org), LuneOS (webos-ports.org) and Mer (merproject.org) to use all of the Clovertrail+ devices for development and testing. I am proud to report that as of now, the Halium build system supports using custom Intel boot tools, and the device boasts a stable 3.10 kernel and Android 7.1-based system build that has Wi-Fi, touch sensor, hardware keys, LEDs and vibrator working.

Full post:  android-ia@lists.01.org archives.

https://github.com/Halium/android_kernel_asus_T00F
https://github.com/Halium/android_device_asus_T00F

Hmm, I didn’t know about Halium…

https://halium.org/

https://halium.org/announcements/2017/04/24/halium-is-in-the-air.html

From the Halium blog’s initial post:

Over the years, various efforts have been made to bring GNU/Linux to mobile devices (for example Maemo, Meego, Mer, SailfishOS, Ubuntu Touch, Plasma Mobile). They have either achieved their individual goals or are working in direction of achieving them. During the development of such projects it was suggested multiple times that these communities should work together as their ultimate goal is the same. However due to various reasons this never happened in the past. However we believe that it is time to change this situation. Currently distributions like AsteroidOS, LuneOS, Mer, Plasma Mobile, SailfishOS, and Ubuntu Touch have one thing in common that they use the libhybris to interact with the android binary blobs and they also run the various android daemons using different methods. And there is lot of fragementation on how this task is handled even though these parts don’t need to be different as their essential goal is to make use of android binary blobs. Project Halium is the effort by the community which aims to bring the common grounds for different distributions and have a common base which includes the Linux kernel, Android Hardware Abstraction Layer, and libhybris. Project Halium also aims to standardize the middlewares used to interact with the hardware of the device. By having these parts shared, we believe that it will reduce the fragmentation we have currently.[…]

architecture

 

CopperheadOS: business model concerns

CopperheadOS is “A security and privacy focused mobile operating system compatible with Android apps.“.

It appears the company is having problems trying to monetize an open sourced operating system. I hope they can solve things, they’re doing interesting security things with Android.

https://copperhead.co/android/
https://github.com/copperheados/

Android 8.0 and Project Treble

https://www.linux.com/news/2017/9/android-oreo-adds-linux-kernel-requirements-and-new-hardening-features

https://source.android.com/devices/architecture/kernel/modular-kernels#core-kernel-requirements

“The Android 8.0 release includes Project Treble, a major re-architect of the Android OS framework designed to make it easier, faster, and less costly for manufacturers to update devices to a new version of Android. Treble is for all new devices launching with Android 8.0 and beyond (the new architecture is already running on the Developer Preview for Pixel phones).[…]”

Android: Untethered initroot

Untethered initroot (USENIX WOOT ’17)
By Roee Hay (@roeehay)
August 30, 2017
CVE-2016-10277 ALEPH-2017024

In USENIX WOOT ‘17, that took place earlier this month in Vancouver, we presented our paper, “fastboot oem vuln: Android Bootloader Vulnerabilities in Vendor Customizations”, covering a year’s work in Android bootloaders research. Our paper also includes some previously undisclosed details on CVE-2016-10277, a critical kernel command-line injection vulnerability in the Motorola Android Bootloader (ABOOT) that we had found and blogged about. In the previous couple of blog posts, we demonstrated a tethered unrestricted root exploit against that vulnerability, that we later extended to other Moto devices – G4 & G5. Additional Moto devices have also been confirmed by the community. In the WOOT’17 paper we describe a natural continuation of that exploit – a second stage untethered secure boot & device locking bypass (tested to be working on the vulnerable versions of Nexus 6, Moto G4 & G5). Moreover, we also present in the paper and this blog post other second stage exploits, such as persistent kernel code execution in Nexus 6, the ability to downgrade critical partitions (such as the bootloaders chain and TrustZone), unlocking a re-locked Nexus 6 bootloader, and more. As usual, our PoC exploit is publicly available in our GitHub repo. DISCLAIMER: Unlike the previous ephemeral jailbreak, the one presented today may brick your device. For example, during the development of it, we had to unlock our (luckily unlockable!) Moto G5 device in order to unbrick it.[…]

https://alephsecurity.com/2017/08/30/untethered-initroot/
https://github.com/alephsecurity/initroot
https://www.usenix.org/conference/woot17/workshop-program/presentation/hay
https://alephsecurity.com/2017/05/23/nexus6-initroot/

Android Oreo docs on keymaster3 and HIDL

In Android 8.0, Keymaster 3 transitioned from the old-style C-structure Hardware Abstraction Layer (HAL) to the C++ HAL interface generated from a definition in the new Hardware Interface Definition Language (HIDL). As part of the change, many of the argument types changed, though types and methods have a one-to-one correspondence with the old types and the HAL struct methods.[…]

https://source.android.com/security/keystore/

https://source.android.com/devices/architecture/

https://source.android.com/security/keystore/attestation

https://developer.android.com/training/articles/security-key-attestation.html

https://source.android.com/devices/architecture/hidl/

https://android.googlesource.com/platform/system/tools/hidl/

Android Oreo Verified Boot’s Rollback Protection

This flew under our radar back at I/O, but it’s big news. On compatible devices, the new Verified Boot changes in Android 8.0 Oreo will prevent a device from booting should it be rolled back to an earlier firmware. The new feature is called Rollback Protection. So if your phone is flashed with older software, you (and your data) are protected from whatever potential security vulnerabilities may have been present in earlier versions. For 99% of users, the new Rollback Protection is great news. If a phone is lost or stolen, it further decreases the number of potential attacks which could be used to gain access, providing better safety for your data.[…]

http://www.androidpolice.com/2017/09/05/android-oreo-feature-spotlight-changes-verified-boot-wont-allow-start-downgraded-os/

https://android.googlesource.com/platform/external/avb/#Rollback-Protection