File decompilation method and electronic device

Abstract

The application discloses a file unshelling method and electronic equipment, and relates to the technical field of computer security, and comprises the following steps: inserting a probe at a target system call of a kernel, and injecting the probe into a target program; identifying a suspiciously shelled process through the target program; monitoring a memory permission change behavior performed by the suspiciously shelled process through the target program, and counting a permission change frequency of a memory region, an entropy value of the memory region and a call chain depth; when it is confirmed that the suspiciously shelled process is in an unshelling stage according to the permission change frequency, the entropy value and the call chain depth, writing data decrypted by the suspiciously shelled process into a target buffer through the target program; reading the data from the target buffer in a user mode, and recombining the data into a memory image according to a base address and a dirty page bitmap and writing the memory image back to a file. The method can avoid I / O bottlenecks caused by full memory dumping, reduce invalid data in the user mode, and reduce CPU occupation and memory bandwidth.

Description

Technical Field

[0001] This invention relates to the field of computer security technology, and in particular to a file unpacking method and electronic device. Background Technology

[0002] Virus file packing is a technique that uses compression, encryption, or obfuscation to evade static detection of malicious code. The packed virus file is dynamically decrypted and executes its original code at runtime. Virus file unpacking refers to removing the "shell" used to "hide" the virus file, restoring its original, analyzable code. Related techniques for file unpacking suffer from drawbacks such as high resource consumption and I / O bottlenecks. Therefore, addressing these technical shortcomings has become a pressing technical problem for those skilled in the art. Summary of the Invention

[0003] This invention provides a file unpacking method and an electronic device to at least solve the problems of high resource consumption and I / O bottlenecks in related technologies.

[0004] This invention provides a method for unpacking files, comprising:

[0005] Insert a probe at the target system call location in the kernel and inject the target program into the probe;

[0006] The target program is used to identify suspicious packed processes;

[0007] The target program monitors the memory permission change behavior of the suspicious packed process, and counts the frequency of permission changes in the memory region, the entropy value of the memory region, and the call chain depth.

[0008] When the suspicious packed process is confirmed to be in the unpacking stage based on the permission change frequency, the entropy value, and the call chain depth, the data decrypted by the suspicious packed process is written into the target buffer by the target program.

[0009] The user reads the data from the target buffer, reassembles the data into a memory image based on the base address and dirty page bitmap, and writes it back to the file.

[0010] The present invention also provides a document unpacking device, comprising:

[0011] An instrumentation module is used to instrument probes at target system calls in the kernel and inject target programs into the probes;

[0012] The identification module is used to identify suspicious packed processes through the target program;

[0013] The monitoring module is used to monitor the memory permission change behavior of the suspicious packed process through the target program, and to count the frequency of permission changes in the memory region, the entropy value of the memory region, and the call chain depth.

[0014] The writing module is used to write the data decrypted by the suspicious packed process into the target buffer through the target program when the suspicious packed process is determined to be in the unpacking stage based on the permission change frequency, the entropy value and the call chain depth.

[0015] The reassembly module is used to read the data from the target buffer in user space, reassemble the data into a memory image based on the base address and the dirty page bitmap, and write it back to the file.

[0016] The present invention also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described file unpacking methods when executing the computer program.

[0017] The present invention also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described file unpacking methods.

[0018] The present invention also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of any of the above-described file unpacking methods.

[0019] The beneficial effects are as follows: The file unpacking method provided by this invention inserts a probe at the target system call in the kernel and injects it into the target program. The target program then performs operations such as identifying suspicious packed processes and dumping data. The target program runs in the kernel and does not require modification of user-space memory. The target program performs process filtering, identifies suspicious packed processes, and dumps only the data decrypted by the suspicious packed processes. This avoids the I / O bottleneck caused by full memory dumping, reduces invalid user-space data, and lowers CPU usage and memory bandwidth. Attached Figure Description

[0020] To more clearly illustrate the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating a file unpacking method provided in an embodiment of the present invention;

[0022] Figure 2 This is a schematic diagram of a process for determining the shelling stage according to an embodiment of the present invention;

[0023] Figure 3 This is a schematic diagram of a specific file unpacking process provided in an embodiment of the present invention;

[0024] Figure 4 A schematic diagram of a system structure provided in an embodiment of the present invention;

[0025] Figure 5 This is a schematic diagram of a document unpacking device provided in an embodiment of the present invention;

[0026] Figure 6 This is a schematic diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0027] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of the present invention.

[0028] It should be noted that, in the description of this invention, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., used in this invention are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0029] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0030] The embodiments of the present invention provide a file unpacking method. The execution flow of the file unpacking method is described in detail below.

[0031] refer to Figure 1 As shown, an embodiment of the present invention provides a file unpacking method including:

