A binary-based iOS application encryption and hardening system
By using encryption and hardening mechanisms to protect iOS applications, the limitations of existing binary IPA hardening schemes are overcome. This enables deep obfuscation of critical functions and defense against dynamic debugging, thereby improving the security of iOS applications.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- NANJING BIG DATA GRP CO LTD
- Filing Date
- 2026-04-01
- Publication Date
- 2026-07-21
AI Technical Summary
Existing binary IPA hardening solutions have limitations in preventing reverse engineering and dynamic debugging, making it difficult to protect critical functions, and they are unusable after Xcode 15 removed the bitcode feature.
An encryption and hardening mechanism is adopted. By prioritizing the execution of hardened code, dynamically obfuscating key functions and coordinating module interactions, including program code insertion, code obfuscation, dynamic library calls and dependency management, obfuscated code and jump tables are generated to prevent reverse analysis and parameter type parsing, thereby achieving anti-debugging and anti-repackaging.
It improves the security of iOS applications, prevents reverse engineering and dynamic debugging, reduces integration costs, and effectively protects critical functions.
Smart Images
Figure CN121980565B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of mobile application security technology, specifically to a binary-based iOS application encryption and hardening system. Background Technology
[0002] In mobile security, client-side code security is crucial because mobile applications typically run on client devices and handle sensitive user data. By hardening applications, reverse engineering and malicious attacks can be effectively resisted, protecting the application's confidential information and intellectual property. Hardening provides a robust security layer for applications through code obfuscation, encryption protection, and anti-debugging techniques, increasing the difficulty for attackers to crack and modify the application.
[0003] Currently, the mainstream hardening solutions are divided into three types: source code hardening, IPA hardening with bitCode, and binary IPA hardening. Although the existing binary IPA hardening solutions have a low integration cost, they still have certain limitations in preventing reverse analysis. They only support simple code obfuscation, are not strong enough in protecting critical functions, and are difficult to defend against attacks such as dynamic debugging and repackaging. Hardening solutions that rely on bitCode have been removed in Xcode 15, so this feature is no longer available. Summary of the Invention
[0004] Purpose of the invention: The purpose of this invention is to provide a binary-based iOS application encryption and hardening system that solves the problems of only supporting simple code obfuscation, insufficient protection for critical functions, difficulty in defending against attacks such as dynamic debugging and repackaging, and the inability to use the bitcode-based hardening solution due to its removal in Xcode 15.
[0005] Technical Solution: The present invention discloses a binary-based iOS application encryption and hardening system. This system employs an encryption and hardening mechanism to protect iOS applications. This mechanism prioritizes the execution of hardened code, dynamically obfuscates key functions, and interacts with collaborative modules. It features program code insertion, code obfuscation, dynamic library calls, and dependency management. Specifically, program code insertion inserts hardened code into the target application's binary file and executes it before the original target application code. Code obfuscation dynamically obfuscates the target application's functions, generating obfuscated code and jump tables to prevent reverse engineering and parameter type parsing. Dynamic library calls load and invoke dynamic library modules to achieve security protection functions, including anti-debugging, anti-repackaging, and data encryption. Dependency management repairs the target application's instruction offsets, data offsets, and Mach-O file format.
[0006] The system includes the following modules: a shell module, which is inserted into the target program and executed before the original program code, including an initialization module and a module for dynamically generating obfuscated code; a dynamic library module, which implements security protection functions and assists the shell module; and a hardening tool module, which generates obfuscated code, shell code, and shell data, inserts the shell code and shell data into the target program, modifies the program entry point, and merges the shell module and the dynamic library module into the target program. The shell module, dynamic library module, and hardening tool module work together through data sharing and function calls: the shell module calls the initialization function of the dynamic library module, the dynamic library module reads the function switches and data in the shell module, and the hardening tool module uses the encryption interface provided by the dynamic library module when generating obfuscated code.
[0007] The shell module execution flow is as follows: First, the dynamic library module is loaded, the initialization function is called, and then the dynamically generated obfuscated code is executed; finally, control is returned to the original program entry point. The shell's runtime includes two processes: startup and execution of the obfuscated code; the specific process is as follows:
[0008] The entry point for the shell startup process is at the entry point of the hardened program. Generally, the shell's function is to load and decrypt the program. After completion, the shell basically does not interfere with the program's operation. However, the special nature of the iOS system is that it does not allow applications to decrypt and dynamically load programs. Therefore, hardening can only be used to obfuscate the code. However, for security reasons, data is usually hardened. After obfuscation, it must be launched first from the shell. Only after initialization is completed can the code logic run normally. The key to running the hardened program is to execute the initialization function in the shell first, such as fixing the obfuscated jump table and customizing the address information in the data, so that the subsequent process can run normally. There are two basic principles in the program loading and execution process that allow the hardening to insert or replace the execution entry function through formatting.
[0009] This includes: the init function of dependent libraries executes earlier than the program itself; by default, Objective-C init executes before init, and init executes before the main function; the startup process is as follows:
[0010] S1. If a dynamic library is introduced for reinforcement, the dynamic library will be loaded first.
[0011] S2. If the dynamic library is loaded, obtain the address of the initialization function from the agreed shell structure and call the initialization logic;
[0012] S3. If the dynamic library does not trigger the initialization logic, initialize it directly from the shell;
[0013] S4. After the shell finishes its work, it calls the original entry point of the target program and resumes the original logic execution of the program.
[0014] The obfuscated code is executed as follows: after entering the function, it jumps directly to the obfuscated code block for execution; after each code block is executed, it reads the target address of the next code block from the jump table and jumps to execute the next instruction; until the function call flow ends; this obfuscation scheme solves the drawback of only being able to use source code or bitcode obfuscation, and can strengthen binary code and protect critical functions.
[0015] The dynamic library module includes: an anti-debugging detection unit and a shell module interaction interface unit; the anti-debugging detection unit is used to implement anti-debugging and prevent repackaging; the shell module interaction interface unit is used to identify and call the initialization functions in the shell; and to identify and read the function switches and data in the shell.
[0016] The hardening tool module includes: a code obfuscation unit, used to obfuscate or dynamically generate shell code and shell data according to the hardening strategy; an insertion unit, used to insert shell code and shell data into the code and data segments of the target program; an entry point modification unit, used to modify the program's entry point to the shell entry function; an addition unit, used to add dependencies on dynamic libraries in the target program; and a dependency management unit, used to repair the target program's instructions, data offsets, and Mach-O file format. The code obfuscation unit performs the following operations:
[0017] (a) Analyze the symbol table, read the configuration, and collect statistics on the addresses and ranges of the functions that need to be obfuscated;
[0018] (b) Preprocess the obfuscated functions and calculate the size of the obfuscated code and data required after obfuscation;
[0019] (c) Decompile the obfuscated function, analyze the function's assembly instructions, semantics, and control flow information, and process the function into blocks;
[0020] (d) Based on the analysis results, the function is obfuscated, and the obfuscated code is dynamically written into the pre-allocated obfuscated code. The jump address is pre-calculated as a virtual address and recorded in the data to form a jump table. After loading, it needs to be repaired according to the real address. The jump table is used to dynamically schedule the execution of code blocks at runtime.
[0021] (e) Merge the shell initialization logic, dynamically generated obfuscated code, and data, and record the region information of the code and data.
[0022] The specific insertion unit operation is as follows: Generally, to ensure the integrity of the source program and that the relative offset is not modified, the code is inserted before the original program code segment, and the shell data is inserted after the original program data segment. It is not mandatory to add it to a specific field. You can refer to the following positions for inserting data: Shell code: Insert before the original code segment; Shell data: Insert at the end of the string; The data segment only reserves space to copy the shell data. This merging method will not introduce a new loading segment and avoids the problem of abnormal upload caused by inserting multiple segments.
[0023] The entry point modification unit operation is as follows: Because the shell code needs to execute before the target program's code in order to perform address correction and execute some protection functions, the target program's entry point must be modified to point to the shell's entry point. For executable programs, this means changing LC_MAIN (the address of the main function) to the shell's main function address. For dynamic libraries, this means changing the address of the first function in the init function list (__init_offsets or __mod_init_func) to the shell's init function address. The original main or init function address must be stored in a custom structure on the shell so that control can be returned when the shell finishes execution.
[0024] Adding a unit involves performing the following operations: The dynamic library is responsible for business functions such as anti-debugging. If these functions are enabled, the dynamic library must be added to the target program's dependency library list so that the target program will load the dynamic library at runtime. In addition, the shell itself also has some dependency libraries, which must also be added to the target program's dependency library list. First, add the LC_LOAD_DYLIB loading command and set the library name. Then, add the LC_RPATH loading command to specify the search path for the dynamic library.
[0025] The dependency management unit includes code repair and file format repair; because the insertion of code and data has affected the original instructions, or some expected address or offset information; the scope of code repair includes the following two sections:
[0026] __TEXT (code segment): PC-related instructions in the original code need to be fixed;
[0027] __DATA (data segment): Records some PC addresses that need to be relocated and need to be repaired.
[0028] Formatting repair includes the following sections and structures:
[0029] __LINKEDIT (Dynamic Link Information Segment): All information regarding data location or size needs to be corrected. The COMMAND field in the file header, including any affected offsets and sizes, also needs correction. This information is preserved in the file format and will be read by the system during loading, so it must be corrected strictly according to the format requirements and its original meaning; otherwise, formatting errors will occur.
[0030] The program self-verification module includes: a feature extraction unit, which interacts with the hardening tool module to read the target program's code segments and function instructions during the hardening process, calculate the verification range, generate a verification value, and save it to the shell module; and a verification execution unit, located in the dynamic library module, which interacts with the shell module to verify the verification value saved in the shell module during program runtime. If the verification fails, a security response is triggered. The verification value is a CRC checksum or a hash value.
[0031] Beneficial effects: Compared with the prior art, the present invention has the following significant advantages: The present invention directly strengthens the IPA packet, reducing access costs; The present invention uses a unique obfuscation processing technology to deeply obfuscate the real code, which not only prevents attackers from analyzing the function body, but also prevents them from parsing the parameter types normally, thereby improving App security and effectively preventing reverse analysis and defending against dynamic debugging. Attached Figure Description
[0032] Figure 1 This is an overall flowchart of the present invention;
[0033] Figure 2 This is a flowchart of the shell module operation of the present invention;
[0034] Figure 3 This is a flowchart of the instruction extraction process of the present invention;
[0035] Figure 4 This is the insertion unit of the present invention;
[0036] Figure 5 This is the function protection of the present invention, the normal function code before reinforcement;
[0037] Figure 6 This invention is reinforced and then jumps to another location to execute. Detailed Implementation
[0038] The technical solution of the present invention will be further described below with reference to the accompanying drawings.
[0039] like Figure 1As shown, this embodiment of the invention provides a binary-based iOS application encryption and hardening system. It employs an encryption and hardening mechanism to protect iOS applications. This mechanism provides protection for the App by prioritizing the execution of hardening code, dynamically obfuscating key functions, and interacting with collaborative modules. It features program code insertion, code obfuscation, dynamic library calls, dependency management, and program self-verification. Specifically, program code insertion inserts the hardening code into the target program's binary file and executes it before the original target program code; code obfuscation dynamically obfuscates the target program's functions, generating obfuscated code and jump tables to prevent reverse engineering and parameter type parsing; dynamic library calls load and invoke dynamic library modules to implement security protection functions, including anti-debugging, anti-repackaging, and data encryption; dependency management repairs the target program's instruction offsets, data offsets, and Mach-O file format; and program self-verification extracts key content features of the target program during the hardening process and performs verification at runtime.
[0040] Among them, such as Figure 2 As shown, the shell module execution flow is as follows: First, the dynamic library module is loaded first, the initialization function is called, and then the dynamically generated obfuscated code is executed; finally, control is returned to the original program entry point; the shell's runtime includes two processes: startup and execution of obfuscated code; the specific process is as follows:
[0041] The entry point for the shell's startup process is at the entry point of the hardened program. A typical shell's function is to load and decrypt the program; after completion, it generally doesn't interfere with the program's execution. However, the special nature of the iOS system prevents applications from decrypting and dynamically loading programs. Therefore, hardening is necessary to obfuscate the code. For security reasons, data is usually hardened. After obfuscation, the program must be launched first from within the shell. Only after initialization is complete can the code logic run normally. The key to running the hardened program is to prioritize the execution of the shell's initialization functions, such as fixing obfuscated jump tables and customizing addresses in the data, ensuring the subsequent processes run correctly. The program loading and execution process follows two fundamental principles that allow the hardening to insert or replace the execution entry function through formatting.
[0042] This includes: the init function of dependent libraries executes earlier than the program itself; by default, Objective-C init executes before init, and init executes before the main function. The startup process is as follows:
[0043] S1. If a dynamic library is introduced for reinforcement, the dynamic library will be loaded first.
[0044] S2. If the dynamic library is loaded, obtain the address of the initialization function from the agreed shell structure and call the initialization logic;
[0045] If the dynamic library does not trigger the initialization logic, S3 will directly initialize from the shell;
[0046] S4. After the shell finishes its work, it calls the original entry point of the target program and resumes the original logic execution of the program.
[0047] like Figure 3 As shown, the obfuscated code is executed as follows: upon entering the function, execution jumps directly to the obfuscated code block; after each code block is executed, the address of the next code block is read from the table, and execution jumps to the next instruction; this continues until the function call flow ends. This obfuscation scheme overcomes the drawback of only being able to use source code or bitcode obfuscation, enabling both binary hardening and protection of critical functions.
[0048] The dynamic library module includes: an anti-debugging detection unit and a shell module interaction interface unit; the anti-debugging detection unit is used to implement anti-debugging and prevent repackaging; the shell module interaction interface unit is used to identify and call the initialization functions in the shell; and to identify and read the function switches and data in the shell.
[0049] The hardening tool module includes: a code obfuscation unit, used to obfuscate or dynamically generate shell code and shell data according to the hardening function; an insertion unit, used to insert shell code and shell data into the code and data segments of the target program; an entry point modification unit, used to modify the program's entry point to the shell entry function; an addition unit, used to add dependencies on dynamic libraries in the target program; and a dependency management unit, used to repair the target program's instructions, data offsets, and Mach-o file format. The code obfuscation unit performs the following operations:
[0050] (a) Analyze the symbol table, read the configuration, and collect statistics on the addresses and ranges of the functions that need to be obfuscated;
[0051] (b) Preprocess the obfuscated functions and calculate the size of the obfuscated code and data required after obfuscation;
[0052] (c) Decompile the obfuscated function, analyze the function's assembly instructions, semantics, and control flow information, and process the function into blocks;
[0053] (d) Based on the analysis results, the function is obfuscated and the obfuscated code is dynamically written into the pre-allocated obfuscated code. The jump address is pre-calculated as a virtual address, recorded in the data, and a jump table is formed. After loading, it needs to be repaired according to the real address.
[0054] (e) The shell initialization logic, dynamically generated obfuscated code, and data are merged, and the region information of the code and data is recorded. The final dynamically generated shell content is shown in Table 1.
[0055] Table 1 Dynamically generated shell content
[0056] ;
[0057] like Figure 4 As shown, the specific insertion unit operation is as follows: Generally, to ensure the integrity of the source program and prevent changes to the relative offset, the code is inserted before the original program code segment, and the shell data is inserted after the original program data segment. It is not mandatory to add data to a specific field; the following positions can be used as a reference for data insertion: Shell code: Inserted before the original code segment. Shell data: Inserted at the end of the string. The data segment only reserves space to copy the shell data. This merging method will not introduce new loading segments, avoiding the possibility of multiple segments causing upload anomalies.
[0058] The entry point modification operation is as follows: Because the shell code needs to execute before the target program's code to perform address correction and execute some protection functions, the target program's entry point must be modified to point to the shell's entry point. For executable programs, this means changing LC_MAIN (the address of the main function) to the shell's main function address. For dynamic libraries, this means changing the address of the first function in the init function list (__init_offsets or __mod_init_func) to the shell's init function address. The original main or init function address must be stored in a custom structure on the shell so that control can be returned when the shell finishes execution.
[0059] Adding a unit involves the following operations: Dynamic libraries are responsible for business functions such as anti-debugging. If these functions are enabled, the dynamic libraries must be added to the target program's dependency library list so that the target program will load the dynamic libraries at runtime. Additionally, the shell itself also has some dependency libraries, which must also be added to the target program's dependency library list. First, add the LC_LOAD_DYLIB loading command and set the library name correctly. Then, add the LC_RPATH loading command to specify the search path for the dynamic libraries.
[0060] The dependency management unit includes code repair and file format repair; because the insertion of code and data has affected the original instructions, or some expected address or offset information. The scope of code repair includes the following two sections:
[0061] __TEXT (code segment): PC-related instructions in the original code need to be fixed;
[0062] __DATA (data segment): Records some PC addresses that need to be relocated and need to be repaired.
[0063] Formatting repair includes the following sections and structures:
[0064] __LINKEDIT (Dynamic Link Information Segment): All information regarding data location or size needs to be corrected. The COMMAND field in the file header, including any affected offsets and sizes, also needs correction. This information is stored in the file format and will be read by the system during loading; therefore, it must be corrected strictly according to the format requirements and its original meaning, otherwise formatting errors will occur.
[0065] The program self-verification module includes: a feature extraction unit, used to read the target program's code segments and function instructions during the hardening process, calculate the verification range, generate a verification value, and save it to the shell; and a verification execution unit, located in the dynamic library module, used to verify the verification value saved in the shell during program runtime. If the verification fails, a security response is triggered. The verification value is a CRC checksum or a hash value. Figure 5 The image shows the normal function code before the function protection and hardening process described in this invention. Figure 6 As shown, this invention, after being reinforced, jumps to another location for execution.
Claims
1. A binary-based iOS application encryption and hardening system, characterized in that, The system comprises the following modules: a shell module, a dynamic library module, and a hardening tool module. The shell module is inserted into the target program and executed before the original program code, including an initialization module and a module for dynamically generating obfuscated code. The dynamic library module implements security protection functions and assists the shell module. The hardening tool module generates obfuscated code, shell code, and shell data, inserts the shell code and shell data into the target program's binary file, modifies the program's entry point, and merges the shell module and dynamic library module into the target program. The shell module, dynamic library module, and hardening tool module collaborate through data sharing and function calls: the shell module calls the initialization function of the dynamic library module, and the dynamic library module reads the shell code... The functional switches and data in the block are encrypted using the encryption interface provided by the dynamic library module when generating obfuscated code. The obfuscated tool module includes: a code obfuscation unit, used to obfuscate or dynamically generate shell code and shell data according to the obfuscation strategy; an insertion unit, used to insert shell code and shell data into the code segment and data segment of the target program; an entry point modification unit, used to modify the program entry point to the shell entry function; an addition unit, used to add dependencies on the dynamic library in the target program; and a dependency management unit, used to repair the instructions, data offsets, and Mach-O file format of the target program. Among them, the code obfuscation unit analyzes the symbol table and configuration information of the target program to determine the functions and address ranges that need to be obfuscated. The function to be obfuscated is subjected to control flow analysis, divided into several code blocks, and obfuscated code blocks and corresponding jump tables are generated. The shell initialization logic is merged with the generated obfuscated code and data to form a complete hardened code segment, and the region information of the code and data is recorded. The obfuscated code generated by the code obfuscation unit is inserted into the target program through the insertion unit, and the entry modification unit ensures that the shell entry function is executed first.
2. The binary-based iOS application encryption and hardening system according to claim 1, characterized in that, The initialization module is used to prioritize loading dynamic library modules and call their initialization functions; the dynamic obfuscation code generation module is used to execute dynamically generated obfuscated code; the obfuscated code is based on control flow analysis and block processing function instructions, and dynamically jumps to code blocks through jump tables at runtime; control is returned to the original entry point of the target program.
3. The binary-based iOS application encryption and hardening system according to claim 1, characterized in that, The dynamic library module includes: an anti-debugging detection unit, used to implement anti-debugging and anti-repackaging; and a shell module interaction interface unit, used to identify and call the initialization functions in the shell, and read the function switches and data in the shell.
4. The binary-based iOS application encryption and hardening system according to claim 1, characterized in that, The generated shell data structure includes: instructions and data; where instructions include: shell code and obfuscation instructions; data includes: shell code associated data, obfuscation code jump table, and other hardening or configuration data; the specific insertion unit operation is as follows: insert shell code before the target code segment; insert shell data at the end of the string; only reserve space in the data segment to copy shell data; the specific entry modification unit operation is as follows: change the address of the main function in the target code to the address of the shell's main function; for dynamic libraries, change the address of the first function in the init function list to the address of the shell's init function; the address of the main function or init function in the target code should be stored in a custom structure on the shell.
5. The binary-based iOS application encryption and hardening system according to claim 1, characterized in that, To add a unit, perform the following operations: First, add the LC_LOAD_DYLIB loading command and set the library name. Then, add the LC_RPATH loading command to specify the search path for the dynamic library.
6. The binary-based iOS application encryption and hardening system according to claim 4, characterized in that, The dependency management unit includes code repair and file format repair; the scope of code repair includes the following two sections: __TEXT code segment: Repairs PC-related instructions in the target code; __DATA segment: Repairs the recorded PC addresses that need to be relocated; File format repair includes: __LINKEDIT dynamic link information segment: repairs all information related to the location or size of data; The COMMAND field in the file header: will fix the affected offsets and sizes.
7. The binary-based iOS application encryption and hardening system according to claim 1, characterized in that, It also includes a program self-verification module, which interacts with the hardening module and the shell module respectively, to extract key content features of the target program during the hardening process and to verify them at runtime; The program self-verification module includes: a feature extraction unit, which interacts with the hardening tool module to read the code segment and function instructions of the target program during the hardening process, calculate the verification range and generate a verification value, and save it to the shell module; and a verification execution unit, which interacts with the shell module to verify the verification value saved in the shell module during program execution. If the verification fails, a security response is triggered. The verification value is either a CRC checksum or a hash value.