WO2017107706A1 - 基于arm指令虚拟化的elf文件保护方法及系统 - Google Patents

基于arm指令虚拟化的elf文件保护方法及系统 Download PDF

Info

Publication number
WO2017107706A1
WO2017107706A1 PCT/CN2016/106146 CN2016106146W WO2017107706A1 WO 2017107706 A1 WO2017107706 A1 WO 2017107706A1 CN 2016106146 W CN2016106146 W CN 2016106146W WO 2017107706 A1 WO2017107706 A1 WO 2017107706A1
Authority
WO
WIPO (PCT)
Prior art keywords
instruction
virtualization
bytecode
file protection
file
Prior art date
Application number
PCT/CN2016/106146
Other languages
English (en)
French (fr)
Inventor
霍亮
Original Assignee
北京奇虎科技有限公司
奇智软件（北京）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 北京奇虎科技有限公司, 奇智软件（北京）有限公司 filed Critical 北京奇虎科技有限公司
Publication of WO2017107706A1 publication Critical patent/WO2017107706A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/121—Restricting unauthorised execution of programs
    • G06F21/125—Restricting unauthorised execution of programs by manipulating the program code, e.g. source code, compiled code, interpreted code, machine code

Definitions

  • the present invention relates to the field of security technologies, and in particular, to an ELF file protection method and system based on ARM instruction virtualization.
  • Android is a free and open source Linux-based operating system for mobile devices such as smartphones and tablets, led and developed by Google and the Open Handset Alliance.
  • the Android platform has developed rapidly and has gradually become the most popular operating system for mobile terminals. In particular, the Android platform has penetrated into various fields, including financial equipment, which has higher security requirements.
  • the open Android system provides application developers with more functional interfaces that increase system scalability but also facilitate malware.
  • Malicious software such as Trojans for Android can be stored in the Android installation package by spoofing, spoofing users to install and grant certain permissions, and then performing certain behaviors in the background through abuse of permissions, including stealing user privacy and defrauding fees; Not only that, for some normal Android system applications, there are also illegal copying, reverse engineering, decompilation, debugging, cracking, secondary packaging, memory interception and other means to threaten the security of the Android system, not only endangering the interests of users, It also causes serious damage to normal application developers.
  • the protection for APK (the abbreviation of Android Package, Android installation package) is mainly based on dex (the abbreviation of Dalvik VM Executes, namely Android Dalvik executive program).
  • dex the abbreviation of Dalvik VM Executes, namely Android Dalvik executive program.
  • the shared link library file of the Android platform has a .so extension, so it is also called SO file, and uses ELF format (Executable and Linkable Format: one for binary files, executable files, object code, shared libraries). And the standard file format for core dumps).
  • ELF format Executable and Linkable Format: one for binary files, executable files, object code, shared libraries.
  • the protection of files in ELF format is relatively weak. Most of the existing ELF files are in the linker mode or upx (Ultimate).
  • Packer for eXecutables executable program file compressor
  • odex the executable file extracted from the APK, the classes.dex file in the APK will be optimized by the dex optimization process to generate a dex file separately
  • the packed program can effectively prevent the disassembly analysis of the program to protect the software copyright and prevent it from being cracked by the software.
  • the cracker only needs to use the upx source code to modify it to unpack the program, and its protection is not enough.
  • the present invention provides an ELF file protection method based on ARM (Advanced RISC Machine) instruction virtualization.
  • an ELF file protection method based on ARM instruction virtualization comprising: converting an original function instruction into a byte code; saving a register and stack information of the original function, adding a jump instruction, and deleting The rest of the instructions; jump to the interpretation engine to interpret the bytecode.
  • the original function instruction can be divided into a plurality of virtualized small instructions and converted into corresponding bytecodes
  • the interpretation engine can include a plurality of sub-interpreting units to correspond to corresponding bytes of the plurality of virtualized small instructions. The code is explained.
  • the beneficial effect is that the original function instructions are various, the organizational form is also ever-changing, and the interpretation engine is difficult to translate and interpret for each specific case. Therefore, by categorizing all the commands that may be encountered first, and then decomposing them into a number of simple virtual small instructions, these virtual small instructions can be handed over to the specialized sub-interpretation units for processing, and each sub-interpretation unit cooperates and coordinates. An explanation of the entire instruction. The implementation is simpler and more flexible.
  • the bytecode is interpreted using a stack-based virtual machine architecture.
  • the beneficial effect is that the virtual machine architecture of this structure is not based on the stack-based virtual machine architecture.
  • an ELF file protection system based on ARM instruction virtualization includes: a conversion unit that converts original function instructions into bytecodes, saves jump instructions of original functions, registers, and stack information, And deleting the remaining instructions; the jump unit, executing the jump instruction; and the interpretation engine interpreting the byte code input after executing the jump instruction according to the preset bytecode semantics.
  • a computer program comprising computer readable code that, when executed on a computing device, causes the computing device to perform the ARMF virtualization based ELF file protection method described above.
  • a computer readable medium storing the above computer program.
  • the original function is virtualized by converting the original function instruction into a byte code, that is, the original function instruction is translated into a string of pseudo code byte streams that are not recognized by both the machine and the human, and Delete the original function instruction.
  • the cracker is cracking, since the original function instruction can not be found, only a string of pseudo code byte streams can be found, and a specific tool must be developed to analyze and decompile the bytecode, which is quite time consuming. Power consumption.
  • the pseudo code byte stream is interpreted by an interpretation engine (also referred to as a virtual machine) using preset semantics, so that the original function instruction code can be simulated and executed. This improves the protection of ELF files.
  • the interpretation engine includes a plurality of sub-interpretation units.
  • the beneficial effect is that the original function instructions are various and the organizational form is also ever-changing.
  • the interpretation engine cannot translate and interpret for each specific situation. All the instructions that may be encountered must be abstracted and then decomposed into several The simple small instructions are then handed over to the specialized sub-interpretation units for processing, and the multiple sub-interpretation units cooperate with the coordination to complete the execution of the entire instruction.
  • the interpretation engine employs a stack-based virtual machine architecture.
  • the beneficial effect is that the stack-based virtual machine does not have the concept of temporary variables, registers, everything is put on the stack, the operation stack needs to be frequently operated, and the virtual registers used are saved in In the stack, the sub-interpretation unit of each original instruction needs to push and pop. Since there is no need to specify an operand in the instruction, the instruction is relatively simple, the instruction system is simple, and the reusability is high.
  • FIG. 1 is a flowchart of an ELF file protection method based on ARM instruction virtualization according to an embodiment of the present invention
  • FIG. 2 is a flow chart of refining an ELF file protection system based on ARM instruction virtualization according to an embodiment of the present invention
  • FIG. 3 is a schematic structural diagram of an ELF file protection system based on ARM instruction virtualization according to an embodiment of the present invention
  • FIG. 4(a) shows an example of an original function
  • FIG. 4(b) shows a case where the original function of the example is processed by the method of the embodiment of the present invention
  • 5(a) and (b) are respectively used to illustrate an example of jumping to a bytecode interpretation engine entry in a method according to an embodiment of the present invention
  • FIG. 6 is a schematic flowchart of a method for reinforcing a multi-ELF file
  • FIG. 7 is a block diagram schematically showing a computing device for performing an ARM instruction virtualization-based ELF file protection method according to an embodiment of the present invention.
  • FIG. 8 schematically illustrates a storage unit for holding or carrying program code implementing an ARM instruction virtualization-based ELF file protection method in accordance with an embodiment of the present invention.
  • an application that can be installed and run needs to be packaged into an Android installation package, ie the APK file format.
  • the APK file is generally downloaded and installed on the mobile phone through the Android application market, and can also be installed from the PC through a data cable interface such as a USB data cable or wireless data transmission.
  • the Android installation package is actually a ZIP file format, but the suffix name is modified to .apk, which can be decompressed by Unzip and other tools to see its internal file structure.
  • Android applications are usually developed in the Java language. After compiling with Android development tools, they become binary bytecodes. These bytecodes are packaged into classes.dex files, which are used by the Dalvik virtual machine on the Android platform. Explain execution.
  • the Android system provides a set of operating environment (Android Framework), the Android application calling system functions are all realized by calling the Android Framework library.
  • the Android system also supports applications running directly through JNI or native executable. At this point, the application executes the binary machine code running directly on the CPU. It does not need to be interpreted by the virtual machine. It can directly call the Android library such as libc, WebKit, SQLite, OpenGL/ES to call the system functions.
  • ELF is an abbreviation of Executable and Linkable Format, which is a file format of executable programs and shared libraries in the Android/Linux operating system.
  • the ELF file in the Android platform is mainly a shared link library file, and its extension is .so, so it is also called a SO file.
  • the instruction format of the SO file is the ARM instruction set or the Thumb instruction set of the ARM architecture.
  • Android's SO file mainly plays the role of interacting with Java through JNI, so it is mainly used as an inventory (and some SO files are executable), and then Loaded by Android Runtime and can be called by the Java layer.
  • SO files are usually stored in the armeabi subfolder of the APK's lib directory.
  • FIG. 1 schematically shows an ELF file protection method based on ARM instruction virtualization according to an embodiment of the present invention.
  • an ELF file protection method based on ARM instruction virtualization includes the following steps:
  • Converting raw function instructions to bytecode can also be referred to as virtualizing the original function.
  • the corresponding bytecode is 0D 01 03 00 00 00 02 05 00 00 00 04 05 00 00 00, thus completing the virtualization of the original function instruction, thus the original function
  • the instructions are converted to bytecode that appears to be meaningless on the surface. Machines and people are unrecognizable, so you need to interpret the execution with a specially configured interpretation engine such as VMP (Virtual Machine Protect).
  • the original function instructions are all virtualized into bytecode.
  • the register information needs to be updated continuously during the execution of the instruction of the original function, it is necessary to simultaneously update the saved register information when interpreting the bytecode corresponding to the instruction, thereby ensuring that the register information is interpreted in the bytecode. Synchronization and balance in the process, in turn, to achieve the effect of simulating the execution of the original function instructions.
  • the interpretation engine VMP puts all registers in the stack structure (VM_CONTEXT), and each item in the structure represents a register or temporary variable.
  • the register and stack information corresponding to the original function are stored at the interpretation engine VMP entry.
  • Fig. 4(a) shows an example of an original function
  • Fig. 4(b) shows a case where the original function of the example is processed by the method of the embodiment of the present invention.
  • the code shown in the figure is a function that virtualizes the original function __cxa_f_10x. It can be seen that the instructions of the original function have all disappeared, and correspondingly some unrecognized bytes in the above code are the bytecodes corresponding to the instructions in the original function.
  • the box "B loc_8F98" Is a function jump instruction, jumps to the interpretation engine VMP entry, and saves the information of the symbol register CPSR. Executing this instruction will jump to the interpretation function for interpretation of the bytecode.
  • "BL sub_8FDC" in the block is a function jump instruction, and execution of the instruction jumps to the interpretation function to interpret the bytecode.
  • the bytecode corresponding to each instruction is isolated by 0x00.
  • the register and stack information stored in the interpretation engine entry need to be updated to ensure the synchronization of the original function register information.
  • the interpretation function parses the bytecodes one by one with the preset bytecode semantics.
  • the interpretation engine updates the saved register and stack information to ensure the integrity of the original function.
  • the interpretation engine exits the original function register and stack information to ensure synchronization and balance of the register information in the bytecode interpretation process, and returns the original function.
  • the above embodiments are not limited to virtualization of a single function, but are applicable to virtualization of a plurality of functions (function A, function B).
  • the original instructions are all converted into bytecodes that the CPU cannot directly execute, in the engine design process, it is necessary to achieve the full simulation of the original instructions, that is, to ensure the semantic integrity of the original instructions.
  • the main consideration is, first of all, to ensure that the bytecode is read correctly.
  • the original instruction may have many different types of expressions, such as the LDR instruction, which can be expressed as:
  • the correct execution of the instruction depends entirely on whether the corresponding bytecode can be successfully interpreted.
  • the homemade engine ensures that the bytecode can be read and executed correctly.
  • the interpretation engine can include an interpretation unit for determining an interpreter corresponding to the bytecode.
  • the interpreter corresponding to the bytecode is determined by the interpreting unit, the interpreting unit completes the bytecode execution, interprets the bytecode using the internally set semantics, and gradually restores the original function instruction and executes.
  • the interpretation unit can include a plurality of sub-interpretation units.
  • the original function instructions are varied and the organizational form is ever-changing.
  • the interpretation engine cannot translate and interpret for each specific situation.
  • all the commands that may be encountered are first classified, and then decomposed into a number of simple small instructions, which are handed over to the specialized sub-interpretation units for processing.
  • a plurality of sub-interpretation units cooperate with the coordination work to complete the execution of the entire instruction.
  • the interpretation engine distributes the decoding algorithm to the dispatcher Dispatch and each subroutine Handler. It only decrypts when fetching and fetching data, and each decoding algorithm is different, and its Seed changes every time it is decrypted. , which further increases the difficulty of cracking the cracker.
  • Vsplit separate each instruction, the value is 0
  • VPushImm32 tells the engine that there are immediate values in the command
  • VPushReg32 tells the engine that the register type in the instruction source operand
  • VPopReg32 Tell the engine, target register type
  • Vwriteback Specially handles LDR or STR instructions, tells the engine that after the target register is assigned, it needs to continue to operate the source register.
  • the engine When the engine processes the bytecode, it first acquires the first bytecode, and then determines the type of the instruction, and then proceeds to the subinterpretation unit to process the instruction. When the processing is completed, VSplit is encountered and the subunit is exited. Continue to explain the next instruction.
  • virtual small instructions need to be processed, including (VPushImm32, VPushReg32, VPushDstReg32, VPopReg32, Vwriteback), and the stack is frequently operated to update the original function register information stored in the stack.
  • the interpretation engine can employ a stack-based virtual machine. Since the stack-based virtual machine does not have the concept of temporary variables and registers, all the contents are put into the stack, and the stack needs to be operated frequently. The virtual registers used by them are stored in the stack, and the sub-interpretation units of each original instruction are required. Push, Pop. Since there is no need to specify an operand in the instruction, the instruction is relatively simple, the instruction system is simple, and the reusability is high.
  • the stack-based virtual machine first pops two numbers from the stack, then adds the two numbers, and pushes the sum onto the stack.
  • the ADD instruction takes up only one byte.
  • the parameters and returns of the ADD instruction are on the stack. There are no complicated registers and memory operations, and the instruction system is very simple.
  • FIG. 6 is a schematic flow chart of a method for reinforcing an ELF file. As shown in FIG. 6, the method includes:
  • step S61 a plurality of SO files are merged into one shell program file to uniformly pack a plurality of SO files to be protected. That is, writing multiple SO files to a specified location in a shell file, The shell file will run before the SO file to get priority and protect the SO file from being illegally modified or decompiled.
  • the full name of the shell is the compression and encryption of executable program resources. Packing, in fact, is to add a coat to the executable file. All the user is executing this shell. When the shell is executed, it decompresses or decrypts the original program in memory, decompresses or decrypts it, and then returns the execution right of the program to the real program. So, the work of these is only performed in memory.
  • the existing method of packing SO files is generally only for a single SO file, that is, a SO file is shelled once. If there are many SO files, it will be packed several times, which will inevitably result in a large volume of the final installation package.
  • all the SO files under lib are uniformly integrated into the same shell, that is, written to a specified position in a shell program file. Through the detection, it is found that the space shrinkage of all SO files is generally about 30% after the shell is added, and the larger the number of SO files, the larger the file size, and the smaller the space occupied.
  • Step S62 performing protection processing on the plurality of SO files in the shell program file, that is, further refining the SO file after the unified shelling.
  • Step S63 receiving a call request of at least one SO file, and determining an object to be called corresponding to the call request.
  • Step S64 calling the at least one SO file at the shell program file according to the determined object to be called.
  • the added shell program loads the corresponding request according to the call request, that is, helps to complete the loading of the requested SO file.
  • the shell program file in the method shown in FIG. 6 includes code capable of decrypting the protected SO file.
  • the shell file will run before the SO file to obtain the priority, and the protected SO file will be decrypted, so that the source code of the SO file is restored to complete, the code is sorted normally, and Encrypted, fully-recoverable code that can be loaded and loaded normally after unpacking.
  • the incorporation of a plurality of SO files into a shell program file in step 61 of the method shown in FIG. 6 includes:
  • the plurality of SO files are converted into a binary stream and written into a shell program file, and the shell program file includes at least header file information of the plurality of SO files.
  • the step of refining the plurality of SO files in the shell program file in step S62 of the method shown in FIG. 6 may be one or more of the following processing methods:
  • step S63 the call request of the at least one SO file is received, and the object to be called corresponding to the call request is determined to include:
  • the invoking the at least one SO file at the shell program file according to the determined object to be called includes:
  • the determination result of the object to be called is received, and the at least one SO file is called accordingly.
  • the shell program file receives the call request of the at least one SO file, and the object to be called corresponding to the call request includes:
  • the hook is used to receive a call request of a third-party application between the third-party application and the shell program file, and parse the object to be called corresponding to the call request.
  • Hook (hook) technology is widely used in computer security technology to hook and intercept various functions of the application to be monitored, so as to monitor the event behavior of these applications, and call different hook functions for different event behaviors to achieve Corresponding security protection according to different behaviors.
  • Hook is a mechanism set by the application during Windows message processing to monitor the message flow and process a certain type of message process in the system that has not yet reached the destination window. If the Hook process is implemented in the application, the Hook will not work if the application is not the current window; if the Hook is implemented in a DLL, the program dynamically calls it during runtime, which can monitor the system in real time. Hook's ability to "integrate" its own code into the process of a hooked program becomes part of the target process. "Hooks" encompasses techniques for altering or increasing the behavior of an operating system, application, or other software component by intercepting function calls, messages, or events passed between software components. The code that handles this intercepted function call, event, or message is called a hook function.
  • Hooks are often used for a variety of purposes, including debugging features and extending functionality. Examples of this may include intercepting keyboard or mouse events before they are passed to the application, or intercepting system calls, system function behavior, function execution results, etc. to monitor or modify the functionality of the application or other components, and the like.
  • this embodiment adopts a hook function to intercept the calling function of the third party to the SO file, and then calls the added shell program, that is, the added shell file completes the actual SO file according to the file name of the SO. load.
  • Android Since Android is an open source system based on the Linux kernel, it can be divided into Java layer, Native C layer, and Linux Kernel layer according to different language environments. Under normal circumstances, the third party calls the SO file, and the corresponding SO file must be loaded according to the SO file name through the Java layer's LoadLibrary function. Specifically, LoadLibrary will call the dlopen function in libdvm.so to finally load the SO file.
  • JNI_OnLoad is the entry function.
  • JNI_OnLoad is the entry function.
  • a function A that needs to be called by the JNI_OnLoad function.
  • the normal process is:
  • function A is converted to a jump instruction. And bytecode.
  • A' mainly includes an interpretation engine (VMP) entry address, an exit address, and a bytecode after virtualization processing, that is, the virtualized function A described above.
  • VMP interpretation engine
  • the interpretation engine can be integrated into this SO as part of the SO, not alone.
  • an ELF file protection system based on ARM instruction virtualization includes a conversion unit 10, a jump unit 20, and an interpretation engine 30.
  • the conversion unit 10 is configured to convert the original function instruction into a byte code, save the register of the original function and the stack information, add the jump instruction, and delete the remaining instructions; the jump unit 20 executes the jump instruction, and jumps to the explanation.
  • the engine entry may include an interpreting unit 301 that interprets the bytecodes one by one according to preset bytecode semantics. After the bytecodes are interpreted, the engine functions are jumped out and jumped to the engine exit to be restored at the engine exit. The original function stack and register information, then return to the original function.
  • the interpretation engine 30 can include an update unit 302 that updates the saved registers and stack information during the interpretation of the bytecode.
  • FIG. 7 illustrates a computing device that can implement an ARM instruction virtualization based ELF file protection method in accordance with the present invention.
  • the computing device traditionally includes a processor 710 and a computer program product or computer readable medium in the form of a storage device 720.
  • Storage device 720 can be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read Only Memory), EPROM, hard disk, or ROM.
  • Storage device 720 has a storage space 730 that stores program code 731 for performing any of the method steps described above.
  • storage space 730 storing program code may include various program code 731 for implementing various steps in the above methods, respectively.
  • the program code can be read from or written to one or more computer program products.
  • These computer program products include program code carriers such as a hard disk, a compact disk (CD), a memory card, or a floppy disk.
  • a computer program product is typically a portable or fixed storage unit such as that shown in FIG.
  • the storage unit may have storage segments, storage spaces, and the like that are similarly arranged to storage device 720 in the computing device of FIG.
  • the program code can be compressed, for example, in an appropriate form.
  • the storage unit comprises computer readable code 731' for performing the steps of the method according to the invention, ie code that can be read by a processor such as 710, which when executed by the computing device causes the computing device Perform each step in the method described above Step.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

