System call trace reconstruction

Abstract

The present disclosure relates to system call trace reconstruction, and specifically introduces techniques for system call trace reconstruction. A method includes determining, by one or more processors, a set of memory locations of a kernel memory structure. The set of memory locations store data indicative of one or more parameters of a user- associated process. The method further includes determining that a first value of a first memory location of the set of memory locations has changed. The method further includes determining an execution of a first system call associated with the user-associated process and the kernel memory structure. The method further includes retrieving one or more values corresponding to respective memory locations of the set of memory locations associated with the first system call. The method further includes providing an output identifying the first system call based on the one or more values corresponding to the respective memory locations.

Description

[0001] Related applications

[0002] This application claims the benefits of U.S. Provisional Application No. 63 / 239,966, filed September 2, 2021, and U.S. Provisional Application No. 63 / 359,750, filed July 8, 2022, the entire contents of which are incorporated herein by reference. Technical Field

[0003] At least one embodiment involves system call tracing reconstruction. For example, at least one embodiment involves a live stack trace. Background Technology

[0004] Cyberattacks often use malware as a means of damaging and / or compromising computers and / or computer systems. A widely used method to prevent malware is virtual machine introspection (VMI). By performing forensic analysis on volatile memory, VMI detects malicious programs that have infiltrated virtual machines (VMs). Memory forensics can be used to gather information when an incident occurs. Its current state can be determined by inferring the VM's current state (e.g., active processes and loaded kernel modules). Malicious activity can be detected by analyzing the VM's current state. In contrast, disk forensics examines artifacts left by cybersecurity attacks. By using memory forensics to construct the behavioral environment of malware and advanced persistent threats, it makes malware very difficult to detect. Attached Figure Description

[0005] Various embodiments of this disclosure will be described with reference to the accompanying drawings, in which:

[0006] Figure 1 A block diagram illustrating system call enabling flow according to at least some embodiments is shown;

[0007] Figure 2 This is a schematic diagram illustrating system call tracing according to at least one embodiment.

[0008] Figure 3A This is a block diagram illustrating an intrusive system call tracing process according to at least one embodiment.

[0009] Figure 3B This is a block diagram illustrating a non-intrusive system call tracing process according to at least one embodiment.

[0010] Figure 4 This is a block diagram illustrating a kernel memory structure according to at least one embodiment.

[0011] Figure 5 This is a block diagram illustrating a kernel memory structure according to at least one embodiment.

[0012] Figure 6 This is a block diagram illustrating the reconstruction of system call traces according to at least one embodiment.

[0013] Figure 7 This is a flowchart of a system call tracing and reconstruction method according to an embodiment of the present disclosure.

[0014] Figure 8 A block diagram depicts an example computing device operating according to one or more aspects of this disclosure. Detailed Implementation

[0015] Techniques for reconstructing system call traces are described. As mentioned above, cyberattacks often use malware as a means of damaging and / or destroying computers and / or computer systems. A widely used method to prevent malware is Virtual Machine Introspection (VMI). By performing forensic analysis on volatile memory, VMI detects malicious programs that have infiltrated virtual machines (VMs). Memory forensics can be used to gather information when an incident occurs. Its current state can be determined by inferring the VM's current state (e.g., active processes and loaded kernel modules). Malicious activity can be detected by analyzing the VM's current state. In contrast, disk forensics examines artifacts left by cybersecurity attacks. By using memory forensics to construct the behavioral environment of malware and advanced persistent threats, it makes malware very difficult to detect.

[0016] Cybercrime is evolving, and detecting malware is becoming increasingly challenging due to its growing ability to evade detection systems. System call tracing logs the operations performed by malware. Tracing system calls typically employs memory forensics methods that manipulate the raw memory image and analyze kernel thread stack states to infer executed system calls. Trap-based methods utilize the processor's ability to hook into events such as system calls, allowing the hypervisor to trace each executed call. VMs can be traced via their guest operating system (OS) and with the help of tools installed within them (such as "strace"). However, this can lead to significant performance degradation on legacy systems.

[0017] Guest-in-the-virtual (VMI) tracking tools can also lead to the observer effect. Sophisticated malware programs can detect and disable tracking tools, for example, by hiding malware behavior or disabling them entirely. To reduce the ability of malware to evade detection, VMI technology places data collection methods outside the infected virtual machine.

[0018] VMI methods are invasive and can impact the performance of programs running within a virtual machine. These methods interfere with code execution and are therefore classified as invasive. In trap-based methods, the VM must exit and re-enter, resulting in high latency penalties. Because existing memory forensics methods operate on a static raw memory image, recording real-time system call traces of processes running within a VM may require pausing the VM after each system call, obtaining the raw memory image, interpreting the call, and then resuming the call afterward. Live-tracking the VM using a combination of memory forensics techniques and trap-based methods also impacts VM performance and security analyst response time.

[0019] Because the goal of non-intrusive system calls is to avoid interfering with VM execution, tracing them via VMI is difficult. For non-intrusive tracing, a separate thread is typically used to actively track executed system calls without requiring special hardware support. For introspection to function correctly, tracing must be faster than the system calls themselves. Otherwise, executed system calls will not be detected. Current programs heavily rely on the processor to optimize system call enable latency. Therefore, analyzing the entire raw memory image using current pure software methods typically takes a very long time.

