Methods for protecting SO files from memory dumping in Android system

Abstract

This invention provides a method for protecting So files from memory dumping in the Android system. The method includes: adjusting the memory mapping behavior of the `mmap` function in the Linker to prevent reporting So file memory mapping information to the maps file; calling a custom function to modify the file header characteristics of the So file and erasing the header characteristics; and hiding the So file record in the shared object list `solist`, thereby protecting the So file. This method effectively prevents So files from being illegally dumped in memory in the Android system, protecting the operational security of applications. Furthermore, because the implementation considers a balance between security and performance, this solution is applicable to various commercial and personal Android devices.

Description

Technical Field

[0001] This invention belongs to the field of computer security technology, specifically a method for protecting SO files from memory dumping under the Android system. Background Technology

[0002] In today's digital age, Android has become one of the most widely used mobile operating systems globally. With the proliferation of various Android-based applications, security issues have become increasingly prominent, especially the security of application data. Shared Object files (SO files), as common binary library files in Android applications, often contain sensitive business logic and data processing functions, making them a primary target for attackers.

[0003] Currently, the main method to prevent SO files from being memory dumped involves encrypting the SO file itself. This method typically involves storing the SO file in encrypted form on the device's disk and decrypting it at runtime before loading it into memory. However, this method has significant limitations:

[0004] 1. Encryption and performance trade-off: While encryption can prevent So files from being read directly on the disk, they must be decrypted at runtime, which can lead to significant performance overhead, especially on resource-constrained devices.

[0005] 2. Runtime Data Exposure: Although the SO file is encrypted on disk, it must exist in plaintext in memory for the application to function correctly. This means that the SO file in memory is still exposed to malicious programs or memory dumping tools with appropriate permissions at runtime.

[0006] 3. Lack of dynamic protection mechanisms: Existing technologies often overlook the importance of runtime protection. Once a So file is loaded into memory, its protection typically relies on the operating system's general memory protection mechanisms, which are insufficient to prevent advanced persistent threats (APTs) or malware with root privileges.

[0007] Therefore, the main problem with existing technologies is that their protection measures mostly remain at the static security level, lacking a comprehensive protection strategy for dynamic operating environments. Thus, even with encryption measures, the So file may still be dumped into memory at runtime, thereby leaking sensitive logic and data contained within. Furthermore, existing methods typically fail to address the integrity and confidentiality issues of data protection in memory, failing to form a comprehensive security protection system.

[0008] To effectively solve the above problems, there is an urgent need for a more efficient and secure technical solution that can prevent So files from being dumped in memory at runtime. Summary of the Invention

[0009] To address the shortcomings of existing technologies, this invention provides a method for protecting SO files from memory dumping under the Android system, which can effectively solve the above problems.

[0010] The technical solution adopted in this invention is as follows:

[0011] This invention provides a method for protecting SO files from memory dumping under the Android system, comprising the following steps:

[0012] Step S1: In the Android system, modify the application's startup script by introducing a custom library file and a custom code segment into the application's startup script. The custom library file is an inline hook, and the inline hook establishes a redirection relationship between the mmap function in the Linker of the application's startup script and the custom code segment.

[0013] Step S2: When the application starts, the modified application startup script is executed as follows: First, the dynamic linker (Linker) is initialized. Then, the Linker dynamically links the required SO files of the application when the application starts. Then, when the mmap function in the Linker is executed, the custom code segment is executed through the inline hook. Through the custom code segment, the memory mapping behavior of the SO file in the mmap function of the Linker is adjusted so that the SO file memory mapping information is not reported to the maps file, thereby hiding the SO file memory mapping information.

[0014] Step S3: After the dynamic linker loads the dynamically linked So file into memory, it calls a custom function to modify the file header feature information of the So file and erase the file header feature information.

[0015] Step S4: Hide the record of the So file in the shared object list solist, thereby completing the protection of the So file.

[0016] Preferred options also include:

[0017] The initialization of the dynamic linker (Linker) is monitored. When the Linker detects that the application needs to link a So file, it determines whether the linked So file is a protected So file. If it is, the inline hook operation and steps S3 and S4 are executed. If not, the normal execution logic is executed.

