Dynamic library loading method and system, electronic device and storage medium

Abstract

The application provides a dynamic library loading method and system, an electronic device and a storage medium. The method comprises the following steps: obtaining a target encrypted file, and obtaining a preconfigured decryption key and an initialization vector from a secure storage area; reading the content of the target encrypted file to a memory to obtain encrypted data; performing decryption processing on the encrypted data according to the decryption key and the initialization vector to obtain decrypted data; in the case that the decrypted data passes integrity verification, creating a memory anonymous file and writing the decrypted data into the memory anonymous file; loading the memory anonymous file through a dynamic loading interface to obtain a dynamic library handle; obtaining the address of a target in an original dynamic library file according to the dynamic library handle, and calling the address of the target to execute corresponding functions, and uninstalling the original dynamic library file through the dynamic library handle and safely clearing the decrypted data in the memory.

Description

Technical Field

[0001] This application relates to the technical field of dynamic library loading methods, and more particularly to dynamic library loading methods, systems, electronic devices, and storage media. Background Technology

[0002] Shared libraries, a widely used code-sharing and modularization technology in modern software systems, encapsulate reusable functional modules into independent binary files, enabling multiple applications to dynamically load and share the same copy of the code at runtime. This mechanism not only significantly reduces system memory usage and avoids the repeated loading of identical code into memory, but also effectively improves software development efficiency and modularity. Furthermore, dynamic libraries offer more flexible version management and updates, supporting feature expansion or bug fixes without recompiling the main program, further enhancing software maintainability and scalability.

[0003] Dynamic libraries are generally stored in plaintext, making them vulnerable to decompilation, analysis, and tampering. This poses significant security risks, particularly in commercial software delivery and intellectual property protection. Summary of the Invention

[0004] This application provides a method, system, electronic device, and storage medium for loading dynamic libraries to solve the problems existing in related technologies. The technical solutions are as follows: Firstly, embodiments of this application provide a method for loading a dynamic library, including: The target encrypted file is obtained, along with a pre-configured decryption key and initialization vector from a secure storage area. The target encrypted file is a non-dynamic library format data file generated by encrypting the original dynamic library file. The contents of the target encrypted file are read into memory to obtain the encrypted data; The encrypted data is decrypted using the decryption key and initialization vector to obtain the decrypted data. Perform integrity verification on the decrypted data. If the decrypted data passes the integrity verification, create an anonymous memory file and write the decrypted data into the anonymous memory file. The dynamic library handle is obtained by loading an anonymous file in memory through the dynamic loading interface; Based on the dynamic library handle, obtain the address of the target in the original dynamic library file, execute the corresponding function call through the target address, and unload the original dynamic library file through the dynamic library handle.

[0005] Secondly, embodiments of this application provide a method system for loading dynamic libraries, including: The first acquisition module is used to acquire the target encrypted file and to acquire the pre-configured decryption key and initialization vector from the secure storage area. The target encrypted file is a data file in non-dynamic library format generated by encrypting the original dynamic library file. The first module is used to read the contents of the target encrypted file into memory to obtain the encrypted data. The second module is used to decrypt the encrypted data based on the decryption key and the initialization vector to obtain the decrypted data. The first verification module is used to perform integrity verification on the decrypted data. If the decrypted data passes the integrity verification, an anonymous memory file is created and the decrypted data is written into the anonymous memory file. The third module is used to load anonymous files in memory through the dynamic loading interface and obtain dynamic library handles; The second acquisition module is used to obtain the address of the target in the original dynamic library file based on the dynamic library handle, execute the corresponding function call through the address of the target, and unload the original dynamic library file through the dynamic library handle.

[0006] Thirdly, embodiments of this application provide an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to execute the aforementioned dynamic library loading method.

[0007] Fourthly, embodiments of this application provide a computer-readable storage medium that stores computer instructions, wherein when the computer instructions are executed on a computer, the methods in any of the above-described embodiments are performed.

[0008] The advantages or beneficial effects of the above technical solutions include at least the following: In this embodiment, the dynamic library loading method acquires a non-dynamic library format data file, ensuring that the target encrypted file lacks the format characteristics of a dynamic library (such as executable and linkable headers) during storage and transmission. This prevents conventional dynamic library analysis and decompilation tools from recognizing the file as a dynamic library, and thus makes it impossible to decompile or reverse engineer it, thereby hiding the dynamic library file type. Obtaining the target address based on the dynamic library handle and executing the function call maintains a usage pattern completely consistent with conventional dynamic library calls. The application can use the encrypted dynamic library without modifying its calling logic, ensuring compatibility. After the function call is completed, the dynamic library is unloaded and the decrypted data is securely cleared, ensuring that the plaintext form of the dynamic library is completely eliminated from memory after use, leaving no disk or memory residue, achieving a "traceless" effect. Furthermore, it achieves full lifecycle security protection for the dynamic library: unrecognizable during storage, uninterceptable during transmission, not written to disk during loading, and leaving no residue after use, effectively preventing the leakage of dynamic library content and enhancing software security and anti-reverse engineering capabilities.

[0009] The above overview is for illustrative purposes only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features of this application will become readily apparent from the accompanying drawings and the following detailed description. Attached Figure Description

[0010] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments disclosed in this application and should not be construed as limiting the scope of this application.

[0011] Figure 1 This is a flowchart of a dynamic library loading method according to an embodiment of this application.

[0012] Figure 2 This is a block diagram of an electronic device according to an embodiment of the present application. Detailed Implementation

[0013] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the spirit or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0014] Figure 1 A flowchart illustrating a method for loading a dynamic library according to an embodiment of this application is shown. Figures 1-2As shown, the dynamic library loading method can include: S110: Obtain the target encrypted file and obtain the pre-configured decryption key and initialization vector from the secure storage area. The target encrypted file is a data file in non-dynamic library format generated by encrypting the original dynamic library file. S120: Read the contents of the target encrypted file into memory to obtain the encrypted data; S130: Decrypt the encrypted data according to the decryption key and initialization vector to obtain the decrypted data; S140: Perform integrity verification on the decrypted data. If the decrypted data passes the integrity verification, create an anonymous memory file and write the decrypted data into the anonymous memory file. S150: Load the anonymous file in memory through the dynamic loading interface to obtain the dynamic library handle; S160: Based on the dynamic library handle, obtain the address of the target in the original dynamic library file, call the address of the target to execute the corresponding function, and unload the original dynamic library file through the dynamic library handle and securely clear the decrypted data in memory.

[0015] In this embodiment, the dynamic library loading method obtains a data file in a non-dynamic library format, so that the target encrypted file does not have the format characteristics of a dynamic library (such as the characteristic header of an executable and linkable format) during storage and transmission. This makes it impossible for conventional dynamic library analysis tools and decompilation tools to recognize the file as a dynamic library file, and they are also unable to decompile or reverse analyze it, thereby achieving the hiding of the dynamic library file type.

[0016] Encrypted data is read into memory and decrypted within memory. The entire decryption process is executed in memory, without generating any intermediate files on disk. Because the decryption key and initialization vector are obtained from a secure storage area, key security is ensured. The decryption operation is completed in memory, avoiding the risk of interception by writing the decrypted plaintext data to disk. Integrity verification of the decrypted data ensures consistency with the original dynamic library data, preventing corrupted dynamic libraries due to incorrect keys, file tampering, or transmission errors, thus guaranteeing the reliability and security of the loading process.

[0017] An anonymous file is created in memory and the decrypted data is written to it, ensuring that the plaintext content of the dynamic library exists only in this memory file. This anonymous file does not correspond to any persistent file on disk, therefore, there is no discoverable plaintext dynamic library file at the file system level. After loading the anonymous file in memory through the dynamic loading interface and obtaining the dynamic library handle, the path link of the anonymous file in the file system is immediately deleted, preventing external processes from accessing its contents via file paths. Since the dynamic library handle remains valid after the path link is deleted, the functionality of the dynamic library is unaffected, thus further reducing the possibility of discovery while maintaining functional integrity. The target address is obtained based on the dynamic library handle, and the function call is executed, maintaining a usage method completely consistent with regular dynamic library calls. Applications can use the encrypted dynamic library without modifying their calling logic, ensuring compatibility. After the function call is completed, the dynamic library is unloaded and the decrypted data is securely cleared, ensuring that the plaintext form of the dynamic library is completely eliminated from memory after use, leaving no disk or memory residue, achieving a "traceless" effect. It achieves full lifecycle security protection for dynamic libraries, ensuring they are unidentifiable during storage, uninterceptable during transmission, not written to disk during loading, and leave no residue after use. This effectively prevents the leakage of dynamic library content and enhances software security and anti-reverse engineering capabilities.

[0018] In step S110, the target encrypted file is obtained, as well as the pre-configured decryption key and initialization vector are obtained from the secure storage area. The target encrypted file is a non-dynamic library format data file generated by encrypting the original dynamic library file.

[0019] In the embodiments of this application, the raw dynamic library file refers to a standard format dynamic link library file that has not been encrypted and can be directly recognized and loaded by the operating system. In the Linux operating system environment, the raw dynamic library file follows the specification of Executable and Linkable Format (ELF format, i.e., a standard file format for executable files, object code, shared libraries, and kernel dumps).