[0020] Various aspects and embodiments of this disclosure can provide a method and / or tool for non-intrusive system call tracing on a live processor (e.g., a VM running on a Linux x86_64 OS). To trace system calls to a specific process, the security analyst's input can indicate the process identifier to be passed to the tool. In response, the tool can analyze the processor's memory to recover register data stored by the operating system when the system call was invoked. Using the register values, the tool can construct a system call trace.

[0021] Various aspects of this disclosure aim to overcome the challenge of implementing a non-intrusive tracer that is faster than any system call tracer. Specifically, various aspects of this disclosure can determine the exact physical address of the registers used to recover system calls by caching their virtual-to-physical translations. Various aspects of this disclosure also include passing these addresses to a dedicated memory sampling framework, such as the Quick Emulator (QEMU) hypervisor. Various aspects of this disclosure also include using the same register values ​​to detect system call execution and / or recovery system call information.

[0022] In an example embodiment, the method includes determining a set of memory locations of a kernel memory structure using one or more processors. This set of memory locations may store data indicating one or more parameters of a user-associated process. The method also includes determining that a first value of a first memory location within the set of memory locations has been changed. The method further includes determining the execution of a first system call associated with the user-associated process and the kernel memory structure. The method also includes retrieving one or more values ​​corresponding to each memory location in the set of memory locations associated with the first system call. The method further includes providing output identifying the first system call based on the one or more values ​​corresponding to each memory location.

[0023] The disclosed aspects improve upon traditional system call tracing techniques by providing systems, methods, and devices capable of real-time system call tracing, which do not rely on post-hoc analysis (e.g., offline) reconstruction of memory structures. These aspects provide techniques for acquiring and analyzing system calls without interrupting ongoing system processes (e.g., without increasing latency). These advancements in the disclosure could enable highly difficult-to-detect and satisfactory non-intrusive surveillance techniques for modern malware.

[0024] Figure 1 A block diagram 100 illustrating a system call enablement process according to at least some embodiments is shown. Main memory 122 has registers allocated within kernel space 104 and some registers allocated within user space 102. During the execution of the operating system (OS) kernel, application threads can run in a non-privileged mode within the physical kernel. The application can execute in this non-privileged mode until a trap handler transfers control back to the kernel in privileged mode. Enabling a system call 112 may involve the same process. The application can use processor instructions (e.g., int 0x80 or syscall in x86 architecture) to transfer control to the trap handler that executes the requested system call.

[0025] Function wrappers for system calls abstract operating system-specific functionality from system calls. For example, the libc "fread()" method can be used to read data from an open file handler to invoke the corresponding Windows and Linux system calls. Internally, these wrappers set processor registers according to predefined calling conventions that both the operating system and the processor adhere to. For example, the system call number and its result are stored in the "rax" register of the x86_64 Linux kernel. Furthermore, "rdx" is used to signal errors, while "rdi", "rsi", "rdx", "r10", "r8", and "r9" are used to pass system call arguments.

[0026] OS system call handler 114 can save user register 124, enable the requested system call 112, and set the return value 110 in the appropriate register. Registers not defined as callee-clobbered can be restored by the kernel before returning execution to a non-privileged program.

[0027] Virtual Machine Introspection (VMI) can refer to a technique for monitoring the state of a virtual machine and performing forensic analysis on it. In some embodiments, VMI utilizes a hypervisor, which may include a layer of software running on the hardware to manage the VM. The hypervisor can access VM memory and apply trap 122, thereby being able to obtain information about the internal state of the VM. The hypervisor may execute in a higher privilege mode than the VM and is unaffected by processes executing within it.

[0028] Different frameworks can be used to automate VMI processes for different operating systems, such as Linux and Windows. These frameworks can facilitate the implementation of memory forensics tools that bridge semantic gaps and learn the behavior of processes executing in VMs.

[0029] Real-time analysis of user register value 124, including setting register value 110 and storing register value 116, was incorporated into the Endpoint Intrusion Detection System (IDS). IDS detects malware by continuously introspecting the state and behavior of the virtual machine.

[0030] Some systems employ highly intrusive methods that leverage agents installed within the virtual machine (VM) to communicate with introspection tools. However, these agents are vulnerable to malware and may be subject to installation rules that could require modifications to the VM that are not authorized for certain users. On some systems, less intrusive methods may exploit the hypervisor's control over the VM. For example, the hypervisor can pause the VM via a trap. Specifically, the introspection tool can read the data being modified. Inconsistent data reads can cause the introspection tool to malfunction or report incorrect results. The VM pause method can also severely impact the performance of the introspection application.

[0031] Various aspects of this disclosure utilize non-intrusive methods. Using non-intrusive methods eliminates the dependency on hypervisor functionality for pausing and / or resuming VMs. Furthermore, using non-intrusive methods may not affect the execution of the tracing process.

