File decryption method, system, electronic device and readable storage medium

Abstract

This invention discloses a file decryption method, system, electronic device, and readable storage medium, particularly relating to the field of network security technology. The method includes: obtaining the address of a target encryption function in a process and instrumenting the target encryption function; monitoring file open operations and initializing the state record of the corresponding file in thread-local storage; intercepting the call to the target encryption function and reading the state record of the corresponding file in thread-local storage; if the state record meets the initial recording condition, extracting the encryption parameters and ciphertext fragments involved in the call to the target encryption function, storing the encryption event containing the encryption parameters and ciphertext fragments, and updating the state record; obtaining the file to be decrypted, extracting the data blocks of the file to be decrypted, and matching the data blocks with the ciphertext fragments in the stored encryption event; when a match is successful, performing a decryption operation on the file to be decrypted based on the encryption parameters in the matched encryption event.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a file decryption method, system, electronic device, and readable storage medium. Background Technology

[0002] Ransomware attacks compromise user devices, encrypt files on those devices, and then demand a ransom from users to decrypt the files, severely damaging user interests.

[0003] Currently, the main methods for recovering from ransomware encryption include: backing up and restoring encrypted files, but this method is difficult to implement, has poor real-time backup capabilities, incurs additional storage space overhead, and the backup may be corrupted. Another method is decryption using ransomware keys leaked online, but this is highly random, has a very low decryption success rate, and cannot be decrypted without the key being leaked.

[0004] The information disclosed in this background section is intended only to enhance the understanding of the overall background of the invention and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention

[0005] The purpose of this invention is to solve the problem of the lack of a universal method for decrypting ransomware encrypted files in the prior art, and to provide a file decryption method, system, electronic device and readable storage medium.

[0006] The first aspect of this invention provides a file decryption method, comprising: obtaining the address of a target encryption function in a process and instrumenting the target encryption function; monitoring file open operations and initializing a state record of the corresponding file in thread-local storage; intercepting the call of the target encryption function and reading the state record of the corresponding file in the thread-local storage; if the state record meets the initial recording condition, extracting the encryption parameters and ciphertext fragments involved in the call of the target encryption function, storing an encryption event containing the encryption parameters and the ciphertext fragments, and updating the state record; obtaining a file to be decrypted, extracting data blocks of the file to be decrypted, and matching the data blocks with the ciphertext fragments in the stored encryption event; when a match is successful, performing a decryption operation on the file to be decrypted based on the encryption parameters in the matched encryption event.

[0007] In one embodiment of the present invention, before obtaining the address of the target encryption function in the process and instrumenting the target encryption function, the method further includes: performing feature retrieval on the target executable file; if code features containing preset encryption behavior are retrieved, then when the target executable file starts the process, a monitoring dynamic library containing instrumentation logic is injected into the process.

[0008] In one embodiment of the present invention, obtaining the address of a target encryption function in a process includes: matching a preset signature in the memory space of the process; obtaining the memory address of the matching position of the preset signature; and determining the address of the target encryption function based on the memory address and a preset offset of the preset signature within the target encryption function.

[0009] In one embodiment of the present invention, the initialization of the state record of the corresponding file in the thread-local storage includes: in response to the file open operation, setting the number of encryption calls to the corresponding file in the thread-local storage of the current thread to an initial value; after reading the state record of the corresponding file in the thread-local storage, the method further includes: if the number of encryption calls to the corresponding file in the thread-local storage is equal to the initial value, then determining that the state record satisfies the first recording condition.

[0010] In one embodiment of the present invention, the step of extracting the encryption parameters and ciphertext fragments involved in the target encryption function call includes: before the target encryption function is executed, extracting the symmetric key, initialization vector, and plaintext data from the function parameters; after the target encryption function is executed, extracting the generated ciphertext data and extracting data of a preset length from the ciphertext data as the ciphertext fragment; storing the symmetric key and the initialization vector as the encryption parameters, and establishing a verification pair using the plaintext data and the ciphertext fragment.

[0011] In one embodiment of the present invention, the step of extracting data blocks from the file to be decrypted and matching the data blocks with the ciphertext fragments in the stored encryption events includes: extracting file attribute features of the file to be decrypted and matching corresponding decryption rules according to the file attribute features; determining the target position of the first encrypted block in the file to be decrypted according to the matched decryption rules and the file attribute features; reading data of a preset length from the target position as the data block; traversing the stored encryption event stream containing each ciphertext fragment, and determining whether the data block is consistent with the ciphertext fragments in the traversed encryption events.

[0012] In one embodiment of the present invention, performing a decryption operation on the file to be decrypted based on the encryption parameters in the matched encryption event includes: determining the overall encryption range and the padding data position in the file to be decrypted according to the matched decryption rules; decrypting the data corresponding to the encryption range using the encryption parameters; and removing the data corresponding to the padding data position.

