Uncategorized

Signing boot images for Android Verified Boot

Signing boot images for Android Verified Boot (AVB)
Various Android devices support Android Verified Boot (AVB). A part of this is more commonly known as dm-verity, which verifies system (and vendor) partition integrity. AVB can however also verify boot images, and stock firmwares generally include signed boot images. Of course this does not mean that all signed boot images are using AVB, many OEMs have their own signature verification scheme. Note: AOSP is moving towards the use of avbtool (taken from Brillo), the following is the old way for signing boot images. Bootloaders might or might not accept unsigned boot images, and might or might not accept boot images signed with our own keys (rather than the OEM’s keys). This depends on the device, bootloader version, and bootloader unlock state. For example, with the bootloader unlocked, the Google Pixel (and XL) devices accepted unsigned boot images up to (but not including) the May 2017 release. From the May 2017 release onwards, the boot images must be signed if flashed (booted works without), but may be signed with your own key rather than the OEM’s. Note: The situation changes when you re-lock the bootloader. I have not tested this, but documentation implies that (one of) the keys used in the current boot image must be used for future flashes until it is unlocked again.[…]

https://forum.xda-developers.com/android/software-hacking/signing-boot-images-android-verified-t3600606

More Info:
https://source.android.com/security/verifiedboot/
https://source.android.com/security/verifiedboot/verified-boot
http://blog.andrsec.com/android/2016/03/26/android-verified-boot.html

 

Standard
Uncategorized

Exploiting Samsung’s Secure Bootloader (S-Boot) for Android

Exploiting Android S-Boot: Getting Arbitrary Code Exec in the Samsung Bootloader (1/2)
Nitay Artenstein (@nitayart) and Gilad Goldman (@gnull00)

Samsung’s Secure Bootloader (S-Boot) for Android lies at the heart of Samsung’s chain of trust concept. An attacker who compromises S-Boot could potentially load an untrusted kernel and system image, therefore bypassing most of the phone’s security mechanisms. This is a well-known attack vector: It’s often used by the Android rooting and modding community, but our guess is that it’s way more popular with law enforcement and government agencies. All the more interesting, then, that S-Boot on contains several memory corruption bugs, one of which could be used to reach full code execution within the bootloader. We can currently confirm the existence of the vulnerability only on Exynos chipsets. It seems universal to approximately 90% of the Samsung Exynos ROMs running on S5, S6 and S7. The very newest ROMs for S7 (February 2017) appear to include a fix for this bug, but we’ll confirm this in a few days. There’s a lot of ground to cover, so we’ll break up this write-up into two posts. In this post we’ll focus on some S-Boot internals, then explore the bootloader’s attack surface and get basic debugging capabilities. We’ll end the post with the discovery of an especially interesting attack surface. In the next post we’ll disclose the actual vulnerability and how we exploited it to get code execution in S-Boot. We won’t go into much detail on the basics of reversing S-Boot, such as how to load it into IDA or find the base address. Fernand Lone Sang (@_kamino_) is about to publish a great article exactly about that and I’ll put a link for it here when it’s out. If you need any help beyond that, just DM me and I’d be glad to give you a hand if I can.[…]

Standard
Uncategorized

Android Things

Supported hardware: Intel® Edison, Intel® Joule, NXP Pico i.MX6UL, Raspberry Pi

https://github.com/androidthings
https://developer.android.com/things/hardware/index.html
https://developer.android.com/things/index.html
https://developer.android.com/things/preview/index.html
https://developer.android.com/things/hardware/developer-kits.html
https://android-developers.googleblog.com/2017/02/android-things-developer-preview-2.html

 

 

Standard
Uncategorized

OnePlus bootloader vulnerabilities

 

Owning a Locked OnePlus 3/3T: Bootloader Vulnerabilities
Feb 08, 2017 • Roee Hay
In this blog post I disclose two vulnerabilities in the OnePlus 3/3T bootloader. The first one, CVE-2017-5626, is a critical severity vulnerability affecting OxygenOS 3.2-4.0.1 (4.0.2 is patched). The vulnerability allows for a physical adversary (or one with ADB/fastboot access) to bypass the bootloader’s lock state, even when Allow OEM Unlocking is disabled, without user confirmation and without triggering a factory reset. This vulnerability allows for kernel code execution (albeit with a 5 seconds warning upon boot). The second vulnerability, CVE-2017-5624, affecting all versions of OxygenOS to date (Feb 10 UPDATE: OxygenOS 4.0.3, released Feb 09, seems to be patched), allows the attacker to disable dm-verity. The combination of the vulnerabilities enables a powerful attack – persistent highly privileged code execution without any warning to the user and with access to the original user’s data (after the victim enters his credentials). Both issues were responsibly disclosed to and acknowledged by OnePlus Security. The first vulnerability, CVE-2017-5626, was reported on January 23rd. It was also found independently by a OnePlus engineer. CVE-2017-5624, reported on January 16th, should be fixed in a future OxygenOS release – the reason for its today’s public disclosure is because someone already published it on January 24th. Disclaimer: I tested the vulnerabilities on OnePlus 3 only, but OnePlus 3T contains the vulnerable code too.[…[

https://securityresear.ch/2017/02/08/oneplus3-bootloader-vulns/

https://oneplus.net/3t

 

Standard
Uncategorized

aboot-parser: Android bootloader parser

Script to parse Android bootloader (aboot) images, extract certificates and verify image signature. May not work on aboot from latest devices. Signature verification follows the ‘Secure Boot and Image Authentication Technical Overview’ whitepaper by Qualcomm. Cf.  https://www.qualcomm.com/documents/secure-boot-and-image-authentication-technical-overview/ Aboot header format as described in  http://newandroidbook.com/Articles/aboot.html See above article for more details about aboot. Inspired by https://github.com/kayrus/kc_s701_break_free
[…]

https://github.com/nelenkov/aboot-parser

Standard
Uncategorized

IBM on attacking Android Custom Boot Modes

IBM’s SecurityIntelligence has a story on attacking Android’s Custom Boot Modes.

Android Vulnerabilities: Attacking Nexus 6 and 6P Custom Boot Modes
By Roee Hay
Co-authored by Michael Goberman.

In recent months, the X-Force Application Security Research Team has discovered several previously undisclosed Android vulnerabilities. The November 2016 and January 2017 Android Security Bulletins included patches to one high-severity vulnerability, CVE-2016-8467, in Nexus 6 and 6P. Our new paper, “Attacking Nexus 6 & 6P Custom Bootmodes,” discusses this vulnerability as well as CVE-2016-6678.[…]

https://securityintelligence.com/android-vulnerabilities-attacking-nexus-6-and-6p-custom-boot-modes/

Standard
Uncategorized

CyanogenMod dies

https://www.xda-developers.com/the-death-of-cyangenmod-and-whats-in-store-for-the-future/

http://www.androidcentral.com/remembering-cyanogenmod

https://cyngn.com/blog/the-future-of-cyanogen-and-the-untapped-power-of-mobile

https://cyngn.com/blog/cyanogen-services-shutting-down

Standard