[0032] Figure 2This is a schematic diagram 200 illustrating system call tracing according to at least one embodiment. Given a raw live image of a guest, system calls can be traced by detecting whether a system call is currently being executed and restoring the values ​​of the computational processing unit (CPU) registers. Detecting system calls using traps may involve placing traps on the system call handler address. This address is obtained from the OS intermediate symbol table (IST), which is generated from a mapping file (e.g., the system mapping file in Linux). However, placing traps on each system call may slow down guest processing execution. A guest can refer to a virtual machine, a guest OS, a container, or any other execution environment in a computer system. The slowdown may be at least in part due to the transfer of control (e.g., VM exit) to the host OS or hypervisor that occurs on each trap.

[0033] like Figure 2 As shown, application execution (e.g., application execution of program 202) can be observed as a computation sequence interleaved with system call enablement in non-privileged mode. A non-intrusive introspection tool polls changes in VM memory to detect new system calls while inferring that the executed system calls should be faster than any system calls enabled by the application. Figure 2 As shown, the fast introspection tool 204 can poll and trace when processing system calls, while the slow introspection tool 206 can incorrectly identify system calls because polling is too slow.

[0034] Figure 3A This is a block diagram 300A illustrating an intrusive system call tracing process according to at least one embodiment. Each system call in the system passes through a call gate. For example, in the Linux kernel, each system call passes through the "do_syscall_64" call gate. In preparation phase 302, introspection tool 320 places trap 322 on a memory call (e.g., "do_syscall_64") from VM 316A-B to program register 310. User 308 sets the program for tracing, and introspection tool 320 infers the program's kernel stack address and the address of the stored user register associated with the user program, program register 310. When the program executes (execution phase 304) and system calls are enabled, the introspection tool receives an indication via system call trap 324 and infers the system call at 326 by reading the value of program register 310. In some embodiments, the identified system call is appended to a log or trace file and stored in a common location with other inferred system calls. In some embodiments, the introspection tool 320 resides in the manager 312 or other guest execution structure and / or is executed by the manager 312 or other guest execution structure.

[0035] Figure 3BThis is a block diagram 300B illustrating a non-intrusive system call tracing process according to at least one embodiment. When system calls are enabled, each kernel stores a unique number in a register field (e.g., program register 310) corresponding to the user program. For example, when system calls are enabled, the Linux kernel stores a unique number in the "rax" register field. Specifically, a single value (e.g., -ENOSYS in the Linux operating system) is set before the system call begins and modified after the system call completes its execution. In the preparation phase 352, an introspection tool 320 sets up a polling thread (e.g., a "poller") to continuously monitor changes in system calls indicating a unique value (e.g., -ENOSYS in the "rax" register field). During the execution phase 354, the introspection tool 320 polls and analyzes the value of program register 310 and infers the system call at 358. In some embodiments, the identified system call is appended to a log or trace file and stored in a common location with other inferred system calls.

