Research on general automatic shelling method for Android application

<span id="Label3"></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">Author: @ Love Bo will win</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">This article is an extended extension of the research on the universal automatic shelling method for Android applications at Uyun.</p></p><span id="OSC_h1_1"><span id="OSC_h1_1"></span></span>0x00 Background and significance<p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">Android apps are more likely to be reversed than traditional PC applications because they can be completely reverted to Java code or Smali intermediate languages, both of which have rich high-level semantic information and are easier to understand. Let the logic of the program easily be exposed to the technical ability or even the attackers who do not need a high threshold. As a result, the Android application Hardening Protection Service came into Being. From the outset, only the company provided services to large Internet companies now have their own reinforcement protection services, but also with money-related Android applications such as banks and more and more began to use the reinforcement to protect themselves, the market is constantly expanding.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">A typical reinforcement protection service usually provides the following protection: anti-reverse, anti-tamper, anti-debugging, anti-theft and other Functions. While hardening services can not avoid and prevent the Application's own security problems and vulnerabilities, it can effectively protect the real logic of the program and protect application Integrity. But these features are also easily exploited by malicious programs, with data suggesting that the proportion of shell-based malicious programs is rising as the reinforcement protection is Prevalent. On the one hand, malicious program analysis needs to be shelled first, on the other hand, if the normal application is easily shelled after analysis, the risk of its face will Rise.</p></p><span id="OSC_h1_2"><span id="OSC_h1_2"></span></span>0X01 Research Objects<p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">The hardening service typically provides dex's overall reinforcement scheme and customized Reinforcement. Custom hardening often requires tighter integration with development, possibly involving deeper reinforcement (such as native code hardening, etc.), while dex's overall hardening requires only the user to provide a compiled Android app Apk. The former is currently lacking in samples and needs to work in depth with the reinforcing firms, who are being provided with the most basic free services by most hardened service providers, and the latter is used more broadly. The main object of this paper is the protection of the Latter's Android application executable, dex file encryption, which is designed to study the general Dex file Recovery Method. The custom hardening service or the confusion protection for native code is not covered in this study.</p></p><span id="OSC_h1_3"><span id="OSC_h1_3"></span></span>0X02 Reinforcement Service Features<p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">We use an example of a static reverse hardening method to describe in detail the characteristics that a hardening service typically Has. This example is a scheme used by a hardened manufacturer a few months ago, and since the hardening service often transforms decryption algorithms and schemes, the implementation details are not applicable to Today's products or other reinforcement services, but the overall reinforcement idea and method and the means of protection used are basically the Same.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">Often when we analyze a hardened app with static tools, the Androidmanifest.xml file adds an entry point class, usually application, on top of preserving all the original information, including defined components, permissions, and so On.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">And Dex's code is like This.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"></p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">The DEX code contains only a handful of classes and code, mostly to do some testing or preparation, and then load the original Dex file dynamically by loading a native library. Because of the dynamic loading mechanism, the hardened Dex file does not involve the original Dex's real code (and Some hardening does not take a full Dex dynamic load).</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">It then uses IDA to load the running native code with the reverse entry point, and the so library is often confused with Packers. Means include destroying the ELF header information to make Ida parse fail, such as:</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"></p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"></p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">There are several fields in the Elf's head that can be clearly seen through READELF.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"></p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">After the fix, Ida can disassemble the so file normally. Then we start the analysis from the entry point, we will find that F5 Anti-compile into C code will be problematic, multiple function content can not be decompile to normal C Code. Look directly at the assembly code to see the following flower instructions:</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"></p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">This is our summary of the product's flower instruction Pattern. It will be pushed through the stack to jump out of the way the Anti-compilation function identification problems, because the anti-compilation usually think of a stack operation as a function call, but in fact he through the stack, calculate the register value, jump again out of the stack after the anti-compilation failure and balance the stack, then execute a really useful command. So there are only two really useful instructions in the example Above.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">The actual assembly instructions can be extracted by writing scripts or even by manual means. After extracting the inverse code, its function is to decrypt the jni_onload Function. Jni_onload will decrypt another elf file from a piece of data, and the new Elf file will not be properly disassembled, and the following code would then revise the Elf's Data. Extract the text end of the new Elf file first, extract a key from the text end to decrypt the rotext, and finally decrypt a real shell program for dex, such as:</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"></p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">The above steps are actually a shell of an elf File. The new decrypted elf file is the actual decryption process for the Dex Shell. This program does not confuse or add shell, through the reverse found that he will take the original Dex after a section of padding data, to obtain some decryption and decompression required parameters, the entire padding data decryption decompression, You can get the real original Dex File. Of course, The Elf also includes some anti-debug back-analysis code, because we are static analysis, do not need to take into account this part of the code, if the use of the debugger to attach a process using dynamic analysis such as dump need to consider how elegant bypass these anti-debugging techniques.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">The above example is an example of a dynamic load of dex, although different hardening services include decryption algorithms, flower instruction patterns, elf shells, and so on in many technical details, but can basically represent the vast majority of the overall decryption of a hardened service using dynamic load Dex to release running and static reversals and crack its way of thinking. We also use this example to Glimpse. Because the frequent transformation decryption algorithm and the reinforcement method is also the first big characteristic of the reinforcement service.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">There is also a dynamic load mechanism that does not use the full Dex file, but instead uses the runtime dynamic self-modification, where some of the exact information in the original Dex will be present in the hardened Dex file, but the protected part of the code is otherwise Hidden. There are also ways to combine the Two. We will be involved in the following case Analysis.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">To summarize, a hardened Android app essentially hides real Dex files, and it itself adds many protections to prevent it from being easily reversed. It can be seen that if the pure static inverse analysis of its shelling algorithm will be very time-consuming and cost-intensive, and different reinforcement services to take the same algorithm, and each itself will be frequent transformation algorithm and reinforcement technology to the pure static reverse shelling method for a short period of time Failure. While the hardening service also takes a number of Android application protections beyond the Dex dynamic loading, we'll summarize here and not start, as this section can even be written in Detail.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">The first category is the Integrity Test. Contains integrity checks for itself at run time, such as checking the validation values of Dex files in memory and checking application certificates to detect whether they are repackaged and inserted into the Code. And the detection of their own environment, such as by checking the specific device files and other methods to detect the simulator, through ptrace or process status, such as detecting whether debugging, hook specific functions to prevent code memory is read or Dump.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">The second big class is code Obfuscation. Often the confusion needs to be based on source code or bytecode modification, which is intended to make it more difficult for analysts to understand the semantics of the Program. The most common include modifying variable names, method names, class names, and so on, encrypting constant strings, invoking methods using the Java reflection mechanism, inserting garbage instructions or invalid code to disrupt program flow, replacing primitive basic instructions with more complex operations, interrupting control flow with JNI methods, and so On.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">The third category, which we define as an anti-analysis or Code-behind technique, is designed to prevent the application code from being exposed directly and easily analyzed in various ways. The most common is the above-mentioned Dex overall encryption protection, as well as the runtime dynamic Self-modification. Runtime dynamic self-modification is primarily when the program is running when it executes to a particular class or method to decrypt and execute the code, and it may be dynamic to correct or modify part of the Dalvik data structure to make the analysis Difficult. Other defense analysis techniques need to take advantage of some small tricks. For example, using static analysis tool bugs, or parsing features to do confrontation, including the ever-present manifest cheating,apk pseudo-encryption, dex file method hiding, inserting illegal instructions or non-existent classes to crash static analysis tools and so On.</p></p><span id="OSC_h1_4"><span id="OSC_h1_4"></span></span>The thought of 0x03 shelling method<p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">In the face of reinforcement procedures, the current popular and commonly used shelling methods are mainly two METHODS. One is static inverse analysis, Its shortcomings are also obvious, difficult and can not resist the transformation algorithm. Another is mainly based on the memory dump technology of SHELLING. The disadvantage is the need to consider the first bypass of various anti-debugging methods, but also to face the growing development and new endless anti-memory dump of various Techniques. For example, tampering with the Dex file header, dynamic tampering with the Dalvik data structure destroys in-memory Dex files, and so on, these anti-technology so that even after the dump of Dex files, but also need to do a lot of observation reinforcement features after the manual repair Work.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">So we propose a general automatic shelling method, Our method is based on dynamic analysis, do not care about the specific implementation of various reinforcement protection, but also can be unified to bypass the various anti-debugging means, but also do not need to do a lot of repair work later.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">The first thing we shelled was the Dex file in the Android app, so we chose to directly modify the source code of the Dalvik virtual machine in the Android system to make the Piles. Because the code in the Dex file needs to interpret execution on the Dalvik virtual machine, all Real-world behavior can be exposed on the Dalvik virtual MACHINE. Dalvik has multiple interpretation modes, in which the portable mode is implemented based on C + +, while other modes are developed using Platform-related assembly language for optimization purposes, in order to facilitate the implementation of our plug-in code, once the discovery begins to explain the application that needs to be shelled, Let us first (source directory Dalvik/vm/interp/interp.cpp) change the interpretation mode to Portable. One of the benefits of this is that modifying the execution environment directly can make it more difficult for Packers to detect the presence of shelling behavior, which is more transparent than a debugger-attached method. Another benefit of doing this on the interpreter is that there is no need to care about the stage at which the hardening program loads and initializes and decrypts the code, and so on, to get the most realistic data and behavior directly at Runtime. The plug-in code is implemented at each instruction switch (dalvik/vm/mterp/out/interpc-portable.cpp) that is executed at Dalvik interpretation, so that it can be shelled at any instruction during execution, while the reinforcing procedure for side-running edge decryption is Addressed. finally, based on the modification of the source code to implement the Real-machine deployment, Android source code can be perfect to support all Nexus Series phones, and do not need to deal with the reinforcement program detection simulator Means.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">The essence of shelling is to get the real behavior of the program, so the insertion of the pile code is actually to get the Dalvik data structure in memory to reflect the real code Executed. In the execution of the instruction can be directly obtained the method that the instruction belongs to, methods this Structure. And each executed method has this method belongs to the class object clazz, and Clazz (source directory Dalvik/vm/oo/object.h) also has pdvmdex (dalvik/vm/ DvmDex.h) object, where the pdexfile (dalvik/libdex/dexfile.h) struct represents the Dex file, that is, when the current method is obtained during execution, the curmethod->clazz-> Pdvmdex->pdexfile is able to get the Dex file structure that this method belongs To. The structure contains the memory information of all DEX files when they are interpreted and the most realistic Dex can be recovered by parsing the Dexfile Structure.</p></p><span id="OSC_h1_5"><span id="OSC_h1_5"></span></span>0x04 Simple shelling implementation<p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">At this point, our first reaction is there is no ready-made program, can be translated Dalvik bytecode, but read into the memory of the dexfile structure as input, and can be directly based on the source code implementation, that is, in C + + implementation, Instead of just reading into a static Dex file as an input, like more static reverse Tools. Find the next found in the Android system source itself provides dexdump (dalvik/dexdump/dexdump.cpp) this tool, directly to meet this Requirement. We make a slight modification to the Dexdump code and insert it into the interpreter, such as:</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"></p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">Let him read the dexfile, the default is to execute the code directly in an App's main activity, and the main activity can be obtained through the Androidmanifest.xml file, because the entry point classes in the file are not Hidden. We found that it was almost possible to deal with most of the hardening procedures, and to get the real code in the Dex file that the hardening program was hiding, output such as:</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"></p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">But the disadvantage of this method is also obvious, that is, the output is Dalvik bytecode text form, on the one hand can not be disassembled to java, on the other hand, the text form is not suitable for subsequent complex program analysis, our best goal is to get a complete Dex File.</p></p><span id="OSC_h1_6"><span id="OSC_h1_6"></span></span>0x05 Perfect Shelling implementation<p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">Usually to the previous step, many other shelling tools in order to recover the complete Dex file, will choose to directly read pdexfile->baseaddr or Pdvmdex->memmap as the starting address, directly the entire file size of memory dump Out. however, we found that some of the hardening software, so that the dump out of the code still does not contain the real code, this is because some of the real information in the Dex file is modified at runtime and mapped to a portion of the file beyond contiguous memory, for example, a dex file is loaded into memory, it should be in a contiguous memory space, It is then resolved to assign values to the structures required for each dynamic execution of the dalvik, while some of the straight-tempered structures should point to contiguous data blocks. however, The hardening program may make some modifications, such as tampering with part of the header data, and reallocating the discontinuous memory to hold the data and the newly allocated data blocks that the index blocks point to. This way, if you use the Dump method directly, you cannot get the complete Dex File.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"></p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">We aim to restore the original Dex file in a uniform way, and do not want the different shells to be used for subsequent repairs, as this will enter the same dilemma as the static inverse hardening algorithm. therefore, based on the simple implementation of the above, there is a more complete implementation of the program, called Dex file Reorganization. The process is very simple, which is to get all the Dalvik data structures required by all the interpreters during the execution of the program, where the actual data structures are interpreted in memory and then re-written back into a new Dex File. As shown, even if the memory is not contiguous, we do not need to care about his original mapped memory operation, you can directly obtain each discontinuous data, according to a certain specification to the data into a new Dex File. The first step is to get an accurate view of each Dalvik data mechanism, in order to ensure the accuracy of the acquisition, we take the way to run in the interpreter to execute the program when the way to obtain the same (refer to the Dexgetxxxx method in the DexFile.h file), because a dex file, The same piece of data can be obtained in a number of ways, for example, a constant string can be read in the file header offset to get, can also be obtained through the Stringid list, and so On. Normally these methods should be correct, but the hardening program will do some Damage. however, it cannot destroy the data that is used when the data is fetched at runtime, because once this is destroyed, the program will not function properly. The exact way to get it is as Follows:</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"></p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">We need to iterate through some pointers and offsets in each array, such as pstringids,pprotoids,...,pclassdefs, each one of them, and merge its contents into a large class (such as Stringdata,typelist,...,classdata , Code). then, When you finish rewriting, you need to pay attention to a few questions. The first is to get the arrangement of these data blocks, we refer to the map item type dalvik/libdex/dexfile.h in the order of the Codes Enumeration. Arrange to adjust the offset value in each data item to the new offset, such as stringdataoff, parametersoff, interfacesoff, classdataoff, codeoff, etc., then for dexheader, Maplist the values in these two structures, we need to re-calculate and fill in, instead of directly taking the original value, for some fixed values such as the header of the file in the first class, we are based on the knowledge directly filled in. finally, you need to consider the differences in in-memory data representations and some data formats in the Dex file, such as some data items that are ULEB128 encoded in the file, and that are directly int in memory, as well as the 4-byte alignment, and the Encoded_method_ Format is Field_idx_diff,method_idx_diff rather than simple Index. Refer to the official Dex file format documentation for specific details</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><code>https://source.android.com/devices/tech/dalvik/dex-format.html</code></p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">When we reorganized, we ignored a number of data blocks, such as all data structures related to annotation, because this part of the real program is not much used, and the structure is particularly complex, ignoring the future of the analysis of the actual behavior of the program is not very significant.</p></p><span id="OSC_h1_7"><span id="OSC_h1_7"></span></span>0X06 Experiment and Discovery<p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">After the code has been changed, we recompile the LIBDVM module and overwrite the original library file with the newly generated libdvm.so written to the system directory/system/lib/, we are experimenting with the Galaxy Nexus phone corresponding to Android 4.3 version and Nexus 4 mobile phone corresponding to Android 4.4.2 Version. We then submitted a simple application that was sent to the various online hardening services to obtain a hardened version of the application before Shelling. The experiment found that the original Dex file could be recovered from almost all hardening programs. Here are some discoveries for hardening procedures. Mainly focused on the means of self-protection used in different reinforcement, some of the results here are dexdump text, because some of the protection measures in this way better show the details, of course, all can directly revert to the Dex File.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"></p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"></p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">The above two examples show that some hardening programs erase the magic number to hide the Dex file in memory, invalidate the poor Dex file, tamper with the header size, and erase the various field offset values in the Header. Since the method we use is to recalculate the header, the reorganized Dex is Unaffected.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"></p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"></p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">In addition, some hardening programs will insert some additional classes to break the normal anti-compilation effect, for example, This class has a way to make the Dex2jar invalid.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"></p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">There is also a shell that changes the codeoff to a negative value so that the code is mapped out of the file memory Range. Our approach allows you to write the code directly back to the normal Location.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"></p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">There is also a shell that overrides certain methods, puts the code into a new method, and decrypts it before execution, and then wipes it out again. In this case, since our shelling code is inserted at each method call, we only need to adjust the shelling point to the execution of the method to implement shelling to recover the Code.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"></p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">In addition to the above examples, we also found that some hardening programs hook the Write function in the process space, and that if the content is specific (such as the Dex file header), then the write operation fails, or if the memory address space is within the mapped Dex file area, write fails, and so On. There is also a hardening program that separates the original Dex file from multiple dex, and modifies specific data items such as Debug_info_off to the wrong value, and then dynamically changes back to the correct value at run Time. There is also a shell that confuses the original program code based on the Bytecode.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">(note: The above examples are not the latest version, there is no guarantee that the existing products of the specific hardening procedures are still consistent with the above examples)</p></p><span id="OSC_h1_8"><span id="OSC_h1_8"></span></span>0x07 Discussion and thinking<p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">First of all, Our approach still has limitations, and one of the subjects shows that we only encrypt the Dex file, and we don't do anti-aliasing Work. second, Our approach is still based on dynamic analysis, will face the limitations of dynamic analysis, such as a piece of encryption code is run to decrypt, but the method can not be triggered execution, our method can not decrypt the code of this Method. At last, Although it is difficult to be detected by the reinforcement program, the tools made by this method are bound to have some characteristics, which may be exploited and antagonistic by the reinforcing procedure.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">finally, I would like to discuss with you the idea of better application hardening for Android Platforms. The fact that the hardening of the Android platform is relatively easy, however, is not without the harder and safer reinforcement solution, but rather the need to take into account performance losses and compatibility issues in the mobile platform, which cannot be avoided. At the same time, I think the trend and practice of strengthening protection mainly focus on the following Points.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">One is that I think Android obfuscation and packers can actually be used Together. From an attacker's point of view, I think brute force confusion may be more effective than packers in protecting code LOGIC. But good obfuscation schemes are actually very difficult to design. At present, the domestic reinforcement is almost no big transformation and confusion of the original code, it may be feared that the modified code will have problems with Compatibility. I think this is a point of development. I found that the more excellent foreign tools in the depth of confusion at this point of the fuss, such as dexprotector, he has both shell, there is confusion, even if the shelling success, or need to face difficult to understand the confusing Code.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">In addition, I think the effect of the partial reinforcement may be stronger than the overall reinforcement in Safety. As in the previous example, a method decrypts itself only at run time and is re-encrypted or erased once it is out of Operation. this, in so doing, uses the low-dynamic execution coverage to further protect itself.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">The third is to better strengthen the effect, the reinforcement process should be as far as possible from the present development of reinforcement into the development of Reinforcement. Now there are some hardening SDKs that are a good attempt in this Area. The interface of a security library is used for sensitive operations directly in the development process. This is both in terms of performance and effect can be the current overall one-cut reinforcement to make a qualitative improvement. Developers who are familiar with the business will be aware of what part of the code they need to protect, because a program actually needs to be protected in a small part of the logic, the reduction of the hardening range can greatly improve performance, while the individual security library files can be targeted protection measures, the effect will be very good, It's also easier to do compatibility testing than the whole app Hardening.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">Reinforcing another idea is to use native code as much as possible, especially the key program logic, native code reverse itself is more difficult than java, add confusion or shell after the more difficult, while native code in fact can also improve performance, is double benefit Scheme. This can also extend the question of how to protect native code in Android applications in depth, and if sensitive operations are protected with depth-confusing protected native code, the cost of the attack is bound to increase significantly.</p></p><p style="BOX-SIZING: border-box; MARGIN: 20px 0px"><p style="BOX-SIZING: border-box; MARGIN: 20px 0px">finally, I think one of the trend of reinforcement protection is to minimize the use of small trick to protect, such as those who use static analysis tool bug or the system to resolve the bug of the APK is not very significant, the reinforcement protection should be considered and strengthened from the system structure of the whole computer system, Instead of concentrating on some small tricks.</p></p><p><p><em></em></p></p><p><p><br></p></p><p><p></p></p><p><p>Research on general automatic shelling method for Android application</p></p></span>