[0020] Standard ELF format dynamic link library files have a specific internal structure and contain the following key components: First, the ELF file header (a fixed-length data structure located at the beginning of the file) contains the file's magic number (a fixed sequence of bytes used to identify the file type; for ELF format files, the first four bytes are fixed as the hexadecimal value "7f 45 4c 46", corresponding to the ASCII characters "DEL" followed by the three letters "ELF"), target architecture type, file type identifier (where a type value of "3" indicates that the file is a shared object file, i.e., a dynamic link library file), entry point address, program header table offset, and section header table offset, among other metadata.

[0021] Second, the Program Header Table (an array of data structures describing the loading information of each segment in the file) instructs the operating system on how to map the segments in the file into the virtual memory address space of the process when loading the dynamic link library file.

[0022] Third, the Section Header Table (an array of data structures describing the attribute information of each section in the file) and the specific sections, including the code section (.text section, which stores machine instruction code), the data section (.data section, which stores initialized global and static variables), the table sections (.symtab and .dynsym sections, which store function names and variable names), the string table sections (.strtab and .dynstr sections, which store name strings), the relocation table sections (.rel and .rela sections, which store relocation entry information), and the dynamic linking information section (.dynamic section, which stores information required by the dynamic linker), etc.

[0023] The magic number identifier, file type identifier, and section organization method in the ELF format structure constitute the criteria for identifying whether a file is a valid dynamic link library. Because these characteristics are public, standardized, and identifiable, attackers can easily identify dynamic link library files on the disk and perform reverse engineering on them.

[0024] Encrypting the original dynamic library file refers to the process of encrypting the complete binary data of the original dynamic library file using a symmetric encryption algorithm. Specifically, it involves using the cryptographic algorithm interface provided by the Secure Sockets Layer (OpenSSL) library to perform a symmetric encryption transformation on the complete binary data of the original dynamic library file using Advanced Encryption Standard (AES) algorithms in Cipher Block Chaining (CBC) mode (a block cipher mode where each plaintext block is XORed with the previous ciphertext block before encryption, and the first plaintext block is XORed with the initialization vector, thus ensuring that the generation of each ciphertext block depends not only on the current plaintext block but also on all previous plaintext blocks, thereby eliminating the regularity of identical plaintext blocks producing identical ciphertext blocks).

[0025] In this embodiment, acquiring the target encrypted file refers to reading the complete binary data of the target encrypted file from a predetermined storage location into the program's memory space. The predetermined storage location can be a specified path in the local disk file system, a specified resource address on a remote network server, or a specific offset position embedded in the application's own binary file data segment.

[0026] When the target encrypted file is stored on the local disk file system, the program opens the target encrypted file through the file input / output interface provided by the operating system (i.e., file read system calls), and loads all the bytes of the file into a pre-allocated memory buffer in a sequential reading manner. The memory buffer is a contiguous block of memory dynamically allocated by the program in the heap memory region (i.e., a memory region dynamically allocated by the operating system for applications that can be requested and released on demand), and its size is equal to the byte length of the target encrypted file.

[0027] When the target encrypted file is stored on a remote network server, the program establishes a secure connection with the remote server through a network communication protocol (such as Hypertext Transfer Protocol Secure, i.e., HTTPS, which adds encryption protection of Secure Sockets Layer or Transport Layer Security protocol on top of Hypertext Transfer Protocol) and transmits the complete binary data of the target encrypted file to the local memory buffer through an encrypted communication channel.

[0028] Regardless of the acquisition method used, after the complete binary data of the target encrypted file is read into the memory buffer, the program will record the total byte length of the binary data for use in determining the data range for decryption operations in subsequent decryption steps.

[0029] The decryption key and initialization vector are two core secret parameters necessary for performing the decryption operation. The decryption key controls the inverse transformation process of the Advanced Encryption Standard (AES) algorithm, and the initialization vector is used in the CBC mode decryption process to perform a bitwise XOR operation with the first intermediate decryption result to recover the first plaintext block. Since the AES algorithm is a symmetric encryption scheme (i.e., the encryption and decryption processes use the same key), the decryption key obtained in this step is the same as the encryption key K used in the aforementioned encryption process, with a length of 256 bits (i.e., 32 bytes); the initialization vector obtained in this step is the same as the initialization vector IV used in the aforementioned encryption process, with a length of twelve bytes (i.e., ninety-six bits). A secure storage area refers to a storage space that is physically or logically separated from the storage location of the target encrypted file and has access control protection mechanisms. Specific implementations of secure storage areas include, but are not limited to, the following: The first type is the Hardware Security Module (HSM), which is a physical device used to manage, process, and store encryption keys, and has a tamper-proof hardware protection mechanism. The decryption key and initialization vector are pre-stored in its secure storage chip. The program initiates a key read request through its API and obtains the key after identity authentication and authorization verification.

[0030] The second form involves a specific directory protected by operating system permissions. The decryption key and initialization vector are stored as files in a directory within the operating system's file system that is subject to strict permission controls. The program reads the file contents as a system user with legitimate access permissions.

[0031] The third form is through environment variables or security configuration services. The decryption key and initialization vector are passed to the program via operating system environment variables or remote security configuration services, and the program obtains them by reading the environment variables or calling the interface.

[0032] Pre-configuration refers to the fact that the decryption key and initialization vector are pre-generated and stored in a secure storage area before execution. This pre-generation occurs offline, using CSPRNG to generate a random byte sequence of a specified length as the value. The decryption key requires 256 bits of random data, and the initialization vector requires 128 bits. After generation, it is deployed to the secure storage area, and the original dynamic library file is encrypted using the same key and vector to generate the target encrypted file.

[0033] This embodiment requires that the decryption key and initialization vector be stored separately from the target encrypted file in a secure storage area, adhering to the principle of separating key and ciphertext storage. Even if an attacker obtains the target encrypted file, they cannot recover the original plaintext data of the dynamic library file due to the lack of the decryption key and initialization vector. The AES-256 algorithm used has an extremely large key space, making exhaustive search attacks infeasible.

[0034] By storing the key and initialization vector separately, attackers cannot effectively decrypt the encrypted file even if it is illegally obtained, thus ensuring the confidentiality of core code and algorithms. The original dynamic library files exist in encrypted form on disk to prevent reverse engineering and code theft. The key and initialization vector are stored separately from the encrypted file, achieving secure isolation, complying with key management standards, and reducing security risks. This step lays the data foundation for subsequent memory decryption and seamless loading operations, ensuring the secure and complete loading process.

[0035] In step S120, the contents of the target encrypted file are read into memory to obtain encrypted data.

[0036] In this embodiment, the complete content of the target encrypted file on a persistent storage medium (such as a hard disk, solid-state drive, flash memory, or other storage device that retains data even after power failure) is read into the process memory space through a file input / output operation interface, forming a continuous sequence of encrypted data bytes to prepare for subsequent decryption operations. This step is a crucial intermediate link between file acquisition and data decryption, ensuring that the encrypted file's ciphertext content is accurately and completely loaded into memory, providing correct input for decryption operations based on the Advanced Encryption Standard (AES) algorithm (a symmetric block cipher algorithm).

[0037] Before performing a file content reading operation, it is necessary to clarify the internal data structure of the target encrypted file. According to the technical solution of this embodiment, the target encrypted file is generated by encrypting the original dynamic link library file (a shared object file with the ".so" extension in Unix-like operating systems) using encryption commands in the Secure Sockets Layer (OpenSSL, a widely used open-source cryptography library) during the build phase (the process of compiling, linking, and packaging the source code into a final distributable product).

[0038] The target encrypted file is opened via the file input / output interface provided by the operating system. In a Linux operating system environment (i.e., an open-source Unix-like operating system kernel and operating systems built upon it), the file opening operation is implemented by calling the file opening function in the standard C programming language (C Programming Language, a general-purpose procedural programming language) runtime library. When calling the file opening function, two parameters are required: the first parameter is the complete path of the target encrypted file in the file system (a string combining the complete directory hierarchy from the root directory of the file system to the target file and the file name); the second parameter is the file opening mode identifier, which in this invention should be set to binary read-only mode (a file access mode that opens the file in binary mode and only allows reading operations, not writing operations). The reason for this is that the content of the target encrypted file is encrypted binary ciphertext data. Using binary read mode ensures that the file content will not undergo any character encoding conversion or newline character conversion by the operating system or standard library during the reading process, thus guaranteeing that the data read into memory is completely consistent with the original data stored on the disk, corresponding byte by byte.

[0039] The file open function returns a file pointer (a pointer to a data structure in standard C used to identify and manipulate an open file) upon successful execution. This file pointer will be used as a handle in subsequent operations such as obtaining the file length, reading the file content, and closing the file. If the file open function returns a null pointer (a special pointer value that does not point to any valid memory address), it indicates that the file open operation has failed. Possible reasons include, but are not limited to, the target encrypted file not existing at the specified path, the currently executing process not having read permissions for the file, or a file system error. In the event of a file open operation failure, this embodiment should terminate the subsequent process and report the error information.

[0040] After successfully opening the target encrypted file, it is necessary to obtain the total length of the file, that is, the total number of bytes occupied by the file on the persistent storage medium. The purpose of obtaining the total file length is to provide precise size parameters for allocating a buffer in memory to store the entire content of the file, ensuring that the allocated memory space can just accommodate the complete content of the file, without wasting memory resources or causing data truncation due to insufficient buffer.

