Method and device for tracking decrypted data in Go language program, equipment and medium

Abstract

The invention provides a method and device for tracking decrypted data in a Go language program, equipment and a medium, and the method comprises the steps: carrying out binary analysis on a target Go language binary program to recognize at least one specific AES decryption function; the method comprises the following steps of: deploying an eBPF program into an operating system kernel, wherein the eBPF program comprises a user mode function entry probe (upprobe) and a user mode function return probe (upprobe); adding the uprobe to an entry point of the identified AES decryption function, and capturing the address and the length of a target buffer area parameter from a CPU register when a function entry is executed; running a user mode application program, and reading, analyzing and displaying the event data in real time; on the premise that a target program is not invaded, data tracking of the Go program after AES decryption is achieved.

Description

Technical Field

[0001] This invention relates to the field of program tracing and security analysis technology, and in particular to a method, apparatus, device, and medium for tracing decrypted data in a Go language program. Background Technology

[0002] In competitive analysis scenarios, it's common to encounter situations where competitor API return values ​​are encrypted using algorithms like AES. Obtaining the plaintext data of these return values ​​is necessary for subsequent analysis. When the competitor's API is a Linux binary program written in Go, traditional techniques for obtaining plaintext data face several unresolved issues due to the lack of source code access. 1. Limitations due to source code dependency: Traditional source code instrumentation methods require modifying the program source code and recompiling. However, most competing binary programs are closed-source software, and their source code cannot be obtained, making such methods completely unsuitable. At the same time, even if the source code can be obtained, modifying the source code may introduce new program vulnerabilities, compromise the stability of the original program, and affect the accuracy of data acquisition. 2. Missing Function Output Acquisition: Simple uprobe tracing solutions can only capture input parameters at the function entry point and cannot obtain the output results after the function execution is complete. However, the plaintext data of encrypted interfaces is usually stored in the output parameters of the decryption function, which can only be read when the function returns. Existing solutions cannot meet this core requirement. 3. Lack of context association mechanism: During the decryption function call, the parameter information such as the output buffer pointer saved at the function entry point needs to be used to match and read the output result when the function returns. However, the traditional eBPF scheme lacks an effective data sharing mechanism between uprobe and uretprobe, which cannot achieve accurate association between function call and return result, resulting in the inability to extract plaintext data correctly. 4. Insufficient Go language compatibility: Traditional eBPF tracing solutions are not fully adapted to Go's function calling conventions, especially the register calling convention used in Go 1.17 and above. This can easily lead to errors when parsing function parameters, resulting in distorted tracing data and an inability to accurately obtain relevant information about the decrypted function. 5. Data Confusion in Concurrent Scenarios: Competitor programs often involve multi-threaded or concurrent call scenarios during actual operation, where multiple threads may trigger decryption function calls simultaneously. Traditional tracing solutions lack a mechanism to distinguish the context of different call instances, which can easily lead to data confusion between different threads, resulting in errors in plaintext data extraction. The aforementioned problems make it difficult for traditional technical solutions to efficiently, accurately, and securely obtain the plaintext data returned by the encrypted interface of the Linux version of the competitor written in Go, which seriously restricts the competitive analysis work. Therefore, a new technical solution is urgently needed to solve the above pain points. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide a method, apparatus, device, and medium for tracing decrypted data in Go language programs. It aims to solve the technical problems of tracing compiled binary programs without modifying the source code, accurately parsing Go language function calling conventions, passing context information between function entry and return, and obtaining decrypted plaintext data in real time. At the same time, it achieves low performance overhead and a high degree of automation in program data tracing, providing technical support for application scenarios such as third-party competitor analysis, program security analysis, encryption algorithm verification, and data leakage tracing.