一种基于ARM指令虚拟化的ELF文件保护方法及系统。所述方法包括：将原始函数指令转换成字节码；保存原始函数的寄存器以及堆栈信息，增加跳转指令，并删除其余指令；执行所述跳转指令，跳转至解释引擎以对所述字节码进行解释。由此，通过将原始函数指令虚拟化转换成字节码，增加了破解者的难度，提高了对文件的保护力度。

Description

基于ARM指令虚拟化的ELF文件保护方法及系统
相关申请的交叉参考
本申请主张在2015年12月25日在中国提交的中国专利申请号No.201510996999.4的优先权，其全部内容通过引用包含于此。
技术领域
本发明涉及安全技术领域，特别涉及基于ARM指令虚拟化的ELF文件保护方法及系统。
背景技术
安卓(Android)是一种基于Linux的自由及开放源代码的操作系统，主要使用于移动设备，如智能手机和平板电脑，由Google公司和开放手机联盟领导及开发。安卓平台发展迅速，已经逐渐成为了移动终端的最普及的操作系统，尤其是安卓平台已经深入到了各个领域，包括金融设备这种对安全性要求更高的产品。与其他终端操作系统相比，开放式的安卓系统为应用开发者提供了更多的功能接口，这些功能接口提高了系统的可扩展性，但同时也为恶意软件提供了便利。针对安卓系统的木马等恶意软件可以通过伪装的方式保存在安卓安装包中，骗取用户安装并授予一定的权限，之后通过滥用权限在后台执行一些特定行为，包括窃取用户隐私、骗取资费等行为；不仅如此，对于一些正常的安卓系统应用，也存在通过非法拷贝、逆向工程、反编译、调试、破解、二次打包、内存截取等手段来威胁安卓系统的安全，不仅危害了使用者的利益，也给正常应用开发者造成严重的损害。
目前市面上针对APK(Android Package的缩写，即Android安装包)的保护主要是基于dex(Dalvik VM Executes的简称，即Android Dalvik执行程序)。目前公开的有梆梆、爱加密、ApkProtect等。另一方面，Android平台的共享链接库文件，其扩展名为.so，因此也叫SO文件，采用ELF格式(Executable and Linkable Format：一种用于二进制文件、可执行文件、目标代码、共享库和核心转储的标准文件格式)。针对ELF格式的文件的保护就相对较弱。现有对于ELF文件大多是采用linker方式或者upx(Ultimate  Packer for eXecutables:可执行程序文件压缩器)方式，采用upx保护odex(APK中提取出来的可运行文件，即将APK中的classes.dex文件通过dex优化过程将其优化生成一个dex文件单独存放)转换程序。即通过加壳来进行保护。加壳的程序可以有效阻止对程序的反汇编分析，以保护软件版权，防止被软件破解。但是，破解者只需要用upx源代码稍作修改就可以脱壳此程序，其保护力度不够。也有采用猥琐代码来给破解者增加一定的复杂度的方式，即对函数名和字符串加密，并且将loader实现原理从java层全部移到jni(Java Native Interface：Java本地调用)实现，但是loader包和原包完全分离，原包仅为加密文件，可轻易实现内存dump(获取内存信息)。
发明内容
为了解决上述问题，本发明提供一种基于ARM(Advanced RISC Machine：高级精简指令机)指令虚拟化的ELF文件保护方法。
根据本发明的一个方面，提供了一种基于ARM指令虚拟化的ELF文件保护方法，包括：将原始函数指令转换成字节码；保存原始函数的寄存器以及堆栈信息，增加跳转指令，并删除其余指令；跳转至解释引擎以对字节码进行解释。
在一些实施方式中，原始函数指令可被分为多个虚拟化小指令并转换为相应的字节码，所述解释引擎可包括多个子解释单元以对多个虚拟化小指令相应的字节码进行解释。
其有益效果是，原始函数指令多种多样，组织形式也千变万化，解释引擎难以针对每一种具体情况都进行翻译解释。因此，通过对所有可能遇到的指令先进行归类，然后分解为若干简单的虚拟小指令，就可以将这些虚拟小指令交给各个专门的子解释单元去处理，各个子解释单元配合协调完成对整个指令的解释。实施更为简单灵活。
在一些实施方式中，对字节码进行解释采用基于堆栈的虚拟机架构体系。
其有益效果是，基于堆栈的虚拟机架构体系，这种结构的虚拟机体系没 有临时变量、寄存器的概念，所有的内容都放入堆栈中，需要频繁的操作堆栈，由于指令中不需要指定操作数，所以其指令相对简单，指令系统简洁，复用性高。
根据本发明的另一个方面，提供了一种基于ARM指令虚拟化的ELF文件保护系统包括：转换单元，将原始函数指令转换成字节码，保存原始函数的跳转指令，寄存器以及堆栈信息，并删除其余指令；跳转单元，执行跳转指令；解释引擎，根据预设的字节码语义对执行所述跳转指令后传入的字节码进行解释。
根据本发明的又一个方面，提供一种计算机程序，其包括计算机可读代码，当计算机可读代码在计算设备上运行时，导致计算设备执行上述的基于ARM指令虚拟化的ELF文件保护方法。
根据本发明的再一个方面，提供一种计算机可读介质，其中存储了上述计算机程序。根据本发明的上述方法和系统，通过将原始函数指令转换成字节码，即将原始函数指令翻译成机器和人都无法识别的一串伪代码字节流，对原始函数进行虚拟化处理，并且删除原始函数指令。这样，破解者在进行破解的时候，由于找不到原始函数指令，只能找到一串伪代码字节流，就必须开发出特定的工具来分析和反编译字节码，这样会相当耗时耗力。如此，通过将原始函数指令虚拟化对ELF文件进行保护，能够增加破译者的破译难度。在具体的执行过程中，通过解释引擎(也称为虚拟机)利用预设的语义对伪代码字节流进行解释，从而能模拟原始函数指令代码并执行。由此提高了对ELF文件的保护力度。在一些实施方式中，解释引擎包括多个子解释单元。
其有益效果是，原始函数指令多种多样，组织形式也千变万化，解释引擎不可能针对每一种具体情况都进行翻译解释，必须对所有可能遇到的指令先进行抽象归类，然后分解为若干简单的小指令，然后交给各个专门的子解释单元去处理，多个子解释单元配合协调工作，完成整个指令的执行。
在一些实施方式中，解释引擎采用基于堆栈的虚拟机架构。
其有益效果是，基于堆栈的虚拟机没有临时变量、寄存器的概念，所有的东西都放入堆栈中，需要频繁的操作堆栈，其使用的虚拟寄存器都保存在 堆栈中，每个原始指令的子解释单元都需要push、pop。由于指令中不需要指定操作数，所以其指令相对简单，指令系统简洁，复用性高。
附图概述
图1为本发明一实施方式的基于ARM指令虚拟化的ELF文件保护方法流程图；
图2为本发明一实施方式的基于ARM指令虚拟化的ELF文件保护系统细化实现流程图；
图3为本发明一实施方式的基于ARM指令虚拟化的ELF文件保护系统结构示意图；
图4(a)显示了原始函数的示例，图4(b)显示了该示例的原始函数经过本发明实施例的方法处理后的情况；
图5(a)和(b)分别用于说明在本发明一实施方式的方法中跳转至字节码解释引擎入口的示例；
图6是对多ELF文件的加固保护方法的流程示意图；
图7示意性地示出了用于执行根据本发明实施例的基于ARM指令虚拟化的ELF文件保护方法的计算设备的框图；
图8示意性地示出了用于保持或者携带实现根据本发明实施例的基于ARM指令虚拟化的ELF文件保护方法的程序代码的存储单元。
本发明的较佳实施方式
下面结合附图对本发明的实施方式进行说明。
本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。
本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。
需要指出的是，本发明的技术方案，理念上与操作系统的选型无关，对于windows、android、IOS等操作系统均适用。但为了说明的便利，以下将主要以Android为例进行说明。
在安卓系统上，一个可以安装、运行的应用，需要打包成安卓安装包，即APK文件格式。APK文件一般通过安卓应用市场下载、安装到手机上，也可以通过USB数据线等数据线接口或无线数据传输的方式从PC端安装。安卓安装包其实是ZIP文件格式，但后缀名被修改成.apk，可以通过Unzip等工具解压看到其内部文件结构。
Android应用通常是用Java语言开发的，它用Android开发工具编译之后变成了二进制的字节码(byte code)，这些字节码被打包成classes.dex文件，由Android平台的Dalvik虚拟机来解释执行。为了能够调用Android系统功能，Android系统提供了一套运行环境(Android Framework)，Android应用调用系统各功能都是通过调用Android Framework的库来实现的。另一方面，Android系统也支持应用程序通过JNI或者native executable直接运行。此时应用执行的是直接在CPU上运行的二进制机器码，不需要经过虚拟机解释，可以直接调用Android库如libc、WebKit、SQLite、OpenGL/ES等来调用系统各功能。如果Android应用要通过JNI或者native executable运行，就需要将要执行的代码编译成ELF文件格式。ELF是Executable and Linkable Format的缩写，是Android/Linux操作系统中可执行程序、共享库的文件格式。
本申请中，Android平台中ELF文件主要是共享链接库文件，其扩展名为.so，因此也叫SO文件。SO文件的指令格式是ARM体系结构的ARM指令集或Thumb指令集。安卓的SO文件主要充当的角色是通过JNI与Java交互，所以主要是作为一个库存在(也有一些SO文件是可执行的)，然后 被Android Runtime加载，并能被Java层调用。SO文件一般存放在APK的lib目录的armeabi子文件夹下。
图1示意性地显示了根据本发明的一种实施方式的基于ARM指令虚拟化的ELF文件保护方法。如图1和2所示，根据本发明的一个方面，基于ARM指令虚拟化的ELF文件保护方法，包括以下步骤：
S1.将原始函数转换成字节码。
将原始函数指令转换为字节码也可称为将原始函数虚拟化。例如，对于指令MOV R5，#3，转换成对应的字节码就是0D 01 03 00 00 00 02 05 00 00 00 04 05 00 00 00，这样就完成了原始函数指令的虚拟化，从而将原始函数指令转换成表面上看起来毫无意义的字节码。机器和人都无法识别，从而需要用特别设置的解释引擎(如特别设置的VMP(Virtual Machine Protect：虚拟机器保护引擎)来解释执行。
S2.保存原始函数的寄存器以及堆栈信息，增加跳转指令，并删除其余指令。
在转换(虚拟化)过程中，原始函数指令全部被虚拟化为字节码。同时，需要保存原始函数对应的寄存器及堆栈信息到一个新的位置。此外，由于在原始函数的指令执行过程中，需要不断更新寄存器信息，故需要在解释指令对应的字节码的时候，也要同时更新被保存的寄存器信息，从而保证寄存器信息在字节码解释过程中的同步及平衡，进而实现模拟原始函数指令执行过程的效果。
解释引擎VMP将所有寄存器都是放在堆栈结构(VM_CONTEXT)当中的，结构中的每一项代表一个寄存器或者临时变量。在本发明的一个实施方式中，将原始函数对应的寄存器及堆栈信息保存在解释引擎VMP入口处。
图4(a)显示一个原始函数的示例，图4(b)显示了该示例的原始函数经过本发明实施例的方法处理后的情况。
图中所示的代码是对原始函数__cxa_f_10x进行虚拟化后的函数。可见原始函数的指令已经全部消失，相对应上述代码中有一些不可识别的字节则是原始函数中指令对应的字节码。如图5(a)所示，方框中的“B loc_8F98” 是一个函数跳转指令，跳转至解释引擎VMP入口中，并保存符号寄存器CPSR的信息。执行该指令将跳转至解释函数进行字节码的解释。
如图5(b)所示，方框中的“BL sub_8FDC”为函数跳转指令，执行该指令即跳转至解释函数以对字节码进行解释。每条指令对应的字节码由0x00进行隔离。
由于原始函数在执行指令时需要更新寄存器信息。例如，指令“MOVER0，#1”就是将R0更新为1。所以在解释字节码的过程中，需要将保存在解释引擎入口的寄存器及堆栈信息进行更新，从而保证原始函数寄存器信息的同步。
S3.执行跳转指令，跳转至解释引擎入口。如上所述，解释引擎入口保存运行环境(各个寄存器的值)以及初始化堆栈(解释引擎使用的变量全部在堆栈中)。
同时，在跳转至解释函数后，解释函数用预设的字节码语义对字节码逐个进行解析。在解析指令对应的字节码的过程中，解释引擎更新被保存的寄存器及堆栈信息，以保证原始函数完整性。字节码解释完毕后，跳转至解释引擎出口，解释引擎出口恢复原始函数寄存器及堆栈信息，以保证寄存器信息在字节码解释过程中的同步及平衡，并返回原始函数。由此，可以实现对原始函数指令执行过程的模拟。
如图2所示，上述实施方式并不限于对单个函数的虚拟化，而是适用于对多个函数(函数A，函数B…)的虚拟化。
由于原始指令全部被转换成CPU不可直接执行的字节码，故在引擎设计过程中，必须要能够达到对原始指令进行完全模拟的效果，即要保证原始指令的语义完整性解释。其中主要考虑的是，首先，要确保正确地读取字节码。原始指令可能会有多种不同类型的表达方式，如LDR指令即可表示为：
LDR R0,[R1]
LDR R0,[R1,#4]
LDR R0,[R1,R2LSL#2]
LDR R0,[R1,#4]！等，
相应地，引擎的设计也需要针对各原始指令这些不同表达的情况进行罗列并分别进行解释。
此外，对函数跳转指令，需要确认函数是函数内部跳转还是函数外部跳转，并需要准确计算出目标跳转地址。所以原始指令的语义完整性解释决定了指令是否能够正确执行。
指令的正确执行完全依赖于对应的字节码是否能够被成功解释。而自创引擎则保证了字节码能够被正确读取以及执行。
解释引擎可包括解释单元，用于确定与字节码对应的解释程序。通过解释单元确定与字节码对应的解释程序，解释单元完成字节码执行，采用内部设定的语义对字节码进行解释，逐步还原原始函数指令并执行。
在一个实施例中，解释单元可包括多个子解释单元。如上所述，原始函数指令多种多样，组织形式也千变万化，解释引擎不可能针对每一种具体情况都进行翻译解释。本实施例中，对所有可能遇到的指令先进行归类，然后分解为若干简单的小指令，交给各个专门的子解释单元去处理。多个子解释单元配合协调工作，完成整个指令的执行。解释引擎把解码算法分布到了调度器Dispatch和每个子程序Handler中，只有在取指令和取数据时才会解密，而每个解码的算法也都是不同的，并且它的Seed每次解密都会变化，从而进一步增加了破解者的破译难度。
例如：MOV R0,#3这条指令，可以分解成几个虚拟小指令：
Vmov
VPushImm32 0x3
VPushReg R0
VPopReg R0
对应的字节码为：
0D 01(03 00 00 00)02(00 00 00 00)04(00 00 00 00)
以下是一些常见的虚拟小指令类型及其说明：
指令对应的虚拟指令(Vmov,Vldr,Vadd…..),
Vsplit：分隔每一条指令，该值为0
VPushImm32：告知引擎，指令中有立即数
VPushReg32：告知引擎，指令源操作数中的寄存器类型
VPushDstReg32：特殊处理STR指令
VPopReg32：告知引擎，目标寄存器类型
Vwriteback：特殊处理LDR或者STR指令，告知引擎，目标寄存器赋值完毕后，需要继续操作源寄存器。
当引擎处理字节码的时候，首先获取第一个字节码，进而判断指令类型，然后进入到子解释单元进而处理该指令。当处理完毕后，遇到VSplit，退出该子单元。继续解释下一条指令。
在子解释单元中，需要处理虚拟小指令，包括(VPushImm32，VPushReg32，VPushDstReg32，VPopReg32，Vwriteback)，并频繁地操作堆栈，更新保存在堆栈中的原始函数寄存器信息。
在一个实施例中，解释引擎可以采用基于堆栈的虚拟机。由于基于堆栈的虚拟机没有临时变量、寄存器的概念，所有的内容都放入堆栈中，需要频繁的操作堆栈，其使用的虚拟寄存器都保存在堆栈中，每个原始指令的子解释单元都需要Push、Pop。由于指令中不需要指定操作数，所以其指令相对简单，指令系统简洁，复用性高。
例如，对于指令ADD，基于堆栈的虚拟机首先从堆栈里Pop两个数，然后将两个数相加，再把和Push到堆栈中。ADD指令只占用一个字节，ADD指令的参数和返回都是在堆栈里，没有复杂的寄存器与内存操作，指令系统非常简洁。
下面以对一个ELF文件加固的示例简单说明字节码是如何进入到引擎中，以及如何输出的。
图6是一个ELF文件的加固方法的流程示意图。如图6所示，该方法包括：
步骤S61，将多个SO文件并入一个壳程序文件中以对待保护的多个SO文件进行统一加壳。即，将多个SO文件写入一个壳程序文件中的指定位置， 壳程序文件会先于SO文件运行，取得优先权，保护SO文件不被非法修改或反编译。
加壳的全称是可执行程序资源的压缩和加密。加壳，其实就是给可执行文件加上个外衣。用户执行的只是这个外壳程序。当执行这个外壳程序的时候，它就会在内存中解压或者解密原程序，解压或解密后再把程序的执行权交还给真正的程序。所以，这些的工作只是在内存中执行的。
现有对SO文件的加壳方法一般是只针对单个SO文件加壳，即一个SO文件加壳一次，如果SO文件很多，就会进行多次加壳，势必造成最终安装包的体积很大。在本发明实施例中，通过将lib下的所有SO文件统一并入同一个壳中，即写入一个壳程序文件中的指定位置。通过检测发现，对所有的SO文件合并加壳后其所占空间缩小量一般在30％左右，而且SO文件数量越多，文件越大，其所占空间的缩小量就越大。
步骤S62，对壳程序文件中的多个SO文件进行加保护处理，即主要对统一加壳后的SO文件进一步的加固。
步骤S63，接收至少一个SO文件的调用请求，确定所述调用请求所对应的待调用对象。
步骤S64,根据所确定的待调用对象，在所述壳程序文件处对所述至少一个SO文件进行调用。
由于SO文件进行了统一加壳处理，所以当第三方对其进行调用时，要由所加的壳程序根据调用请求进行相应的加载，即帮助完成所请求的SO文件的加载。
在本发明的一个实施例中，图6所示的方法中的壳程序文件中包含能够对加保护处理后的SO文件进行解密处理的代码。在加载运行SO文件时，壳程序文件会先于SO文件运行，取得优先权，对加保护处理后的SO文件进行解密处理，使得SO文件的源代码恢复为完整的、代码排序正常的、无加密的、可完全还原的代码，进而在解壳后可以正常的加载运行。
在本发明的一个实施例中，图6所示方法的步骤61中将多个SO文件并入一个壳程序文件中包括：
将所述多个SO文件转换成二进制流，写入一个壳程序文件中，所述壳程序文件中至少包含所述多个SO文件的头文件信息。
在本发明的一个实施例中，图6所示方法的步骤S62中对壳程序文件中的多个SO文件进行加固处理可以是如下的一种或多种处理方式：
1)去掉多个SO文件的隐藏信息，从而导致SO文件信息缺失，即使有人对SO文件进行恶意解密或反编译，也无法得到完整的SO文件，很难做到静态工具分析。
2)对多个SO文件进行分段加密处理。可以是对多个SO文件的数据节和代码节分别进行加密，增加解密难度。
3)对多个SO文件进行代码混淆处理，在不改变代码逻辑的情况下，在多个SO文件的代码中增加无用代码，或者对多个SO文件的代码进行重命名，使反编译后的源代码难以看懂，增加反编译后代码分析的难度。
4)对多个SO文件进行反调试处理。可以是将可用于反调试的点插入到多个SO文件进行代码混淆后的代码中；代码混淆后，反调试的点就不容易找到，这样能给破解者进行调试的时候造成很多困扰，增加破解难度。
步骤S63中接收至少一个SO文件的调用请求，确定所述调用请求所对应的待调用对象包括：
在壳程序文件外接收至少一个SO文件的调用请求，确定所述调用请求所对应的待调用对象；
所述根据所确定的待调用对象，在壳程序文件处对所述至少一个SO文件进行调用包括：
在壳程序文件处，接收所述待调用对象的确定结果，相应地对所述至少一个SO文件进行调用。
在一个实施例中，壳程序文件外接收至少一个SO文件的调用请求，确定所述调用请求所对应的待调用对象包括：
在系统库文件中建立钩子；
利用所述钩子在第三方应用和所述壳程序文件之间接收第三方应用的调用请求，解析所述调用请求所对应的待调用对象。
计算机安全技术中广泛采用Hook(钩子)技术对待监控的应用程序的各种函数进行挂钩拦截，以便实现对这些应用程序的事件行为的监控，对应不同事件行为调用不同的钩子函数进行处理，从而实现依据不同的行为做出相应的安全防护处理。
其中，Hook(钩子)是应用程序在Windows消息处理过程中设置的用来监控消息流并且处理系统中尚未到达目的窗口的某一类型消息过程的机制。如果Hook过程在应用程序中实现，若应用程序不是当前窗口时，该Hook就不起作用；如果Hook在DLL中实现，程序在运行中动态调用它，它能实时对系统进行监控。Hook的这个本领，使它能够将自身的代码“融入”被Hook住的程序的进程中，成为目标进程的一个部分。“钩子”涵盖了用于通过拦截在软件组件之间传递的函数调用、消息、或事件来改变或增加操作系统、应用程序、或其他软件组件的行为的技术。而处理这种被拦截的函数调用、事件或消息的代码就被称为钩子函数。钩子通常用于各种目标，包括对功能进行调试和对功能进行扩展。其示例可以包括在键盘或鼠标事件传递到应用程序之前拦截它们，或者拦截系统调用(system call)、或者系统函数行为、函数执行结果等，以监视或修改应用程序或其他组件的功能等等。
基于这一原理，本实施例采用钩子函数，拦截第三方对SO文件的调用函数，转而调用所加的壳程序，即由所加的外壳程序文件根据SO的文件名完成实际的SO文件的加载。
由于Android是基于Linux内核的开源系统，根据语言环境不同可以分为Java层、Native C层、Linux Kernel层。正常情况下，第三方调用SO文件，必须通过Java层的LoadLibrary函数根据SO文件名进行相应的SO文件的加载。具体来说，LoadLibrary会调用libdvm.so里面的dlopen函数来最终加载SO文件。
系统加载SO文件的正常流程是首先把SO映射到内存，然后执行INIT_ARRAY，进而进入JNI_OnLoad函数。JNI_OnLoad是入口函数。假设有函数A需要被JNI_OnLoad函数调用。正常流程为：
JNI_OnLoad＝>A＝>返回至JNI_OnLoad
如果要将函数A作为保护的对象，那么函数A就被转换为跳转指令以 及字节码。
JNI_OnLoad＝>A’＝>引擎＝>A’＝>返回至JNI_OnLoad
A’主要包括解释引擎(VMP)入口地址、出口地址以及虚拟化处理后的字节码，即上文所描述的虚拟化后的函数A。
解释引擎可以集成在这个SO当中，作为SO的一部分，而非单独存在。
如图3所示，根据本发明的另一个方面，基于ARM指令虚拟化的ELF文件保护系统包括转换单元10，跳转单元20，和解释引擎30。其中，转换单元10用于将原始函数指令转换成字节码，并保存原始函数的寄存器以及堆栈信息，增加跳转指令，并删除其余指令；跳转单元20执行跳转指令，跳转至解释引擎入口；解释引擎30可包括解释单元301，按照预设的字节码语义对字节码逐个进行解释，字节码解释完毕后，跳出引擎函数，并跳转至引擎出口，在引擎出口恢复原始函数堆栈以及寄存器信息，然后返回原始函数。解释引擎30可包括更新单元302，在解释所述字节码的过程中，更新被保存的寄存器及堆栈信息。
图7示出了可以实现根据本发明的基于ARM指令虚拟化的ELF文件保护方法的计算设备。该计算设备传统上包括处理器710和以存储设备720形式的计算机程序产品或者计算机可读介质。存储设备720可以是诸如闪存、EEPROM(电可擦除可编程只读存储器)、EPROM、硬盘或者ROM之类的电子存储器。存储设备720具有存储用于执行上述方法中的任何方法步骤的程序代码731的存储空间730。例如，存储程序代码的存储空间730可以包括分别用于实现上面的方法中的各种步骤的各个程序代码731。这些程序代码可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。这些计算机程序产品包括诸如硬盘、紧致盘(CD)、存储卡或者软盘之类的程序代码载体。这样的计算机程序产品通常为例如图8所示的便携式或者固定存储单元。该存储单元可以具有与图7的计算设备中的存储设备720类似布置的存储段、存储空间等。程序代码可以例如以适当形式进行压缩。通常，存储单元包括用于执行根据本发明的方法步骤的计算机可读代码731＇，即可以由诸如710之类的处理器读取的代码，当这些代码由计算设备运行时，导致该计算设备执行上面所描述的方法中的各个步 骤。
以上所述的仅是本发明的一些实施方式。对于本领域的普通技术人员来说，在不脱离本发明创造构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。