[0032] S101: Insert a probe at the target system call location in the kernel and inject the target program into the probe;

[0033] S102: Identify suspicious packed processes through the target program;

[0034] S103: Monitor the memory permission change behavior of the suspicious packed process through the target program, and count the frequency of permission changes in the memory region, the entropy value of the memory region, and the call chain depth;

[0035] S104: When the suspicious packed process is determined to be in the unpacking stage based on the permission change frequency, the entropy value and the call chain depth, the data decrypted by the suspicious packed process is written into the target buffer by the target program.

[0036] S105: Read the data from the target buffer in user space, reassemble the data into a memory image based on the base address and dirty page bitmap, and write it back to the file.

[0037] The kernel refers to the operating system kernel. The operating system kernel is the most core and fundamental part of the operating system, responsible for managing computer hardware resources and providing basic services to upper-level applications. The main functions of the kernel include: Process management: controlling the creation, scheduling, and termination of processes, determining which process uses the CPU and for how long. Memory management: managing the system's memory resources, including allocating and reclaiming memory, ensuring memory isolation and safety between different processes. File system management: providing access interfaces to storage devices (such as hard drives and SSDs), managing file creation, reading, writing, and deletion operations. Device driver management: controlling and managing hardware devices (such as keyboards, mice, monitors, network cards, etc.), communicating with the hardware through drivers. System call interface: providing a unified interface for applications to access hardware and system resources, shielding them from underlying hardware differences. Target system calls refer to the selected system calls used to set probes. Target system calls can include execve, mmap, mprotect, etc. The function of execve is to replace the image of the current process with a new program (i.e., the code, data, stack, etc., executed by the current process will be replaced by the new program). `mmap` maps files or anonymous memory into a process's virtual address space, used for dynamic memory allocation and loading shared libraries. `mprotect` modifies access permissions of mapped memory regions (e.g., read-only, executable, inaccessible), and handles file mappings.

[0038] Probes are inserted at the target system call locations in the kernel. The purpose of inserting probes is to dynamically inject programs at the probe locations without modifying the kernel source code or restarting the system, thereby safely and efficiently observing kernel behavior.

[0039] Based on the probe insertion, the target program is injected into the probe. The target program is responsible for identifying suspicious packed processes, monitoring the memory permission change behavior of the suspicious packed processes, and statistically analyzing the permission change frequency, entropy value, and call chain depth of memory regions. Based on the permission change frequency, entropy value, and call chain depth, it determines whether the suspicious packed process is in the unpacking stage. When it is determined that the suspicious packed process is in the unpacking stage, it performs a dump on the data decrypted by the suspicious packed process.

[0040] In some embodiments, the probe injection target procedure includes:

[0041] The probe is injected into the extended Berkeley packet filter program.

[0042] In this embodiment, the target program is an eBPF (extended Berkeley Packet Filter) program. The eBPF program runs in kernel space, does not modify user-space memory, does not trigger common detection logic such as ptrace, frida, and xposed, requires no ptrace attachment, and does not trigger SIGTRAP or SIGSTOP, nor modify TracerPid. Therefore, it can bypass JNI anti-debugging, anti-ptrace, and anti-injection shell strategies.

[0043] Based on the probe injection into the target program, suspicious packed processes are identified through the target program.

[0044] In some embodiments, identifying suspicious packed processes through the target program includes:

[0045] The target program monitors process creation behavior.

[0046] Read the header of the entity file of the newly created process;

[0047] Determine whether the file header contains a magic number feature;

[0048] If the file header contains magic number characteristics, the newly created process is a suspicious packed process.

[0049] The target program monitors the execve creation process.

[0050] For example: `bpftrace -e 'tracepoint:syscalls:sys_enter_execve { printf("PID%d executed: %s\n", pid, str(args->filename));}`. This code indicates that all processes are tracking the execution of the `execve` system call in real time, and prints the PID of the process executing the new program and its corresponding executable file path.

[0051] For all newly created processes, read the file header (ELF) of the new process's entity file and identify magic number characteristics in the header. For example, identify features such as "UPX!" or VMProtect. If the file header contains magic number characteristics, the newly created process is a suspected packed process. In other words, if the new process's header is an ELF and contains magic number characteristics, the new process is a suspected packed process. Add this suspected packed process to the process tracking map to avoid unnecessary calculations on ordinary processes. Record the process PID, path, and parameters for context association in subsequent mmap / mprotect events.

[0052] You can use kprobe / sys_mprotect to monitor the memory permission change behavior of suspicious packed processes. Based on the frequency of memory permission changes, entropy changes, and call chain depth, you can determine in real time whether it is the unpacking stage.

[0053] In some embodiments, determining whether a suspicious packed process is in the unpacking stage based on the permission change frequency, the entropy value, and the call chain depth includes:

