File shelling method and electronic equipment

Abstract

The invention discloses a file shelling method and electronic equipment, and relates to the technical field of computer security, and the file shelling method comprises the following steps: inserting a probe at a target system calling position of a kernel, and injecting a target program into the probe; identifying a suspicious shell adding process through the target program; monitoring a memory permission change behavior executed by the suspicious packing process through the target program, and counting the permission change frequency of the memory region, the entropy value of the memory region and the call chain depth; when it is confirmed that the suspicious packing process is in the unpacking stage according to the permission change frequency, the entropy value and the call chain depth, data decrypted by the suspicious packing process is written into a target buffer area through a target program; and reading the data from the target buffer area in the user mode, recombining the data into a memory mirror image according to the base address and the dirty page bitmap, and writing the memory mirror image back to the file. According to the method, the I / O bottleneck caused by full-memory dump can be avoided, invalid data in a user mode can be reduced, and CPU occupation and memory bandwidth can be reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer security, and in particular to a file unpacking method and electronic equipment. BACKGROUND

[0002] Virus file packing is a technology of escaping static detection by compressing, encrypting or confusing malicious code. The virus file after packing is decrypted and executed dynamically at runtime. Virus file unpacking refers to stripping off the "shell" used to "hide" the virus file and restoring the original and analyzable code of the virus file. The related art has defects such as high resource occupation and I / O bottleneck in file unpacking. Therefore, how to solve the above technical defects has become a technical problem to be solved by the technical personnel in the field. SUMMARY

[0003] The present application provides a file unpacking method and electronic equipment to at least solve the problems of high resource occupation and I / O bottleneck in the related art.

[0004] The present application provides a file unpacking method, comprising: inserting a probe at a target system call of a kernel and injecting the probe into a target program; identifying a suspicious packing process through the target program; monitoring memory permission change behavior executed by the suspicious packing process through the target program, and counting permission change frequency of a memory region, entropy value of the memory region and call chain depth; when it is confirmed that the suspicious packing process is in an unpacking stage according to the permission change frequency, the entropy value and the call chain depth, writing data decrypted by the suspicious packing process into a target buffer through the target program; reading the data from the target buffer in a user mode, and reorganizing the data into a memory image according to a base address and a dirty page bitmap and writing back to a file.

[0005] The present application also provides a file unpacking device, comprising: an insertion module for inserting a probe at a target system call of a kernel and injecting the probe into a target program; an identification module for identifying a suspicious packing process through the target program; a monitoring module for monitoring memory permission change behavior executed by the suspicious packing process through the target program, and counting permission change frequency of a memory region, entropy value of the memory region and call chain depth; a writing module for writing data decrypted by the suspicious packing process into a target buffer through the target program when it is determined that the suspicious packing process is in an unpacking stage according to the permission change frequency, the entropy value and the call chain depth. A reorganization module is configured to read the data from the target buffer in a user mode, and reorganize the data into a memory image according to a base address and a dirty page bitmap, and write the memory image back to a file.

[0006] The application further provides an electronic device, comprising a memory configured to store a computer program, and a processor configured to execute the computer program to implement the steps of any of the file unshelling methods.

[0007] The application further provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of any of the file unshelling methods.

[0008] The application further provides a computer program product, comprising a computer program, and the computer program is executed by a processor to implement the steps of any of the file unshelling methods.

[0009] The file unshelling method has the beneficial effects that: the file unshelling method inserts a probe at a target system call of a kernel, and injects the probe into a target program, and performs suspicious shell process identification and dumping operations through the target program, the target program runs in the kernel, and the user mode memory does not need to be modified. The target program performs process filtering, identifies suspicious shell processes, and only dumps the data decrypted by the suspicious shell processes, so that the I / O bottleneck caused by full memory dumping can be avoided, and the user mode invalid data can be reduced, and the CPU occupation and the memory bandwidth can be reduced. BRIEF DESCRIPTION OF DRAWINGS

[0010] In order to more clearly illustrate the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0011] Figure 1 A file unshelling method flowchart provided by the embodiments of the present application; Figure 2 A shell unshelling stage judgment flowchart provided by the embodiments of the present application; Figure 3 A specific file unshelling flowchart provided by the embodiments of the present application; Figure 4 A system structure diagram provided by the embodiments of the present application; Figure 5 A file unshelling device diagram provided by the embodiments of the present application; Figure 6 An electronic device diagram provided by the embodiments of the present application. DETAILED DESCRIPTION

[0012] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative effort belong to the protection scope of the present application.