[0036] In preparation stages 302 and 352, the introspection tool 320 obtains information for introspection applications (e.g., ... Figure 3B The getpid() function and PID = 100 are shown. The introspection tool 320 initializes system call detection mechanisms: traps for intrusive methods and polling for non-intrusive methods, such as... Figure 3A -B is shown.

[0037] Note that each operating system can store thread contexts that are typically different from each other. For example, in Linux, the "task-struct" structure contains information about each process. Extracting the contents of this structure can be done in various ways, including using software plugins.

[0038] In some embodiments, the processing logic uses a VMI approach that involves constructing a profile of the thread structure. This profile may reflect the intermediate symbol table (IST) of a given operating system kernel (e.g., the Linux kernel) and provide explicit offsets for all kernel symbols. In some embodiments, the IST has the exact address of the process list header, and traversing this list utilizes the VMI's virtual-to-physical translation capabilities. For example, the traversal may stop when a "task-struct" with a user-provided process identifier is found. This "task-struct" can then be used in the next stage to retrieve the value of a process register (e.g., program register 310).

[0039] Figure 4This is a block diagram 400 illustrating a kernel memory structure according to at least one embodiment. In some embodiments, the main memory (e.g., the main memory 314 of FIG3, sometimes referred to as the "kernel memory structure") may include information about processes, such as their parent, children, names, virtual memory addresses, and / or thread-related information, such as... Figure 4 As shown. For example, “task_struct” 402 may include kernel stack 404, which includes a single register containing user program information.

[0040] Introspection tools (e.g., introspection tool 320 in Figure 3) analyze main memory (e.g., task_struct 402 stored in the kernel region of physical memory), following a stack pointer that points to the top of the kernel stack for the corresponding thread. When a function is enabled in the kernel, the kernel stack is used as a traditional stack. Specifically, the kernel stack's "frame matching function" returns an address and arguments, along with a frame pointer. However, the kernel stack also stores thread context (e.g., "thread_info"). For example, in the Linux kernel memory structures, a "thread_info" structure is stored at the top of the task_struct 402 stack, a "pt_regs" structure is stored at the bottom of the stack, and may be followed by a value for detecting unauthorized stack size modifications. Thread context (e.g., "thread_info" in Linux) is used to compute addresses in main memory and map them to addresses in kernel memory structures (e.g., kernel stack 404). The use of thread context provides a bidirectional mapping between kernel memory structures (e.g., kernel stack 404) and main memory structures (e.g., "task_struct" 402).

[0041] In some embodiments, the kernel stack is page-aligned and can be limited to 16 kilobytes (KB) or 32 KB in size.

[0042] In some embodiments, the IST may not contain the kernel stack size, and may need to calculate the exact address of a program register structure (e.g., "pt_regs"). In some embodiments, the introspection tool may infer the exact kernel stack size and use it to calculate the address of "pt_regs". For example, the introspection tool may read the memory of the kernel stack from the top of the stack and eventually reach an invalid address that may represent the bottom of the stack. The introspection tool may further determine the "pt_regs" structure, which can be obtained by subtracting the inferred address from the size of the "pt_regs" structure, which can be obtained from the IST.

[0043] Figure 5This is a block diagram 500 illustrating a kernel memory structure according to at least one embodiment. Figure 5 A single register 504 stored in kernel memory structure 502 is depicted. The IST contains distinct offsets for each register field relative to the beginning of the "pt_regs" structure. The absolute address of each field can be calculated using "pt_regs". Introspection tools can read the values ​​of the registers (e.g., using a memory acquisition implementation with VMI). Introspection tools can obtain the location of the registers and map their contents back to system call instructions.

[0044] In some embodiments, one of the register locations (e.g., the "rax" register location) stores the number of the system call being executed. This register value can be used as an identifier for invoking the corresponding system call. The parameters of the corresponding system call can be stored in the corresponding register locations of the respective registers 504. For example, in a Linux environment, the parameters of the system call function can be stored in "rdi", "rsi", "rdx", "r8", "r10", and "r9".

[0045] In some embodiments, introspection tools are implemented by placing traps on memory accesses to specific physical addresses. For example, in a Linux environment, a trap might be placed on the physical address "do_syscall_64". The trap can enable callback functions that enumerate the calling process's memory by obtaining per-thread structures. For example, an interrupt function can be generated on a specific address access. When a guest accesses an address, the introspection processing component (e.g., the hypervisor or host operating system) can enable system call tracing for the introspection tools before returning control to the VM.

[0046] In some embodiments, the introspection tool identifies when the Linux kernel is processing a new system call by polling accesses to memory structures (e.g., "pt_regs"). The introspection tool may use a separate thread that continuously polls register addresses to identify new system call frames.

[0047] During execution, the introspection tool detects system calls and infers their identities using kernel memory structures (e.g., "pt_regs"). Specifically, the introspection tool can poll specific fields (e.g., "ax" and "orig_ax"). The introspection tool can use the stored values ​​as an indexer of the Linux kernel system call table to infer system call identifiers. For example, it maps system calls to unique integer values.

[0048] In some embodiments, enabling system call instructions places the next program instruction into a register field (e.g., "rip") as the return address. The instructions preceding the return address may contain valid system call instruction opcodes. For example, in the x86_64 architecture, available system call instructions include the "SYSCALL", "SYSENTER", "int 0x80", and "0xCD80" data fields, respectively. An introspection tool can read two bytes before the return address and match them against the aforementioned opcodes. For non-intrusive tracing embodiments, the tracing process can be performed by a background thread that can hide verification delays and operate independently of the tracing thread (e.g., without competing with the tracing thread).

[0049] Figure 6 This is a block diagram illustrating a system call tracing reconstruction system 600 according to at least one embodiment. Figure 6 As shown, the system call tracing reconstruction system 600 includes a direct communication channel 616 between a system call introspection component 602 and a hypervisor 612. The system call introspection component 602 may have access to the introspection library (libVMI) 604. The hypervisor 612 may wait for requests from shared memory regions of the LibVMI tracing tool. Each request may contain the physical address of a register associated with the user program (e.g., “pt_regs”), and an offset for each register obtained from the IST. Once a request arrives, a thread (e.g., polling thread 614) can be selected from a thread pool to continuously poll user program-specific registers (e.g., “ax”) of the kernel 606 and / or the kernel virtual machine (KVM) 608. After the application terminates, the thread returns to the pool and is free to handle new requests. The polling thread 614 can access kernel registers continuously via cache lines.

[0050] In some embodiments, user program-specific register locations are computed in the virtual address space. For example, polling changes in the "ax" member may require translating virtual resource locations into physical memory locations.

[0051] In some embodiments, upon system call, kernel 606 stores register values ​​associated with the user program. Once all registers are stored, one of them (e.g., the "ax" field) may store a unique value indicating the activation or termination of the system call. After storing the register values, kernel 606 may enable the system call. The result is that the return value of the system call replaces the unique value ("-ENOSYS") stored in a specific part of the memory structure (e.g., the "ax" field).

[0052] In some embodiments, polling thread 614 executes on a different core than kernel 606 (e.g., hypervisor 612 and / or guest VM 610). Polling thread 614 may observe whether a unique value (“-ENOSYS”) is in a specific field (e.g., the “ax” field) and further determine whether a system call is currently activated based on a value stored in that specific field.

[0053] Figure 7 This is a flowchart of a method 700 for system call tracing reconstruction according to an embodiment of this disclosure. Method 700 can be executed by processing logic, which may include hardware (circuit, dedicated logic, etc.), software (such as executing on a general-purpose computer system or a dedicated machine), or any combination thereof. In one implementation, method 700 is executed by the introspection tool 320 of FIG3, while in some other implementations… Figure 7 One or more blocks can be executed by one or more other machines not shown in the diagram.

[0054] At block 702, processing logic (e.g., system call introspection 602, polling thread 614) determines a set of memory locations on the kernel memory structure (e.g., kernel 606). This set of memory locations corresponds to a user-associated process (e.g., an application or function that receives memory allocations on the kernel memory structure). For example, in a Linux environment, this set of memory locations may include, for instance, processes such as... Figure 5 The data field of memory register 504.

[0055] In some embodiments, this set of memory locations is associated with user-associated processes. User-associated processes may correspond to a VM (e.g., a guest OS or a guest application, e.g.) Figure 6 The guest processing component (VM 610), container, or any other process executing within the computer system. For example, the processing logic can be performed using a hypervisor that runs along with the kernel memory structure associated with the VM for memory allocation. In another embodiment, method 500 can be executed by a first processing core, while kernel operations (e.g., management of the kernel memory structure, execution of system calls, etc.) can also be executed by a second processing core. The first and second processing cores can include any combination of guest processing components (e.g., VM, hypervisor, container, etc.) and physical processing structures (e.g., non-transitory storage media, physical processing components, native processing components, etc.).

[0056] In some embodiments, the processing logic extracts data indicating the thread context of the kernel memory structure (e.g., ...). Figure 6(e.g., KVM 608 and / or Kernel 606). The thread context may correspond to a first operating system (e.g., Linux). One or more memory locations may be determined based on the thread context. For example, the thread context may include an intermediate symbol table (IST) corresponding to the first operating system.

[0057] In some embodiments, logical polling is handled (e.g., using polling thread 614) via a guest (e.g., Figure 6 The guest VM (610) requests access to one or more memory locations in the kernel memory structure. The processing logic can be handled by a different guest (e.g., VM 610) that operates alongside the kernel memory structure. Figure 6 The execution entity (e.g., hypervisor) of the guest VM (610) is used for execution. For example, one or more processors may be executed by a side processor (such as the vSphere Management Assistant (VMA) engine) and / or a Peripheral Component Interconnect Express (PCIe) device independent of the kernel memory architecture.

[0058] At block 704, the processing logic determines that the first value of the first location in the group of memory locations has changed. For example, in a Linux environment, the first value may include the "-ENOSYS" value, and the first location in the group of memory locations may include an "ax" data field.

[0059] At block 706, the processing logic determines the execution of the first system call associated with the user-associated process and kernel memory structures. Changes in the values ​​of specific registers may trigger the introspection tool to identify that a system call has occurred. The introspection tool can determine which system call was enabled based on specific register values ​​and / or combinations of register values.

[0060] At block 708, the processing logic retrieves one or more values ​​corresponding to each memory location in the set of memory locations associated with the first system call. For example, each memory location in the set of memory locations may include parameters for the system call function. In a Linux environment, these memory locations may include one or more of the data fields “rdi”, “rsi”, “rdx”, “r8”, “r10”, and “r9”.

[0061] At block 710, the processing logic provides an output identifying the first system call based on one or more values ​​corresponding to each memory location. In some embodiments, the identified system call is appended to a log or trace file and stored in a common location with other inferred system calls.

[0062] Figure 8A block diagram depicts an example computing device 800 operating according to one or more aspects of this disclosure. In various illustrative examples, various components of the computing device 800 may represent various components of the client device 150, metering system 110, server 120, data repository 140, manufacturing system 102, and machine learning system 170, such as... Figure 1 As shown.

[0063] Example computing device 800 can be connected to other computer devices in a LAN, intranet, extranet, and / or the Internet. Computing device 800 can operate at server capacity in a client-server network environment. Computing device 800 can be a personal computer (PC), set-top box (STB), server, network router, switch, or bridge, or any device capable of executing a set of instructions (sequentially or otherwise) specifying the actions the device should take. Furthermore, although only a single example computing device is shown, the term "computer" should also be understood to include any collection of computers that individually or jointly execute a set (or more) of instructions to perform any or more methods discussed herein.

[0064] Example computing device 800 may include processing device 802 (also called processor or CPU), main memory 804 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM), such as synchronous DRAM (SDRAM) etc.), static memory 806 (e.g., flash memory, static random access memory (SRAM) etc.), and auxiliary memory (e.g., data storage device 818), which can communicate with each other via bus 830.