[0054] Determine whether the frequency of permission changes meets the first preset condition;

[0055] Determine whether the entropy value satisfies the second preset condition;

[0056] Determine whether the depth of the call chain meets the third preset condition;

[0057] If the frequency of permission changes meets the first preset condition, the entropy value meets the second preset condition, and the call chain depth meets the third preset condition, then the suspicious packed process is in the unpacking stage.

[0058] A first preset condition is set for the frequency of permission changes, a second preset condition is set for the entropy value, and a third preset condition is set for the call chain depth. When the frequency of permission changes meets the first preset condition, the entropy value meets the second preset condition, and the call chain depth meets the third preset condition, the suspicious packed process is considered to be in the unpacking stage.

[0059] Set corresponding discrimination conditions for permission change frequency, entropy value, and call chain depth. When the permission change frequency, entropy value, and call chain depth all meet the corresponding discrimination conditions, the suspicious packed process is determined to be in the unpacking stage, which can improve the accuracy of the judgment.

[0060] The determination of whether the frequency of permission changes meets the first preset condition includes:

[0061] Determine whether the frequency of permission changes is greater than or equal to a preset frequency threshold;

[0062] If the frequency of permission changes is greater than or equal to a preset frequency threshold, then the frequency of permission changes satisfies the first preset condition.

[0063] If the frequency of permission changes is less than the preset frequency threshold, then the frequency of permission changes does not meet the first preset condition.

[0064] In this embodiment, the first preset condition is that the frequency of permission changes is greater than or equal to a preset frequency threshold.

[0065] For example, if the preset frequency threshold is 2 times / 10ms, then if mprotect changes the permissions of the same memory region from PROT_WRITE to PROT_EXEC (a fast flip of RW↔RX indicates that the shell is decrypting and correcting relocation) at least twice consecutively, then the permission change frequency is considered to meet the first preset condition. Otherwise, the permission change frequency is considered not to meet the first preset condition.

[0066] In some embodiments, determining whether the entropy value satisfies a second preset condition includes:

[0067] Determine whether the decrease in the entropy value within a preset time period is greater than or equal to a preset entropy reduction threshold.

[0068] If the decrease in the entropy value within a preset time period is greater than or equal to a preset entropy reduction threshold, then the entropy value satisfies the second preset condition.

[0069] If the decrease in entropy value within a preset time period is less than a preset entropy reduction threshold, then the entropy value does not meet the second preset condition.

[0070] In this embodiment, the second preset condition is that the decrease in the entropy value of the memory region within a preset time period is greater than or equal to the preset entropy reduction threshold.

[0071] For example, if the entropy of a memory region decreases by more than 2.5 within 10 ms, i.e., ΔH = H(t-Δt) - H(t) ≥ 2.5 (a sudden drop from high-entropy ciphertext to low-entropy plaintext), then the entropy is considered to meet the second preset condition. Otherwise, the entropy is considered not to meet the second preset condition. ΔH represents the decrease in entropy within 10 ms.

[0072] In some embodiments, determining whether the decrease in entropy value within a preset time period is greater than or equal to a preset entropy reduction threshold includes:

[0073] A preset entropy reduction threshold corresponding to the shell type is determined based on the shell type; different shell types are set with independent entropy reduction thresholds.

[0074] Determine whether the decrease in entropy value within a preset time period is greater than or equal to the preset entropy reduction threshold corresponding to the shell type.

[0075] Different shell types are set with independent entropy reduction thresholds. The corresponding entropy reduction threshold is determined according to the shell type, and then it is determined whether the amount of entropy reduction within a preset time is greater than or equal to the entropy reduction threshold corresponding to the shell type.

[0076] For example, the entropy reduction threshold for the UPX shell can be set to 2.5, and the entropy reduction threshold for the VMProtect shell can be set to 3. Therefore, if the shell type is VMProtect, the corresponding preset entropy reduction threshold is 3, and it is then determined whether the decrease in entropy value within a preset time is greater than or equal to 3.

[0077] By determining the corresponding entropy reduction threshold based on the shell type, and then judging whether the decrease in entropy value within a preset time is greater than or equal to the entropy reduction threshold corresponding to the shell type, the detection accuracy can be improved.

[0078] In some embodiments, determining whether the call chain depth meets a third preset condition includes:

[0079] Determine whether the depth of the call chain has reached a preset threshold and whether a back edge has occurred;

[0080] If the depth of the call chain reaches a preset threshold and a back edge occurs, then the depth of the call chain satisfies the third preset condition.

[0081] If the call chain depth does not reach the preset threshold and / or no back edge appears, then the call chain depth does not meet the third preset condition.

[0082] In this embodiment, the third preset condition is whether the call chain depth reaches a preset threshold and a back edge occurs.