[0013] It should be noted that, in the description of the present application, the terms “comprise”, “contain” or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device comprising a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. The terms “first”, “second” and the like in the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence.

[0014] In order for those skilled in the art to better understand the technical solutions of the present application, the present application will be further described in detail below with reference to the drawings and specific embodiments.

[0015] The embodiments of the present application provide a file unshelling method. In combination with the execution flow of the file unshelling method, the method is described in detail below.

[0016] Reference Figure 1 As shown in the figure, the file unshelling method provided by the embodiments of the present application comprises: S101: inserting a probe at a target system call of a kernel, and injecting the probe into a target program; S102: identifying a suspicious shelled process through the target program; S103: monitoring a memory permission change behavior performed by the suspicious 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; S104: when it is determined according to the permission change frequency, the entropy value and the call chain depth that the suspicious shelled process is in an unshelling stage, writing data decrypted by the suspicious shelled process into a target buffer through the target program; S105: 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.

[0017] Kernel refers to the operating system kernel. The operating system kernel is the most core and basic part of the operating system, responsible for managing computer hardware resources and providing basic services for upper-layer application programs. The main functions of the kernel include: process management: controls the creation, scheduling, termination of processes, and determines which process uses the CPU and for how long. Memory management: manages the system's memory resources, including allocating and reclaiming memory, ensuring memory isolation and security between different processes. File system management: provides an access interface to storage devices (such as hard disks, SSDs), and manages file creation, reading, writing, deletion, and other operations. Device driver management: controls and manages hardware devices (such as keyboards, mice, displays, network cards, etc.), and communicates with hardware through drivers. System call interface: provides a unified interface for applications to access hardware and system resources, hiding the differences between underlying hardware. Target system calls refer to selected system calls for setting probes. Target system calls can include execve, mmap, mprotect, etc. The function of execve is to replace the current process's image (i.e. the code, data, stack, etc. executed by the current process) with a new program. The function of mmap is to map files or anonymous memory to the process's virtual address space, used for dynamic memory allocation and loading shared libraries. The function of mprotect is to modify the access permissions of mapped memory regions (such as read-only, executable, inaccessible, etc.), file mapping, etc.

[0018] A probe is inserted at the target system call of the kernel. The purpose of inserting the probe is to dynamically inject a program at the probe location without modifying the kernel source code or restarting the system, safely and efficiently observing kernel behavior.

[0019] On the basis of inserting the probe, a target program is injected into the probe. The target program is responsible for identifying suspiciously packed processes, monitoring the memory permission change behavior of suspiciously packed processes, counting the frequency of memory region permission changes, the entropy value of the memory region, and the call chain depth, judging whether the suspiciously packed process is in the unpacking stage according to the frequency of memory region permission changes, the entropy value, and the call chain depth, and performing Dump on the data decrypted by the suspiciously packed process when it is determined that the suspiciously packed process is in the unpacking stage.

[0020] In some embodiments, the probe injection target program includes: The probe injection target program includes:

[0021] The target program in this embodiment is an eBPF (extended Berkeley Packet Filter) program. The eBPF program runs in the kernel space, does not modify the user space memory, does not trigger common detection logics such as ptrace, frida, xposed, and the like, does not need to be attached by ptrace, and the eBPF program does not trigger SIGTRAP, SIGSTOP, and does not modify the TracerPid, so that the shell strategy such as JNI anti-debugging, anti-ptrace, anti-injection and the like can be bypassed.

[0022] On the basis of injecting the probe into the target program, a suspiciously shell-processed process is identified by the target program.

[0023] In some embodiments, identifying the suspiciously shell-processed process by the target program comprises: monitoring process creation behavior by the target program; reading a file header of an entity file of the created new process; judging whether the file header contains a magic number feature; if the file header contains the magic number feature, the created new process is a suspiciously shell-processed process.

[0024] The target program monitors the execve-created process.

[0025] For example: bpftrace -e 'tracepoint:syscalls:sys_enter_execve { printf("PID%d executed: %s\n", pid, str(args->filename));}'. The code indicates that all processes performing the execve system call are traced in real time, and the process PID performing the new program and the corresponding executable file path are printed.

[0026] For all the created new processes, the file header (ELF) of the entity file of the new process is read, and the magic number feature in the file header is identified. For example, the features such as ('UPX!', VMProtect feature, and the like) are identified. If the file header contains the magic number feature, the created new process is a suspiciously shell-processed process. That is, if the process header of the new process is ELF and contains the magic number feature, the new process is a suspiciously shell-processed process, the suspiciously shell-processed process is added to the process map to be tracked, and unnecessary calculation on ordinary processes is avoided. The process PID, path, and parameter are recorded, and context correlation is performed for subsequent mmap / mprotect events.

