This blog post is about how to efficiently spot code mutations between distinct versions of an Android application.

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)