[0083] For example, if the call chain depth reaches a preset threshold K and a back edge occurs, then the call chain depth meets the second preset condition. Otherwise, the call chain depth is considered not to meet the second preset condition.

[0084] As a specific method, determining whether a suspicious packed process is in the unpacking stage based on the permission change frequency, the entropy value, and the call chain depth includes:

[0085] Determine whether the frequency of permission changes meets the first preset condition;

[0086] If the frequency of permission changes meets the first preset condition, then determine whether the entropy value meets the second preset condition;

[0087] If the entropy value satisfies the second preset condition, then determine whether the call chain depth satisfies the third preset condition;

[0088] If the call chain depth meets the third preset condition, then the suspicious packed process is in the unpacking stage.

[0089] refer to Figure 2 As shown, the system detects changes in memory permissions, determining whether the frequency of permission changes from PROT_WRITE to PROT_EXEC in a memory region is greater than or equal to a preset frequency threshold. PROT_WRITE represents write permission, and PROT_EXEC represents execute permission. If the frequency of permission changes from PROT_WRITE to PROT_EXEC in a memory region is greater than or equal to the preset frequency threshold, the entropy change is calculated, and the decrease in entropy within a preset time period is determined to be greater than or equal to a preset entropy reduction threshold. If the decrease in entropy within a preset time period is greater than or equal to the preset entropy reduction threshold, the call chain depth is analyzed to determine whether the call chain depth has reached a preset threshold and whether a back edge has appeared. If the call chain depth reaches the preset threshold and a back edge has appeared, the suspected packed process is in the unpacking stage, meeting the unpacking trigger condition, and a memory dump is then executed.

[0090] The relevant script can be as follows:

[0091] struct vma_stat {

[0092] u64 last_ns;

[0093] u32 cnt; / / Frequency count

[0094] u32 hist

[256] ; / / Byte histogram

[0095] u32 depth; / / Call chain depth

[0096] };

[0097] SEC("kprobe / mprotect")

[0098] int trace_prot(struct pt_regs *ctx)

[0099] {

[0100] struct vma_stat *vs = bpf_vma_stat_lookup(); / / Custom helper

[0101] u64 now = bpf_ktime_get_ns();

[0102] / * 1. Frequency statistics: 10 ms window * /

[0103] if (now - vs->last_ns < 10*1000*1000) vs->cnt++;

[0104] else { vs->cnt = 1; vs->last_ns = now;}

[0105] / * 2. Entropy value: 4 KB histogram before sampling * /

[0106] bpf_probe_read_kernel(vs->hist, sizeof(vs->hist), vma_start);

[0107] / * 3. Call chain depth: stack_id → number of levels * /

[0108] vs->depth = bpf_get_stack_depth(); / / helper pseudocode

[0109] / * 4. Determination* /

[0110] if (vs->cnt >= 2 && entropy_drop(vs->hist) >= 2.5 && vs->depth >= 3){

[0111] struct verdict *v = bpf_ringbuf_reserve(...);

[0112] v->vma_start = vma_start;

[0113] v->len = vma_end - vma_start;

[0114] bpf_ringbuf_submit(v, 0);

[0115] }

[0116] return 0;

[0117] }

[0118] In some embodiments, it also includes:

[0119] Configure the corresponding entropy reduction threshold according to the shell type.

[0120] The entropy reduction threshold can be trained based on historical samples and written into the target object.

[0121] The target object can be BPF_MAP_TYPE_ARRAY_OF_MAPS.

[0122] The outer layer of BPF_MAP_TYPE_ARRAY_OF_MAPS is an array, and each element of the array is a file descriptor that points to another BPF mapping.

[0123] Independent thresholds for different shell types. For example, the entropy reduction threshold for the UPX shell can be set to 2.5, while the entropy reduction threshold for the VMProtect shell can be set to 3.

[0124] Different shell types can be configured with independent entropy reduction thresholds, which can improve detection accuracy.

[0125] In some embodiments, the method further includes: writing the preset threshold into a target array in the user space; the preset threshold supports hot updates.

[0126] The preset threshold corresponding to the call chain depth, i.e. the number of shell layers, is written into the array BPF_MAP_TYPE_ARRAY by the user-space policy and can be hot-updated.

[0127] When a suspicious packed process is identified as being in the unpacking phase, a dump is performed only on the executable memory region that has been modified. The VMA tracing function of the eBPF program can be used to record the dirty page bitmap, and only the dirty page content is written to the target buffer. The dirty page content, i.e., the data decrypted by the suspicious packed process, is then output to user space through the target buffer.

[0128] In some embodiments, writing the data decrypted by the suspicious packed process into the target buffer via the target program includes:

[0129] The target program writes the data decrypted by the suspicious packed process into a circular buffer.