[0027] The suspiciously packed process execution memory permission change behavior can be monitored using the kprobe / sys_mprotect, and whether it is in the unpacking stage is determined in real time according to the memory permission change frequency, the entropy value change and the call chain depth.

[0028] In some embodiments, determining whether the suspiciously packed process is in the unpacking stage according to the permission change frequency, the entropy value and the call chain depth comprises: determining whether the permission change frequency meets a first preset condition; determining whether the entropy value meets a second preset condition; determining whether the call chain depth meets a third preset condition; If the permission change frequency meets the first preset condition, and the entropy value meets the second preset condition, and the call chain depth meets the third preset condition, the suspiciously packed process is in the unpacking stage.

[0029] The first preset condition is set for the permission change frequency, the second preset condition is set for the entropy value, and the third preset condition is set for the call chain depth. When the permission change frequency meets the first preset condition, and the entropy value meets the second preset condition, and the call chain depth meets the third preset condition, it is considered that the suspiciously packed process is in the unpacking stage.

[0030] The corresponding discrimination conditions are set for the permission change frequency, the entropy value and the call chain depth, respectively. When the permission change frequency, the entropy value and the call chain depth all meet the corresponding discrimination conditions, it is determined that the suspiciously packed process is in the unpacking stage, which can improve the accuracy of the determination.

[0031] The determination of whether the permission change frequency meets the first preset condition comprises: determining whether the permission change frequency is greater than or equal to a preset frequency threshold; If the permission change frequency is greater than or equal to the preset frequency threshold, the permission change frequency meets the first preset condition; If the permission change frequency is less than the preset frequency threshold, the permission change frequency does not meet the first preset condition.

[0032] In this embodiment, the first preset condition is that the permission change frequency is greater than or equal to the preset frequency threshold.

[0033] For example, if the preset frequency threshold is 2 times / 10 ms, it is considered that the permission change frequency meets the first preset condition if at least twice in a row the mprotect modifies the permission of the same memory region from PROT_WRITE to PROT_EXEC (fast flipping of RW↔RX indicates that the shell is being decrypted, modified and relocated). Otherwise, it is considered that the permission change frequency does not meet the first preset condition.

[0034] In some embodiments, determining whether the entropy value meets the second preset condition comprises: determining whether the reduction amount of the entropy value in the preset time is greater than or equal to a preset entropy reduction threshold value; if the reduction amount of the entropy value in the preset time is greater than or equal to the preset entropy reduction threshold value, the entropy value meets the second preset condition; if the reduction amount of the entropy value in the preset time is less than the preset entropy reduction threshold value, the entropy value does not meet the second preset condition.

[0035] In the embodiment, the second preset condition is that the reduction amount of the entropy value of the memory region in the preset time is greater than or equal to the preset entropy reduction threshold value.

[0036] For example, if the reduction amount of the entropy value of the memory region in 10 ms is greater than 2.5, that is, ΔH = H(t-Δt) -H(t)≥ 2.5 (high entropy ciphertext→low entropy plaintext sudden drop), it is considered that the entropy value meets the second preset condition. Otherwise, it is considered that the entropy value does not meet the second preset condition. ΔH represents the reduction amount of the entropy value in 10 ms.

[0037] In some embodiments, determining whether the reduction amount of the entropy value in the preset time is greater than or equal to a preset entropy reduction threshold value comprises: determining a preset entropy reduction threshold value corresponding to the shell type according to the shell type; different shell types are set with independent entropy reduction threshold values; determining whether the reduction amount of the entropy value in the preset time is greater than or equal to the preset entropy reduction threshold value corresponding to the shell type.

[0038] Different shell types are set with independent entropy reduction threshold values, the corresponding entropy reduction threshold value is determined according to the shell type, and then it is determined whether the reduction amount of the entropy value in the preset time is greater than or equal to the entropy reduction threshold value corresponding to the shell type.

[0039] For example, the entropy reduction threshold value corresponding to the UPX shell can be set to 2.5, and the entropy reduction threshold value corresponding to the VMProtect shell can be set to 3. If the shell type is the VMProtect shell, the corresponding preset entropy reduction threshold value is 3, and then it is determined whether the reduction amount of the entropy value in the preset time is greater than or equal to 3.

