Forensics acquisition: Analysis and circumvention of Samsung Secure Boot enforced Common Criteria Mode

Forensics acquisition: Analysis and circumvention of samsung secure boot enforced common criteria mode
Gunnar Alendal, Geir Olav Dyrkolbotn, StefanAxelssonab

The acquisition of data from mobile phones have been a mainstay of criminal digital forensics for a number of years now. However, this forensic acquisition is getting more and more difficult with the increasing security level and complexity of mobile phones (and other embedded devices). In addition, it is often difficult or impossible to get access to design specifications, documentation and source code. As a result, the forensic acquisition methods are also increasing in complexity, requiring an ever deeper understanding of the underlying technology and its security mechanisms. Forensic acquisition techniques are turning to more offensive solutions to bypass security mechanisms, through security vulnerabilities. Common Criteria mode is a security feature that increases the security level of Samsung devices, and thus make forensic acquisition more difficult for law enforcement. With no access to design documents or source code, we have reverse engineered how the Common Criteria mode is actually implemented and protected by Samsung’s secure bootloader. We present how this security mode is enforced, security vulnerabilities therein, and how the discovered security vulnerabilities can be used to circumvent Common Criteria mode for further forensic acquisition.

Samsung on root of trust

Starting From Scratch: Trusted Root in Samsung Mobile Devices
Jan 26, 2018 by Joel Snyder

Android’s decoupling of the hardware and operating system brings benefits to IT: It allows application and hardware vendors to compete on innovation, features, form factor, price and security. Samsung Knox is an example of the latter: A combination of hardware features and software enhancements to Android that increase mobile security. Not every Android phone is designed for the enterprise market. Vendors such as Samsung have evaluated the higher security requirements of enterprise customers and have responded by releasing trusted platforms: Devices with built-in hardware that establishes the integrity and identity of the platform and ensures only trusted software is loaded. With a trusted platform, bootkit and rootkit attacks by malware and curious end users are generally blocked. Additionally, data encryption is more difficult to subvert because keys are not software accessible. Today’s technology comes from the Trusted Computing Group (TCG) which publishes the Trusted Platform Module (TPM). TCG started in 2003, defining what a trusted platform would look like, and how it might be implemented and standardized. A TPM is a computer-within-a-computer, completely shielded from the main CPU. Software, whether friendly or unfriendly, can’t reach into the memory or storage of the TPM directly. In larger devices, such as laptops and desktops, the TPM is usually a separate chip.[…]


Reversing/exploiting Samsung’s TrustZone, part 1

Unbox Your Phone — Part I.
This is the first part of a blog series about reverse engineering and exploiting Samsung’s TrustZone. Following parts in the series so far: 2, 3. This first post covers the basics of the architecture. All of this is public info, nothing new, all of it has been covered in bits and pieces in various publications before. Some of it comes from Trustonic/Samsung materials, some of it from open source software, and some of it from the few great instances of prior research. It’s here as an intro, for completeness. Later in the series, I summarize the reverse engineering results and explain the vulnerabilities that I have found.[…]

View story at

View story at


View story at


Reverse Engineering Samsung S6 SBOOT – Part II

Reverse Engineering Samsung S6 SBOOT – Part II
By Fernand Lone Sang

In my previous article, 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. A few months back, I started digging into various TEE implementations and that led me to reverse engineer Samsung’s proprietary bootloader SBOOT [1]. At that time, I suspected that the Trustonic’s TEE <t-base was somehow embedded in the bootloader’s image of Exynos-based smartphones, and it turned out that my assumptions were good. Back then, I used two techniques to locate <t-base in SBOOT but I did not find enough time to cleanup my notes and blog about it until now. This article describes the two techniques I used.[…]

Breaking Samsung Galaxy Secure Boot through Download mode

“A bootloader bug in Samsung Galaxy smartphones allows an attacker with physical access to execute arbitrary code. Protections like OS lock screen and reactivation lock can be defeated. Several attacks are possible, including memory dump. Fortunately countermeasures exist for unpatched devices.”

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.[…]

Samsung S6 Modem firmware reversing

Reverse Engineering Samsung S6 Modem
04 Mar 2016

So I was a little late to the game, and just got my hands on a Samsung Galaxy S6, specifically the SM-G920F which will be the topic of discussion in this post. I am quite curious as to understanding the structure of the device’s modem.bin file. While I haven’t been able to get a de-obfuscated/decrypted version of modem.bin yet, hopefully this post will help others quickly get up-to-speed and assist in the pursuit of one. Anyone interested in helping or contributing can hit me with the Tweets @theqlabs or submit a PR.

TL;DR – i do not have a decrypted modem.bin yet, but here are all my notes, send help. ❤

Full post:

Android USB-OTG vulnerability

Interesting story from TechWorm on a Samsung-flavored Android security issue, unclear how this impacts other vendor’s flavors of Android:

Samsung lets you hack it smartphone even with factory reset protection enabled with a USB OTG

In order to protect a Android smartphones from theives, Google introduced a new feature in Android 5.0 Lollipop. The new feature allows your phone to stay protected in the event of a factory data reset that occurs from within recovery. Android 5.0 Lollipop gives this root level protection to Android smartphone owners and it will persistently ask for the primary Google account’s password after a phone has been factory reset in this manner. This protection helps the owner in case a thief or a hacker tries to gain access to the phone. However, a Android user, RootJunky has proved that it is easy to bypass this system level protection with just a USB OTG cable and APK within 10 minutes.  RootJunky recently discovered a flaw on Samsung devices which allows you to bypass the system level protection with just that. […]

Full story:


Linux Security Summit 2015 proceedings available

As part of LinuxCon North America, the Linux Security Summit recently finished, and presentations are now available (I omitted the few talks which had no presentations from below list):

* Keynote: Giant Bags of Mostly Water – Securing your IT Infrastructure by Securing your Team, Konstantin Ryabitsev, Linux Foundation
* CC3: An Identity Attested Linux Security Supervisor Architecture, Greg Wettstein, IDfusion
* SELinux in Android Lollipop and Android M, Stephen Smalley, NSA
* Discussion: Rethinking Audit, Paul Moore, Red Hat
* Assembling Secure OS Images, Elena Reshetova, Intel
* Linux and Mobile Device Encryption, Paul Lawrence, Mike Halcrow, Google
* Discussion: Core Infrastructure Initiative, Emily Ratliff, Linux Foundation
* Security Framework for Constraining Application Privileges, Lukasz Wojciechowski, Samsung
* IMA/EVM: Real Applications for Embedded Networking Systems, Petko Manolov, Konsulko Group, Mark Baushke, Juniper Networks
* Ioctl Command Whitelisting in SELinux, Jeffrey Vander Stoep, Google
* IMA/EVM on Android Device, Dmitry Kasatkin, Huawei Technologies
* Subsystem Update: Smack, Casey Schaufler, Intel
* Subsystem Update: AppArmor, John Johansen, Canonical
* Subsystem Update: Integrity, Mimi Zohar, IBM
* Subsystem Update: SELinux, Paul Moore, Red Hat
* Subsystem Update: Capabilities, Serge Hallyn, Canonical
* Subsystem Update: Seccomp, Kees Cook, Google
* Discussion: LSM Stacking Next Steps, Casey Schaufler, Intel