[0041] In step S130, the encrypted data is decrypted according to the decryption key and the initialization vector to obtain the decrypted data.

[0042] In this embodiment, decryption is the reverse operation of encryption. Since the symmetric encryption algorithm used in this scheme operates in counter mode, the encryption and decryption processes are completely identical. Both generate a keystream based on the decryption key and initialization vector, and then perform a byte-by-byte XOR operation between the keystream and the input data. Therefore, the specific decryption process is as follows: using the same decryption key and initialization vector as in the encryption stage, the same keystream is generated in the same way as in the encryption stage. Then, this keystream is XORed byte-by-byte with the encrypted data. Because the XOR operation is reflexive, performing the same XOR operation twice on the same data will restore the original data. Therefore, the above operation can restore the original dynamic library data, i.e., the decrypted data.

[0043] The decryption process is performed entirely in memory, without generating any intermediate files on disk. The decrypted data is stored in the process's memory space for subsequent integrity verification and anonymous memory file writing steps.

[0044] In this embodiment, a decryptor instance (i.e., a software object generated according to the specified encryption algorithm parameters to perform decryption operations) is created based on the preset decryption algorithm type and working mode type.

[0045] In the embodiments of this application, the preset decryption algorithm type is Advanced Encryption Standard (AES), a symmetric block cipher algorithm that transforms a fixed-length plaintext data block into a ciphertext data block of equal length through multiple rounds of substitution and permutation operations. The preset operating mode type is Cipher Block Chaining Mode, a block cipher operating mode in which each plaintext block needs to be XORed with the previous ciphertext block before encryption, and during decryption, each data block after decryption needs to be XORed with the previous ciphertext block to restore it to a plaintext block. The process of creating a decryptor instance includes the following steps: First, by calling the Cipher Factory Method (a factory method used to generate corresponding cipher objects based on specified algorithm names, working mode names, and padding names), and passing the parameter string "Advanced Encryption Standard / Cyclic Block Chaining Mode / Padded 7" (i.e., "AES / CBC / PKCS7Padding", where "AES" represents the Advanced Encryption Standard algorithm and "CBC" represents the Cipher Block Chaining working mode), a cipher instance (a software object capable of performing encryption or decryption operations) is obtained. Then, the working state of the cipher instance is set to Decryption Mode (the state where the cipher instance is configured to perform decryption operations), and the decryption key and initialization vector are passed as parameters to the cipher instance for initialization configuration, making the cipher instance a decryptor instance with decryption capabilities.

[0046] By employing the Advanced Encryption Standard (AES) as the decryption algorithm, and leveraging its thoroughly verified security and reliability, the correctness and security of the decryption process are ensured. AES employs a multi-round iterative substitution and permutation operation structure, possessing high resistance to cryptanalysis and effectively resisting various cryptanalysis methods such as known-plaintext attacks and chosen-plaintext attacks. Furthermore, by adopting a cipherblock chaining working mode, the decryption of each ciphertext block depends not only on the decryption key but also on the content of the previous ciphertext block (or, for the first ciphertext block, on the initialization vector), thus forming a chain-like associated structure. This chain-like associated structure ensures that even if identical plaintext blocks exist in the original data, different ciphertext blocks will be generated after encryption, effectively hiding repetitive pattern information in the original data and enhancing encryption security. During the decryption process, by utilizing the same chain-like associated relationship, the encrypted data can be accurately restored to the original plaintext data.

[0047] In step S140, the integrity of the decrypted data is verified. If the decrypted data passes the integrity verification, an anonymous memory file is created and the decrypted data is written into the anonymous memory file.

[0048] In this embodiment, the purpose of integrity verification is to verify whether the decrypted data maintains its integrity and accuracy during the decryption process, that is, to confirm that the decrypted data has not suffered any bit-level errors, loss, or tampering. If the decrypted data passes integrity verification, an anonymous memory file is created, and the decrypted data that passed integrity verification is written into the anonymous memory file. This achieves secure storage of the decrypted data in memory space, preventing the decrypted plaintext data from falling into persistent storage media in file form, effectively reducing the risk of sensitive data being illegally obtained.

[0049] A memory anonymous file is a special file object that exists only in the operating system's memory space. It is not associated with any file system path on persistent storage media; that is, there is no corresponding file entry for it in the directory structure of the disk file system. Persistent storage media includes, but is not limited to, hard disk drives, solid-state drives, flash memory, and other storage devices that retain data even after power is lost.

[0050] If the decrypted data passes integrity verification, an anonymous memory file is created by invoking a system call provided by the operating system to create a memory file. System calls are the standard interface mechanism for applications to request services from the operating system kernel.

[0051] Specifically, the memory file descriptor create function is called to create the anonymous memory file. The memory file descriptor create function is a system call interface provided by the operating system kernel for creating anonymous memory files. The debug name parameter of the anonymous memory file is used to identify the file during system debugging; the debug name parameter does not appear in the file system's directory structure and does not constitute a file path that can be accessed externally. The file creation flags parameter specifies the behavioral attributes and security constraints of the anonymous memory file.

[0052] The file creation flag parameter can be set to a seal flag. When the seal flag is set, the memory anonymous file supports file sealing operations. File sealing operations can restrict subsequent operation permissions on the memory anonymous file, such as prohibiting write operations or modifying the size of the memory anonymous file, thereby further enhancing the security of the data stored in the memory anonymous file. When the memory file descriptor creation function executes successfully, the operating system kernel allocates the corresponding kernel data structure in memory space, creates a blank memory anonymous file object, and returns the file descriptor associated with the memory anonymous file object. At this time, the initial size of the memory anonymous file is zero bytes, waiting for subsequent data write operations.

[0053] After the anonymous memory file is successfully created, the decrypted data, which has passed integrity verification, is written to the anonymous memory file. The write operation is implemented through the file write system call provided by the operating system.

[0054] During the write operation, the operating system kernel copies the decrypted data from user space to a memory buffer in kernel space associated with the anonymous memory file. User space refers to the memory area used by the application, while kernel space refers to the memory area used by the operating system kernel. Because the data of the anonymous memory file is stored in the kernel space memory buffer, the decrypted data is not written to persistent storage.

[0055] After the write operation is complete, the file offset of the anonymous memory file is reset to the beginning of the file. The file offset is the pointer to the current read / write operation's position within the file. Resetting the file offset ensures that subsequent read operations on the anonymous memory file can start reading the decrypted data from the beginning of the file. After successfully writing the decrypted data to the anonymous memory file, a file sealing operation can be performed to restrict subsequent write permissions. The file sealing operation sets the anonymous memory file to a read-only state, prohibiting any process from modifying or appending the decrypted data already written to the file. The file sealing operation effectively prevents the decrypted data from being accidentally overwritten or maliciously tampered with during subsequent use, further ensuring the integrity and security of the decrypted data.

[0056] An anonymous memory file is created, and decrypted data that has passed integrity verification is written into it. This decrypted data exists only in the operating system's memory space and is not stored as a plaintext file on persistent storage media, fundamentally eliminating the risk of sensitive plaintext data remaining on the disk file system. Even if an attacker gains access to persistent storage media, they cannot extract the decrypted data content, improving data storage security. Simultaneously, the anonymous memory file has no corresponding file path or name in the file system directory structure, making it undiscoverable and inaccessible by external processes through conventional methods, reducing the possibility of unauthorized access to the decrypted data and enhancing its stealth. The anonymous memory file is accessed through a file descriptor, and this file descriptor is only valid within the creating process, limiting its scope. Other processes cannot directly access or use it, achieving process-level access isolation and protection. When the process holding the file descriptor terminates, the operating system automatically reclaims the memory space and completely removes the decrypted data, ensuring that the lifecycle of the decrypted data is consistent with the process using it, avoiding the risk of data leakage due to manual cleanup issues.

[0057] In step S150, an anonymous memory file is loaded through the dynamic loading interface to obtain a dynamic library handle.

[0058] In this embodiment, the dynamic loading interface refers to the Application Programming Interface (API) provided by the operating system for dynamically loading shared library files during program runtime. In Linux (an open-source operating system) and Android (a mobile operating system based on the Linux kernel) operating systems, the dynamic loading interface is specifically the dlopen function (dynamic library opening function). The dlopen function can load a specified shared library into the memory address space of the current process during program execution and return a dynamic library handle.

[0059] A dynamic library handle is a reference identifier returned by the operating system to the caller after successfully loading a dynamic library. The dynamic library handle itself does not directly contain the data content of the dynamic library; instead, it serves as an index credential necessary for subsequent operations such as symbol lookups and function calls on the dynamic library. Through the dynamic library handle, the caller can further obtain the addresses of exported functions or variables in the dynamic library, thereby enabling the invocation of functional interfaces within the dynamic library.

[0060] The specific process of obtaining a dynamic library handle by loading an anonymous file in memory through a dynamic loading interface is as follows: An anonymous file is created using the memory-anonymous file creation system call (memfd_create, the memory file descriptor creation function), and a corresponding file descriptor is obtained. A file descriptor is a non-negative integer identifier assigned by the operating system kernel to each opened file, used to uniquely identify the file in subsequent file read / write operations and file load operations.