[0040] Determining the corresponding entropy reduction threshold value according to the shell type, and then determining whether the reduction amount of the entropy value in the preset time is greater than or equal to the entropy reduction threshold value corresponding to the shell type, can improve the detection accuracy.

[0041] In some embodiments, determining whether the call chain depth meets the third preset condition comprises: determining whether the call chain depth reaches a preset threshold value and whether a back edge appears; if the call chain depth reaches the preset threshold value and the back edge appears, the call chain depth meets the third preset condition; If the call chain depth does not reach the preset threshold and / or the back edge does not occur, the call chain depth does not satisfy the third preset condition.

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

[0043] For example, if the call chain depth reaches the preset threshold K and the back edge occurs, the call chain depth satisfies the second preset condition. Otherwise, it is considered that the call chain depth does not satisfy the second preset condition.

[0044] As a specific manner, judging whether the suspiciously packed process is in the unpacking stage according to the permission change frequency, the entropy value and the call chain depth comprises: judging whether the permission change frequency satisfies a first preset condition; If the permission change frequency satisfies the first preset condition, judging whether the entropy value satisfies a second preset condition; If the entropy value satisfies the second preset condition, judging whether the call chain depth satisfies a third preset condition; If the call chain depth satisfies the third preset condition, the suspiciously packed process is in the unpacking stage.

[0045] Reference Figure 2 As shown, the memory permission change is detected, and whether the permission change frequency of the memory region from PROT_WRITE to PROT_EXEC satisfies a preset frequency threshold is judged. PROT_WRITE is a write permission, and PROT_EXEC is an execution permission. If the permission change frequency of the memory region from PROT_WRITE to PROT_EXEC is greater than or equal to the preset frequency threshold, the entropy value change is calculated, and whether the entropy value reduction amount in a preset time is greater than or equal to a preset entropy reduction threshold is judged. If the entropy value reduction amount in the preset time is greater than or equal to the preset entropy reduction threshold, the call chain depth is analyzed, and whether the call chain depth reaches the preset threshold and the back edge occurs is judged. If the call chain depth reaches the preset threshold and the back edge occurs, the suspiciously packed process is in the unpacking stage, the unpacking trigger condition is satisfied, and then the memory Dump is executed.

[0046] The related script can be as follows: struct vma_stat { u64 last_ns; u32 cnt; / / frequency count u32 hist

[256] ; / / byte histogram u32 depth; / / call chain depth }; SEC("kprobe / mprotect") int trace_prot(struct pt_regs *ctx) { struct vma_stat *vs = bpf_vma_stat_lookup(); / / Custom helper u64 now = bpf_ktime_get_ns(); / * 1. Frequency statistics: 10 ms window * / if (now - vs->last_ns < 10*1000*1000) vs->cnt++; else { vs->cnt = 1; vs->last_ns = now;} / * 2. Entropy value: 4 KB histogram before sampling * / bpf_probe_read_kernel(vs->hist, sizeof(vs->hist), vma_start); / * 3. Call chain depth: stack_id → number of levels * / vs->depth = bpf_get_stack_depth(); / / helper pseudocode / * 4. Determination* / if (vs->cnt >= 2 && entropy_drop(vs->hist) >= 2.5 && vs->depth >=3) { struct verdict *v = bpf_ringbuf_reserve(...); v->vma_start = vma_start; v->len = vma_end - vma_start; bpf_ringbuf_submit(v, 0); } return 0; }

[0047] In some embodiments, it also includes: Configure the corresponding entropy reduction threshold according to the shell type.

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

[0049] The target object can be a BPF_MAP_TYPE_ARRAY_OF_MAPS.

[0050] The outer layer of the BPF_MAP_TYPE_ARRAY_OF_MAPS is an array, and each element of the array is a file descriptor pointing to another BPF map.

[0051] Different shell types have independent threshold values. For example, the entropy reduction threshold value corresponding to the UPX shell can be set to 2.5, and the entropy reduction threshold value corresponding to the VMProtect shell can be set to 3.

[0052] Different shell types configure independent entropy reduction threshold values, which can improve detection accuracy.

[0053] In some embodiments, further comprising: writing the preset threshold value into a target array in the user mode; and the preset threshold value supports hot updating.

[0054] The preset threshold value corresponding to the call chain depth, i.e., the shell layer number, is written into the array BPF_MAP_TYPE_ARRAY by the user mode strategy and can be hot updated.

