What are the security risks if the SDK is not hardened?

What security risks will there be if the SDK is not reinforced?

1. It is easy for competitors or malicious parties to peek into internal implementation details or internal calling processes, and may even leak private data

The Android platform SDK is extremely large Some of them are written in Java language and can be easily decompiled. Simple obfuscation may expose internal implementation details, while private data within the SDK is more likely to be leaked. If these details reveal the implementation method of key technology, then it is tantamount to leaking the core technology.

2. Malicious advertisements or malicious codes are implanted by malicious parties through bytecode injection and other means and then repackaged and released

Due to the particularity of the SDK, unlike App There is signature verification logic like that, so once a malicious person implants some malicious code or malicious advertisements in your SDK and then re-releases it, it will be difficult to detect, seriously affecting the brand image and reputation of the developer.

3. The cracked person bypasses key logic and causes economic losses

If the SDK has a payment function, the malicious person analyzes and finds the payment logic, which happens to involve payment-related logic. If server-side verification is not done well, once malicious actors remove these payment logic through AOP, it means that paid services will be available for free.

4. The SDK itself may have vulnerabilities and can be easily exploited by malicious parties.

SDK developers often focus on the implementation of functions during development. Security is generally not taken too seriously, so it is difficult to ensure that the SDK you develop does not have any vulnerabilities. Therefore, once there are some security vulnerabilities in the SDK, and these vulnerabilities are known and exploited by malicious actors, it is like laying a landmine that may explode at any time. The reputation of SDK developers will not only be affected by threats to data and privacy security, but they may also be liable for financial compensation if problems arise.

How to solve

It can be seen from the above security risk analysis that the crux of the problem is that malicious users can easily obtain the implementation logic of the SDK. Therefore, it is recommended that developers take the following protective measures:

1. Modifications of key data must pass server-side verification: For example, in the payment-related logic mentioned above, modifications to data involving balance or payment amount must first pass The server verifies, and then synchronizes the results to the client;

2. The key logic is implemented in the Native layer: some key logic of the Java layer is transferred to the JNI layer and implemented in C/C to increase the decompilation threshold. ;

3. Encrypt strings: Strings in the code, especially strings with sensitive information, must be encrypted and decrypted at runtime.

But achieving the above points is not enough. It can only prevent ordinary developers. The SDK we worked so hard to develop may become cannon fodder in the hands of professional crackers, resulting in financial losses.

Therefore, it is recommended to access third-party security services, such as Yidun’s SDK reinforcement service.

Introduction to Yidun SDK reinforcement

Before introducing the Yidun SDK reinforcement, let’s first introduce the obfuscation method currently used by most developers on the market - Proguard . Proguard is the most widely used obfuscation on the Android platform. It is processed from the syntax level through abstract syntax trees, making the processed code difficult to read and understand. As shown below:

But changing the class name and method name to some meaningless random strings, such as "a,b,c", although it can improve It costs the cracker to read and understand, but obviously the effect is extremely limited. For crackers, it's only a matter of time before they can figure out the code's intent.

So what is Yidun’s SDK reinforcement solution? Next, I will introduce to you:

1. Yidun SDK reinforcement VMP solution

Extract the methods of the class to be protected and encrypt the extracted instructions. The runtime is executed through a custom virtual machine, making it impossible for crackers to obtain the original code logic.

The effect is as follows:

##2.Yidun SDK reinforcement Java2c solution

This solution is Nativeize the methods of the class to be protected, and at the same time convert the original function implementation logic into the C/C code corresponding to the Native layer, and directly execute the corresponding Native function during runtime. The effect is as follows:

Example before reinforcement

# #Example after hardening

From the perspective of static analysis, compared with Proguard obfuscation, it is obvious that the hardened method has been Nativeized, and the implementation logic is completely invisible in the Java layer. The original function logic of the Java layer is converted into the C/C code implementation of the JNI layer. At the same time, the generated Native layer SO is encrypted to improve the difficulty of cracking in all aspects.

(Note: In order to see more clearly in the picture above, the hardened method has been converted to the corresponding Native layer implementation, and the generated Native layer SO is not encrypted. In actuality, the Yidun SDK hardened Java2c solution will Native layer SO for encryption)

The above is the detailed content of What are the security risks if the SDK is not hardened?. For more information, please follow other related articles on the PHP Chinese website!