[0004] In a first aspect, the present invention provides a method for tracking decrypted data in a Go language program, comprising the following steps: Step 1: Perform binary analysis on the target Go language binary program to identify at least one specific AES decryption function whose signature includes a target buffer parameter for storing the decrypted plaintext data; Step 2: Deploy an eBPF program into the operating system kernel. The eBPF program includes a user-mode function entry probe uprobe and a user-mode function return probe uretprobe. Step 3: Append the uprobe to the entry point of the identified AES decryption function. When the function is executed at the entry point, capture the address and length of the target buffer parameter from the CPU register. Step 4: Append the uretprobe to the return point of the identified AES decryption function. When the function returns, obtain the address and length of the target buffer based on the current thread ID; use kernel-mode functions to read the contents of the target buffer from user-mode memory to obtain the decrypted plaintext data; encapsulate the plaintext data and related tracking information into event data. Step 5: Run a user-space application configured to load the eBPF program, attach the uprobe and uretprobe, and read, parse, and display the event data in real time.

[0005] Secondly, the present invention provides an apparatus for tracking decrypted data in a Go language program, comprising: The function identification module performs binary analysis on the target Go language binary program to identify at least one specific AES decryption function whose signature includes a target buffer parameter for storing the decrypted plaintext data. The deployment module deploys an eBPF program to the operating system kernel. The eBPF program includes a user-mode function entry probe uprobe and a user-mode function return probe uretprobe. The capture context module attaches the uprobe to the entry point of the identified AES decryption function, and captures the address and length of the target buffer parameters from the CPU register when the function entry point is executed; The data acquisition module appends the `uretprobe` to the return point of the identified AES decryption function. When the function returns, it: obtains the address and length of the target buffer based on the current thread ID; uses kernel-mode functions to read the contents of the target buffer from user-mode memory to obtain the decrypted plaintext data; and encapsulates the plaintext data and related tracking information into event data. The parsing and display module runs a user-space application configured to load the eBPF program, attach the uprobe and uretprobe, and read, parse, and display the event data in real time.

[0006] Thirdly, the present invention provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in the first aspect.

[0007] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect.

[0008] One or more technical solutions provided by this invention have at least the following technical effects or advantages: 1. This invention does not require modification of the target Golang program's source code or recompilation of the binary file. It achieves tracing solely through eBPF's uprobe / uretprobe probes attached to the entry and return points of the target function. This feature perfectly solves the problem of closed-source competing programs and deployed binary programs being unanalyzable through source code instrumentation, and is the core advantage of this method.

[0009] 2. This invention addresses the register calling convention used in Go 1.17+, directly extracting key parameters such as the dst pointer and length from registers like BX and CX. This avoids the problem of incorrect parameter parsing in Go programs, which is common in traditional eBPF solutions, and ensures the accuracy of parameter acquisition.

[0010] 3. This invention stores the context information (such as the dst pointer) at the entry point of the decryption function in a hash table (decrypt_ctx) with pid_tgid as the key. When the function returns, it accurately matches the calling instance, realizes the context passing between uprobe and uretprobe, and successfully captures the decrypted output data (instead of only being able to obtain the input parameters).

[0011] 4. This invention uses pid_tgid (process ID + thread ID) as the unique identifier of the context, which can distinguish different decryption function call instances in multi-threaded / concurrent scenarios, effectively avoiding the problem of data confusion between multiple threads in traditional solutions, and ensuring the uniqueness and accuracy of the tracking data.

[0012] 5. The user-space program of this invention reads the event data reported by the kernel in real time through the ringbuf ring buffer, automatically parses it and prints the results in hexadecimal and string form, and can achieve continuous decryption data tracking without manual intervention, which is suitable for large-scale competitive product analysis, batch program monitoring and other scenarios.

[0013] 6. The core tracing logic of this invention revolves around the AES decryption function in the Go standard library. By simply adjusting the function name attached to the probe, it can be adapted to the tracing of decryption functions of other encryption algorithms (such as DES and RSA), and can also be extended to the capture of parameters / return values ​​of other user-space functions.

[0014] 7. The eBPF program of this invention runs in kernel mode, and its data processing and transmission efficiency is far superior to traditional logging and debugger solutions, with minimal impact on the target program's performance. Even in high-concurrency interface call scenarios, it will not cause the target program to respond slowly or be interrupted, meeting the tracing requirements of production environments.