[0061] In Linux and Android operating systems, each opened file descriptor has a corresponding virtual path in the operating system's process file system (proc file system). The format of the virtual path corresponding to the file descriptor of an anonymous memory file is: / proc / self / fd / N Where / proc represents the root directory of the process's file system; self represents the current process itself; fd represents the file descriptor directory; and N represents the value of the file descriptor corresponding to the anonymous file in memory.

[0062] The virtual path is passed as an input parameter to the dlopen function (the dynamic library opening function) for loading. The dlopen function locates the decrypted data stored in the anonymous memory file based on the virtual path, which is the raw binary data of the dynamic library, and parses and loads it into the memory address space of the current process according to the shared library format.

[0063] The loading process specifically includes: the dlopen function reads the dynamic library binary data from the anonymous memory file, parses the binary data according to the Executable and Linkable Format, completes segment mapping, symbol resolution, and relocation processing, and finally maps the executable code and data segment of the dynamic library into the virtual memory space of the current process.

[0064] After the dlopen function successfully completes the loading process, it returns a dynamic library handle. A dynamic library handle is a pointer to a dynamic library management data structure maintained internally by the operating system. The caller can then use the dynamic library handle to locate and invoke the target functions within the dynamic library in subsequent steps.

[0065] Since memory-anonymous files exist only in memory and do not correspond to any physical files on disk, the binary data of the dynamic library remains in memory and is never written to disk storage during the loading process via the dynamic loading interface. This method avoids exposing the decrypted dynamic library file to the file system, thereby reducing the risk of reverse engineering or illegal copying of the dynamic library. By referencing and loading memory-anonymous files through virtual paths in the process file system, it utilizes the standard interface mechanism provided by the operating system itself, requiring no modification to the operating system kernel or dynamic linker, ensuring compatibility and universality across different versions of Linux and Android operating systems.

[0066] In step S160, the address of the target in the original dynamic library file is obtained according to the dynamic library handle, and the corresponding function is executed by calling the address of the target. The original dynamic library file is then unloaded through the dynamic library handle, and the decrypted data in memory is securely cleared.

[0067] In this embodiment, the dynamic library handle is the reference identifier returned after loading the anonymous file in memory using the dlopen function (dynamic library open function) in the aforementioned steps. The address of the target function in the original dynamic library file is obtained using the dlsym function (dynamic library symbol lookup function) based on the dynamic library handle.

[0068] The `dlsym` function (dynamic library symbol lookup function) is a dynamic symbol resolution interface provided by the operating system. Its function is to find the corresponding memory address in a loaded dynamic library based on a specified symbol name. The symbol name refers to the name identifier of the exported function in the original dynamic library file. Calling the `dlsym` function requires two input parameters: the first parameter is the dynamic library handle, i.e., the reference identifier returned by the `dlopen` function (dynamic library open function) in the previous steps, used to specify which loaded dynamic library to perform the symbol lookup. The second parameter is the symbol name of the target function, i.e., the name string of the exported function to be called in the original dynamic library file.

[0069] The `dlsym` function (dynamic library symbol lookup function) searches the symbol table of the dynamic library pointed to by the dynamic library handle based on the two parameters mentioned above. The symbol table is a mapping table included when a dynamic library file is compiled according to the Executable and Linkable Format (EPF). This mapping table records the relationship between the name of each exported function in the dynamic library and its corresponding memory address. When the `dlsym` function finds an entry in the symbol table that matches the symbol name of the target function, it returns the address of the target function in the current process's memory space, i.e., the address of the target function. The address of the target function is a function pointer that points to the entry point of the target function in memory.

[0070] After obtaining the address of the target function, the target function is directly called via a function pointer to execute its corresponding functional logic. Specifically, the caller converts the address value returned by the `dlsym` function (the dynamic library symbol lookup function) into a function pointer type that matches the parameter and return types of the target function. Then, the necessary call parameters are passed through the function pointer to complete the call to the target function. After being called, the target function executes its own defined functional logic and returns the execution result to the caller. Since the loading and calling of the dynamic library are both completed in memory, the binary content of the original dynamic library file does not appear in the disk file system during the entire call process, thus achieving the effect of a seamless call.

[0071] After the objective function has finished executing, resource release and safe cleanup operations are performed, which include the following two phases: Phase 1: Unloading the dynamic library. The original dynamic library file is unloaded using the `dlclose` function (dynamic library closing function). The `dlclose` function is a resource release interface provided by the operating system, used in conjunction with the `dlopen` function (dynamic library opening function). The `dlclose` function takes a dynamic library handle as input, unloads the dynamic library corresponding to the handle from the current process's memory address space, releases the memory resources occupied by the dynamic library, and invalidates the dynamic library handle. After the `dlclose` function completes execution, the code and data segments of the dynamic library are no longer mapped to the current process's virtual memory space, and the address of the target function is no longer available.

[0072] The second stage involves securely removing the decrypted data from memory. After uninstalling the dynamic library, any remaining decrypted data in memory is securely removed. Decrypted data refers to the plaintext binary data of the original dynamic library file obtained after decrypting the encrypted data in the preceding steps.

[0073] Secure cleanup refers to explicitly overwriting memory to zero out or randomly overwrite the memory area storing decrypted data, ensuring that the decrypted data no longer remains in plaintext form in memory. Secure cleanup is implemented by calling the `memset_s` function (a secure memory fill function) or the `OPENSSL_cleanse` function (a memory cleanup function provided by the OpenSSL library). The `memset_s` function is a memory fill function that is not optimized away by the compiler, guaranteeing that the fill operation on the specified memory area will be executed. The `OPENSSL_cleanse` function (a memory cleanup function provided by the OpenSSL library) uses a specific implementation to prevent the compiler from removing the cleanup operation during the optimization phase, thus ensuring that the decrypted data is completely overwritten and cleared. The memory areas covered by the secure cleanup operation include: the memory buffer storing the decrypted data, the memory area storing the decryption key, and the memory area storing the initialization vector. By safely clearing the memory areas containing all the aforementioned sensitive data, it is ensured that no sensitive information related to the original dynamic library file remains in the memory space of the current process after the dynamic library is uninstalled.

[0074] In addition, the file descriptor corresponding to the anonymous memory file is closed using the `close` function (file descriptor closing function). After the file descriptor is closed, the operating system will automatically reclaim the memory resources occupied by the anonymous memory file, and the anonymous memory file will then be destroyed.

[0075] By dynamically obtaining the address of the target function and calling it at runtime using the `dlsym` function (dynamic library symbol lookup function), static dependencies on dynamic libraries during the compilation phase are avoided. This allows applications to load and call the functional interfaces in dynamic libraries on demand, improving program flexibility and modularity. The `dlclose` function (dynamic library closing function) promptly unloads used dynamic libraries, releasing memory resources occupied by them and preventing long-term ineffective memory occupation, thus reducing system memory overhead. Furthermore, by destroying anonymous files in memory by closing file descriptors, the decrypted data of the original dynamic library file leaves no trace in the operating system after use, achieving seamless loading and execution of dynamic libraries and meeting the technical requirements for protecting dynamic library intellectual property rights and preventing reverse engineering.

[0076] In one embodiment of this application, the symmetric encryption algorithm is the Advanced Encryption Standard (AES) algorithm, the encryption key is 32 bytes long, and the initialization vector is 12 bytes long. Based on the encryption key and the initialization vector, the original dynamic library data is encrypted using the symmetric encryption algorithm to obtain ciphertext data including: Generate a key stream based on the encryption key and initialization vector; The key stream and the original dynamic library data are processed byte by byte to obtain the ciphertext data; The encryption key and decryption key are the same, and the encryption and decryption processes are the reverse of each other.

[0077] In this embodiment, the encryption key refers to the secret parameter used to control the encryption transformation process in the encryption algorithm. In this invention, the encryption key is a predetermined fixed-length binary data segment, which serves as one of the input parameters of the Advanced Encryption Standard (AES) algorithm to drive the encryption operation. The encryption key remains consistent throughout the encryption and decryption phases; that is, the encryption key used for encryption is the same key used for decryption, and they are completely identical. The initialization vector (IV) refers to a segment of random or pseudo-random initial data introduced before the encryption operation begins. The purpose of the initialization vector is to ensure that even if the same original dynamic library data is encrypted multiple times using the same encryption key, the generated ciphertext data will be different due to the different initialization vectors, thereby enhancing the randomness and security of the encryption result. In this invention, the initialization vector participates in the keystream generation process as a component of the initial value of the counter in the counter mode.

[0078] A keystream is a sequence of pseudo-random bytes of the same length as the data to be encrypted, generated using an encryption algorithm. In counter mode, the keystream generation process is as follows: First, an initial value for the counter is constructed based on the initialization vector. The counter is a value that increments sequentially with each data block processed. Second, the current counter value is used as the input plaintext block. Using the encryption key, an Advanced Encryption Standard (AES) algorithm is applied to this counter value to generate an encrypted output block. This encrypted output block is the byte sequence in the keystream corresponding to the current data block. Subsequently, the counter value is incremented, and the above encryption process is repeated until the total length of the generated keystream equals the length of the original dynamic library data. Finally, all encrypted output blocks are sequentially concatenated to form a complete keystream.