[0055] When it is judged that the suspiciously armored process is in the unarming stage, only the executable memory region that has been changed is executed Dump. The VMA tracking function of the eBPF program can be used to record the dirty page bitmap, and only the dirty page content is written into the target buffer, so that the dirty page content, i.e., the data decrypted by the suspiciously armored process, is output to the user mode through the target buffer.

[0056] In some embodiments, writing the data decrypted by the suspiciously armored process into the target buffer by the target program comprises: Writing the data decrypted by the suspiciously armored process into the ring buffer by the target program.

[0057] The VMA tracking function of the eBPF program can be used to record the dirty page bitmap, and only the dirty page content is written into the ring buffer.

[0058] The related script can be as follows: / * 1. Shell layer threshold value K issued by the policy center (example) * / struct { __uint(type, BPF_MAP_TYPE_ARRAY); __uint(max_entries, 1); __type(key, u32); __type(value, u32); } k_cfg SEC(".maps"); / * 2. ringbuf: push metadata first, then dirty page content * / struct { __uint(type, BPF_MAP_TYPE_RINGBUF); __uint(max_entries, 4 * 1024 * 1024); } rb SEC(".maps"); / * Metadata header * / struct meta { __u64 base; / / VMA start __u64 len; / / VMA length __u64 dirty

[16] ; / / 4K granularity bitmap, max 4K*64*16 = 4 MB }; / * 3. Hook: vm_write_fault triggers dirty page * / SEC("fentry / vm_write_fault") int BPF_PROG(trace_vm_write_fault, struct vm_area_struct *vma, unsigned long address) { / * 3.1 Filter: executable region + threshold K * / if (!(vma->vm_flags & VM_EXEC)) return 0; __u32 zero = 0; __u32 *k = bpf_map_lookup_elem(&k_cfg, &zero); if (!k || *k == 0) / / If K is not issued, default to 0, i.e., no filtering return 0; / * 3.2 Calculate page index, bitmap set * / __u64 pgoff = (address - vma->vm_start) >> 12; __u64 idx = pgoff >> 6; / / 64-bit group __u64 bit = pgoff & 0x3FULL; / * 3.3 Apply metadata * / struct meta *m = bpf_ringbuf_reserve(&rb, sizeof(*m), 0); if (!m) return 0; m->base = vma->vm_start; m->len = vma->vm_end - vma->vm_start; __builtin_memset(m->dirty, 0, sizeof(m->dirty)); if (idx < 16) m->dirty[idx] |= 1ULL << bit; / * 3.4 Apply and fill 4K page data * / __u32 page_sz = 4096; void *page_data = bpf_ringbuf_reserve(&rb, page_sz, 0); if (!page_data) { bpf_ringbuf_discard(m, 0); return 0; } void *user_page = (void *)(address & ~(page_sz - 1)); if (bpf_probe_read_user(page_data, page_sz, user_page) < 0) { bpf_ringbuf_discard(m, 0); bpf_ringbuf_discard(page_data, 0); return 0; } / * 3.5 Commit: metadata first, then data * / bpf_ringbuf_submit(m, 0); bpf_ringbuf_submit(page_data, 0); return 0; }。

[0059] In the user state, data is taken from the target buffer, and according to the base address and bitmap, the data is reassembled into a complete memory image and written back to the file, thereby completing the file unpacking.

[0060] In some embodiments, reading the data from the target buffer in the user state includes: Asynchronously reading the data from the target buffer in the user state.

[0061] In embodiments where the target buffer is a ring buffer, data is asynchronously taken from the ring buffer in the user state, and according to the base address and bitmap, the data is reassembled into a complete memory image and written back to the file, thereby completing the file unpacking.