[0130] The VMA tracing function of the eBPF program can be used to record the dirty page bitmap, and only the contents of the dirty pages are written to the circular buffer.

[0131] The relevant script can be as follows:

[0132] / * 1. Shell threshold K issued by the strategy center (example) * /

[0133] struct {

[0134] __uint(type, BPF_MAP_TYPE_ARRAY);

[0135] __uint(max_entries, 1);

[0136] __type(key, u32);

[0137] __type(value, u32);

[0138] } k_cfg SEC(".maps");

[0139] / * 2. ringbuf: Push metadata first, then push dirty page content * /

[0140] struct {

[0141] __uint(type, BPF_MAP_TYPE_RINGBUF);

[0142] __uint(max_entries, 4 * 1024 * 1024);

[0143] } rb SEC(".maps");

[0144] / * Metadata Header * /

[0145] struct meta {

[0146] __u64 base; / / VMA start

[0147] __u64 len; / / VMA length

[0148] __u64 dirty

[16] ; / / 4K granularity bitmap, maximum 4K*64*16 = 4 MB

[0149] };

[0150] / * 3. Hook: vm_write_fault triggers dirty pages * /

[0151] SEC("fentry / vm_write_fault")

[0152] int BPF_PROG(trace_vm_write_fault,

[0153] struct vm_area_struct *vma,

[0154] unsigned long address)

[0155] {

[0156] / * 3.1 Filtering: Executable Region + Threshold K * /

[0157] if (!(vma->vm_flags & VM_EXEC))

[0158] return 0;

[0159] __u32 zero = 0;

[0160] __u32 *k = bpf_map_lookup_elem(&k_cfg, &zero);

[0161] if (!k || *k == 0) / / If K is not issued, the default is 0, meaning no filtering.

[0162] return 0;

[0163] / * 3.2 Calculate page index and set bitmap bits * /

[0164] __u64 pgoff = (address - vma->vm_start) >> 12;

[0165] __u64 idx = pgoff >> 6; / / 64 bits per group

[0166] __u64 bit = pgoff & 0x3FULL;

[0167] / * 3.3 Requesting Metadata * /

[0168] struct meta *m = bpf_ringbuf_reserve(&rb, sizeof(*m), 0);

[0169] if (!m)

[0170] return 0;

[0171] m->base = vma->vm_start;

[0172] m->len = vma->vm_end - vma->vm_start;

[0173] __builtin_memset(m->dirty, 0, sizeof(m->dirty));

[0174] if (idx < 16)

[0175] m->dirty[idx] |= 1ULL << bit;

[0176] / * 3.4 Request and populate 4K pages of data * /

[0177] __u32 page_sz = 4096;

[0178] void *page_data = bpf_ringbuf_reserve(&rb, page_sz, 0);

[0179] if (!page_data) {

[0180] bpf_ringbuf_discard(m, 0);

[0181] return 0;

[0182] }

[0183] void *user_page = (void *)(address & ~(page_sz - 1));

[0184] if (bpf_probe_read_user(page_data, page_sz, user_page) < 0) {

[0185] bpf_ringbuf_discard(m, 0);

[0186] bpf_ringbuf_discard(page_data, 0);

[0187] return 0;

[0188] }

[0189] / * 3.5 Commit: Metadata first, then data * /

[0190] bpf_ringbuf_submit(m, 0);

[0191] bpf_ringbuf_submit(page_data, 0);

[0192] return 0;

[0193] }

[0194] In user space, data is retrieved from the target buffer, and the data is reassembled into a complete memory image based on the base address and bitmap and written back to the file, thus completing the file unpacking.

[0195] In some embodiments, reading the data from the target buffer in user space includes:

[0196] The data is read asynchronously from the target buffer in user space.

[0197] Based on the embodiment where the target buffer is a circular buffer, data is asynchronously retrieved from the circular buffer in user space, and the data is reassembled into a complete memory image according to the base address and bitmap and written back to the file, thereby completing the file unpacking.

[0198] The relevant script can be as follows:

[0199] static int handle_event(void *ctx, void *data, size_t len)

[0200] {

[0201] struct dump_meta *meta = data;

[0202] void *bitmap = meta + 1;

[0203] void *pages = (char *)bitmap + meta->bitmap_bytes;

[0204] char fname

[64] ;

[0205] snprintf(fname, sizeof(fname), "dump.%d.mem", meta->pid);

[0206] int fd = open(fname, O_RDWR | O_CREAT, 0644);

[0207] if (fd < 0) { perror("open"); return 0;}

[0208] if (ftruncate(fd, meta->len) < 0) perror("ftruncate");

[0209] void *base = mmap(NULL, meta->len, PROT_READ | PROT_WRITE,

[0210] MAP_SHARED, fd, 0);

[0211] if (base == MAP_FAILED) { perror("mmap"); goto out;}

[0212] / * Write back the page based on the bitmap * /

[0213] for (__u32 i = 0; i < meta->nr_dirty; i++) {

[0214] __u32 idx = i;

[0215] void *dst = (char *)base + (idx << 12);

[0216] memcpy(dst, pages + (idx << 12), 4096);

[0217] }

[0218] munmap(base, meta->len);

[0219] printf("dumped %d dirty pages for pid %d\n", meta->nr_dirty, meta->pid);

[0220] out:

[0221] close(fd);

[0222] return 0;

[0223] }