[0018] Preferably, the maps file is located under the proc / [pid] path and is used to store memory address mapping and allocation relationships.

[0019] Preferably, a custom function is called to modify the header feature information of the SO file, thereby removing the header feature information. Specifically:

[0020] The custom function locates the file header of the So file in memory, and then replaces or deletes the identifier of the file header characteristics.

[0021] Preferably, step S4 specifically includes:

[0022] The code segment executed by the dynamic linker is modified directly in memory to change how it handles the shared object list solist, thus hiding the records of the solist files.

[0023] The method for protecting SO files from memory dumping under the Android system provided by this invention has the following advantages:

[0024] The method for protecting .so files from memory dumping under the Android system provided by this invention can effectively prevent .so files from being illegally dumped in memory under the Android system, thus protecting the operational security of applications. Furthermore, because a balance between security and performance is considered during implementation, this solution is applicable to various commercial and personal Android devices. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating the method for protecting SO files from memory dumping under the Android system provided by the present invention. Detailed Implementation

[0026] To make the technical problems solved, the technical solutions, and the beneficial effects of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the invention.

[0027] This invention provides a method for protecting So files from memory dumping under the Android system. This method adopts the following three core technological innovations to achieve more comprehensive and dynamic memory protection for So files, including: changing the linker's function jump through inline Hook to achieve map hiding, erasing So file header features, and hiding itself in the So list (solist).

[0028] See Figure 1 This invention provides a method for protecting SO files from memory dumping under the Android system, comprising the following steps:

[0029] Step S1: In the Android system, modify the application's startup script by introducing a custom library file and a custom code segment into the application's startup script. The custom library file is an inline hook, and the inline hook establishes a redirection relationship between the mmap function in the Linker of the application's startup script and the custom code segment.

[0030] Step S2: When the application starts, the modified application startup script is executed as follows: First, the dynamic linker (Linker) is initialized. Then, the Linker dynamically links the required SO files of the application when the application starts. Then, when the mmap function in the Linker is executed, the custom code segment is executed through the inline hook. Through the custom code segment, the memory mapping behavior of the SO file in the mmap function of the Linker is adjusted so that the SO file memory mapping information is not reported to the maps file, thereby hiding the SO file memory mapping information. The maps file is located under the proc / [pid] path and is used to store the memory address mapping allocation relationship.

[0031] In this step, to improve the flexibility of the method, the following configuration can also be performed: listen to the initialized dynamic linker (Linker), and when the Linker detects that the application needs to link an SO file, determine whether the linked SO file is a protected SO file; if so, execute the inline hook operation and steps S3 and S4; if not, jump to execute the normal execution logic.

[0032] Step S3: After the dynamic linker loads the dynamically linked So file into memory, it calls a custom function to modify the file header feature information of the So file and erase the file header feature information.

[0033] In this step, a custom function is called to modify the file header feature information of the So file and erase the file header feature information. Specifically, the custom function locates the file header of the So file in memory and then replaces or deletes the identifier of the file header feature.

[0034] Step S4: Hide the record of the So file in the shared object list solist, thereby completing the protection of the So file.

[0035] Step S4 is as follows:

[0036] The code segment executed by the dynamic linker is modified directly in memory to change how it handles the shared object list solist, thus hiding the records of the solist files.

[0037] The method for protecting .so files from memory dumping under the Android system provided by this invention can effectively prevent .so files from being illegally dumped in memory under the Android system, thus protecting the operational security of applications. Furthermore, because a balance between security and performance is considered during implementation, this solution is applicable to various commercial and personal Android devices.

[0038] The following is an example:

[0039] Implementation Environment

[0040] Operating System: Android 11

[0041] Processor: ARM64 architecture

[0042] *Target application: Sample application (AppExample)

[0043] 1. Inline Hook settings:

[0044] *During system startup, a custom library file is imported by modifying the Android startup script. This library contains code for setting up inline hooks.

[0045] * Use inline hooking technology to modify the dynamic linker's mmap function so that it does not report mapped SO files to the / proc / [pid] / maps file when performing memory mapping. This way, even if the SO file is loaded into memory, its location and attributes will not be displayed.