[0013] A second aspect of the present invention provides a file decryption system, comprising: a monitoring module for acquiring the address of a target encryption function in a process and instrumenting the target encryption function; a first processing module for monitoring file open operations and initializing a state record of the corresponding file in thread-local storage; a second processing module for intercepting the call of the target encryption function and reading the state record of the corresponding file in the thread-local storage; a third processing module for extracting encryption parameters and ciphertext fragments involved in the call of the target encryption function, storing an encryption event containing the encryption parameters and the ciphertext fragments, and updating the state record if the state record meets the initial recording condition; a matching module for acquiring a file to be decrypted, extracting data blocks of the file to be decrypted, and matching the data blocks with the ciphertext fragments in the stored encryption events; and a decryption module for performing a decryption operation on the file to be decrypted based on the encryption parameters in the matched encryption event when a match is successful.

[0014] A third aspect of the present invention provides an electronic device comprising: 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, the instructions being executed by the at least one processor to enable the at least one processor to perform a file decryption method as described in the first aspect.

[0015] A fourth aspect of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the file decryption method as described in the first aspect.

[0016] Compared with the prior art, the technical effects achieved by the present invention are as follows:

[0017] By instrumenting the address of the target encryption function within the process and initializing state records in thread-local storage in conjunction with monitoring file open operations, encryption parameters and ciphertext fragments are extracted to generate encryption events only when the state record meets the initial recording condition during the interception of encryption function calls. This allows for precise identification and interception of only the first segment of encryption behavior after a single file is opened, effectively avoiding the monitoring event storm caused by high-speed full-disk encryption by ransomware and reducing the performance impact of security monitoring on normal system operation. Furthermore, in the post-decryption stage, data blocks of the file to be decrypted are extracted and matched with ciphertext fragments in the stored encryption events. Upon successful matching, decryption is performed based on the corresponding encryption parameters. This ensures that even if the ransomware renames or moves the target file after encryption, the accurate key can still be accurately and reliably retrieved and the file restored. This solves the problem of the lack of a universal method for decrypting ransomware-encrypted files in existing technologies. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating a file decryption method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the framework of a file decryption system according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the frame of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0019] Unless otherwise expressly stated, throughout the specification and claims, the term "comprising" or its variations such as "including" or "comprises" shall be understood to include the stated elements or components without excluding other elements or other components.

[0020] The technical solution of the present invention is illustrated below through specific embodiments. It should be understood that the one or more steps mentioned in the present invention do not preclude the existence of other methods and steps before or after the combined steps, or that other methods and steps may be inserted between these explicitly mentioned steps. It should also be understood that these examples are for illustrative purposes only and are not intended to limit the scope of the present invention. Unless otherwise stated, the numbering of each method step is only for the purpose of identifying each method step, and not for limiting the order of each method or limiting the scope of the present invention. Changes or adjustments to their relative relationships, without substantial changes to the technical content, can also be considered as within the scope of the present invention.

[0021] This embodiment provides a file decryption method, the execution entity of which can be a monitoring dynamic library injected into the address space of the target process by a security protection agent, and a decryption tool software that runs afterward.

[0022] like Figure 1 As shown, the method specifically includes the following steps: S101, Obtain the address of the target encryption function in the process, and instrument the target encryption function; In this embodiment, the target encryption function includes not only standard encryption application programming interface (API) functions provided by the operating system (such as CryptEncrypt and BCryptEncrypt on the Windows platform), but also statically linked encryption library functions integrated within the ransomware.

[0023] In this embodiment, the feature code refers to a binary instruction sequence that can uniquely identify the encryption logic.

[0024] The monitoring module first scans the target process's memory code segment, retrieving signatures using preset feature matching rules, such as the YARA (Yet Another Recursive Acronym) rule. Upon successful matching, it obtains the absolute address of the signature in memory. Since the signature may be located inside a function, it consults a preset offset table and calculates the accurate entry address using the formula "Function Entry Address = Matched Address - Preset Offset". Subsequently, it uses inline hooking technology to insert a jump instruction at the entry address, redirecting the execution flow to a preset stub function.

[0025] It should be noted that the monitoring modules involved in the various embodiments of this invention do not exist as independent native operating system processes in terms of physical architecture, but are compiled and configured as a form of dynamically linked code. For example, a .dll file in a Windows operating system environment, or a .so file in a Linux environment.

[0026] S102, monitor file open operations and initialize the corresponding file status record in thread-local storage; In this embodiment, a state record refers to a logical structure stored in thread-local storage (TLS) used to track the encryption behavior of a specific file within the current thread.

[0027] The monitoring module intercepts the system's file operation APIs at the underlying level to obtain file handles. When ransomware attempts to open a file to be encrypted, the monitoring module intercepts the request and obtains the file handle. Subsequently, it creates a mapping table in the current worker thread's thread-local storage (TLS) space, using the file handle as the key, and initializes the corresponding encryption call count to an initial value, such as the integer 0 or a null value.