[0224] Data is asynchronously output to user space through a circular buffer without blocking process execution, making it suitable for production environments or high-frequency triggering scenarios.

[0225] refer to Figure 3 As shown, the following describes a specific implementation method.

[0226] Insert a probe at the target system call in the kernel and inject the eBPF program into the probe.

[0227] Monitor the execve event and collect process creation behavior.

[0228] Read the ELF file header of the newly created process to identify its modulus characteristics.

[0229] Record the process PID, path, and parameters, and add processes that can be packed into the process map to be tracked.

[0230] Monitor mmap / mprotect events to collect memory allocation and permission change behaviors.

[0231] Detect the frequency of permission changes, detect changes in entropy values, and analyze the depth of the call chain.

[0232] If the frequency of permission changes is greater than or equal to a preset frequency threshold, and the decrease in the entropy value within a preset time is greater than or equal to a preset entropy reduction threshold, and the call chain depth reaches a preset threshold and a back edge occurs, then the unpacking trigger condition is considered to be met.

[0233] Perform a dump on the executable memory region that has been modified.

[0234] The VMA tracing function of an eBPF program is used to record dirty page bitmaps. The eBPF VMA tracing function allows the eBPF program to observe the creation, modification, destruction, and permission / content changes of the process's virtual memory region (VMA) in real time and non-intrusively, and sends key events (starting address, length, permissions, dirty page bitmap, etc.) to user space for further analysis.

[0235] Write the contents of the dirty page to the circular buffer.

[0236] Dirty page contents are asynchronously output to user space via a circular buffer.

[0237] In user space, the data is reassembled into a complete memory image based on the base address and the dirty page bitmap, and then written back to the file.

[0238] The file unpacking method provided in this invention implements kernel-level monitoring: directly monitoring system calls and memory operations in kernel space using eBPF technology; performing dynamic behavior analysis: identifying the unpacking timing by analyzing the program's runtime behavior characteristics; achieving seamless unpacking: completing the unpacking operation without interfering with the normal operation of the program; achieving cross-platform support: using CO-RE technology to achieve compatibility across different kernel versions; implementing dynamic dirty page dumping: only dumping the modified executable memory region, avoiding the I / O bottleneck caused by full memory dumping; and implementing asynchronous data reassembly based on bitmaps.

[0239] refer to Figure 4As shown, as a specific implementation, the kernel mode can include a critical system call monitoring module, an unpacking trigger detection module, and a memory dump module. The critical system call monitoring module monitors `execve` and `mmap / mprotect`. The unpacking trigger detection module performs permission change frequency detection, entropy analysis, and call chain depth analysis. `eBPFmap` is a general-purpose data structure that stores different types of data, providing functions such as user-mode and kernel-mode data interaction, data storage, and multi-program data sharing. When the unpacking trigger condition is met, the memory dump module performs a memory dump, writing dirty page contents to the circular buffer.

[0240] Dirty page contents are asynchronously output to user space via a circular buffer.

[0241] The user-space dump processing module reassembles the data into a complete memory image. The user-space strategy module uses a hot update strategy to update the threshold corresponding to the call chain depth recorded in the eBPF map.

[0242] In summary, the file unpacking method provided by this invention inserts a probe at the target system call in the kernel and injects it into the target program. The target program then performs operations such as identifying suspicious packed processes and dumping data. Since the target program runs in the kernel, it does not require modification of user-space memory. The target program performs process filtering, identifies suspicious packed processes, and dumps only the data decrypted by these processes. This avoids the I / O bottleneck caused by full memory dumping, reduces invalid user-space data, and lowers CPU usage and memory bandwidth.

[0243] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0244] Embodiments of the present invention also provide a file unpacking device, see reference. Figure 5 As shown, the file unpacking device includes:

[0245] Instrumentation module 10 is used to insert probes at target system calls in the kernel and inject target programs into the probes;

[0246] The identification module 20 is used to identify suspicious packed processes through the target program;

[0247] The monitoring module 30 is used to monitor the memory permission change behavior of the suspicious packed process through the target program, and to count the frequency of permission changes in the memory region, the entropy value of the memory region, and the call chain depth.