[0079] It's important to note that in counter mode, the object encrypted by the Advanced Encryption Standard (AES) algorithm is not the original dynamic library data itself, but rather the value of the counter. The original dynamic library data does not directly participate in the block cipher operations of the AES algorithm; instead, it is processed byte-by-byte with the keystream in subsequent steps.

[0080] After generating a keystream of the same length as the original dynamic library data, an exclusive OR (XOR) operation is performed byte-by-byte between the keystream and the original dynamic library data to obtain the ciphertext data. The XOR operation is a bit-by-bit binary logical operation. Its rules are: when the values ​​of the two bits involved in the operation are the same, the result is zero; when the values ​​of the two bits involved in the operation are different, the result is one.

[0081] The specific process of byte-by-byte operation is as follows: perform an XOR operation between the first byte of the original dynamic library data and the first byte of the key stream to obtain the first byte of the ciphertext data; perform an XOR operation between the second byte of the original dynamic library data and the second byte of the key stream to obtain the second byte of the ciphertext data; and so on, until the last byte of the original dynamic library data and the last byte of the key stream are XORed to obtain the complete ciphertext data.

[0082] The above byte-by-byte XOR operation can be represented as: C[i] = P[i] ⊕ K[i] Where C[i] represents the i-th byte of the ciphertext data, P[i] represents the i-th byte of the original dynamic library data, K[i] represents the i-th byte of the key stream, the symbol “⊕” represents the XOR operation, and the value of i ranges from the first byte to the last byte.

[0083] In this embodiment, the encryption key and decryption key are the same, meaning that the key used to encrypt the original dynamic library data during the encryption phase is the same key used to decrypt the ciphertext data during the decryption phase. This characteristic is an inherent property of symmetric encryption algorithms, that is, the encryptor and decryptor share the same key.

[0084] Encryption and decryption are inverse operations, meaning that in counter mode, the decryption process is structurally identical to the encryption process. Specifically, decryption uses the same decryption key and initialization vector, generating the same keystream as encryption. This keystream is then XORed byte-by-byte with the ciphertext data to reconstruct the original dynamic library data. The principle behind this is the reflexivity of the XOR operation; performing the same XOR operation twice on the same data will restore the original data. Specifically: P[i] ⊕ K[i] = C[i] (encryption process) C[i] ⊕ K[i] = P[i] (Decryption process) Where P[i] represents the i-th byte of the original dynamic library data, K[i] represents the i-th byte of the keystream, and C[i] represents the i-th byte of the ciphertext data. During encryption, the i-th byte of the original dynamic library data is XORed with the i-th byte of the keystream to obtain the i-th byte of the ciphertext data; during decryption, the i-th byte of the ciphertext data is XORed again with the i-th byte of the same keystream to recover the i-th byte of the original dynamic library data. Therefore, in counter mode, the encryption and decryption processes use the same computational flow, differing only in the input data: during encryption, the input is the original dynamic library data, and the output is ciphertext data; during decryption, the input is ciphertext data, and the output is the original dynamic library data. Thus, encryption and decryption are inverse operations of each other.

[0085] The aforementioned counter mode based on advanced encryption standards is used to encrypt dynamic library data. By generating a keystream and performing a byte-by-byte XOR operation with the original dynamic library data, streaming encryption of the dynamic library data is achieved. This eliminates the need for padding the original dynamic library data, ensuring that the encrypted ciphertext data has the same length as the original dynamic library data. Since encryption and decryption are inverse operations with consistent processes, the implementation complexity is reduced, and the processing efficiency of encryption and decryption is improved. Furthermore, by introducing an initialization vector into the keystream generation, the randomness of the encryption result is enhanced, thereby increasing the security strength of the dynamic library data.

[0086] In one embodiment of this application, creating a memory anonymous file and writing decrypted data into the memory anonymous file includes: Create an anonymous file in memory that exists only in memory and does not correspond to any persistent file on disk, and obtain the file descriptor of the anonymous file in memory; The decrypted data is written to an anonymous file in memory using a file descriptor. Based on the file descriptor, generate the path identifier of the anonymous file in memory within the virtual file system; The lifecycle of an anonymous file in memory is associated with the open state of the file descriptor. When the file descriptor is closed, the contents of the anonymous file in memory are automatically destroyed when the process ends.

[0087] In this embodiment, a memory anonymous file refers to a special type of file that exists only in memory and does not correspond to any persistent file on disk. When a memory anonymous file is created, it does not generate any visible file entity in the disk file system; all its data content is stored in system memory. Because a memory anonymous file does not establish an association with any persistent file on disk, external programs or users cannot discover or access its content by traversing the disk file system, thus effectively preventing decrypted dynamic library data from being exposed in plaintext on the disk storage medium. A persistent file refers to a file stored on non-volatile storage media such as disk that retains its data content even after system power failure or process termination. Unlike persistent files, the data content of a memory anonymous file is not written to non-volatile storage media such as disk, and therefore does not possess the characteristics of persistent storage.

[0088] An anonymous file in memory is created by calling the memory file creation system call interface provided by the operating system. Specifically, the memfd_create (memory file descriptor creation) system call is used to perform the creation operation of the anonymous file in memory. memfd_create (memory file descriptor creation) is a system call interface provided by the Linux kernel (an open-source operating system) that creates an anonymous file in memory and returns a file descriptor corresponding to that anonymous file.

[0089] A file descriptor is a non-negative integer identifier assigned by the operating system kernel to each opened file. As an index for processes to access file resources, a process can perform read, write, and other operations on its corresponding file through that file descriptor. In this invention, after a memory-anonymous file is successfully created, the operating system kernel returns a file descriptor corresponding to that memory-anonymous file. All subsequent operations on that memory-anonymous file are performed through that file descriptor. During the creation of a memory-anonymous file, a name parameter needs to be specified for it. This name parameter is only used for debugging and identification purposes and will not create a corresponding file entry in the disk file system. In other words, even if a name parameter is specified, the memory-anonymous file will not appear in the directory structure of the disk file system.

[0090] After obtaining the file descriptor of the anonymous memory file, the decrypted data is written to the anonymous memory file through the file descriptor.

[0091] Decrypted data refers to the original dynamic library data obtained by decrypting the encrypted ciphertext data. The content of the decrypted data is identical to the original dynamic library data before encryption, containing the complete executable content of the dynamic library.

[0092] The specific process of the write operation is as follows: using a file descriptor as the identifier of the target file, the operating system's file write interface is called to write all bytes of the decrypted data into the anonymous memory file corresponding to the file descriptor. Since the storage space of the anonymous memory file is located in system memory, the write operation essentially transfers the decrypted data from the process's user-mode memory space to the memory area managed by the kernel. After the write operation is complete, the complete content of the decrypted data is stored in the anonymous memory file, which can be accessed and read subsequently through the file descriptor.

[0093] It should be noted that during the entire writing process, the decrypted data is never written to non-volatile storage media such as disks. All data transmission and storage operations are completed in memory space, thus ensuring that the decrypted plaintext data of the dynamic library will not leave any trace on the disk.

[0094] After writing the decrypted data to the anonymous file in memory, it is necessary to generate a path identifier for the anonymous file in the virtual file system based on the file descriptor, so that the subsequent dynamic library loading interface can locate and load the dynamic library data in the anonymous file in memory through this path identifier.

[0095] A virtual file system (VFS) is an abstract file system layer provided by the operating system kernel. The VFS presents various internal kernel information and resources to user space in the form of files and directories, but the files do not correspond to actual data stored on the disk; instead, they are virtual file entries dynamically generated by the kernel at runtime. In Linux (an open-source operating system), the proc file system (a pseudo-file system for process information) is a typical example of a VFS, mounted at the " / proc" path under the system root directory. A path identifier is a string representation used to uniquely locate a file within the directory hierarchy of a file system. In this invention, the path identifier is the virtual path of an anonymous file in memory within the VFS.

[0096] The path identifier is generated as follows: based on the process identifier of the current process and the file descriptor value of the anonymous memory file, the path identifier of the anonymous memory file is concatenated according to the file descriptor symbolic link path rules in the virtual file system. Specifically, the format of the path identifier is " / proc / process identifier / fd / file descriptor value". Here, " / proc" is the mount root path of the virtual file system; "process identifier" is the unique number of the process currently executing this method in the operating system, which can be obtained through the system call interface provided by the operating system to obtain the process identifier; "fd" is the name of the file descriptor directory, which stores the symbolic link entries of all files opened by the current process; and "file descriptor value" is the specific integer value of the file descriptor obtained when creating the anonymous memory file in the previous steps.

[0097] A process identifier is a unique number assigned by the operating system to each running process. The process identifier value of the current process can be obtained by calling the getpid system call interface.

[0098] A symbolic link is a special file entry in a file system that does not contain actual data content but rather serves as a reference to another file or file resource. In the file descriptor directory of the virtual file system, each file descriptor value corresponds to one symbolic link entry, which points to the actual file resource associated with the file descriptor. For anonymous memory files, the symbolic link entries in the file descriptor directory constitute the accessible path of that anonymous memory file within the virtual file system.

[0099] The path identifier generated in the above manner can be used as a file path parameter by the subsequent dynamic library loading interface to locate and read the decrypted data stored in the anonymous file in memory, thereby achieving the purpose of loading the dynamic library from memory.