[0015] 8. Compared to logging solutions that may store sensitive plaintext data, this invention transmits data in real time via ringbuf, eliminating the need for storing intermediate logs on the ground and reducing the risk of data leakage. At the same time, it avoids the system security risks associated with using debuggers in production environments, thus meeting security and compliance requirements.

[0016] 9. This invention can flexibly control resource consumption through the parameter configuration of eBPF map (such as the maximum number of entries in decrypt_ctx and the size of the ring buffer of events), and the deployment of user-space programs based on the ebpf-go library is simple, requiring only the target binary program path to run, resulting in low operation and maintenance costs.

[0017] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0018] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0019] Figure 1 This is a flowchart of the method in Embodiment 1 of the present invention; Figure 2 This is a schematic diagram of the device in Embodiment 2 of the present invention. Detailed Implementation

[0020] The overall concept of the technical solution in this application is as follows: Operating steps Step 1: Analyze the target binary file # Use the `go tool nm` command to analyze the target Go program and find decrypted function symbols. `go tool nm`<aes_encrypt_demo> Output example: 4a8a80 T crypto / internal / fips140 / aes.(*Block).Decrypt Locate the target function: crypto / internal / fips140 / aes.(*Block).Decrypt Verify the function signature: func(b*Block)Decrypt(dst,src[]byte), where dst is the decrypted data. Step 2: Write the eBPF program (kernel mode) Define the data structure: event: contains event_type, pid, tgid, timestamp, comm, data, data_len decrypt_context: Stores the dst pointer and length (used for passing between uprobe and uretprobe). events: BPF_MAP_TYPE_RINGBUF decrypt_ctx: BPF_MAP_TYPE_HASH, storing the context with pid_tgid as the key. Implement the uprobe handling function (function entry point): Function name: uprobe / aes_decrypt Obtain parameters according to Go 1.17+ register conventions: BX register = dst.ptr (pointer to the destination buffer) CX register = dst.len (target buffer length) Save the context information (dst_ptr, dst_len) to a hashmap with the key pid_tgid. Implement the uretprobe processing function (function return value): Function name: uretprobe / aes_decrypt Retrieve the previously saved context from the hashmap based on the pid_tgid. Use bpf_probe_read_user to read the decrypted data (from the memory pointed to by the dst pointer). Submit the event to ringbuf Clean up the context data in the hashmap Step 3: Write the user-mode program initialization: Remove memory lock restrictions Load the compiled eBPF ELF file Additional uprobe and uretprobe: Use link.OpenExecutable() to open the target executable file. Use exec.Uprobe() to attach to the function entry. Use exec.Uretprobe() to append to the function return. Reading and outputting data: Create a ringbuf reader Loop through event data Parse and print: event type, process information, hexadecimal data, and string data. Step 4: Run the tracing program . / crypto_trace<target_program_path> The specific implementation is as follows: Tracing AES-decrypted data in a Go program 1. Analyze Go binary executables shell # Enter the command, passing in the Go binary program to be analyzed. go tool nm<aes_encrypt_demo> # Output Example # ... # 496de0 T crypto / internal / fips140.setIndicator # 4a8900 T crypto / internal / fips140 / aes.(*Block).BlockSize # 4a8a80 T crypto / internal / fips140 / aes.(*Block).Decrypt # ... ``` The key decryption function was found to be `crypto / internal / fips140 / aes.(*Block).Decrypt`. Checking the function's signature in the Go source code repository reveals that `src` represents the data before encryption. The function is defined as follows: ```go func (b *Block) Decrypt(dst, src []byte) ``` 2. Write an eBPF program to trace the decrypted data. eBPF program code Data structure, eBPF map definition ```C #define MAX_DATA_LEN 256 / / Event type - Decryption indicates that AES decryption is invoked and the decrypted data is stored. #define EVENT_DECRYPT 2 struct event { / / Event Type u32 event_type; u32 pid; u32 tgid; u64 timestamp; char comm