[0028] By leveraging the features of TLS, it is possible to ensure that the state records of multi-threaded ransomware do not interfere with each other when processing different files concurrently, thus achieving precise monitoring at the thread level.

[0029] S103, intercept the call to the target encryption function and read the status record of the corresponding file in the thread local storage; When the ransomware reads file data and calls the target encryption function to prepare for conversion, the execution flow is hijacked to the stub function of the monitoring module. The stub function obtains the ID of the current thread by calling the function, accesses its associated TLS zone, retrieves the status record of the corresponding file established in step S102 above, and reads the current number of encryption calls.

[0030] S104, if the status record meets the first recording condition, then extract the encryption parameters and ciphertext fragments, store the encryption event, and update the status record; In this embodiment, the first recording condition refers to determining whether the current encryption action is the first data transformation of the file after it has been opened. In practical applications, whether the file is undergoing its first data transformation after being opened is determined by whether the number of encryption calls in TLS equals the initial value of 0.

[0031] In one example, before the encryption function actually executes, the stub function retrieves the symmetric key (Key), initialization vector (IV), and plaintext data to be encrypted from a register or stack and caches them securely. Then, the original encryption function is allowed to execute, and upon function return, the generated ciphertext data is intercepted, and the first 16 bytes of this ciphertext data are extracted as a ciphertext fragment. To reduce storage overhead, only the first 16 bytes of the ciphertext data are extracted as a ciphertext fragment. The Key, IV, plaintext-ciphertext checksum, and 16-byte ciphertext fragment are encapsulated as an encryption event and stored in a local database. The call count in TLS is atomically incremented (e.g., updated to 1).

[0032] Subsequently, if the ransomware repeatedly executes subsequent encryption calls on the same file, the stub function will silently allow the ransomware to pass through when it checks the TLS and finds that the number of calls is greater than 0, thus avoiding the performance loss caused by a large number of monitoring events for the same large file.

[0033] S105, obtain the file to be decrypted, extract the data block of the file to be decrypted, and match the data block with the ciphertext fragment in the stored encryption event.

[0034] During the decryption phase, the decryption tool employs a path-independent blind matching strategy. The file header of the file to be decrypted, after encryption, may have been renamed by the ransomware, such as changing the suffix to .locked. In this embodiment, the decryption tool opens the file to be decrypted in binary read-only mode and extracts the 16 bytes of data from the file header corresponding to the offset position in the interception phase as a feature data block. Subsequently, the decryption tool traverses all stored encryption events in a streaming parsing manner, calling underlying memory comparison instructions to perform a rigorous binary byte-by-byte comparison of this feature data block with the ciphertext fragments in the encryption event library.

[0035] S106, When a match is successful, perform a decryption operation on the file to be decrypted based on the encryption parameters in the matched encryption event.

[0036] If a match is found, it means the unique key corresponding to the encryption of the file has been found. The decryption tool retrieves the corresponding key and IV, and combines them with preset decryption rules, such as the AES-128-CBC decryption logic for the WannaCry (worm-like ransomware) family, to restore the file. Data is recovered using the encryption step size determined by the decryption rules, and the length of any extra padding data added by the ransomware is calculated and removed according to the rules, ultimately achieving a complete file recovery.

[0037] Through the embodiments of this invention, the address of the target encryption function in the process is obtained for instrumentation, and a state record is initialized in the thread-local storage in conjunction with monitoring file open operations. When intercepting encryption function calls, encryption parameters and ciphertext fragments are extracted to generate encryption events only when the state record meets the first recording condition. This can accurately identify and intercept only the first segment of encryption behavior after a single file is opened, effectively avoiding the monitoring event storm caused by high-speed full-disk encryption by ransomware, and reducing the performance loss of security monitoring on the normal operation of the system. Furthermore, in the post-decryption stage, the data blocks of the file to be decrypted are extracted and matched with the ciphertext fragments in the stored encryption events. When the match is successful, the decryption operation is performed based on the corresponding encryption parameters. This ensures that even if the ransomware renames or moves the target file after encryption, the accurate key can still be accurately and reliably retrieved and the file restored. This solves the problem of the lack of a universal method to decrypt ransomware-encrypted files in the prior art.

[0038] In some optional embodiments, before performing step S101 (obtaining the address of the target encryption function in the process and instrumenting it), a pre-monitoring and guidance process is also included, which may specifically include the following steps: S201, Perform feature retrieval on the target executable file.

[0039] In this embodiment, a preliminary security screening is performed on program files that are about to run or have just run. The target executable file refers to a program file that attempts to request memory and allocate process control blocks in the operating system (such as .exe or .dll files in Windows, or ELF files in Linux). Feature retrieval refers to the process of scanning the binary code segment, constant area, or import table of the file using a pattern matching algorithm.

