This blog post is about techniques to disable Android runtime restrictions

As few seats are still available for next session of the Android training [1], we setup a crackme challenge for which you have to find the correct phone number that leads to the following message:

Earlier this year, on March 2018, we published a blog post detailing 2 vulnerabilities in the Android Bluetooth stack, which were independently discovered by Quarkslab, but were fixed in the March 2018 Android Security Bulletin while we were in the process of reporting them to Google.

On how we used LIEF to lift an Android x86_64 library to Linux to perform our usual white-box attacks on it.

The March 2018 Android Security Bulletin includes fixes for 10 vulnerabilities in its Bluetooth stack, some of which were also independently discovered by Quarkslab, but were fixed while we were in the process of reporting them to Google (spoiler alert: we have reported a few more new Bluetooth vulnerabilities to the Android team — we'll disclose the details after they get fixed). This blogpost shows technical details for a couple of these fixed bugs, which can be triggered remotely and without any user interaction, as well as proof-of-concept code for them.

In my previous article [1], I explained how to load Samsung's proprietary bootloader SBOOT into IDA Pro. The journey to the TEE OS continues in this second article which describes two techniques to locate Trustonic's TEE <t-base in the binary blob.

Various Samsung Exynos based smartphones use a proprietary bootloader named SBOOT. It is the case for the Samsung Galaxy S7, Galaxy S6 and Galaxy A3, and probably many more smartphones listed on Samsung Exynos Showcase [1]. I had the opportunity to reverse engineer pieces of this bootloader while assessing various TEE implementations. This article is the first from a series about SBOOT. It recalls some ARMv8 concepts, discusses the methodology I followed and the right and wrong assumptions I made while analyzing this undocumented proprietary blob used on the Samsung Galaxy S6.

This article explains a recently disclosed vulnerability, independently discovered by the Google's Project Zero team and by Quarkslab some months ago. To our knowledge, this vulnerability was present, on all Samsung devices using Android 5, and allowed remote code execution as system user simply by browsing a website, by downloading an email attachment or via a malicious third party application with no permission.

Multiple kernel vulnerabilities in the Samsung S4 (GT-I9500)

UPDATE: A way to patch the vulnerability is provided at the end of the article. We explain a vulnerability found when the Samsung Galaxy S5 was released and patched recently by Samsung. It allows a remote attacker to install an arbitrary application by using an unsecure update mechanism implemented in the UniversalMDMClient application related to the Samsung KNOX security solution. The vulnerability has been patched on the Samsung Galaxy S5 but also Note 4 and Alpha. Yet the Samsung Galaxy S4, S4 mini, Note3 and Ace 4 (and possibly others) are still vulnerable.