[0065] Processing device 802 represents one or more general-purpose processing devices, such as microprocessors, central processing units, etc. More specifically, processing device 802 may be a Complex Instruction Set Computing (CISC) microprocessor, a Reduced Instruction Set Computing (RISC) microprocessor, a Very Long Instruction Word (VLIW) microprocessor, a processor implementing other instruction sets, or a processor implementing combinations of instruction sets. Processing device 802 may also be one or more special-purpose processing devices, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, etc. According to one or more aspects of this disclosure, processing device 802 may be configured to execute implementations of FIG500. Figure 6 The instructions for method 600 are shown.

[0066] The example computing device 800 may also include a network interface device 808, which can be communicatively coupled to a network 820. The example computing device 800 may also include a video display 810 (e.g., a liquid crystal display (LCD), a touch screen, or a cathode ray tube (CRT)), an alphanumeric input device 812 (e.g., a keyboard), a cursor control device 814 (e.g., a mouse), and a sound signal generation device 816 (e.g., a speaker).

[0067] Data storage device 818 may include machine-readable storage medium (or, more specifically, non-transitory machine-readable storage medium) 828 thereon storing one or more sets of executable instructions 822. According to one or more aspects of this disclosure, the executable instructions 822 may include... Figure 5 –6 shows the executable instructions associated with execution methods 500 and 600.

