What are the security risks if SDK is not reinforced?

<p>What are the security risks if SDK is not reinforced?</p><p>1. It is easy for competing products or malicious people to peek into the internal implementation details or internal call flow, and may even reveal private data.</p><p>Most of the SDK of Android platform is written in Java language, which is easy to be decompiled. Simple confusion may expose internal implementation details, while private data inside SDK is more likely to be leaked. If these details reveal the implementation methods of key technologies, it is equivalent to revealing the core technologies.</p><p>2. Malicious people implant malicious advertisements or malicious codes through bytecode injection and then repackage and publish them.</p><p>Because of the particularity of SDK, there is no signature verification logic like App. Therefore, once a malicious person implants some malicious codes or malicious advertisements in your SDK and then republishes them, it will be difficult to detect them, which will seriously affect the brand image and reputation of developers.</p><p>3. The cracked person bypasses the key logic and causes economic losses.</p><p>If there is a payment function in SDK, and the payment logic is found by the malicious person, which happens to involve the payment-related logic and is not well verified by the server, once the malicious person removes these payment logics through AOP means, it means that the payment service will be available for free.</p><p>4. There may be loopholes in the 4.SDK itself, which can be easily exploited by malicious people.</p><p>SDK developers often focus on the realization of functions in development, and generally do not pay too much attention to security, so it is difficult to ensure that there are no loopholes in their own SDK. Therefore, once there are some security loopholes in the SDK, and these loopholes are known by malicious people and then used, it is like burying a mine that may detonate at any time. The reputation of SDK developers will not only be affected by the threat of data and privacy security, but also be liable for financial compensation in case of problems.</p><p>How to solve</p><p>From the above analysis of security risks, it can be seen that the crux of the problem is that malicious users can easily obtain the implementation logic of SDK. Therefore, it is suggested that developers take the following protective measures:</p><p>1. The modification of key data must be verified by the server: for example, the above-mentioned payment-related logic, the modification of data involving balance or paid amount must first be verified by the server, and then the results must be synchronized to the client;</p><p>2. Key logics are implemented in Native layer: some key logics in Java layer are transferred to JNI layer to be implemented in C/C++ to improve the threshold of decompilation;</p><p>3. String encryption: The string in the code, especially the string of sensitive information, must be encrypted and decrypted at runtime.</p><p>But it is not enough to do the above, only to prevent the general developers. The SDK we have worked so hard to develop may become cannon fodder in the hands of professional crackers, which will lead to economic losses.</p><p>Therefore, it is recommended to access third-party security services, such as the SDK reinforcement service of Yidun.</p><p>Introduction of Yidun SDK reinforcement</p><p>Before introducing the reinforcement of Yidun SDK, let&#39;s first introduce the confusing method used by most developers on the market-Proguard. Proguard is the most widely used confusion in Android platform, and it is handled from the grammatical level through abstract syntax tree, which makes the processed code difficult to read and understand. As follows:</p><p><img src="https://freeonlinedomain.com/uploads/allimg/Server/20230912/5zirjmtheol149.jpg"/></p><p>However, changing the class name and method name to some meaningless random strings, such as a,b,c, can increase the reading and understanding cost of the cracker, but obviously its function is extremely limited. For the cracker, it is only a matter of time before the intention of the code is analyzed.</p><p>So what is Yidun&#39;s SDK reinforcement solution? Next, I will introduce you:</p><p>1. The scheme of reinforcing VMP with Yidun SDK</p><p>The method of the class to be protected is evacuated, and the extracted instructions are encrypted, which is executed by a custom virtual machine at runtime, so that the cracker cannot get the original code logic.</p><p>The effect is as follows:</p><p><img src="https://freeonlinedomain.com/uploads/allimg/Server/20230912/ziubftcmaol150.jpg"/></p><p>2. Easy Shield SDK Strengthening Java2c Scheme</p><p>In this scheme, the method of the class to be protected is nativized, and at the same time, the original function realization logic is converted into the corresponding C/C++ code of the Native layer, and the corresponding Native function is directly executed at runtime. The effect is as follows:</p><p><img src="https://freeonlinedomain.com/uploads/allimg/Server/20230912/tzftirxyikj151.jpg"/> Example before reinforcement</p><p><img src="https://freeonlinedomain.com/uploads/allimg/Server/20230912/pcretriovyx152.jpg"/> <img src="https://freeonlinedomain.com/uploads/allimg/Server/20230912/ll4ihir0k1c153.jpg"/></p><p><img src="https://freeonlinedomain.com/uploads/allimg/Server/20230912/gsoczm15rg5154.jpg"/></p><p>Example after reinforcement</p><p>From the perspective of static analysis, compared with Proguard confusion, it is obvious that the reinforced method has been nativized and the implementation logic is completely invisible in the Java layer. The original function logic of Java layer is transformed into C/C++ code implementation of JNI layer, and the generated SO of Native layer is encrypted, which improves the cracking difficulty in all directions.</p><p>(Note: In the above figure, in order to see clearly that the reinforced method has been implemented in the corresponding Native layer, the generated Native layer SO is not encrypted. In fact, the enhanced Java2c scheme with easy shield SDK will encrypt the reinforced Native layer SO.)</p>