[0040] In real-world applications, when an operating system attempts to launch a target executable file, a security daemon (Agent) deployed on the host machine intercepts the launch process and invokes a built-in rule engine (such as the YARA engine) to scan the file's binary code segment or import table. It determines whether the file exhibits suspicious encryption behavior characteristics; for example, it checks whether the code segment contains initialization constants specific to common encryption algorithms, specific bit manipulation instruction sequences, or whether the import table contains a high-density aggregation of underlying system encryption APIs.

[0041] S202, if the target executable file is found to contain suspicious encryption behavior characteristics, then when the target executable file starts its process, a monitoring dynamic library containing instrumentation logic is injected into the process.

[0042] The monitoring dynamic library in this embodiment contains instrumentation logic, which encapsulates the core code for finding the address of encrypted functions, executing inline hooks, and operating thread-local storage (TLS).

[0043] If the rule engine returns a match result, the process is suspended, memory is allocated in its virtual address space, and the target process is forced to load the monitoring dynamic library containing the core code for instrumentation and state filtering by creating a remote thread. After the monitoring dynamic library is loaded, it automatically initializes, thereby initiating subsequent function instrumentation and monitoring actions within the process.

[0044] Specifically, the Agent writes the path to the monitoring dynamic library into the aforementioned allocated memory space, and forces the target process to load the monitoring dynamic library by creating a remote thread or inserting an asynchronous procedure call. After the monitoring dynamic library is successfully loaded, it executes the initialization function, thereby obtaining the highest execution privilege within the process, and then spontaneously starts the subsequent S101 instrumentation action and the S102 state machine initialization action.

[0045] In the above embodiments, feature retrieval in the early stage is used as a pre-filter to perform intrusive dynamic library injection and instrumentation only on high-risk target processes, thereby ensuring system data security while maintaining the native running performance of the operating system to the greatest extent.

[0046] In some optional embodiments, step S101 above may specifically include the following steps: S301, match the preset signature in the process's memory space; In this embodiment, the preset signature code usually refers to a unique binary machine instruction sequence or a specific encryption algorithm initialization constant extracted during reverse engineering analysis of historical ransomware samples. The encryption algorithm initialization constant includes, but is not limited to, the iconic S-box data structure in the AES algorithm and a specific magic number in the ChaCha20 algorithm (streaming symmetric encryption algorithm).

[0047] In one example, after the target process starts and maps its code segment into physical memory, the monitoring module starts a lightweight pattern matching engine (such as an embedded YARA rule engine) in the process's virtual address space (especially the code segment with execution privileges). This engine uses a signature rule tree extracted in advance based on reverse analysis of historical ransomware samples to perform a sliding window binary comparison of the memory data stream. Once a continuous byte stream matches the hash value or mask of the signature rule, it is determined that a fragment of the target encrypted function body has been found.

[0048] S302, Obtain the memory address of the preset feature code matching position; When the matching engine reports a hit, the monitoring module captures the current memory cursor position where the hit point is located as the feature base address. It should be noted that since the preset feature code with extremely high distinguishability is usually located in the middle of the execution logic of the encryption function (such as inside the core round encryption loop), the memory address obtained at this time is only the local starting address of the feature instruction, rather than the actual starting entry address (function header) of the encryption function.

[0049] S303: Calculate the address of the target encryption function based on the memory address and the preset offset of the preset signature within the target encryption function.

[0050] In this embodiment, the preset offset refers to the byte distance between the characteristic instruction sequence and its corresponding function entry point (i.e., the function prologue at the assembly level, such as push rbp; mov rbp,rsp) measured by security experts during prior analysis of the sample.

[0051] Specifically, the monitoring module retrieves the preset offset value bound to the hit feature code, and calculates the entry base address of the target encryption function by subtracting the preset offset from the matched memory address and performing relative address-based operations.

[0052] Then, after calculating the base address of the target encryption function's entry point, this address is converted into an operable function pointer. To ensure the absolute accuracy of the calculation (preventing offset misalignment due to code obfuscation), a disassembly verification is performed at the calculated entry point to confirm whether it is a valid function prologue instruction.

[0053] Once confirmed, the monitoring module can overwrite the jumper command at the precisely located entry address to implement inline instrumentation.

[0054] The above embodiments overcome the obstacle of static link libraries having no sign table for reference, while ensuring that instrumentation operations strictly occur at the function header, thereby guaranteeing the integrity and balance of the memory stack during subsequent extraction of encrypted parameters.

[0055] In some optional embodiments, step S102 may specifically include: S401, in response to the file open operation, the number of encrypted calls to the file in the thread-local storage of the current thread is set to the initial value.

[0056] In practical applications, Thread-Local Storage (TLS) is a mechanism provided by the operating system that allows multiple threads within the same process to have private copies of global variables.

[0057] The monitoring module listens to the operating system's file system I / O interfaces at a low level (such as ZwCreateFile in the Windows kernel layer or CreateFileW in the user layer). When a worker thread of the ransomware attempts to open a victim file, the monitoring module captures the operation and obtains the file handle returned by the operating system.