[0068] The executable instructions 822 may also reside wholly or at least partially within the main memory 804 and / or the processing device 802 during execution via the example computing device 800, which also constitutes a computer-readable storage medium, and the main memory 804 and the processing device 802. The executable instructions 822 may also be transmitted or received over a network via the network interface device 808.

[0069] Although the computer-readable storage medium 828 is Figure 8 While the term "computer-readable storage medium" is not explicitly used to refer to a single medium, it should be understood to include single or multiple media (e.g., centralized or distributed databases, and / or associated caches and servers) that store one or more sets of operational instructions. The term "computer-readable storage medium" should also be considered to include any medium capable of storing or encoding a set of instructions for machine execution, which causes the machine to perform any one or more of the methods described herein. Therefore, the term "computer-readable storage medium" should be considered to include, but is not limited to, solid-state storage as well as optical and magnetic media.

[0070] In at least one embodiment, Figure 8 A system is shown that includes interconnected hardware devices or "chips". In at least one embodiment, Figure 8 An example of a SoC can be shown. In at least one embodiment, Figure 8 The devices shown can interoperate with proprietary interconnects, standardized interconnects (e.g., Perpheral Component Interconnect Express (PCIe)), or some combination thereof. In at least one embodiment, one or more components of computing device 800 interoperate using Compute Fast Link (“CXL”).

[0071] Other variations are within the spirit of this disclosure. Therefore, while the disclosed technology is readily available for various modifications and alternative structures, certain embodiments illustrated are shown in the accompanying drawings and have been described in detail above. However, it should be understood that the disclosure is not intended to be limited to any specific form or form disclosed, but rather is intended to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the disclosure as defined in the appended claims.

[0072] In the context of describing the disclosed embodiments, particularly in the context of the following claims, the terms “a” and “an”, “the”, and similar designations should be interpreted as encompassing both the singular and plural, unless otherwise stated herein or explicitly contradicted by the context, and not as definitions of the terms. Unless otherwise stated, the terms “comprising,” “having,” “including,” and “containing” should be interpreted as open-ended terms (i.e., “including, but not limited to”). “Connection,” when unmodified and referring to a physical connection, should be interpreted as being partially or wholly contained therein, attached, or joined together, even with something in between. References to value ranges herein are intended only as a shorthand method for individually referencing each individual value falling within the range, unless otherwise stated herein, and each individual value is incorporated into the specification as if it were individually referenced herein. In at least one embodiment, the terms “group” (e.g., “a set of items”) or “subset” should be interpreted as a non-empty set containing one or more members, unless otherwise stated by the context or contradicted by the context. Furthermore, unless the context otherwise indicates or contradicts, the term "subset" for a corresponding group does not necessarily refer to an appropriate subset of the corresponding group, but a subset and a corresponding group can be equivalent.

[0073] Conjunctions, such as phrases of the form "at least one of A, B, and C" or "at least one of A, B, and C," should be understood, in conjunction with the context, generally as indicating items, terms, etc., which can be A or B or C, or any suitable non-empty subset of the set A, B, and C, unless explicitly stated otherwise or clearly contradicted by the context. For example, in an illustrative example of a set with three members, the conjunction phrases "at least one of A, B, and C" and "at least one of A, B, and C" refer to any suitable set of the following: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Thus, this language of conjunctions is generally not intended to imply that certain embodiments require at least one of A, at least one of B, and at least one of C to be present separately. Furthermore, unless explicitly stated or contradicted by the context, the term "multiple" indicates a plural state (e.g., "multiple items" means multiple items). In at least one embodiment, the number of multiple items is at least two, but may be more when so explicitly stated or indicated by the context. Furthermore, unless otherwise stated or clearly indicated from the context, the phrase “based on” means “at least partially based on”, not “based on only”.