[0100] The lifecycle refers to the entire duration of an anonymous memory file from its creation to its destruction. In this invention, the lifecycle of an anonymous memory file is associated with the open state of its file descriptor.

[0101] The open state of a file descriptor refers to the state in which the file descriptor is valid and available in the operating system kernel, meaning that the file descriptor has not been closed. When a file descriptor is in the open state, the data content of the anonymous file in memory remains valid in memory and can be accessed normally through the file descriptor or path identifier.

[0102] When a file descriptor is closed, the contents of the anonymous memory file are automatically destroyed when the process terminates. Specifically, since the anonymous memory file does not correspond to any persistent file on disk, the continuation of its data depends entirely on the file descriptor's reference relationships. When the process holding the file descriptor closes the file descriptor or the process itself terminates, the operating system kernel releases the kernel resources occupied by the file descriptor and reclaims all the storage space occupied by the anonymous memory file. The decrypted data stored in the anonymous memory file will be completely erased and cannot be recovered or accessed in any way.

[0103] Automatic destruction refers to the process of clearing and reclaiming resources from anonymous memory files without requiring explicit deletion by the application. Instead, it is automatically completed by the operating system kernel when the file descriptor is closed or the process terminates. This mechanism ensures that even if the application does not actively perform cleanup operations, the decrypted plaintext data of dynamic libraries will not remain in the system.

[0104] Since the anonymous in-memory file exists only in memory and does not correspond to any persistent file on disk, the decrypted plaintext data of the dynamic library is never written to the disk storage medium throughout the entire loading and usage process. This effectively prevents attackers from obtaining the plaintext data of the dynamic library by scanning the disk file system, significantly improving the security protection of the dynamic library data. Through a path identification mechanism based on a virtual file system, subsequent dynamic library loading interfaces can access the dynamic library data stored in memory using standard file paths, without requiring modifications to the existing dynamic library loading process, thus ensuring compatibility between this method and existing dynamic library loading mechanisms.

[0105] Since the lifecycle of anonymous memory files is associated with the open state of file descriptors, the decrypted data will be automatically destroyed when the process ends or the file descriptor is closed, without the need for additional cleanup mechanisms. This reduces the security risk of sensitive data remaining due to negligence and realizes automated secure lifecycle management of decrypted data.

[0106] In one embodiment of this application, the integrity verification of the decrypted data includes: Calculate the hash digest value of the decrypted data to obtain the second hash digest value; Parse the custom file header identifier and the first hash digest value from the target encrypted file; Compare the second hash digest value with the first hash digest value; If the second hash digest value matches the first hash digest value, the decrypted data is deemed to have passed the integrity check. If the second hash digest value is inconsistent with the first hash digest value, it is determined that the decrypted data has failed the integrity check, and the encrypted and decrypted data in memory are securely cleared.

[0107] In this embodiment, after obtaining the decrypted data, the same hash algorithm as in the encryption stage is used to perform a hash operation on the decrypted data to obtain a second hash digest value. A hash algorithm is an algorithm that converts input data of arbitrary length into a fixed-length output value through specific mathematical operations. The fixed-length output value is the hash digest value. Hash algorithms have a one-way characteristic, meaning that the original input data cannot be derived from the hash digest value. Simultaneously, hash algorithms also have collision resistance, meaning that the probability of different input data producing the same hash digest value is extremely low. A hash digest value is a fixed-length numerical value generated after the input data is processed by a hash algorithm. The hash digest value can serve as a unique identifier for the input data; when the input data undergoes any slight change, the generated hash digest value will show a significant difference.

[0108] In this embodiment, the hash algorithm specifically employs the Secure Hash Algorithm 2-256 variant (Secure Hash Algorithm 2-256). This variant can convert input data of any length into a fixed-length hash digest of 256 bits (32 bytes). The second hash digest is the hash digest obtained after performing the hash operation on the decrypted data during the decryption phase. The second hash digest reflects the current actual state of the decrypted data. The calculation process is as follows: taking all bytes of the decrypted data as input, processing it using the Secure Hash Algorithm 2-256 variant, and outputting a 256-bit hash digest; this output value is then used as the second hash digest.

[0109] After calculating the second hash digest value, it is necessary to parse the custom file header identifier and the first hash digest value that were pre-stored during the encryption stage from the target encrypted file, so as to serve as the comparison benchmark for integrity verification.

[0110] The target encrypted file refers to the file generated after encrypting the original dynamic library data during the encryption phase. The data structure of the target encrypted file consists of two parts arranged sequentially: a custom file header and ciphertext data. The custom file header is a fixed-format metadata information area appended to the ciphertext data during the encryption phase. The custom file header contains a custom file header identifier and a first hash digest value. The custom file header identifier is a pre-defined marker data with fixed content used to identify whether the target encrypted file is a legitimate encrypted file generated by the encryption method of this embodiment. In this embodiment, the custom file header identifier is set to "ENSO" (Encrypted Secure Object). The custom file header identifier is located at the beginning of the custom file header and occupies a fixed byte length. By reading the data at the beginning of the target encrypted file and determining whether it matches the preset "ENSO" identifier, it can be confirmed whether the target encrypted file is a legitimate encrypted file format.

[0111] The first hash digest value refers to the hash digest value obtained after performing a hash operation on the original dynamic library data during the encryption phase. The first hash digest value is calculated and stored in the custom file header during the encryption phase. The first hash digest value reflects the original content state of the original dynamic library data before encryption and serves as the baseline value for subsequent integrity verification. The first hash digest value is stored in the custom file header immediately following the custom file header identifier, and its length is thirty-two bytes (i.e., 256 bits). The parsing process is as follows: First, read a fixed number of bytes of data at the beginning of the target encrypted file to obtain the custom file header identifier; then, read the thirty-two bytes of data immediately following the custom file header identifier to obtain the first hash digest value. Through the above parsing operations, the custom file header identifier and the first hash digest value can be extracted from the custom file header of the target encrypted file.

[0112] After obtaining the second hash digest value and the first hash digest value, the second hash digest value is compared byte by byte with the first hash digest value. Since the first hash digest value is calculated on the original dynamic library data during the encryption stage, while the second hash digest value is calculated on the decrypted data during the decryption stage, if the decryption process is correct and the data has not been tampered with or damaged, the decrypted data should be completely consistent with the original dynamic library data, and therefore the second hash digest value should be exactly the same as the first hash digest value.

[0113] When the second hash digest value is completely identical to the first hash digest value byte-by-byte, it indicates that the decrypted data is identical in content to the original dynamic library data before encryption. The decrypted data has not been tampered with, damaged, or lost during transmission and storage; therefore, the decrypted data has passed the integrity check. After passing the integrity check, the decrypted data can be used as legitimate and valid dynamic library data for subsequent loading and calling operations.

[0114] When the second hash digest value is inconsistent with the first hash digest value byte-by-byte, it indicates that the decrypted data differs from the original dynamic library data before encryption. This difference may be caused by the following reasons: the ciphertext data in the target encrypted file has been tampered with or corrupted during storage or transmission; or the encryption key used during decryption is inconsistent with the encryption key used in the encryption stage, leading to an incorrect decryption result. In either case, the decrypted data cannot be considered legitimate and valid dynamic library data; therefore, the decrypted data has failed the integrity check.

[0115] After determining that the decrypted data has failed the integrity check, a secure cleanup operation needs to be performed on both the encrypted and decrypted data in memory.

[0116] Secure erasure refers to overwriting sensitive data in a memory region, setting every byte in the memory region to zero or another preset fixed value. This ensures that the sensitive data is completely erased and cannot be recovered through memory reads or dumps. Secure erasure differs from ordinary memory release. Ordinary memory release only marks a memory region as available for reallocation without changing the data already stored there, so some sensitive data may remain after the memory is released. Secure erasure, however, explicitly overwrites the data in the memory region, ensuring that sensitive data is completely removed before memory is released.

[0117] The specific process of the secure erasure operation is as follows: First, locate the memory area occupied by the encrypted data and overwrite each byte in that memory area with a value of zero; then, locate the memory area occupied by the decrypted data and overwrite each byte in that memory area with a value of zero. After completing the above overwriting operations, release the memory space occupied by the encrypted and decrypted data.

[0118] When integrity verification fails, the decrypted data may be tampered with or incorrectly decrypted. If not promptly removed, it could be obtained and exploited by malicious programs through memory scanning. Simultaneously, encrypted data, being ciphertext, may increase the risk of being obtained and analyzed offline if it remains in memory for an extended period. Therefore, performing secure cleanup operations on both encrypted and decrypted data effectively prevents sensitive data from remaining in memory and reduces the security risk of data leakage.

[0119] By pre-calculating the first hash digest value of the original dynamic library data during the encryption phase and storing it in a custom file header, and then recalculating the second hash digest value of the decrypted data during the decryption phase and comparing it with the first hash digest value, it is possible to accurately detect whether the decrypted data is completely consistent with the original dynamic library data, thereby effectively detecting possible tampering or damage to the data during storage or transmission. Furthermore, by setting a custom file header identifier, it is possible to quickly determine whether the target encrypted file is a legitimate encrypted file generated by the encryption method of this invention during the parsing phase, avoiding invalid decryption and verification operations on illegal files or files with incorrect formats.