Claims (12)

  1. 基于ARM指令虚拟化的ELF文件保护方法，包括：
    将原始函数指令转换成字节码；
    保存原始函数的寄存器以及堆栈信息，增加跳转指令，并删除其余指令；
    执行所述跳转指令，跳转至解释引擎以对所述字节码进行解释。
  2. 根据权利要求1所述的基于ARM指令虚拟化的ELF文件保护方法，还包括：所述跳转指令指向所述解释引擎入口，所述解释引擎入口保存各个指令寄存器的值和初始化堆栈。
  3. 根据权利要求1或2所述的基于ARM指令虚拟化的ELF文件保护方法，其中所述解释引擎在解释所述字节码的过程中，更新被保存的寄存器及堆栈信息。
  4. 根据权利要求1-3任一项所述的基于ARM指令虚拟化的ELF文件保护方法，其中所述原始函数指令被分为多个虚拟化小指令并转换为相应的字节码；和/或
    所述解释引擎采用多个子解释单元对所述字节码进行解释。
  5. 根据权利要求1-4任一项所述的基于ARM指令虚拟化的ELF文件保护方法，其中所述对字节码进行解释采用基于堆栈的虚拟机架构。
  6. 基于ARM指令虚拟化的ELF文件的保护系统，包括：
    转换单元，用于将原始函数指令转换成字节码，保存原始函数的跳转指令，寄存器以及堆栈信息，并删除其余指令；
    跳转单元，执行所述跳转指令；
    解释引擎，根据预设的字节码语义对执行所述跳转指令后传入的字节码进行解释。
  7. 根据权利要求6所述的基于ARM指令虚拟化的ELF文件保护装置，其中所述解释引擎包括包括多个子解释单元。
  8. 根据权利要求6所述的基于ARM指令虚拟化的ELF文件保护系统，其中所述解释引擎采用基于堆栈的虚拟机架构。
  9. 根据权利要求6-8任一项所述的基于ARM指令虚拟化的ELF文件保护系统，其中所述跳转指令指向所述解释引擎入口，所述解释引擎入口保存各个指令寄存器的值和初始化堆栈。
  10. 根据权利要求6-8任一项所述的基于ARM指令虚拟化的ELF文件保护系统，其中所述解释引擎还包括更新单元，在解释所述字节码的过程中，更新被保存的寄存器及堆栈信息。
  11. 一种计算机程序，包括计算机可读代码，当所述计算机可读代码在计算设备上运行时，导致所述计算设备执行根据权利要求1-5中的任一项所述的基于ARM指令虚拟化的ELF文件保护方法。
  12. 一种计算机可读介质，其中存储了如权利要求11所述的计算机程序。