[16] ; / / Decrypted data u8 data[MAX_DATA_LEN]; / / Data length u32 data_len; } __attribute__((packed)); / / Decryption context: Store the dst pointer when the decryption function is called, and retrieve the parsed value when the decryption function returns. struct decrypt_context { u64 dst_ptr; u64 dst_len; }; struct { __uint(type, BPF_MAP_TYPE_RINGBUF); __uint(max_entries, 256 * 1024); } events SEC(".maps"); struct { __uint(type, BPF_MAP_TYPE_HASH); __uint(max_entries, 10240); __type(key, __u64); / / pid_tgid __type(value, struct decrypt_context); } decrypt_ctx SEC(".maps"); ``` AES Decrypt entry (uprobe) - stores the dst pointer ```C / / AES Decrypt entry point - saves the dst pointer / / func (c *Block) Decrypt(dst, src []byte) / / AX = c (*Block) / / BX = dst.ptr, CX = dst.len, DI = dst.cap / / SI = src.ptr, R8 = src.len, R9 = src.cap SEC("uprobe / aes_decrypt") int uprobe_aes_decrypt(struct pt_regs *ctx) { u64 pid_tgid = bpf_get_current_pid_tgid(); struct decrypt_context cc = { .dst_ptr = ctx->bx, / / BX = dst.ptr .dst_len = ctx->cx, / / CX = dst.len }; bpf_map_update_elem(&decrypt_ctx, &pid_tgid, &cc, BPF_ANY); return 0; } ``` AES Decrypt return (uretprobe) - Capture dst ```C / / AES Decrypt return - Capture dst SEC("uretprobe / aes_decrypt") int uretprobe_aes_decrypt(struct pt_regs *ctx) { u64 pid_tgid = bpf_get_current_pid_tgid(); struct decrypt_context *cc; / / Get the decryption context saved in `uprobe / aes_decrypt` cc = bpf_map_lookup_elem(&decrypt_ctx, &pid_tgid); if (!cc) return 0; struct event *e; e = bpf_ringbuf_reserve(&events, sizeof(*e), 0); if (!e) { bpf_map_delete_elem(&decrypt_ctx, &pid_tgid); return 0; } / / Event Type - AES Decryption e->event_type = EVENT_DECRYPT; / / Context information population e->pid = pid_tgid; e->tgid = pid_tgid >> 32; e->timestamp = bpf_ktime_get_ns(); bpf_get_current_comm(e->comm, sizeof(e->comm)); / / Retrieve the decryption pointer dst from the decryption context, length void *dst_ptr = (void *)cc->dst_ptr; u64 dst_len = cc->dst_len; if (dst_len > MAX_DATA_LEN) { e->data_len = MAX_DATA_LEN; } else { e->data_len = dst_len; } if (dst_ptr && e->data_len > 0) { / / Read the decrypted data long ret = bpf_probe_read_user(e->data, e->data_len, dst_ptr); if (ret < 0) { e->data_len = 0; } } / / Submit Event bpf_ringbuf_submit(e, 0); / / Clean up the decryption context bpf_map_delete_elem(&decrypt_ctx, &pid_tgid); return 0; } ``` User-mode program code 1. Load the eBPF application using the ebpf-go library; 2. Append the eBPF program to the entry point (uprobe) of the `crypto / internal / fips140 / aes.(*Block).Decrypt` function in the target binary; 3. The `crypto / internal / fips140 / aes.(*Block).Decrypt` function, which appends the eBPF program to the target binary, returns (uretprobe); 4. Read the data in ringbuf and parse and print it; ```go package main import ( "bytes" "encoding / binary" "encoding / hex" "errors" "log" "os" "os / signal" "syscall" "github.com / cilium / ebpf / link" "github.com / cilium / ebpf / ringbuf" "github.com / cilium / ebpf / rlimit" ) func main() { if len(os.Args) != 2 { log.Fatal("Usage: . / crypto_trace<target_path> ") } targetPath := os.Args[1] / / Remove kernel resource limits if err := rlimit.RemoveMemlock(); err != nil { log.Fatal("Removing memlock:", err) } / / Load the compiled eBPF ELF and load it into the kernel var objs crypto_traceObjects if err := loadCrypto_traceObjects(&objs, nil); err != nil { log.Fatal("Loading eBPF objects:", err) } defer objs.Close() / / Load the executable file to be traced exec, err := link.OpenExecutable(targetPath) if err != nil { log.Fatal("Open executable file:", err) } upDecrypt, err := exec.Uprobe("crypto / internal / fips140 / aes.(*Block).Decrypt", objs.UprobeAesDecrypt, &link.UprobeOptions{}) if err != nil { log.Fatal("Attach uprobe aes_decrypt:", err) } defer upDecrypt.Close() uretDrcrypt, err := exec.Uretprobe("crypto / internal / fips140 / aes.(*Block).Decrypt", objs.UretprobeAesDecrypt, &link.UprobeOptions{}) if err != nil { log.Fatal("Attach uretprobe aes_decrypt:", err) } defer uretDrcrypt.Close() / / Create ringbuf reader reader, err := ringbuf.NewReader(objs.Events) if err != nil { log.Fatal("Create ringbuf reader failed:", err) } sig := make(chan os.Signal, 1)[[ID=X]] signal.Notify(sig, syscall.SIGINT, syscall.SIGTERM) go func() { <-sig reader.Close() }() for { / / Read data from ringbuf record, err := reader.Read() if err != nil { if errors.Is(err, ringbuf.ErrClosed) { log.Println("Exit...") return } log.Println("Read ring buffer failed:", err) continue } / / Parse data var event Event if err = binary.Read(bytes.NewReader(record.RawSample),binary.LittleEndian, &event); err != nil { It should be noted that in the original text, there is an unclear tag ` ` which is marked as ` ` in the translation for the purpose of maintaining consistency. Also, the package `errors` is assumed to be imported correctly in the relevant code context. And the type `Event` should be defined appropriately in the original code.log.Println("Resolve event failed:", err) continue } / / Print data PrintEvent(&event) } } const ( EVENT_DECRYPT = 2 MAX_DATA_LEN = 256 ) / * struct event { / / Event Type u32 event_type; u32 pid; u32 tgid; u64 timestamp; char comm

[16] ; / / Decrypted data u8 data[MAX_DATA_LEN]; / / Data length u32 data_len; }; / type Event struct { EventType uint32 Pid uint32 Tgid uint32 Timestamp uint64 Comm

[16] byte Data [MAX_DATA_LEN]byte DataLen uint32 } func PrintEvent(event *Event) { common := string(bytes.TrimRight(event.Comm[:], "\x00")) srcData := event.Data[:event.DataLen] log.Printf("==================== Event [%s]====================",formatEventType(event.EventType)) / / Print common data: pid, comm, tgid log.Printf("Pid: %d, Common: %s, Tgid: %d", event.Pid, common,event.Tgid) / / Print the decrypted data in hexadecimal format log.Printf("Data(hex) [%d] %s", event.DataLen, hex.EncodeToString(srcData)) / / Formatted print of decrypted data log.Printf("Data(str) [%d] %s", event.DataLen, srcData) } func formatEventType(eventType uint32) string { switch eventType { case EVENT_DECRYPT: return "Decrypt" default: return "Unknown" } } ``` Example

[0021] like Figure 1 As shown, this embodiment provides a method for tracking decrypted data in a Go language program, including the following steps: Step 1: Perform binary analysis on the target Go language binary program to identify at least one specific AES decryption function whose signature includes a target buffer parameter for storing the decrypted plaintext data; Step 2: Deploy an eBPF program into the operating system kernel. The eBPF program includes a user-mode function entry probe uprobe and a user-mode function return probe uretprobe. Step 3: Append the uprobe to the entry point of the identified AES decryption function. When the function is executed at the entry point, capture the address and length of the target buffer parameter from the CPU register. Step 4: Append the uretprobe to the return point of the identified AES decryption function. When the function returns, obtain the address and length of the target buffer based on the current thread ID; use kernel-mode functions to read the contents of the target buffer from user-mode memory to obtain the decrypted plaintext data; encapsulate the plaintext data and related tracking information into event data. Step 5: Run a user-space application configured to load the eBPF program, attach the uprobe and uretprobe, and read, parse, and display the event data in real time.

[0022] In this embodiment, preferably, step 1 specifically involves: using the Go tool nm tool (built into the Go language) to analyze the target Go language binary program to identify at least one specific AES decryption function. The function signature includes a target buffer parameter for storing the decrypted plaintext data. The specific AES decryption function is the crypto / internal / fips140 / aes.(*Block).Decrypt function in the Go standard library.

[0023] In this embodiment, preferably, step 3 specifically involves: attaching the uprobe to the entry point of the identified AES decryption function; capturing the address and length of the target buffer parameter from the CPU register during function entry execution; and storing the address and length in a mapping as a decryption context, wherein the mapping uses the thread ID as the key to distinguish concurrent calls; the address of the target buffer parameter is captured from the BX register, and the length is captured from the CX register; the decryption context mapping is a hash table used to store the correspondence between thread IDs and decrypt_context structures; the decrypt_context structure contains the target buffer address and length; Step 4 specifically involves: attaching the `uretprobe` to the return point of the identified AES decryption function; upon function return and execution: retrieving the corresponding decryption context from the mapping based on the current thread ID, and obtaining the address and length of the target buffer; using kernel-mode functions to read the contents of the target buffer from user-mode memory to obtain the decrypted plaintext data; encapsulating the plaintext data and related tracking information into event data; writing the event data into a circular buffer mapping for transmission from kernel mode to user-mode applications; and deleting the decryption context of the current thread from the mapping.

[0024] In this embodiment, preferably, step 5 specifically involves: running a user-mode application configured to load the eBPF program, attach the uprobe and uretprobe, and read, parse, and display the event data from the circular buffer mapping in real time, including displaying the decrypted plaintext data in hexadecimal and string formats.

[0025] Based on the same inventive concept, this application also provides an apparatus corresponding to the method in Embodiment 1, as detailed in Embodiment 2.

[0026] Example 2 like Figure 2 As shown, this embodiment provides a device for tracking decrypted data in a Go language program, including: The function identification module performs binary analysis on the target Go language binary program to identify at least one specific AES decryption function whose signature includes a target buffer parameter for storing the decrypted plaintext data. The deployment module deploys an eBPF program to the operating system kernel. The eBPF program includes a user-mode function entry probe uprobe and a user-mode function return probe uretprobe. The capture context module attaches the uprobe to the entry point of the identified AES decryption function, and captures the address and length of the target buffer parameters from the CPU register when the function entry point is executed; The data acquisition module appends the `uretprobe` to the return point of the identified AES decryption function. When the function returns, it: obtains the address and length of the target buffer based on the current thread ID; uses kernel-mode functions to read the contents of the target buffer from user-mode memory to obtain the decrypted plaintext data; and encapsulates the plaintext data and related tracking information into event data. The parsing and display module runs a user-space application configured to load the eBPF program, attach the uprobe and uretprobe, and read, parse, and display the event data in real time.

[0027] In this embodiment, preferably, the identification function module specifically involves: using the Go tool nm tool (built into the Go language) to analyze the target Go language binary program to identify at least one specific AES decryption function. The function signature includes a target buffer parameter for storing the decrypted plaintext data. The specific AES decryption function is the crypto / internal / fips140 / aes.(*Block).Decrypt function in the Go standard library.

[0028] In this embodiment, preferably, the capture context module specifically comprises: attaching the uprobe to the entry point of the identified AES decryption function; capturing the address and length of the target buffer parameter from the CPU register during function entry execution; and storing the address and length in a mapping as a decryption context, wherein the mapping uses the thread ID as the key to distinguish concurrent calls; the address of the target buffer parameter is captured from the BX register; and the length is captured from the CX register; the decryption context mapping is a hash table used to store the correspondence between thread IDs and decrypt_context structures; the decrypt_context structure contains the target buffer address and length; The data acquisition module specifically involves: attaching the `uretprobe` to the return point of the identified AES decryption function; upon function return and execution: retrieving the corresponding decryption context from the mapping based on the current thread ID, and obtaining the address and length of the target buffer; using kernel-mode functions to read the contents of the target buffer from user-mode memory to obtain the decrypted plaintext data; encapsulating the plaintext data and related tracking information into event data; writing the event data into a circular buffer mapping for transmission from kernel mode to user-mode applications; and deleting the decryption context of the current thread from the mapping.

[0029] In this embodiment, preferably, the parsing and display module specifically comprises: running a user-mode application configured to load the eBPF program, attach the uprobe and uretprobe, and read, parse, and display the event data from the circular buffer mapping in real time, including displaying the decrypted plaintext data in hexadecimal and string formats.

[0030] Since the apparatus described in Embodiment 2 of the present invention is an apparatus used to implement the method of Embodiment 1 of the present invention, those skilled in the art can understand the specific structure and variations of the apparatus based on the method described in Embodiment 1 of the present invention, and therefore will not be described again here. All apparatuses used in the method of Embodiment 1 of the present invention fall within the scope of protection of the present invention.

[0031] Based on the same inventive concept, this application provides an electronic device embodiment corresponding to Embodiment 1, as detailed in Embodiment 3.

[0032] Example 3 This embodiment provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it can implement any of the implementation methods in Embodiment 1.

[0033] Since the electronic device described in this embodiment is the device used to implement the method in Embodiment 1 of this application, those skilled in the art can understand the specific implementation method and various variations of the electronic device in this embodiment based on the method described in Embodiment 1 of this application. Therefore, how the electronic device implements the method in the embodiment of this application will not be described in detail here. Any device used by those skilled in the art to implement the method in the embodiment of this application falls within the scope of protection of this application.

[0034] Based on the same inventive concept, this application provides a storage medium corresponding to Embodiment 1, as detailed in Embodiment 4.

[0035] Example 4 This embodiment provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it can implement any of the implementation methods in Embodiment 1.

[0036] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0037] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

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

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

[0040] While specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and not intended to limit the scope of the present invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A method for tracing decrypted data in a Go language program, characterized in that: Includes the following steps: Step 1: Perform binary analysis on the target Go language binary program to identify at least one specific AES decryption function whose signature includes a target buffer parameter for storing the decrypted plaintext data; Step 2: Deploy an eBPF program into the operating system kernel. The eBPF program includes a user-mode function entry probe uprobe and a user-mode function return probe uretprobe. Step 3: Append the uprobe to the entry point of the identified AES decryption function. When the function is executed at the entry point, capture the address and length of the target buffer parameter from the CPU register. Step 4: Append the uretprobe to the return point of the identified AES decryption function. When the function returns and executes: obtain the address and length of the target buffer based on the current thread ID; The kernel-mode function reads the contents of the target buffer from user-mode memory to obtain the decrypted plaintext data; the plaintext data and related tracking information are then encapsulated into event data. Step 5: Run a user-space application configured to load the eBPF program, attach the uprobe and uretprobe, and read, parse, and display the event data in real time.

2. The method for tracking decrypted data in a Go program according to claim 1, characterized in that: Step 1 specifically involves using the Go tool nm tool, which comes with the Go language, to analyze the target Go binary program in order to identify at least one specific AES decryption function. The function signature includes a target buffer parameter for storing the decrypted plaintext data. The specific AES decryption function is the crypto / internal / fips140 / aes.(*Block).Decrypt function in the Go standard library.

3. The method for tracking decrypted data in a Go program according to claim 1, characterized in that: Step 3 specifically involves: attaching the uprobe to the entry point of the identified AES decryption function; during function entry execution, capturing the address and length of the target buffer parameter from the CPU registers, and storing the address and length in a mapping as a decryption context; wherein the mapping uses the thread ID as the key to distinguish concurrent calls; the address of the target buffer parameter is captured from the BX register, and the length is captured from the CX register; the decryption context mapping is a hash table used to store the correspondence between thread IDs and decrypt_context structures; the decrypt_context structure contains the target buffer address and length; Step 4 specifically involves: attaching the uretprobe to the return point of the identified AES decryption function; when the function returns and executes: retrieving the corresponding decryption context from the mapping based on the current thread ID, and obtaining the address and length of the target buffer; The kernel-mode function reads the contents of the target buffer from user-mode memory to obtain the decrypted plaintext data; the plaintext data and related tracking information are encapsulated into event data; the event data is written into a circular buffer map for transmission from kernel mode to user-mode applications. Remove the decryption context of the current thread from the mapping.

4. The method for tracking decrypted data in a Go program according to claim 1, characterized in that: Step 5 specifically involves running a user-space application configured to load the eBPF program, attach the uprobe and uretprobe, and read, parse, and display the event data from the circular buffer mapping in real time, including displaying the decrypted plaintext data in hexadecimal and string formats.

5. A device for tracking decrypted data in a Go language program, characterized in that: include: The function identification module performs binary analysis on the target Go language binary program to identify at least one specific AES decryption function whose signature includes a target buffer parameter for storing the decrypted plaintext data. The deployment module deploys an eBPF program to the operating system kernel. The eBPF program includes a user-mode function entry probe uprobe and a user-mode function return probe uretprobe. The capture context module attaches the uprobe to the entry point of the identified AES decryption function, and captures the address and length of the target buffer parameters from the CPU register when the function entry point is executed; The data acquisition module appends the uretprobe to the return point of the identified AES decryption function. When the function returns and executes, it obtains the address and length of the target buffer based on the current thread ID. The kernel-mode function reads the contents of the target buffer from user-mode memory to obtain the decrypted plaintext data; the plaintext data and related tracking information are then encapsulated into event data. The parsing and display module runs a user-space application configured to load the eBPF program, attach the uprobe and uretprobe, and read, parse, and display the event data in real time.

6. The apparatus for tracking decrypted data in a Go program according to claim 5, characterized in that: The identification function module specifically involves using the Go tool nm, a tool built into the Go language, to analyze the target Go binary program to identify at least one specific AES decryption function. This function signature includes a target buffer parameter for storing the decrypted plaintext data. The specific AES decryption function is the crypto / internal / fips140 / aes.(*Block).Decrypt function in the Go standard library.

7. The apparatus for tracking decrypted data in a Go program according to claim 5, characterized in that: The capture context module specifically involves: attaching the uprobe to the entry point of the identified AES decryption function; capturing the address and length of the target buffer parameter from the CPU register during function entry execution; and storing the address and length in a mapping as the decryption context. This mapping uses the thread ID as the key to distinguish concurrent calls. The address of the target buffer parameter is captured from the BX register, and the length is captured from the CX register. The decryption context mapping is a hash table used to store the correspondence between thread IDs and decrypt_context structures. The decrypt_context structure contains the target buffer address and length. The data acquisition module specifically involves: attaching the uretprobe to the return point of the identified AES decryption function; and when the function returns and executes: retrieving the corresponding decryption context from the mapping based on the current thread ID, and obtaining the address and length of the target buffer. The kernel-mode function reads the contents of the target buffer from user-mode memory to obtain the decrypted plaintext data; the plaintext data and related tracking information are encapsulated into event data; the event data is written into a circular buffer map for transmission from kernel mode to user-mode applications. Remove the decryption context of the current thread from the mapping.

8. The apparatus for tracking decrypted data in a Go program according to claim 5, characterized in that: The parsing and display module specifically involves running a user-space application configured to load the eBPF program, attach the uprobe and uretprobe, and read, parse, and display the event data from the circular buffer mapping in real time, including displaying the decrypted plaintext data in hexadecimal and string formats.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 1 to 4.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 4.

Images