[0058] Subsequently, the TLS space of the currently executing thread is accessed, and a mapping structure is established using the file handle or file object ID as the key. A state counter named "encryption call count" is initialized within this mapping structure and forcibly initialized to a preset value (e.g., the integer 0). Thus, the lifecycle state of the file is precisely bound to the specific thread currently processing it at the context level.

[0059] After reading the status record of the corresponding file in the thread-local storage, the process also includes, but is not limited to: if the number of encryption calls to the corresponding file in the thread-local storage is equal to the initial value, then it is determined that the status record meets the conditions for the first recording.

[0060] Specifically, after intercepting the target encryption function call, it is determined whether the number of encryption calls corresponding to the file in the thread-local storage is equal to the initial value.

[0061] When the ransomware reads a piece of file data and calls the target encryption function to prepare for encryption conversion, the execution flow is hijacked to the stub function of the monitoring module. The stub function examines the cached state mapping table in the current thread's TLS by calling the API, and finds the number of encryption calls corresponding to the file handle currently being processed.

[0062] If the value is determined to be equal to the initial value (i.e., equal to 0), it indicates that this is the first time the ransomware has performed an encryption action on the data block of the file after opening it. At this point, the initial recording condition is met, and the parameter extraction logic is initiated, which involves capturing the key, IV, and the first 16 bytes of plaintext and ciphertext, generating and persisting the encryption event.

[0063] After the above actions are completed, immediately perform an atomic increment operation on the counter in TLS, for example, update it to 1.

[0064] If ransomware executes the encryption call a second or more times on the same file, the stub function will find that the counter is no longer equal to the initial value when querying TLS. This indicates that the decryption key and verification fingerprint required for the file were successfully intercepted during the first call, and recording them again is invalid and redundant, so there is no need to record them again. At this point, all parameter extraction and event storage logic is skipped, and the encryption call is silently allowed with a very short clock cycle instruction, allowing it to be executed by the system's native code.

[0065] In some optional embodiments, the extraction of encryption parameters and ciphertext fragments involved in the target encryption function call in step S104 above may specifically include the following steps: S501: Before the target encryption function is executed, extract the symmetric key, initialization vector, and plaintext data from the function parameters; In this embodiment, in the underlying calling convention of the operating system, when a function is called, its parameters are pushed into the CPU register or thread stack in a specific order.

[0066] Specifically, when the ransomware execution flow first jumps into the monitoring module's stub function, the original target encryption function has not yet been executed. At this time, the stub function directly reads the corresponding CPU register or memory pointer based on the parameter distribution rules obtained through reverse analysis of the target encryption function, locating the core cryptographic parameters that will soon participate in the computation.

[0067] Then, from the corresponding memory address, the symmetric key (Key), the initialization vector (IV), and a copy of the original plaintext data to be encrypted are copied to the current thread's protected independent buffer for temporary storage.

[0068] S502, after the target encryption function is executed, extract the generated ciphertext data and extract data of a preset length from the ciphertext data as a ciphertext fragment; Specifically, before the original encryption function finishes execution and returns to the caller, the monitoring module intercepts the execution flow again. At this point, the plaintext in the original memory buffer has usually been encrypted in place and converted into ciphertext. The stub function then reads the buffer again to obtain the ciphertext data.

[0069] To avoid the extremely high memory overhead caused by recording all ciphertext and the potential user privacy compliance issues, the monitoring module extracts a preset length of binary data (usually the size of a standard encrypted block, such as 16 bytes) from the header of the ciphertext data block and defines it as a ciphertext fragment.

[0070] S503 stores the symmetric key and initialization vector as encryption parameters and establishes a checksum using plaintext data and ciphertext fragments.

[0071] In this embodiment, a check pair is a data structure used for cryptographic result verification in an offline state, which includes the known original plaintext and its corresponding incomplete ciphertext after being encrypted by a specific key.

[0072] The 16 bytes of plaintext data temporarily stored beforehand are strongly associated with and bound to the 16 bytes of ciphertext data extracted afterward, forming a one-to-one "plaintext-ciphertext" verification data structure, which is then serialized and encapsulated into the final encrypted event log.

[0073] The establishment of this checksum provides a solid offline mathematical proof for subsequent decryption. During the decryption phase, when the decryption tool obtains the key extracted from a file and attempts to decrypt it, it will first perform a trial decryption on the ciphertext in the file header. If the plaintext obtained from the trial decryption is completely consistent with the plaintext hash value or byte order in the checksum recorded in the event log, the accuracy of the key is mathematically confirmed, thus avoiding secondary file corruption caused by blind decryption.