[0062] The relevant script can be as follows: static int handle_event(void *ctx, void *data, size_t len) { struct dump_meta *meta = data; void *bitmap = meta + 1; void *pages = (char *)bitmap + meta->bitmap_bytes; char fname

[64] ; snprintf(fname, sizeof(fname), "dump.%d.mem", meta->pid); int fd = open(fname, O_RDWR | O_CREAT, 0644); if (fd < 0) { perror("open"); return 0;} if (ftruncate(fd, meta->len) < 0) perror("ftruncate"); void *base = mmap(NULL, meta->len, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (base == MAP_FAILED) { perror("mmap"); goto out;} / * Write back pages as bitmap * / for (__u32 i = 0; i < meta->nr_dirty; i++) { __u32 idx = i; void *dst = (char *)base + (idx << 12); memcpy(dst, pages + (idx << 12), 4096); } munmap(base, meta->len); printf("dumped %d dirty pages for pid %d\n", meta->nr_dirty,meta->pid); out: close(fd); return 0; }。

[0063] Data is asynchronously output to the user state through a ring buffer, which does not block the process execution and is suitable for production environment or high-frequency triggering scenarios.

[0064] Reference Figure 3 A specific embodiment is described below.

[0065] A probe is inserted at a target system call of the kernel, and an eBPF program is injected at the probe.

[0066] An execve event is monitored, and process creation behavior is collected.

[0067] An ELF file header of a newly created process is read, and module features are identified.

[0068] A process PID, path, and parameters are recorded, and a shellable process is added to a map of processes to be tracked.

[0069] Mmap / mprotect events are monitored, and memory allocation and permission change behavior are collected.

[0070] Permission change frequency is detected, entropy value change is detected, and call chain depth is analyzed.

[0071] If the permission change frequency is greater than or equal to the preset frequency threshold, and the reduction amount of the entropy value in the preset time is greater than or equal to the preset entropy reduction threshold, and the call chain depth reaches the preset threshold and a back edge occurs, it is considered that the shell triggering condition is met.

[0072] Performing dumping on the executable memory region that has changed.

[0073] The dirty page bitmap is recorded by using the VMA tracking function of the eBPF program. The VMA tracking function of the eBPF is to observe the creation, modification, destruction and permission / content change of the process virtual memory area (VMA) in real time and non-intrusively by using the eBPF program, and send the key events (start address, length, permission, dirty page bitmap, etc.) to the user state for further analysis.

[0074] Writing the dirty page content into the ring buffer.

[0075] Asynchronously outputting the dirty page content to the user state through the ring buffer.

[0076] Reorganizing the data into a complete memory image according to the base address and the dirty page bitmap in the user state and writing back to the file.

[0077] The file shell method provided by the embodiment of the application realizes kernel-level monitoring: directly monitoring system calls and memory operations in the kernel space by using the eBPF technology; performing dynamic behavior analysis: identifying a shell opportunity by analyzing the runtime behavior characteristics of a program; realizing non-susceptible shell: completing the shell operation without interfering with the normal operation of the program; realizing cross-platform support: realizing compatibility across different kernel versions by using the CO-RE technology; realizing dynamic Dump dirty pages: only dumping the executable memory region that has changed, avoiding the I / O bottleneck caused by full memory dump; and realizing asynchronous reorganization of data based on a bitmap.

[0078] Reference Figure 4 As a specific implementation mode, the kernel state can include a key system call monitoring module, a shell triggering detection module, a memory dump module and the like. The key system call monitoring module monitors execve and mmap / mprotect. The shell triggering detection module performs permission change frequency detection, entropy value analysis and call chain depth analysis. The eBPF map is a general data structure for storing different types of data, and provides functions such as user state and kernel state data interaction, data storage, and multi-program shared data. When the shell triggering condition is met, the memory dump module performs memory dump and writes the dirty page content into the ring buffer.

[0079] Asynchronously outputting the dirty page content to the user state through the ring buffer.

[0080] The user state dump processing module reorganizes the data into a complete memory image. The user state policy module updates the threshold corresponding to the call chain depth recorded in the eBPF map by using a hot update strategy.

[0081] In summary, the file unshelling method inserts a probe at a target system call of a kernel, injects the probe into a target program, and performs suspicious shell process identification and dumping through execution of the target program. The target program runs in the kernel and does not need to modify the user state memory. The target program performs process filtering, identifies suspicious shell processes, and only dumps the decrypted data of the suspicious shell processes, thereby avoiding I / O bottlenecks caused by full memory dumping, reducing user state invalid data, and reducing CPU occupancy and memory bandwidth.

[0082] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be realized by means of software on a general hardware platform as necessary, and of course can also be realized by hardware, but in many cases the former is a better embodiment.

[0083] Embodiments of the present application also provide a file unshelling device, referring to Figure 5 As shown in the figure, the file unshelling device comprises: The insertion module 10 is used for inserting a probe at a target system call of a kernel, and injecting the probe into a target program; The identification module 20 is used for identifying a suspicious shell process through the target program; The monitoring module 30 is used for monitoring memory permission change behavior performed by the suspicious shell process through the target program, and counting permission change frequency of a memory region, an entropy value of the memory region, and a call chain depth; The writing module 40 is used for writing data decrypted by the suspicious shell process into a target buffer through the target program when it is determined that the suspicious shell process is in an unshelling stage according to the permission change frequency, the entropy value, and the call chain depth; The reorganization module 50 is used for reading the data from the target buffer in a user state, and reorganizing 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.

[0084] On the basis of the above embodiments, as a specific embodiment, the judgment module 40 comprises: The first judgment unit is used for judging whether the permission change frequency satisfies a first preset condition; The second judgment unit is used for judging whether the entropy value satisfies a second preset condition; The third judgment unit is used for judging whether the call chain depth satisfies a third preset condition; The determining unit is configured to determine that the suspiciously packed process is in a de-packing stage 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.

[0085] On the basis of the above-mentioned embodiments, as a specific implementation, the first judging unit is configured to: determine whether the permission change frequency is greater than or equal to a preset frequency threshold value; if the permission change frequency is greater than or equal to the preset frequency threshold value, the permission change frequency meets the first preset condition; if the permission change frequency is less than the preset frequency threshold value, the permission change frequency does not meet the first preset condition.

[0086] On the basis of the above-mentioned embodiments, as a specific implementation, the second judging unit is configured to: determine whether a reduction amount of the entropy value within a preset time is greater than or equal to a preset entropy reduction threshold value; if the reduction amount of the entropy value within the preset time is greater than or equal to the preset entropy reduction threshold value, the entropy value meets the second preset condition; if the reduction amount of the entropy value within the preset time is less than the preset entropy reduction threshold value, the entropy value does not meet the second preset condition.

[0087] On the basis of the above-mentioned embodiments, as a specific implementation, the second judging unit includes: an entropy reduction threshold value determining sub-unit configured to determine a preset entropy reduction threshold value corresponding to the shell type according to the shell type, and different shell types are provided with independent entropy reduction threshold values; an entropy value judging sub-unit configured to determine whether a reduction amount of the entropy value within a preset time is greater than or equal to the preset entropy reduction threshold value corresponding to the shell type.

[0088] On the basis of the above-mentioned embodiments, as a specific implementation, the third judging unit is configured to: determine whether the call chain depth reaches a preset threshold value and whether a back edge appears; if the call chain depth reaches the preset threshold value and the back edge appears, the call chain depth meets the third preset condition; if the call chain depth does not reach the preset threshold value and / or the back edge does not appear, the call chain depth does not meet the third preset condition.

[0089] On the basis of the above-mentioned embodiments, as a specific implementation, the identification module 20 includes: a monitoring unit configured to monitor process creation behavior through the target program; a reading unit configured to read a file header of an entity file of a created new process; A judging unit is configured to judge whether the file header contains a magic number feature. A confirming unit is configured to, if the file header contains the magic number feature, determine that the created new process is a suspiciously packed process.

[0090] As a specific implementation, the plug-in module 10 is used for: In the probe injection extended Berkeley packet filter program.

[0091] As a specific implementation, the plug-in module 10 is further used for: An entropy drop threshold configuration module is configured to configure the corresponding entropy drop threshold according to the shell type.

[0092] As a specific implementation, the plug-in module 10 is further used for: A threshold writing module is configured to write the preset threshold into a target array in the user mode; and the preset threshold supports hot updating.

[0093] As a specific implementation, the writing module 40 is used for: Writing, by the target program, the data decrypted from the suspiciously packed process into a ring buffer.

[0094] As a specific implementation, the reorganization module 50 is used for: Reading, asynchronously in the user mode, the data from the target buffer.

[0095] The file unpacking device provided by the present application inserts a probe at a target system call of a kernel, and injects the probe into a target program, so that the target program performs operations such as identifying a suspiciously packed process and dumping, and the target program runs in the kernel and does not need to modify user mode memory. The target program performs process filtering, identifies a suspiciously packed process, and dumps data decrypted from the suspiciously packed process, so that I / O bottlenecks caused by full memory dumping can be avoided, and user mode invalid data can be reduced, and CPU occupancy and memory bandwidth can be reduced.

[0096] The features of the embodiments of the file unpacking device can be referred to the related descriptions of the embodiments of the file unpacking method, which will not be repeated here.

[0097] Embodiments of the present application also provide an electronic device, as shown in Figure 6 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 file unpacking method embodiments.

[0098] The electronic device provided by the application inserts a probe at a target system call of a kernel, and injects the probe into a target program, so that the target program running in the kernel can perform operations such as identifying suspiciously armored processes and dumping, without the need to modify user memory.

[0099] The embodiment of the application further provides a computer readable storage medium, and the computer readable storage medium stores a computer program.

[0100] In an example embodiment, the computer readable storage medium can include, but is not limited to, a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store a computer program.

[0101] The embodiment of the application further provides a computer program product, and the computer program product includes a computer program.

[0102] The embodiment of the application further provides another computer program product, and the computer program product includes a non-volatile computer readable storage medium.

[0103] Those skilled in the art can further realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be realized by electronic hardware, computer software or a combination of both. In order to clearly illustrate the interchangeability of hardware and software, the components and steps of the examples have been described in the above description in general terms. Whether the functions are realized 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 realize the described functions for each specific application, but such implementation should not be considered beyond the scope of the application.

[0104] The above describes in detail the file unshelling method and the electronic device provided by the present application. The principles and implementation manners of the present application are described by using specific examples, and the above description of the examples is only applicable to helping understand the method of the present application and the core idea thereof. It should be pointed out that, for those skilled in the art, without departing from the principles of the present application, the present application can be improved and modified in several ways, and these improvements and modifications also fall within the protection scope of the present application.

Claims

1. A file de-encapsulation method, characterized by, The method 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 packed process through the target program; monitoring a memory permission change behavior performed by the suspiciously packed 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 determined that the suspiciously packed process is in an unpacking stage according to the permission change frequency, the entropy value, and the call chain depth, writing, by the target program, data decrypted by the suspiciously packed process into a target buffer; reading, in a user mode, the data from the target buffer, 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.

2. The file un-cabbing method of claim 1, wherein, The step of determining whether the suspiciously packed process is in the unpacking stage according to the permission change frequency, the entropy value, and the call chain depth comprises the following steps: determining whether the permission change frequency satisfies a first preset condition; determining whether the entropy value satisfies a second preset condition; determining whether the call chain depth satisfies a third preset condition; if the permission change frequency satisfies the first preset condition, the entropy value satisfies the second preset condition, and the call chain depth satisfies the third preset condition, the suspiciously packed process is in the unpacking stage.

3. The file decapsulation method of claim 2, wherein, The step of determining whether the permission change frequency satisfies the first preset condition comprises the following steps: determining whether the permission change frequency is greater than or equal to a preset frequency threshold; if the permission change frequency is greater than or equal to the preset frequency threshold, the permission change frequency satisfies the first preset condition; if the permission change frequency is less than the preset frequency threshold, the permission change frequency does not satisfy the first preset condition.

4. The file unstuffing method of claim 2, wherein, The step of determining whether the entropy value satisfies the second preset condition comprises the following steps: determining whether a reduction amount of the entropy value within a preset time is greater than or equal to a preset entropy reduction threshold; if the reduction amount of the entropy value within the preset time is greater than or equal to the preset entropy reduction threshold, the entropy value satisfies the second preset condition; if the reduction amount of the entropy value within the preset time is less than the preset entropy reduction threshold, the entropy value does not satisfy the second preset condition.

5. The file unstuffing method of claim 4, wherein, The step of determining whether the reduction amount of the entropy value within the preset time is greater than or equal to the preset entropy reduction threshold comprises the following steps: determining the preset entropy reduction threshold corresponding to the shell type according to the shell type; different shell types are provided with independent entropy reduction thresholds; determining whether the reduction amount of the entropy value within the preset time is greater than or equal to the preset entropy reduction threshold corresponding to the shell type. Correspondingly, the method further comprises the following step: configuring the corresponding entropy reduction threshold according to the shell type.

6. The file unstuffing method of claim 2, wherein, The step of determining whether the call chain depth satisfies the third preset condition comprises the following steps: determining whether the call chain depth reaches a preset threshold and whether a back edge occurs; if the call chain depth reaches the preset threshold and the back edge occurs, the call chain depth satisfies the third preset condition; if the call chain depth does not reach the preset threshold and / or the back edge does not occur, the call chain depth does not satisfy the third preset condition.

7. The file unstuffing method of claim 1, wherein, The step of identifying the suspiciously packed process through the target program comprises the following steps: monitoring a process creation behavior through the target program; reading a file header of an entity file of a newly created process; determining whether the file header contains a magic number feature; if the file header contains the magic number feature, the newly created process is a suspiciously packed process.

8. The file unstuffing method of claim 6, wherein, The method further comprises the following steps: writing the preset threshold into a target array in the user mode; The preset threshold supports hot update.

9. The file unstuffing method of claim 1, wherein, writing, by the target program, the data decrypted from the suspicious packed process into a target buffer includes: writing, by the target program, the data decrypted from the suspicious packed process into a ring buffer.

10. An electronic device, comprising: comprising: a memory for storing a computer program; a processor for implementing the steps of the file unpacking method according to any one of claims 1 to 9 when executing the computer program.

Images