In recent years, with the rapid development of mobile internet, security issues have become increasingly serious. Among these devices, the Android system accounts for over 80%. Various decompilation, unpacking, and repackaging tools are emerging one after another. This article starts with Android Dex and finally introduces the new generation of mobile security deep protection solutions from Aijiaji.
Introduction to Android Dex
The intermediate layer in Android development is generally implemented in Java and uses a special Dalvik virtual machine. Dalvik is a non-Java standard Java virtual machine. While JVM is stack-based, Dalvik is register-based, reportedly customized by Google to avoid legal risks for Android.
Dex stands for Dalvik VM executes, which is the type of executable file on the Android platform. Dex files are collections of Dalvik bytecode, not Java bytecode. After compiling Java code, tools on the Android platform can convert Java bytecode into Dex bytecode.
Introduction to Android So
Generally speaking, the security of Dex is recognized to be inferior to that of So in the security community, mainly because Dex can be easily restored to understandable Java code by various decompilation tools, while So contains native machine instructions, making it difficult to restore the original code.
So stands for Shared Object, which is an indivisible unit generated from one or more relocatable objects. Shared objects can be bound to dynamic executable files to form runnable programs. As the name suggests, shared objects can be shared by multiple applications. Some Unix-like operating systems, such as Linux, have dynamic link libraries that are So, and the Android system, being an open-source operating system based on Linux, also has its dynamic link libraries as So, similar to Dlls on Windows.
For security and performance reasons, Android developers generally write core algorithms and important business logic in C/C++ and place them in So. Therefore, the security of these C/C++ codes is extremely important for enterprises, as it is the last line of defense for the app. Once breached, it can lead to immeasurable losses.
Risks Faced by C/C++ Code
Although So cannot be decompiled, does that mean it is completely safe and without risks? Let’s take a look at some common security risks of So:
-
Sensitive information visibility
We know that apps are for human use, which involves human-computer interaction UI. Whether it is a console program or a graphical interface program, it must provide user-friendly prompts, and these prompts are generally presented as strings.
As shown in the figure below, after opening the So file with IDA, sensitive strings in the source code can be directly seen.
Solution: Developers can save strings as byte arrays encrypted using ASC2BCD and decrypt them using BCD2ASC before use. Generally, security vendors use OLLVM-based string encryption obfuscation, pre-encrypting strings and decrypting them at the function header or before use.
Defect: Attackers can track through dynamic debugging, and there are many open-source deobfuscation tools targeting OLLVM available online.
-
Static analysis
So is an ELF file composed of code and data. We can use IDA to open the So file to view the disassembled code for static analysis and use F5 to view the corresponding C pseudo code of the function.
Solution: Obfuscating So can somewhat counter static analysis and increase the difficulty of reverse engineering, but reverse engineers can still see the assembly code. Generally, security vendors use shellcode to protect So, encrypting and compressing the code segment, automatically calling the shell code for decryption when So is loaded.
Defect: Dynamic debugging can dump memory at the decryption location after loading the shell.
-
Dynamic debugging
Using IDA for dynamic debugging of So files allows you to see the contents of memory and the values of registers.
Solution: Runtime protection against debugging can be implemented by detecting ptrace, debugger process names, debugger ports, processes, etc. If debugging is detected, the application exits.
Defect: A single protective measure is too weak; it can generally be bypassed by modifying the code segment or dynamically modifying memory and register values using IDA Patch So.
Given that traditional protective measures are not strong enough and can be easily cracked by reverse engineers, Aijiaji has focused on research and developed the 7th generation deep defense system based on VMP, including: SecLLVM secure compiler, JAVA2CPP hardening, So Linker hardening, etc.
SecLLVM Secure Compiler
-
Deeply customized obfuscation based on OLLVM, adding block scheduling, indirect jumps, etc., can prevent IDA F5.
-
A virtual machine compiler implemented based on the LLVM open-source framework, which directly applies virtualization protection to specified functions during compilation;
-
A custom IVM virtual machine instruction set that supports random instruction sets, generating different instruction sets with each compilation;
-
Dynamic hot updates of virtual machine instructions (cloud updates), without writing files, directly decrypting and running the updated bytecode in memory;
-
Based on the above features, once the code is encrypted, attackers cannot decrypt and restore the code through debugging to analyze core business logic.
During compilation, the original code corresponding to functions in C/C++ is compiled into virtual machine bytecode. When the program executes that code, it calls the virtual machine interpreter to execute the relevant bytecode, and after execution, it exits the virtual machine to continue executing local code. Code virtualization protection can make functions become a unified virtual machine entry call, preventing hardened code from being disassembled and statically analyzed, effectively protecting C/C++ code logic. The implementation principle is shown in the figure below:
The following figure shows the original C++ source code:
The following figure shows the effect of the above source code compiled into SO and viewed in IDA with F5:
The following figure shows the effect of using the SecLLVM secure compiler for virtualization protection viewed in IDA with F5:
It can be seen that after the original function is virtualized, the code logic completely transforms into a single virtual machine entry. No matter how complex the function is, after successful virtualization, it ultimately results in such an incredibly simple whiteboard.
JAVA2CPP Hardening Solution
JAVA2CPP is a new generation Android Dex hardening solution that first translates Java code in the Dex file into C++ code, then compiles this C++ code into a dynamic library, and clears the original bytecode, converting specified protected methods in JAVA into native methods. JAVA2CPP can protect the security of Dex under static conditions and effectively prevent crackers from obtaining Java code from Dex through dynamic debugging. Combined with our obfuscation, virtualization, and So Linker solutions, the protection strength reaches its maximum.
The following figure shows the Java code decompiled from the APP package:
The following figure shows the function dispatchKeyEvent in the above Java code converted to native code and viewed in IDA with F5:
It can be seen that the Java code has been converted to native code, and no matter what tools reverse engineers use, they cannot decompile the function dispatchKeyEvent back to Java source code.
So Linker Solution
So Linker is a new generation Android So protection technology. Its implementation principle is to first encrypt and compress the So file to be hardened and insert it into another So. Then, at runtime, the data is decrypted, and dynamic loading links resolve symbols. After So Linker hardening, it can achieve symbol hiding, anti-debugging, and anti-dump functions.
The following figure shows the contents of the code segment before using So Linker hardening:
The following figure shows the contents of the code segment after using So Linker hardening:
It can be seen that the code segment is completely different because we have swapped it out for another So file, which is no longer the original So.
The following figure shows the function list seen in IDA without using So Linker hardening:
The following figure shows the function list seen in IDA after using So Linker hardening:
It can be seen that all function names have been hidden, as the new So is set to hide symbols by default.
The following figure shows the error message from IDA when attempting to debug the hardened So:
It can be seen that IDA can no longer debug the hardened So.
Note: This article is from the technical sharing article “Entering Enterprises to See Security – Station 17 Aijiaji”
Author of this article: Xiao Wei
Research and development personnel of Aijiaji virtual machine protection, responsible for the scheme design, supervision, and implementation of virtual machine protection products in security products. He has rich experience in virtual machine protection project development, is a senior programmer, and has an in-depth understanding of virtual machines.
– End –
Popular Book Recommendations:
Previous Popular News:
-
CTF.TSRC 2018 Team Competition Question 11 “Eden” Solution Ideas
-
Some Details about CVE-2017-8890
-
CTF.TSRC 2018 Team Competition Question 10 “Chivalrous Duo” Solution Ideas
-
From Patch to Root – Analysis of CVE-2014-4323
Public Account ID: ikanxue
Official Weibo: Kanxue Security
Business Cooperation: [email protected]