[0074] In some optional embodiments, step S105 above may specifically include the following steps: S601, extract the file attribute features of the file to be decrypted, and match the corresponding decryption rules according to the file attribute features; In this embodiment, file attribute features refer to static metadata that can reflect traces of ransomware tampering with the file. For example, it can be the file extension (such as .locked, .WannaCry, or random character extension), the total byte size of the file in the storage medium, or the specific signature code Magic Bytes located at the beginning and end of the file.

[0075] The decryption tool obtains these characteristics by calling the operating system's file system API and inputs them into a preset rule matching engine. This rule matching engine internally maintains a feature fingerprint database of multiple ransomware families. Through fuzzy matching or regular expressions, it compares the extracted attribute features with the fingerprint database to determine the ransomware family to which the file belongs and loads the corresponding decryption rule object.

[0076] S602, based on the matching decryption rules and file attribute characteristics, determine the target location of the first encrypted block in the file to be decrypted; The decryption rules in this embodiment are a set of algorithms that include the destruction logic of a specific ransomware family, the encryption offset calculation formula, and the padding distribution pattern. Different ransomware viruses often employ differentiated encryption strategies to balance encryption efficiency and destructive strength. For example, some families may skip the first 1024 bytes of a file to avoid critical system data, or dynamically calculate the encryption step size based on the file size.

[0077] The decryption tool, based on the loaded decryption rules and combined with the file attribute characteristics, executes the corresponding offset calculation function to calculate the physical starting offset of the first ciphertext block generated when the ransomware family encrypts the specific file, and thus determines the target position of the first encrypted block in the file to be decrypted.

[0078] S603, read data of a preset length from the target location as a data block; In this embodiment, the data block is a ciphertext sequence of the unique identity fingerprint of the file to be decrypted.

[0079] The decryption tool uses standard file stream I / O interfaces, such as ifstream in C++ or the ReadFile function in the Windows API, to precisely position the file pointer at the offset address determined in step S602 above, and then reads the binary data according to a preset length.

[0080] In this embodiment, the preset length typically corresponds to the smallest processing unit block of the underlying encryption algorithm, such as the 16-byte standard block in the Advanced Encryption Standard (AES) algorithm, or the 128-bit packet length of the SMS4 algorithm commonly used in wireless LAN standards. After reading, the data segment is temporarily stored in the memory cache.

[0081] S604, traverse the stored encrypted event stream containing each ciphertext fragment, and determine whether the data block is consistent with the ciphertext fragment in the traversed encrypted event.

[0082] In this embodiment, the encrypted event stream refers to the sequence of data records that are intercepted in real time and persistently stored in a local database or structured log file through instrumentation technology during the pre-interception phase. Each record typically contains process information of the encryption process, the corresponding symmetric key, the initialization vector, and the first ciphertext fragment generated by the operation.

[0083] The decryption tool retrieves these records using a streaming parsing method, performing a byte-by-byte memory comparison between the data blocks extracted in step S603 and the ciphertext fragments in the records. Based on cryptographic principles, when two ciphertext sequences are completely identical at a specific offset, it can be confirmed that the key and initialization vector in the current record are the only legitimate parameters required to decrypt the file.

[0084] If the comparison results are inconsistent, continue reading the next event in the encrypted event stream for comparison.

[0085] If the comparison result is a complete match, a hit signal is logically triggered to determine that the symmetric key (Key) and initialization vector (IV) recorded in the current event are the exact parameters used by the ransomware to encrypt this part of the data.

[0086] Upon a successful hit, the event traversal of the file is stopped, and the encryption time, encryption algorithm, key, IV, and checksum information associated with the file are output and passed to the subsequent decryption execution module.

[0087] In some optional embodiments, step S106 above may specifically include the following steps: S701, based on the matching decryption rules, determine the overall encryption range and the location of the padding data in the file to be decrypted; After confirming a match in the encryption parameters, the decryption tool first determines the overall encryption range and padding data positions in the file to be decrypted based on the matching decryption rules. The overall encryption range refers to the actual physical interval within which the ransomware performs encryption on the original file; specifically, it is represented by a set of data pairs containing a starting offset and the encryption length. In this embodiment, the instantiated decryption rule object, based on the known underlying destruction logic of the ransomware family and the total size of the current file, deduces the physical offset and specific length of one or more actual encrypted data blocks within the file, which serve as the encryption range.

[0088] Because ransomware aims for rapid destruction, it often avoids full encryption, instead employing block encryption or intermittent encryption strategies. For example, it might encrypt only the first 4KB of data in a file, or encrypt 64KB at 1MB intervals. Decryption tools, by analyzing the step size and logic defined in the decryption rules, can precisely determine which sections of the file are ciphertext that must be decrypted and which sections are the original plaintext that are skipped.

[0089] S702 decrypts the data corresponding to the encrypted range using the encryption parameters and removes the data corresponding to the padding data position.