[0046] Specifically, this step achieves map hiding by modifying the linker's function jumps through inline hooking. This invention employs inline hooking technology to precisely modify the function jump instructions of the Android system's dynamic linker. This technology adjusts the linker's memory mapping behavior in real time during the loading of the SO file, effectively hiding memory mapping information and preventing it from being detected by external programs through system APIs (such as / proc / [pid] / maps). This improvement not only enhances security but also ensures the smoothness and efficiency of system operation by optimizing the hooking process.

[0047] 2. Removal of file header features:

[0048] * Immediately after the SO file is loaded into memory, a custom function is called to modify the characteristic information in the SO file header. This function locates the SO file header in memory and replaces or deletes identifiers (such as magic number, version number, etc.), thereby avoiding memory scans based on these characteristics.

[0049] Specifically, after the So file is loaded into memory, the present invention dynamically erases or modifies the characteristic information (such as magic number, version information, and other identifiers) in the header of the So file, thereby preventing memory scanning and identification based on file header characteristics and effectively preventing malware from locating and dumping the So file through standard feature recognition technology.

[0050] 3. Hide the So list:

[0051] *The existence of the .so file is hidden by modifying the machine code of the running dynamic linker in memory. This method does not modify the linker's source code or its static files, but directly modifies the code segment executed by the linker in memory to change how it handles the list of shared objects (solist).

[0052] Specifically, this invention further enhances security by hiding records of SO files in the system's shared object list (solist). By modifying the system's shared object management mechanism, even if an application's SO file is loaded and executed in memory, its existence will not be detected by the system's standard list and query operations, and its entry will not be displayed in the system-maintained solist. Through this technique, even if a user or program with high privileges attempts to query or traverse the solist, it will be unable to discover the protected SO file.

[0053] By applying the above technologies, this invention effectively improves the confidentiality and security of SO files in the Android system, providing robust and reliable security protection for applications. This method is not only suitable for preventing conventional memory dump attacks, but also effectively resists advanced persistent threats and insider threat models, protecting the core logic and sensitive data of applications from leakage.

[0054] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for protecting SO files from memory dumping under the Android system, characterized in that, Includes the following steps: Step S1: In the Android system, modify the application's startup script by introducing a custom library file and a custom code segment into the application's startup script. The custom library file is an inline hook, which establishes a redirection relationship between the mmap function in the Linker of the application's startup script and the custom code segment. Step S2: When the application starts, the modified application startup script is executed as follows: First, the dynamic linker (Linker) is initialized. Then, the Linker dynamically links the required SO files of the application when the application starts. Then, when the mmap function in the Linker is executed, the custom code segment is executed through the inline hook. Through the custom code segment, the memory mapping behavior of the SO file in the mmap function of the Linker is adjusted so that the SO file memory mapping information is not reported to the maps file, thereby hiding the SO file memory mapping information. Step S3: After the dynamic linker loads the dynamically linked So file into memory, it calls a custom function to modify the file header feature information of the So file and erase the file header feature information. Step S4: Hide the record of the So file in the shared object list solist, thereby completing the protection of the So file.

2. The method for protecting SO files from memory dumping under the Android system according to claim 1, characterized in that, Also includes: The initialization of the dynamic linker (Linker) is monitored. When the Linker detects that the application needs to link a So file, it determines whether the linked So file is a protected So file. If it is, the inline hook operation and steps S3 and S4 are executed. If not, the normal execution logic is executed.

3. The method for protecting SO files from memory dumping under the Android system according to claim 1, characterized in that, The maps file, located under the proc / [pid] path, is used to store memory address mapping and allocation relationships.

4. The method for protecting SO files from memory dumping under the Android system according to claim 1, characterized in that, Call a custom function to modify the header signature information of the SO file, specifically by removing the header signature information: The custom function locates the file header of the So file in memory, and then replaces or deletes the identifier of the file header characteristics.

5. The method for protecting SO files from memory dumping under the Android system according to claim 1, characterized in that, Step S4 is as follows: The code segment executed by the dynamic linker is modified directly in memory to change how it handles the shared object list solist, thus hiding the records of the solist files.

Images