[0248] The writing module 40 is used to write the data decrypted by the suspicious packed process into the target buffer through the target program when the suspicious packed process is determined to be in the unpacking stage based on the permission change frequency, the entropy value and the call chain depth.

[0249] The reassembly module 50 is used to read the data from the target buffer in user space, reassemble the data into a memory image according to the base address and dirty page bitmap, and write it back to the file.

[0250] Based on the above embodiments, as a specific implementation method, the determination module 40 includes:

[0251] The first judgment unit is used to determine whether the permission change frequency meets the first preset condition;

[0252] The second judgment unit is used to determine whether the entropy value satisfies the second preset condition;

[0253] The third judgment unit is used to determine whether the call chain depth meets the third preset condition;

[0254] The determining unit is configured to determine that if the permission change frequency meets a first preset condition, the entropy value meets a second preset condition, and the call chain depth meets a third preset condition, then the suspicious packed process is in the unpacking stage.

[0255] Based on the above embodiments, as a specific implementation method, the first determination unit is used for:

[0256] Determine whether the frequency of permission changes is greater than or equal to a preset frequency threshold;

[0257] If the frequency of permission changes is greater than or equal to a preset frequency threshold, then the frequency of permission changes satisfies the first preset condition.

[0258] If the frequency of permission changes is less than the preset frequency threshold, then the frequency of permission changes does not meet the first preset condition.

[0259] Based on the above embodiments, as a specific implementation method, the second determination unit is used for:

[0260] Determine whether the decrease in the entropy value within a preset time period is greater than or equal to a preset entropy reduction threshold.

[0261] If the decrease in the entropy value within a preset time period is greater than or equal to a preset entropy reduction threshold, then the entropy value satisfies the second preset condition.

[0262] If the decrease in entropy value within a preset time period is less than a preset entropy reduction threshold, then the entropy value does not meet the second preset condition.

[0263] Based on the above embodiments, as a specific implementation method, the second determination unit includes:

[0264] An entropy reduction threshold determination subunit is used to determine a preset entropy reduction threshold corresponding to the shell type based on the shell type; different shell types are set with independent entropy reduction thresholds.

[0265] The entropy value judgment subunit is used to determine whether the decrease in the entropy value within a preset time is greater than or equal to the preset entropy reduction threshold corresponding to the shell type.

[0266] Based on the above embodiments, as a specific implementation method, the third determination unit is used for:

[0267] Determine whether the depth of the call chain has reached a preset threshold and whether a back edge has occurred;

[0268] If the depth of the call chain reaches a preset threshold and a back edge occurs, then the depth of the call chain satisfies the third preset condition.

[0269] If the call chain depth does not reach the preset threshold and / or no back edge appears, then the call chain depth does not meet the third preset condition.

[0270] Based on the above embodiments, as a specific implementation method, the identification module 20 includes:

[0271] The monitoring unit is used to monitor the process creation behavior through the target program;

[0272] The read unit is used to read the file header of the entity file of the newly created process;

[0273] The judgment unit is used to determine whether the file header contains magic number features;

[0274] The confirmation unit is configured to determine if the newly created process is a suspicious packed process if the file header contains magic number characteristics.

[0275] Based on the above embodiments, as a specific implementation method, the insertion module 10 is used for:

[0276] The probe is injected into the extended Berkeley packet filter program.

[0277] Based on the above embodiments, as a specific implementation method, it further includes:

[0278] The entropy reduction threshold configuration module is used to configure the corresponding entropy reduction threshold according to the shell type.

[0279] Based on the above embodiments, as a specific implementation method, it further includes:

[0280] A threshold writing module is used to write the preset threshold to a target array in the user space; the preset threshold supports hot updates.

[0281] Based on the above embodiments, as a specific implementation method, the writing module 40 is used for:

[0282] The target program writes the data decrypted by the suspicious packed process into a circular buffer.

[0283] Based on the above embodiments, as a specific implementation method, the recombining module 50 is used for:

[0284] The data is read asynchronously from the target buffer in user space.

[0285] The file unpacking device provided by this invention inserts a probe at the target system call location in the kernel and injects the probe into the target program. The target program then performs operations such as identifying suspicious packed processes and dumping data. The target program runs in the kernel and does not require modification of user-space memory. The target program performs process filtering, identifies suspicious packed processes, and dumps the data decrypted by the suspicious packed processes. This avoids the I / O bottleneck caused by full memory dumping, reduces invalid user-space data, and lowers CPU usage and memory bandwidth.

[0286] For a description of the features in the embodiment corresponding to the file unpacking device, please refer to the relevant description in the embodiment corresponding to the file unpacking method; they will not be repeated here.