[0074] The operations of the processes described herein can be performed in any suitable order unless otherwise stated herein or otherwise explicitly contradicted by the context. In at least one embodiment, processes such as those described herein (or variations thereof and / or combinations thereof) are executed under the control of one or more computer systems configured with executable instructions and are implemented as code (e.g., executable instructions, one or more computer programs, or one or more application programs) that execute jointly on one or more processors via hardware or a combination thereof. In at least one embodiment, the code is stored on a computer-readable storage medium, for example, in the form of a computer program containing a plurality of instructions executable by one or more processors. In at least one embodiment, the computer-readable storage medium is a non-transitory computer-readable storage medium that excludes transient signals (e.g., propagation of transient electrical or electromagnetic transmissions) but includes non-transitory data storage circuitry (e.g., buffers, caches, and queues) within a transceiver of transient signals. In at least one embodiment, code (e.g., executable code or source code) is stored on a group of one or more non-transitory computer-readable storage media, on which executable instructions (or other memory for storing executable instructions) are stored, causing the computer system to perform the operations described herein when executed by one or more processors of a computer system (i.e., as a result of execution). In at least one embodiment, the group of non-transitory computer-readable storage media includes multiple non-transitory computer-readable storage media, and one or more individual non-transitory storage media lack all the code, while the multiple non-transitory computer-readable storage media collectively store all the code. In at least one embodiment, execution of the executable instructions causes different instructions to be executed by different processors—for example, the non-transitory computer-readable storage media stores the instructions and the main central processing unit (“CPU”) executes some instructions, while the graphics processing unit (“GPU”) executes other instructions. In at least one embodiment, different components of the computer system have separate processors, and different processors execute different subsets of instructions.

[0075] Therefore, in at least one embodiment, the computer system is configured to implement services that perform one or more individual or collective operations of the processes described herein, and such a computer system is configured with suitable hardware and / or software to achieve performance. Furthermore, the computer system implementing at least one embodiment of this disclosure is a single device, and in another embodiment, it is a distributed computer system comprising multiple devices and operating in different ways, such that the distributed computer system performs the operations described herein and that the single device does not perform all operations.

[0076] Any and all examples or exemplary language provided herein (e.g., “such as”) are used only to better illustrate the disclosed embodiments and do not constitute a limitation on the scope of the disclosure unless otherwise required. No language in the specification should be construed as indicating that any unclaimed element is essential to the practice of the disclosure.

[0077] All references cited herein, including publications, patent applications and patents, are incorporated herein by reference to the extent that each reference is individually and specifically indicated by reference as incorporated herein in its entirety.

[0078] In the description and claims, the terms “coupled” and “connected” and their derivatives may be used. It should be understood that these terms may not be intended to be synonyms with each other. Rather, in specific examples, “connected” or “coupled” may be used to indicate direct or indirect physical or electrical contact between two or more elements. “Coupled” may also mean that two or more elements do not have direct contact with each other, but still cooperate or interact with each other.

[0079] Unless otherwise expressly stated, it is understood that throughout the specification terminology, such as “processing,” “computing,” “calculating,” “determining,” etc., refers to the actions and / or processes of a computer or computing system or similar electronic computing device that manipulate and / or convert data represented as physical quantities (e.g., electronic quantities) within the registers and / or memory of the computing system into other data similarly represented as physical quantities within the memory, registers, or other such information storage, transmission, or display devices of the computing system.

[0080] Similarly, the term "processor" can refer to any suitable device or part of a device that processes electronic data from registers and / or memory and converts that electronic data into other electronic data that can be stored in registers and / or memory. As a non-limiting example, a "processor" can be a CPU or a GPU. A "computing platform" can include one or more processors. As used herein, a "software" process can include, for example, software and / or hardware entities that perform work over time, such as tasks, threads, and intelligent agents. Furthermore, each process can refer to multiple processes for executing instructions sequentially or in parallel, continuously or intermittently. In at least one embodiment, the terms "system" and "method" are used interchangeably herein, provided that a system can embody one or more methods and a method can be considered a system.

[0081] In this document, reference may be made to obtaining, acquiring, receiving, or inputting analog or digital data into a subsystem, computer system, or computer-implemented machine. In at least one embodiment, the process of obtaining, acquiring, receiving, or inputting analog and digital data can be accomplished in various ways, such as by receiving data as a parameter of a function call or a call to an application programming interface (API). In at least one embodiment, the process of obtaining, acquiring, receiving, or inputting analog or digital data can be accomplished by transmitting data via a serial or parallel interface. In at least one embodiment, the process of obtaining, acquiring, receiving, or inputting analog or digital data can be accomplished by transmitting data from a providing entity to an acquiring entity via a computer network. In at least one embodiment, reference may also be made to providing, outputting, transmitting, sending, or presenting analog or digital data. In various examples, the process of providing, outputting, transmitting, sending, or presenting analog or digital data can be accomplished by using data as an input or output parameter of a function call, a parameter of an application programming interface, or an inter-process communication mechanism.

[0082] While the description herein illustrates exemplary embodiments of the described techniques, other architectures may be used to implement the described functionality, and are intended to be within the scope of this disclosure. Furthermore, although specific assignments of responsibility may be defined for illustrative purposes above, various functions and responsibilities may be allocated and divided in different ways depending on the circumstances.