[0120] In one embodiment of this application, loading an anonymous memory file through a dynamic loading interface to obtain a dynamic library handle includes: Pass the path identifier as a parameter to the dynamic loading interface; Map the contents of the dynamic library in the anonymous memory file to the current process's runtime memory space to obtain the dynamic library handle; The file path deletion interface is called to delete the path link corresponding to the path identifier, so that the anonymous file in memory cannot be accessed by external processes through the file path.

[0121] In this embodiment, the path identifier is passed as a parameter to the dlopen function (dynamic library opening function). That is, the path identifier of the anonymous memory file in the file system replaces the traditional disk file path as the input parameter of the dlopen function. Since the path identifier points to the anonymous memory file descriptor through the " / proc / self / fd / " path mechanism, and the anonymous memory file already contains the decrypted and complete dynamic library content, the dlopen function can locate and read the dynamic library content stored in the anonymous memory file using the path identifier.

[0122] It's important to note that the `dlopen` function (dynamic library opening function) requires a load mode parameter when called. The load mode parameter specifies how symbols in the dynamic library are resolved. Common load modes include immediate binding mode (RTLD_NOW mode), which means that all symbol references in the dynamic library are resolved immediately upon loading. By passing the path identifier and the load mode parameter to the `dlopen` function, the dynamic library content in an anonymous memory file is loaded.

[0123] By passing the path identifier to the dynamic loading interface, the goal of loading dynamic libraries from anonymous memory files is achieved. The entire loading process does not require writing the decrypted dynamic library content to any file on the disk, thereby avoiding the decrypted dynamic library file being exposed in plaintext in the disk file system and reducing the risk that the dynamic library content can be obtained by malicious programs by scanning disk files.

[0124] The operating system locates the anonymous memory file based on the path identifier and maps the dynamic library content stored in the anonymous memory file into the runtime memory space of the current process. The current process refers to the application process that calls the dlopen function (dynamic library opening function), that is, the process corresponding to the Android application that needs to use the dynamic library. The runtime memory space refers to the virtual memory address space allocated by the operating system to the current process. The code segments, data segments, etc., required by the current process during execution are all loaded into the runtime memory space.

[0125] The mapping process refers to the operating system loading the contents of the dynamic library from the anonymous memory file into a specified area of ​​the current process's runtime memory space according to the format requirements of the dynamic library file, and completing the relocation operation of the addresses of each symbol in the dynamic library. The relocation operation refers to binding the external symbols (including function symbols and variable symbols) referenced in the dynamic library to their actual addresses in the runtime memory space, so that when the code in the dynamic library is called, it can correctly jump to the corresponding function entry address or access the corresponding variable storage address.

[0126] A dynamic library handle is a pointer returned by the `dlopen` function (the dynamic library open function) after successfully loading a dynamic library. It's an abstract reference to the loaded dynamic library in the runtime memory space; essentially, it's a pointer to a dynamic library information structure maintained internally by the operating system. The purpose of the dynamic library handle is to allow subsequent steps to pass it as a parameter to the symbol lookup interface (i.e., the `dlsym` function, the dynamic library symbol lookup function). This interface searches for a function or variable symbol with a specified name within the loaded dynamic library, obtaining its actual address in runtime memory, and thus enabling the calling of a specific function or access to a specific variable within that dynamic library.

[0127] Specifically, when the return value of the dlopen function (dynamic library opening function) is not empty, it means that the dynamic library was loaded successfully, and the return value is the dynamic library handle; when the return value of the dlopen function (dynamic library opening function) is empty, it means that the dynamic library failed to load. In this case, the specific reason for the loading failure can be obtained through the error information retrieval interface (i.e., the dlerror function, dynamic library error retrieval function).

[0128] By mapping the dynamic library content from the anonymous memory file to the current process's runtime memory and obtaining a dynamic library handle, subsequent calls to functions within the dynamic library can be made through the dynamic library handle, thus enabling the normal use of the dynamic library. Furthermore, since the dynamic library content is directly mapped from the anonymous memory file to the runtime memory, the entire process does not involve writing the decrypted dynamic library file to disk, thereby maintaining the security of the dynamic library content during the loading process.

[0129] The file path deletion interface refers to the system call interface provided by the operating system for deleting file path links in the file system. In the specific implementation plan of the technical disclosure, the file path deletion interface specifically uses the unlink function (file link deletion function) in the Android operating system. The function of the unlink function (file link deletion function) is to take a file path as an input parameter, delete the directory entry of that file path in the file system, that is, to break the link relationship between the file path and the file entity it points to.

[0130] A path link is an accessible link in the file system between a path name and an anonymous file in memory, formed by a path identifier (i.e., " / proc / self / fd / " plus the file descriptor value). Through a path link, any process (including the current process and external processes) that knows the path identifier string can, in theory, access and read the anonymous file in memory using that path identifier. External processes refer to processes other than the current process, including but not limited to other application processes running on the same Android device, system service processes, and potentially malicious program processes.

[0131] The path identifier is passed as an argument to the `unlink` function (the function that deletes file links). After the `unlink` function is executed, the path link corresponding to the path identifier is removed from the directory structure of the file system. After the path link is deleted, the anonymous memory file no longer has an accessible path name in the file system, meaning that no process can anymore locate and access the dynamic library content stored in the anonymous memory file via file path.

[0132] It's important to clarify that deleting the path link does not destroy the anonymous file itself or clear the dynamic library content stored within it. This is because, in the operating system's file management mechanism, the anonymous file descriptor is still held by the current process, and the dynamic library content has already been mapped into the current process's runtime memory space using the `dlopen` function (the dynamic library opening function). When determining whether a file can be released, the operating system requires both conditions to be met: the file's path link count is zero, and no process holds the file descriptor. Since the current process still holds the anonymous file descriptor, the anonymous file and its dynamic library content remain valid in memory. The functionality of the dynamic libraries loaded into the runtime memory space is unaffected, and the current process can still call functions in the dynamic libraries normally through the dynamic library handle.

[0133] By deleting the path link corresponding to the path identifier, the path for external processes to access the anonymous memory file via file path is cut off. This ensures that the decrypted dynamic library content exists only in the current process's runtime memory space, and external processes cannot obtain the decrypted dynamic library content through file system paths. This step, together with the aforementioned anonymous memory file creation and dynamic library loading steps, together achieve a complete security protection process for the dynamic library from decryption to loading to path clearing. This effectively prevents the decrypted dynamic library content from being stolen or tampered with by external malicious processes through file system paths, thereby improving the security protection capabilities of dynamic library file loading on the Android platform.

[0134] In one embodiment of this application, before reading the contents of the target encrypted file into memory to obtain the encrypted data, the method further includes: Read the header data of the target encrypted file; Determine whether the file header data contains a custom file header identifier; If the file header data contains a custom file header identifier, the target encrypted file is determined to be a legitimate encrypted dynamic library file, and the read operation continues. If the file header data does not contain a custom file header identifier, the target encrypted file is determined to be an illegal file, and the loading process is terminated.

[0135] In this embodiment, the target encrypted file refers to a pre-encrypted dynamic library file stored in the Android application installation package. A custom file header identifier has been added to the target encrypted file during the encryption stage; this custom file header identifier is located at the beginning of the target encrypted file, i.e., the header area of ​​the target encrypted file.

[0136] The file header data refers to a segment of binary data of a preset length, read starting from the beginning of the target encrypted file. The file header data contains custom file header identifier information written during the encryption phase. The file header data is read as follows: starting from the first byte of the target encrypted file, the corresponding number of bytes are read sequentially according to the preset length of the custom file header identifier, and this read data is used as the file header data. The preset length is consistent with the byte length occupied when the custom file header identifier is written during the encryption phase, thus ensuring that the read file header data completely covers the area containing the custom file header identifier.

[0137] A custom file header identifier is a specific identifier data segment predefined and written into the header of the target encrypted file by the encryption tool during the encryption phase. The custom file header identifier is a pre-agreed fixed byte sequence used to uniquely identify that the file is a legitimate encrypted dynamic library file generated after processing by this scheme's encryption process. The specific content of the custom file header identifier remains consistent between the encryption and decryption ends; that is, the custom file header identifier written during the encryption phase and the custom file header identifier used for comparison during the decryption phase are the same byte sequence.

[0138] The specific method for judgment is as follows: the read file header data is compared byte by byte with the custom file header identifier pre-stored on the decryption end. If the corresponding byte sequence in the file header data is completely consistent with the custom file header identifier, it is determined that the file header data contains the custom file header identifier; if there is any inconsistency between the corresponding byte sequence in the file header data and the custom file header identifier, it is determined that the file header data does not contain the custom file header identifier.

[0139] After the above comparison and judgment, if the file header data contains a custom file header identifier, it indicates that the header area of ​​the target encrypted file contains identifier data that is completely consistent with the custom file header identifier written during the encryption stage. This comparison result shows that the target encrypted file is indeed a file generated after being processed by the encryption process of this scheme, and its file structure conforms to the encrypted dynamic library file format defined by this scheme, and has not been tampered with or replaced by external programs.

