Increasing popularity of connected devices in recent years has led devices manufacturers to deal with security issues in a more serious way than before. In order to address these issues appropriately, a specification has emerged to define a way to ensure the integrity and confidentiality of data running in the entity implementing this specification.

Given the popularity of GDI Bitmap objects for exploitation of kernel vulnerabilities -due to the fact that almost any kind of memory corruption vulnerability (except for NULL-writes) could be used to reliably gain arbitrary R/W primitives over the kernel memory by abusing Bitmaps- Microsoft decided to kill exploitation techniques based on Bitmaps. In order to do this, Windows 10 Fall Creators Update (also known as Windows 10 1709) introduced the Type Isolation feature, an exploitation mitigation in the Win32k subsystem, which splits the memory layout of SURFACE objects, the internal representation of Bitmaps on the kernel side. This blogpost takes a deep dive into the details of how Type Isolation is implemented.

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.

On September 13th, 2016 Microsoft released security bulletin MS16-104 [1], which addresses several vulnerabilities affecting Internet Explorer. One of those vulnerabilities is CVE-2016-3353, a security feature bypass bug in the way .URL files are handled. This security issue does not allow for remote code execution by itself; instead, it allows attackers to bypass a security warning in attacks involving user interaction. In this blogpost we discuss the whole process, from reverse engineering the patch to building a Proof-of-Concept for this vulnerability.

A binary analysis of CVE-2016-7259: A win32k kernel bug.

An optimization for the finite field multiplication on 128-bit elements for AES-GCM exists whose explanation was not published, preventing any further application with different parameters. We reverse engineered the result to 1) get the explanation and 2) be able to apply it with other parameters.

Since Windows XP SP2, the Windows firewall is deployed and enabled by default in every Microsoft Windows operating system. Starting with Windows Vista the firewall relies on a set of API and services called the Windows Filtering Platform (WFP). Although used by almost every Windows OS, WFP is still one of the relatively unknown beast that lies in the kernel. In this post we will see how the firewall manages its persistent state.

We recently looked at the Obfuscator-LLVM project in order to test its different protections. Here are our results, and explanations on how we deal with obfuscation.

Modern OSes have a feature that mitigates the exploitation of stack based buffer overflows. It basically works by writing a "cookie" value before the return address in the stack in the prologue of a function and checking it before the function returns (for further information, see [1] and [2]). This article talks about how this mitigation has been enforced in Windows 8.