[0083] Furthermore, although the subject matter has been described in language specific to structural features and / or methodological behavior, it should be understood that the subject matter claimed in the appended claims is not necessarily limited to the specific features or behaviors described. Rather, specific features and behaviors are disclosed as exemplary forms for implementing the claims.

Claims

1. A method comprising: A kernel memory structure, identified by one or more processors, comprises a set of memory locations that store data indicating one or more parameters of a user-associated process; The one or more processors monitor the user-associated process's access to the kernel memory structure to identify a first system call corresponding to the user-associated process; In response to detecting a change in a first value in a first memory location within the group of memory locations, the one or more processors determine that the execution of the first system call has occurred, wherein the first value indicates the state of the first system call; In response to determining that the execution of the first system call has occurred, the one or more processors retrieve a value from one or more second memory locations in the set of memory locations associated with the first system call; as well as The one or more processors provide output identifying the first system call based on the one or more values ​​in the one or more second memory locations.

2. The method according to claim 1, further comprising: Data indicating the thread context of the kernel memory structure is extracted by one or more processors, wherein the thread context corresponds to a first operating system (OS), and the set of memory locations is determined based on the thread context.

3. The method of claim 2, wherein the data includes a first intermediate symbol table (IST) corresponding to the first operating system (OS).

4. The method of claim 1, wherein the user-associated process corresponds to a virtual machine (VM), and the one or more processors are associated with a hypervisor, wherein at least a portion of the method is executed by the hypervisor.

5. The method according to claim 1, further comprising: The one or more processors determine, based on the identifier of the first system call, an instance of malware associated with the user's associated process; as well as A second output indicating an instance of the malware is provided by one or more processors.

6. The method according to claim 1, further comprising: The one or more processors poll for access requests to this set of memory locations in the kernel memory structure.

7. The method according to claim 1, wherein the kernel memory structure corresponds to the kernel stack of the first operating system.

8. The method according to claim 7, further comprising: The one or more processors determine the null character in the third memory location of the kernel memory structure, wherein the set of memory locations is determined based on the proximity between the set of memory locations and the third memory location.

9. A computing system, comprising: Memory; and One or more processors, coupled to the memory, are used for: Identify a kernel memory structure comprising a set of memory locations that store data indicating one or more parameters of the user-associated process; Monitor the user-associated process's access to the kernel memory structure to identify the first system call corresponding to the user-associated process; In response to detecting a change in a first value in a first memory location within the group of memory locations, it is determined that the execution of the first system call has occurred, wherein the first value indicates the state of the first system call; In response to determining that the execution of the first system call has occurred, a value from one or more second memory locations in the set of memory locations is retrieved, the one or more second memory locations being associated with the first system call; as well as The output identifying the first system call is provided based on one or more values ​​in one or more second memory locations.

10. The computing system of claim 9, wherein the one or more processors are further configured to: Extract data indicating the thread context of the kernel memory structure, the thread context corresponding to a first operating system (OS), wherein the set of memory locations is determined based on the thread context.

11. The computing system of claim 10, wherein the data includes a first intermediate symbol table IST corresponding to the first operating system OS.

12. The computing system of claim 9, wherein the one or more processors are further configured to: Based on the identifier of the first system call, an instance of malware associated with the user's process is identified; and Provides a second output indicating an instance of the malware.

13. The computing system of claim 9, wherein the one or more processors are further configured to: Polling for access requests to this set of memory locations in the kernel memory structure.

14. The computing system of claim 9, wherein the kernel memory structure corresponds to the kernel stack of the first operating system.

15. The computing system of claim 9, wherein the user-associated process corresponds to a virtual machine (VM), and the one or more processors are associated with a hypervisor.

16. A non-transitory computer-readable storage medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform an operation, the operation comprising: Identify a kernel memory structure comprising a set of memory locations that store data indicating one or more parameters of the user-associated process; Monitor the user-associated process's access to the kernel memory structure to identify the first system call corresponding to the user-associated process; In response to detecting a change in a first value in a first memory location within the group of memory locations, it is determined that the execution of the first system call has occurred, wherein the first value indicates the state of the first system call; In response to determining that the execution of the first system call has occurred, a value from one or more second memory locations in the set of memory locations is retrieved, the one or more second memory locations being associated with the first system call; as well as The output identifying the first system call is provided based on one or more values ​​in one or more second memory locations.

17. The non-transitory computer-readable storage medium of claim 16, wherein the instructions further cause the one or more processors to perform operations including: Extract data indicating the thread context of the kernel memory structure, the thread context corresponding to a first operating system (OS), wherein the set of memory locations is determined based on the thread context.

18. The non-transitory computer-readable storage medium of claim 16, wherein the instructions further cause the one or more processors to perform operations, the operations comprising: Based on the identifier of the first system call, an instance of malware associated with the user's associated process is identified; as well as Provides a second output indicating an instance of the malware.

19. The non-transitory computer-readable storage medium of claim 18, wherein the user-associated process corresponds to a virtual machine (VM), and the one or more processors are associated with a hypervisor.

20. The non-transitory computer-readable storage medium of claim 16, wherein the kernel memory structure corresponds to the kernel stack of a first operating system.

Images