[0140] A legitimate encrypted dynamic library file refers to an encrypted dynamic library file whose content is complete and whose file format conforms to the encryption specifications of this scheme. That is, the header of the target encrypted file contains the correct custom header identifier, and the data part after the header is the original content of the encrypted dynamic library.

[0141] After confirming that the target encrypted file is a legitimate encrypted dynamic library file, the read operation continues. Continuing the read operation means that, provided the custom file header verification is successful, the encrypted data portion of the target encrypted file following the custom file header is read. Specifically, the bytes occupied by the custom file header are skipped, and the remaining data content is read starting from the position after the custom file header. The data read is the original encrypted dynamic library data. This original encrypted dynamic library data will be passed to the decryption process in subsequent steps to decrypt and restore the original content of the dynamic library.

[0142] By verifying the legitimacy of the target encrypted file through a custom file header identifier before performing subsequent data reading and decryption operations, it is ensured that the data processed in the subsequent decryption process comes from a legitimate encrypted dynamic library file, avoiding meaningless decryption operations on illegal or tampered files, thereby improving the reliability and security of the overall loading process.

[0143] Secondly, embodiments of this application provide a method system for loading dynamic libraries, including: The first acquisition module is used to acquire the target encrypted file and to acquire the pre-configured decryption key and initialization vector from the secure storage area. The target encrypted file is a data file in non-dynamic library format generated by encrypting the original dynamic library file. The first module is used to read the contents of the target encrypted file into memory to obtain the encrypted data. The second module is used to decrypt the encrypted data based on the decryption key and the initialization vector to obtain the decrypted data. The first verification module is used to perform integrity verification on the decrypted data. If the decrypted data passes the integrity verification, an anonymous memory file is created and the decrypted data is written into the anonymous memory file. The third module is used to load anonymous files in memory through the dynamic loading interface and obtain dynamic library handles; The second acquisition module is used to obtain the address of the target in the original dynamic library file based on the dynamic library handle, call the address of the target to execute the corresponding function, and unload the original dynamic library file through the dynamic library handle.

[0144] In this embodiment, the dynamic library loading system acquires a non-dynamic library format data file, ensuring that the target encrypted file lacks the format characteristics of a dynamic library (such as executable and linkable headers) during storage and transmission. This prevents conventional dynamic library analysis and decompilation tools from recognizing the file as a dynamic library, and thus makes it impossible to decompile or reverse engineer it, thereby hiding the dynamic library file type. The target address is obtained based on the dynamic library handle, and a function call is executed, maintaining a usage method completely consistent with conventional dynamic library calls. The application can use the encrypted dynamic library without modifying its calling logic, ensuring compatibility. After the function call is completed, the dynamic library is unloaded, and the decrypted data is securely cleared, ensuring that the plaintext form of the dynamic library is completely eliminated from memory after use, leaving no disk or memory residue, achieving a "traceless" effect. Furthermore, it achieves full lifecycle security protection for the dynamic library: unrecognizable during storage, uninterceptable during transmission, not written to disk during loading, and leaving no residue after use, effectively preventing the leakage of dynamic library content and enhancing software security and anti-reverse engineering capabilities.

[0145] The functions of each module in each device in the embodiments of this application can be found in the corresponding descriptions in the above methods, and will not be repeated here.

[0146] Figure 2 A structural block diagram of an electronic device according to an embodiment of this application is shown. Figure 2 As shown, the electronic device includes a memory 410 and a processor 420. The memory 410 stores instructions that can be executed on the processor 420. When the processor 420 executes the instructions, it implements the dynamic library loading method in the above embodiments. The number of memories 410 and processors 420 can be one or more. This electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0147] The electronic device may also include a communication interface 430 for communicating with external devices and exchanging data. The devices are interconnected using different buses and can be mounted on a common motherboard or otherwise as needed. The processor 420 can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). The bus can be divided into address buses, data buses, control buses, etc. For ease of illustration, Figure 2 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0148] Optionally, in a specific implementation, if the memory 410, processor 420 and communication interface 430 are integrated on a single chip, the memory 410, processor 420 and communication interface 430 can communicate with each other through an internal interface.

[0149] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.

[0150] This application provides a computer-readable storage medium (such as the memory 410 described above) that stores computer instructions, which, when executed by a processor, implement the method provided in this application.

[0151] Optionally, memory 410 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device, etc. Furthermore, memory 410 may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory 410 may optionally include memory remotely located relative to processor 420, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0152] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope disclosed in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for loading dynamic libraries, characterized in that, include: The target encrypted file is obtained, and a pre-configured decryption key and initialization vector are obtained from a secure storage area. The target encrypted file is a data file in non-dynamic library format generated by encrypting the original dynamic library file. The contents of the target encrypted file are read into memory to obtain encrypted data; The encrypted data is decrypted using the decryption key and the initialization vector to obtain decrypted data. The decrypted data is subjected to integrity verification. If the decrypted data passes the integrity verification, an anonymous memory file is created and the decrypted data is written into the anonymous memory file. The anonymous memory file is loaded through the dynamic loading interface to obtain a dynamic library handle; Based on the dynamic library handle, the address of the target in the original dynamic library file is obtained, and the corresponding function is executed by calling the address of the target. The original dynamic library file is then unloaded using the dynamic library handle, and the decrypted data in memory is securely cleared.

2. The method according to claim 1, characterized in that, The acquisition of the target encrypted file includes: Read all contents of the original dynamic library file into memory to obtain the original dynamic library data; Calculate the hash digest value of the original dynamic library data to obtain the first hash digest value; Obtain the pre-configured encryption key and the initialization vector from the secure storage area; Based on the encryption key and the initialization vector, the original dynamic library data is encrypted using a symmetric encryption algorithm to obtain ciphertext data; The custom file header identifier, the first hash digest value, and the ciphertext data are combined and written into a new file according to a preset format to obtain the target encrypted file.

3. The method according to claim 2, characterized in that, The symmetric encryption algorithm is the Advanced Encryption Standard (AES) algorithm. The encryption key is 32 bytes long, and the initialization vector is 12 bytes long. The original dynamic library data is encrypted using the symmetric encryption algorithm based on the encryption key and the initialization vector to obtain ciphertext data, including: A key stream is generated based on the encryption key and the initialization vector; The key stream and the original dynamic library data are processed byte by byte to obtain ciphertext data; The encryption key is the same as the decryption key, and the encryption process and the decryption process are the reverse operations of each other.

4. The method according to claim 3, characterized in that, The step of creating an anonymous memory file and writing the decrypted data into the anonymous memory file includes: Create an anonymous memory file that exists only in memory and does not correspond to any persistent file on disk, and obtain the file descriptor of the anonymous memory file; The decrypted data is written to the anonymous memory file using the file descriptor. Based on the file descriptor, generate the path identifier of the anonymous memory file in the virtual file system; The lifecycle of the anonymous memory file is associated with the open state of the file descriptor. When the file descriptor is closed, the contents of the anonymous memory file are automatically destroyed when the process ends.

5. The method according to claim 4, characterized in that, The integrity verification of the decrypted data includes: Calculate the hash digest value of the decrypted data to obtain the second hash digest value; Parse the custom file header identifier and the first hash digest value from the target encrypted file; Compare the second hash digest value with the first hash digest value; If the second hash digest value matches the first hash digest value, the decrypted data is determined to have passed the integrity check. If the second hash digest value is inconsistent with the first hash digest value, it is determined that the decrypted data has failed the integrity check, and the encrypted data and the decrypted data in memory are securely cleared.

6. The method according to claim 5, characterized in that, The process of loading the anonymous memory file through the dynamic loading interface to obtain the dynamic library handle includes: Pass the path identifier as a parameter to the dynamic loading interface; Map the dynamic library content in the anonymous memory file to the current process's runtime memory space to obtain a dynamic library handle; The file path deletion interface is called to delete the path link corresponding to the path identifier, so that the anonymous memory file cannot be accessed by external processes through the file path.

7. The method according to claim 6, characterized in that, Before reading the contents of the target encrypted file into memory to obtain the encrypted data, the process further includes: Read the header data of the target encrypted file; Determine whether the file header data contains the custom file header identifier; If the custom file header identifier is included in the file header data, the target encrypted file is determined to be a legitimate encrypted dynamic library file, and the read operation continues. If the custom file header identifier is not included in the file header data, the target encrypted file is determined to be an illegal file, and the loading process is terminated.

8. A method system for loading dynamic libraries, characterized in that, include: The first acquisition module is used to acquire the target encrypted file and to acquire the pre-configured decryption key and initialization vector from the secure storage area. The target encrypted file is a data file in non-dynamic library format generated by encrypting the original dynamic library file. The first obtaining module is used to read the contents of the target encrypted file into memory to obtain encrypted data; The second obtaining module is used to decrypt the encrypted data according to the decryption key and the initialization vector to obtain decrypted data; The first verification module is used to perform integrity verification on the decrypted data. If the decrypted data passes the integrity verification, a memory anonymous file is created and the decrypted data is written into the memory anonymous file. The third module is used to load the anonymous memory file through the dynamic loading interface to obtain a dynamic library handle; The second acquisition module is used to obtain the address of the target in the original dynamic library file according to the dynamic library handle, call the address of the target to execute the corresponding function, and unload the original dynamic library file through the dynamic library handle.

9. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the method as described in any one of claims 1-7.

Images