[0090] Determining the location of padding data is crucial for achieving full recovery of compromised files. Padding data refers to non-original data appended to the original file structure by ransomware after encryption to identify the victim's status or store metadata. Examples include encrypted identifiers (such as specific hexadecimal strings) appended to the end of the file, the encrypted original filename, ransom notes, or random padding bytes generated to align encrypted blocks.

[0091] The decryption tool locates the start and end points of this extra data by using the family destruction patterns recorded in the decryption rules. This precise location of the unnecessary payload provides accurate address references for subsequent "physical stripping" operations, preventing the decrypted file from containing redundant suffix data that could cause applications to fail to open it or MD5 verification to fail.

[0092] During the decryption process, the decryption tool decrypts the data corresponding to the entire encrypted range using the encryption parameters and removes the data corresponding to the padding positions. The encryption parameters include the previously matched symmetric key and initialization vector (IV).

[0093] The decryption tool invokes cryptographic operators corresponding to the ransomware family, such as an AES-CBC decryptor or a Salsa20 stream decryption module, to perform in-situ restoration for each defined encrypted segment. The decrypted plaintext data is written back to the corresponding offset in the file, overwriting the original ciphertext.

[0094] Subsequently, the decryption tool uses the operating system's file stream manipulation instructions, such as the file truncation function (Truncate), to physically delete the identified padding data range.

[0095] Through the above embodiments, the decryption tool not only completed the cryptographic reversal at the data level, but also repaired the logical length and physical boundaries of the file by stripping the padding, ultimately restoring the damaged file to its original state before the ransomware attack.

[0096] Another embodiment of the present invention relates to a file decryption system, such as Figure 2 As shown, the system may specifically include: The monitoring module 20 is used to obtain the address of the target encryption function in the process and to instrument the target encryption function; The first processing module 21 is used to monitor file open operations and initialize the status record of the corresponding file in the thread-local storage; The second processing module 22 is used to intercept the call to the target encryption function and read the status record of the corresponding file in the thread local storage; The third processing module 23 is further configured to, if the state record meets the first recording condition, extract the encryption parameters and ciphertext fragments involved in the target encryption function call, store the encryption event containing the encryption parameters and the ciphertext fragments, and update the state record; Matching module 24 is used to obtain the file to be decrypted, extract the data block of the file to be decrypted, and match the data block with the ciphertext fragment in the stored encryption event; The decryption module 25 is used to perform a decryption operation on the file to be decrypted based on the encryption parameters in the matched encryption event when a match is successful.

[0097] Optionally, in this embodiment, it further includes: The retrieval module is used to perform feature retrieval on the target executable file before obtaining the address of the target encryption function in the acquisition process and instrumenting the target encryption function; The dynamic injection module is used to inject a monitoring dynamic library containing instrumentation logic into the process when the target executable file starts its process if code features containing preset encryption behavior are retrieved.

[0098] Optionally, in this embodiment, the monitoring module 20 includes: The feature matching submodule is used to match preset feature codes in the memory space of the process; The base address acquisition submodule is used to acquire the memory address of the preset feature code matching position; The address calculation submodule is used to determine the address of the target encryption function based on the memory address and the preset offset of the preset feature code within the target encryption function.

[0099] Optionally, in this embodiment, the first processing module 21 includes: The event response submodule is used to respond to the file open operation by setting the number of encrypted calls for the corresponding file in the thread-local storage of the current thread to an initial value; Optionally, in this embodiment, it further includes: a state evaluation module, used to determine if the state record satisfies the first recording condition before extracting the encryption parameters and ciphertext fragments involved in the target encryption function call, if the number of encryption calls corresponding to the file in the thread local storage is equal to the initial value.

[0100] Optionally, in this embodiment, the third processing module 23 includes: The pre-acquisition submodule is used to extract the symmetric key, initialization vector, and plaintext data from the function parameters before the target encryption function is executed; The post-intercepting submodule is used to extract the generated ciphertext data after the target encryption function is executed, and to extract data of a preset length from the ciphertext data as the ciphertext fragment; An encapsulation and storage submodule is used to store the symmetric key and the initialization vector as encryption parameters, and to establish a checksum using the plaintext data and the ciphertext fragment.

[0101] Optionally, in this embodiment, the matching module 24 includes: The header reading submodule is used to read the header data of the file to be decrypted; The data block extraction submodule is used to extract data of a preset length from the file header data as the data block; The streaming comparison submodule is used to traverse the stored encrypted event stream containing each of the ciphertext fragments and determine whether the data block is consistent with the ciphertext fragment in the traversed encrypted event.

[0102] Optionally, in this embodiment, the decryption module 25 includes: The attribute acquisition submodule is used to extract the file attribute features of the file to be decrypted; The rule matching submodule is used to match the corresponding decryption rules based on the file attribute features; The range definition submodule is used to determine the encryption range and padding data position in the file to be decrypted according to the decryption rules. The decryption submodule is used to decrypt the data corresponding to the encryption range using the encryption parameters, and remove the data corresponding to the padding data position.

