This is a follow-up to our compendium blog post that presented the internals of Samsung's security hypervisor, including all the nitty-gritty details. This extensive knowledge is put to use in today's blog post that explains how we attacked Samsung RKP. After revealing three vulnerabilities leading to the compromise of the hypervisor or of its assurances, we also describe the exploitation paths we came up with. Finally, we take a look at the patches made by Samsung following our report.

After an in-depth analysis of the NPU OS and its interaction with the Android kernel, this second part gives a more offensive outlook on this component. We will go through the main attack vectors to target it and detail two vulnerabilities that can be chained together to get code execution in the NPU from the NPU driver before pivoting back into the kernel.

This series of blog posts aims to describe and explain the internals of a recent addition to Samsung's system-on-chips, namely their Neural Processing Unit. The first part digs into the internals of the NPU and the second one focuses on the exploitation of some vulnerabilities we found in the implementation. If you're interested in reversing a minimal OS, want to understand how Android interacts with peripherals and do exploitation like it's the early 2000's, this series might be for you.

The purpose of this blog post is to provide a comprehensive reference of the inner workings of the Samsung RKP. It enables anyone to start poking at this obscure code that is executing at a high privilege level on their device. In addition, a now-fixed vulnerability that allowed getting code execution in Samsung RKP is revealed. It is a good example of a simple mistake that compromises platform security, as the exploit consists of a single call, which is all it takes to make hypervisor memory writable from the kernel.