[0287] Embodiments of the present invention also provide an electronic device, with reference to Figure 6 As shown, the electronic device includes a memory 1 and a processor 2. The memory 1 stores a computer program, and the processor 2 is configured to run the computer program to perform the steps in any of the above-described file unpacking method embodiments.

[0288] The electronic device provided by this invention inserts a probe at the target system call location in the kernel and injects a target program into the probe. The target program performs operations such as identifying suspicious packed processes and dumping data. The target program runs in the kernel and does not require modification of user-space memory. The target program performs process filtering, identifies suspicious packed processes, and dumps the data decrypted by the suspicious packed processes. This avoids the I / O bottleneck caused by full memory dumps, reduces invalid user-space data, and lowers CPU usage and memory bandwidth.

[0289] Embodiments of the present invention also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described file unpacking method embodiments when running.

[0290] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0291] Embodiments of the present invention also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described file unpacking method embodiments.

[0292] Embodiments of the present invention also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described file unpacking method embodiments.

[0293] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0294] The above provides a detailed description of the file unpacking method and electronic device provided by this invention. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the above embodiments are only intended to help understand the method and core ideas of this invention. It should be noted that those skilled in the art can make various improvements and modifications to this invention without departing from its principles, and these improvements and modifications also fall within the protection scope of this invention.

Claims

1. A method for unpacking files, characterized in that, include: Insert a probe at the target system call location in the kernel and inject the target program into the probe; The target program is used to identify suspicious packed processes; The target program monitors the memory permission change behavior of the suspicious packed process, and counts the frequency of permission changes in the memory region, the entropy value of the memory region, and the call chain depth. When the suspicious packed process is determined to be in the unpacking stage based on the permission change frequency, the entropy value, and the call chain depth, the data decrypted by the suspicious packed process is written into the target buffer by the target program. In user space, the data is read from the target buffer, and the data is reassembled into a memory image based on the base address and the dirty page bitmap and written back to the file; Determining whether a suspicious packed process is in the unpacking phase based on the permission change frequency, the entropy value, and the call chain depth includes: Determine whether the frequency of permission changes meets the first preset condition; Determine whether the entropy value satisfies the second preset condition; Determine whether the depth of the call chain meets the third preset condition; If the permission change frequency meets the first preset condition, the entropy value meets the second preset condition, and the call chain depth meets the third preset condition, then the suspicious packed process is in the unpacking stage. Determining whether the frequency of permission changes meets the first preset condition includes: Determine whether the frequency of permission changes is greater than or equal to a preset frequency threshold; If the frequency of permission changes is greater than or equal to a preset frequency threshold, then the frequency of permission changes satisfies the first preset condition. If the frequency of permission changes is less than the preset frequency threshold, then the frequency of permission changes does not meet the first preset condition. Determining whether the entropy value satisfies the second preset condition includes: Determine whether the decrease in the entropy value within a preset time period is greater than or equal to a preset entropy reduction threshold. If the decrease in the entropy value within a preset time period is greater than or equal to a preset entropy reduction threshold, then the entropy value satisfies the second preset condition. If the decrease in entropy value within a preset time period is less than a preset entropy reduction threshold, then the entropy value does not meet the second preset condition. Determining whether the call chain depth meets the third preset condition includes: Determine whether the depth of the call chain has reached a preset threshold and whether a back edge has occurred; If the depth of the call chain reaches a preset threshold and a back edge occurs, then the depth of the call chain satisfies the third preset condition. If the call chain depth does not reach the preset threshold and / or no back edge appears, then the call chain depth does not meet the third preset condition.

2. The file unpacking method according to claim 1, characterized in that, Determining whether the decrease in entropy value within a preset time period is greater than or equal to a preset entropy reduction threshold includes: A preset entropy reduction threshold corresponding to the shell type is determined based on the shell type; different shell types are set with independent entropy reduction thresholds. Determine whether the decrease in the entropy value within a preset time is greater than or equal to a preset entropy reduction threshold corresponding to the shell type; Correspondingly, it also includes: Configure the corresponding entropy reduction threshold according to the shell type.

3. The file unpacking method according to claim 1, characterized in that, Identifying suspicious packed processes through the target program includes: The target program monitors process creation behavior. Read the header of the entity file of the newly created process; Determine whether the file header contains a magic number feature; If the file header contains magic number characteristics, the newly created process is a suspicious packed process.

4. The file unpacking method according to claim 1, characterized in that, Also includes: The preset threshold is written to the target array in the user state; The preset threshold supports hot updates.

5. The file unpacking method according to claim 1, characterized in that, The process of writing the data decrypted by the suspicious packed process into the target buffer via the target program includes: The target program writes the data decrypted by the suspicious packed process into a circular buffer.

6. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the file unpacking method as described in any one of claims 1 to 5 when executing the computer program.

Images