...
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 purchase Amadis's Kernels in source code, you can skip this section since you can apply these two techniques without problem by yourself on your own .
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 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 harder to be understood 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 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 from 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 The code flow flattening tool we use, is based on the LLVM compilator. The source code is compiled using DeClang the code flow flattening tool after applying the Name Mangling to generate the final AAR file.
...
The MPoC certification requires a lot more additional 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 to MPoC certify your end-to-end solution.
MPoC specification require these two techniques (Code Flow Flattening & Code Mangling) to be applied on all software (not only the EMV level 2 stack & kernels) to obtain the MPoC certification. Even if we apply them on the EMV level 2 stack & kernels on your behalf, It remains your responsibility to implement them on the rest of the Software..
We didn't apply more security techniques on the kernels because it will make to facilitate the integration harder for you. Security . In fact, 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 to provide MPoC compliant kernels that can be easily integrated inside your product and will not interfere with your MPoC security.