[0103] Another embodiment of the present invention relates to an electronic device, such as Figure 3 As shown, it includes: at least one processor 301; and a memory 302 communicatively connected to the at least one processor 301; wherein the memory 302 stores instructions executable by the at least one processor 301, the instructions being executed by the at least one processor 301 to enable the at least one processor 301 to perform the file decryption methods in the above embodiments.

[0104] The memory and processor are connected via a bus, which can include any number of interconnecting buses and bridges, connecting various circuits of one or more processors and memories. The bus can also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and will not be described further herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by the processor is transmitted over the wireless medium via an antenna, which further receives data and transmits it to the processor.

[0105] The processor manages the bus and general processing, and also provides various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory is used to store data used by the processor during operation.

[0106] Another embodiment of the present invention relates to a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the method embodiments described above.

[0107] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0108] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0109] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0110] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A file decryption method, characterized in that, include: Obtain the address of the target encryption function in the process, and instrument the target encryption function; Monitor file open operations and initialize the corresponding file status records in thread-local storage; Intercept the call to the target encryption function and read the state record of the corresponding file in the thread-local storage; If the state record meets the initial recording condition, then the encryption parameters and ciphertext fragments involved in the target encryption function call are extracted, the encryption event containing the encryption parameters and the ciphertext fragments is stored, and the state record is updated. Obtain the file to be decrypted, extract the data block of the file to be decrypted, and match the data block with the ciphertext fragment in the stored encryption event; When a match is successful, the file to be decrypted is decrypted based on the encryption parameters in the matched encryption event.

2. The method according to claim 1, characterized in that, Before obtaining the address of the target encryption function in the process and instrumenting the target encryption function, the method further includes: Perform feature retrieval on the target executable file; If code features containing preset encryption behavior are found, a monitoring dynamic library containing instrumentation logic is injected into the process when the target executable file starts its process.

3. The method according to claim 1, characterized in that, The step of obtaining the address of the target encryption function in the process includes: Match a preset signature in the memory space of the process; Obtain the memory address of the preset feature code matching position; The address of the target encryption function is determined based on the memory address and the preset offset of the preset feature code within the target encryption function.

4. The method according to claim 1, characterized in that, The initialization of the corresponding file's state record in thread-local storage includes: In response to the file open operation, the number of encryption calls for the corresponding file in the thread-local storage of the current thread is set to an initial value; After reading the status record of the corresponding file in the thread-local storage, the method further includes: If the number of encryption calls to the file in the thread-local storage is equal to the initial value, then it is determined that the state record meets the first recording condition.

5. The method according to claim 1, characterized in that, The extraction of encryption parameters and ciphertext fragments involved in the target encryption function call includes: Before the target encryption function is executed, the symmetric key, initialization vector, and plaintext data are extracted from the function parameters. After the target encryption function is executed, the generated ciphertext data is extracted, and data of a preset length is extracted from the ciphertext data as the ciphertext segment; The symmetric key and the initialization vector are stored as encryption parameters, and a checksum is established using the plaintext data and the ciphertext fragment.

6. The method according to claim 1, characterized in that, The step of extracting data blocks from the file to be decrypted and matching the data blocks with the ciphertext fragments in the stored encryption event includes: Extract the file attribute features of the file to be decrypted, and match the corresponding decryption rules based on the file attribute features; Based on the matching decryption rules and file attribute characteristics, determine the target position of the first encrypted block in the file to be decrypted; Read data of a preset length from the target location as the data block; Traverse the stored encrypted event stream containing each of the ciphertext fragments, and determine whether the data block is consistent with the ciphertext fragment in the traversed encrypted event.

7. The method according to claim 6, characterized in that, The process of performing a decryption operation on the file to be decrypted based on the encryption parameters in the matched encryption event includes: Based on the matching decryption rules, determine the overall encryption range and the location of the padding data in the file to be decrypted; The data corresponding to the encrypted range is decrypted using the encryption parameters, and the data corresponding to the filling data position is removed.

8. A file decryption system, characterized in that, include: The monitoring module is used to obtain the address of the target encryption function in the process and to instrument the target encryption function. The first processing module is used to monitor file open operations and initialize the status records of the corresponding files in the thread-local storage. The second processing module is used to intercept the call to the target encryption function and read the status record of the corresponding file in the thread local storage; The third processing module is further configured to, if the state record meets the initial recording condition, extract the encryption parameters and ciphertext fragments involved in the target encryption function call, store the encryption event containing the encryption parameters and the ciphertext fragments, and update the state record; The matching module is used to obtain the file to be decrypted, extract the data block of the file to be decrypted, and match the data block with the ciphertext fragment in the stored encryption event; The decryption module is used to perform a decryption operation on the file to be decrypted based on the encryption parameters in the matched encryption event when a match is successful.

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 file decryption method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the file decryption method according to any one of claims 1 to 7.

Images