PCT/CN2016/106146 2015-12-25 2016-11-16 基于arm指令虚拟化的elf文件保护方法及系统 WO2017107706A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510996999.4A CN105608346A (zh) 2015-12-25 2015-12-25 基于arm指令虚拟化的elf文件保护方法及系统
CN201510996999.4 2015-12-25

Publications (1)

Publication Number Publication Date
WO2017107706A1 true WO2017107706A1 (zh) 2017-06-29

Family

ID=55988275

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/106146 WO2017107706A1 (zh) 2015-12-25 2016-11-16 基于arm指令虚拟化的elf文件保护方法及系统

Country Status (2)

Country Link
CN (1) CN105608346A (zh)
WO (1) WO2017107706A1 (zh)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109684794A (zh) * 2018-12-07 2019-04-26 成都盈海益讯科技有限公司 一种代码保护虚拟机kvm系统实现方法、装置、计算机设备及存储介质
CN110275710A (zh) * 2019-06-10 2019-09-24 天翼电子商务有限公司 一种Java本地接口一致性检查方法及系统、存储介质及终端
CN110489162A (zh) * 2019-08-02 2019-11-22 北京字节跳动网络技术有限公司 安装包so文件精简方法、装置、介质和设备
CN110554998A (zh) * 2018-03-30 2019-12-10 腾讯科技（深圳）有限公司 一种通过替换函数内部指令的钩子方法、装置、终端及存储介质
CN111190604A (zh) * 2019-12-30 2020-05-22 航天信息股份有限公司 一种安卓应用内存混淆方法、装置、电子设备及介质
CN111562916A (zh) * 2019-02-13 2020-08-21 百度在线网络技术（北京）有限公司 共享算法的方法和装置
CN112114933A (zh) * 2020-08-14 2020-12-22 咪咕文化科技有限公司 应用程序保护方法、电子设备和存储介质
CN112486496A (zh) * 2020-11-25 2021-03-12 上海连尚网络科技有限公司 一种用于生成和运行so文件的方法与设备
CN112883374A (zh) * 2021-02-02 2021-06-01 电子科技大学 一种基于ART环境下的Android平台应用程序通用脱壳方法及系统

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105608346A (zh) * 2015-12-25 2016-05-25 北京奇虎科技有限公司 基于arm指令虚拟化的elf文件保护方法及系统
CN106096338B (zh) * 2016-06-07 2018-11-23 西北大学 一种具有数据流混淆的虚拟化软件保护方法
CN108460276B (zh) * 2016-12-09 2022-01-25 北京奇虎科技有限公司 一种安卓安装包的动态链接库so文件的处理方法和装置
CN106778271B (zh) * 2016-12-15 2019-05-14 华中科技大学 一种安卓加固插件的逆向处理方法
CN108334756B (zh) * 2017-01-20 2020-05-12 武汉斗鱼网络科技有限公司 一种对递归下降式分析器反编译的干扰方法及装置
CN107122635A (zh) * 2017-04-27 2017-09-01 北京洋浦伟业科技发展有限公司 一种so文件的加固方法、装置和apk的加固方法
CN107480476B (zh) * 2017-06-15 2020-05-19 西北大学 一种基于ELF感染的Android本地层指令编译虚拟化加壳方法
CN107577925B (zh) * 2017-08-11 2019-07-05 西北大学 基于双重ARM指令虚拟的Android应用程序保护方法
CN107480479B (zh) * 2017-08-15 2020-08-07 北京奇虎科技有限公司 应用程序的加固方法及装置、计算设备、计算机存储介质
CN110096338B (zh) * 2019-05-10 2021-12-14 百度在线网络技术（北京）有限公司 智能合约执行方法、装置、设备及介质
CN110502874B (zh) * 2019-07-19 2021-05-25 西安理工大学 一种基于文件自修改的Android App加固方法
CN110457046B (zh) * 2019-08-22 2023-05-12 广州小鹏汽车科技有限公司 混合指令集程序的反汇编方法、装置、存储介质及终端
CN113536328A (zh) * 2020-04-21 2021-10-22 中国移动通信集团重庆有限公司 链接库文件加密的方法、装置及计算设备
CN111767116B (zh) * 2020-06-03 2023-09-05 江苏中科重德智能科技有限公司 面向机械臂程序开发编程语言的虚拟机及对汇编文件的运行方法
CN112199160B (zh) * 2020-10-16 2021-12-28 常熟理工学院 虚拟指令还原方法、装置、设备及存储介质
CN112527392A (zh) * 2020-12-11 2021-03-19 成都云铀子网络科技有限公司 一种静态翻译和静态桥接的安卓模拟器指令翻译方法
CN113590624A (zh) * 2021-07-29 2021-11-02 北京天融信网络安全技术有限公司 一种数据处理方法及电子装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060271921A1 (en) * 2002-06-21 2006-11-30 Pace Antipiracy Protecting software from unauthorized use by converting source code modules to byte codes
CN102831342A (zh) * 2012-07-28 2012-12-19 北京深思洛克软件技术股份有限公司 一种提高安卓系统中应用程序保护强度的方法
CN105046117A (zh) * 2015-06-30 2015-11-11 西北大学 一种具有指令集随机化的代码虚拟化软件保护系统
CN105608346A (zh) * 2015-12-25 2016-05-25 北京奇虎科技有限公司 基于arm指令虚拟化的elf文件保护方法及系统

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102736943B (zh) * 2012-06-12 2015-06-17 电子科技大学 一种嵌入式浏览器引擎动态编译执行方法
CN103294518B (zh) * 2012-12-31 2016-04-27 北京北大众志微系统科技有限责任公司 一种解释器中间接跳转预测方法及系统
CN103530171A (zh) * 2013-10-25 2014-01-22 大唐微电子技术有限公司 一种智能卡虚拟机及其实现方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060271921A1 (en) * 2002-06-21 2006-11-30 Pace Antipiracy Protecting software from unauthorized use by converting source code modules to byte codes
CN102831342A (zh) * 2012-07-28 2012-12-19 北京深思洛克软件技术股份有限公司 一种提高安卓系统中应用程序保护强度的方法
CN105046117A (zh) * 2015-06-30 2015-11-11 西北大学 一种具有指令集随机化的代码虚拟化软件保护系统
CN105608346A (zh) * 2015-12-25 2016-05-25 北京奇虎科技有限公司 基于arm指令虚拟化的elf文件保护方法及系统

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110554998A (zh) * 2018-03-30 2019-12-10 腾讯科技（深圳）有限公司 一种通过替换函数内部指令的钩子方法、装置、终端及存储介质
CN110554998B (zh) * 2018-03-30 2024-02-13 腾讯科技（深圳）有限公司 一种通过替换函数内部指令的钩子方法、装置、终端及存储介质
CN109684794A (zh) * 2018-12-07 2019-04-26 成都盈海益讯科技有限公司 一种代码保护虚拟机kvm系统实现方法、装置、计算机设备及存储介质
CN109684794B (zh) * 2018-12-07 2023-06-23 成都盈海益讯科技有限公司 一种代码保护虚拟机kvm系统实现方法、装置、计算机设备及存储介质
CN111562916A (zh) * 2019-02-13 2020-08-21 百度在线网络技术（北京）有限公司 共享算法的方法和装置
CN110275710B (zh) * 2019-06-10 2023-07-14 天翼电子商务有限公司 一种Java本地接口一致性检查方法及系统、存储介质及终端
CN110275710A (zh) * 2019-06-10 2019-09-24 天翼电子商务有限公司 一种Java本地接口一致性检查方法及系统、存储介质及终端
CN110489162A (zh) * 2019-08-02 2019-11-22 北京字节跳动网络技术有限公司 安装包so文件精简方法、装置、介质和设备
CN110489162B (zh) * 2019-08-02 2023-09-22 北京字节跳动网络技术有限公司 安装包so文件精简方法、装置、介质和设备
CN111190604A (zh) * 2019-12-30 2020-05-22 航天信息股份有限公司 一种安卓应用内存混淆方法、装置、电子设备及介质
CN111190604B (zh) * 2019-12-30 2023-11-03 航天信息股份有限公司 一种安卓应用内存混淆方法、装置、电子设备及介质
CN112114933A (zh) * 2020-08-14 2020-12-22 咪咕文化科技有限公司 应用程序保护方法、电子设备和存储介质
CN112486496A (zh) * 2020-11-25 2021-03-12 上海连尚网络科技有限公司 一种用于生成和运行so文件的方法与设备
CN112883374B (zh) * 2021-02-02 2022-07-01 电子科技大学 一种基于ART环境下的Android平台应用程序通用脱壳方法及系统
CN112883374A (zh) * 2021-02-02 2021-06-01 电子科技大学 一种基于ART环境下的Android平台应用程序通用脱壳方法及系统

