Introduction

The MPoC certification process requires the evaluated entity to implement a certain level of security in the product. Some of the security decisions are left open ended while other methods are explicitly required. This is the case for reverse engineering techniques. The MPoC explicitly asks for Name Mangling and Code Flow Flattening (MPoC 1B-1.5b page 74) to be implemented in the final MPoC product.

If you purchased Amadis's Kernels in source code, you can skip this section since you can apply these two techniques without problem.

Name Mangling is a technique that can only be applied on the source code while Code Flow Flattening can only be applied at compilation. If you purchased Amadis's Kernels in object code you will not be able to implement them.

To solve this problem, the 'Protect' version of the object code kernels comes with Name Mangling and Code Flow Flattening already applied.

Name Mangling

Name Mangling is a technique that transforms functions, variables names and strings inside the source code. It converts something like 'myFunction()' to something like '8b8508871ea()'. The goal is to make understanding the source code complicated during a reverse engineering. It is the main code protection technique, without it the rest of the other techniques like Code Flow Flattening would not be effective.

We apply Name Mangling using Stunnix on the source code before compilation. The public kernels API is left unmodified. This process doesn't affect anything (performance, development process, etc...).

Code Flow Flattening

Code Flow Flattening is a technique that modifies the flow of execution to obscure it. Even with Name Mangling, if you know at what place in the process chronology something happens you can still manage to reverse engineer it. For example, validation processes (like serial number, authentication or anti-piracy methods) tend to happen at the beginning of the execution flow. Code Flow Flattening helps to prevent reverse engineering by re-ordering the code to make it difficult to know what part of the software is executed before or after another one (it hides the chronology of execution).

We use DeClang for this, it is based on the LLVM compilator. The source code is compiled using DeClang after applying the Name Mangling to generate the final AAR file.

Code Flow Flattening affects performance, this is why we applied it with moderation on the kernels to balance performance and security.

Integrating Object Code Kernels in your Security

The MPoC certification requires a lot more security from the final product than just Name Mangling and Code Flow Flattening on the kernels. It is your responsibility to secure the entire solution and integrate the kernels inside it. Relying only on the two techniques we applied to get certified will not be enough.

These two techniques are required from you on all the product (not just the kernels) for the MPoC certification. Even if we apply them on the kernels on your behalf, you still need to implement them on the rest of the product.

We didn't apply more security techniques on the kernels because it will make the integration harder for you. Security and protection techniques tend to conflict with one another and create issues that are hard to solve. If we did so, it will end up costing you time and money. By only applying Name Mangling and Code Flow Flattening we ensure that you have MPoC compliant kernels that can be easily integrated inside your product and will not interfere with your MPoC security.