Also Published As

Publication number Publication date
CN105608346A (zh) 2016-05-25

Similar Documents

Publication Publication Date Title
WO2017107706A1 (zh) 基于arm指令虚拟化的elf文件保护方法及系统
US10891369B2 (en) Dynamic switching between pointer authentication regimes
US10127381B2 (en) Systems and methods for switching emulation of an executable file
Roundy et al. Binary-code obfuscations in prevalent packer tools
Checkoway et al. Return-oriented programming without returns
KR101213821B1 (ko) 동적 변환을 통한 프로액티브 컴퓨터 말웨어 보호
US8090959B2 (en) Method and apparatus for protecting .net programs
US20170161493A1 (en) Executing Native-Code Applications in a Browser
WO2016078130A1 (zh) 一种防逆向apk文件的动态加载方法
KR101806090B1 (ko) 멀웨어 검출을 위한 애플리케이션들의 제네릭 언패킹
CN105608391A (zh) 多elf文件保护方法及系统
CN103413074B (zh) 一种通过api实现软件保护的方法和装置
Padaryan et al. Automated exploit generation for stack buffer overflow vulnerabilities
Otsuki et al. Building stack traces from memory dump of Windows x64
EP2988242A1 (en) Information processing device, and information processing method
Wang et al. Binary code retrofitting and hardening using SGX
US20190102279A1 (en) Generating an instrumented software package and executing an instance thereof
CN110597496B (zh) 应用程序的字节码文件获取方法及装置
WO2016126206A1 (en) Method for obfuscation of code using return oriented programming
Hebbal Semantic monitoring mechanisms dedicated to security monitoring in IaaS cloud
WO2022044021A1 (en) Exploit prevention based on generation of random chaotic execution context
Langerud et al. PowerScan: A Framework for Dynamic Analysis and Anti-Virus Based Identification of Malware
Zhang et al. Cover: Enhancing Virtualization Obfuscation Through Dynamic Scheduling Using Flash Controller-Based Secure Module
Shonia et al. ANALYSIS OF WINDOWS PORTABLE EXECUTABLE SOFTWARE PROTECTION SYSTEMS
Wets et al. " Building a malware mutation tool

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16877517

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16877517

Country of ref document: EP

Kind code of ref document: A1