Component calling method, device, equipment, medium and product

Abstract

The application discloses a component calling method, device, equipment, medium and product. The method comprises the following steps: analyzing a target component file to obtain function feature information of a callable function; constructing a RAG knowledge base; searching the RAG knowledge base to obtain semantic information matched with the function feature information; generating executable calling logic based on the semantic information and a preset large model, so as to realize the calling of a target component in the target component file based on the executable calling logic. The application combines static analysis and dynamic semantic enhancement, can automatically complete semantic understanding and calling encapsulation of a function interface, directly outputs a callable and linkable calling code, and significantly improves integration efficiency.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a component invocation method, apparatus, device, medium, and product. Background Technology

[0002] In the field of computer software technology, especially in software integration, reverse engineering and system interoperability scenarios, efficiently and accurately calling third-party provided binary components (such as dynamic link libraries, static libraries, shared objects, etc.) is a fundamental and critical requirement.

[0003] Currently, for component calls, the main approach is to first obtain the header files or detailed interface documentation provided by the component vendor. Then, developers analyze and process the header files or detailed interface documentation to obtain executable call logic.

[0004] However, the above methods are labor-intensive and time-consuming. Summary of the Invention

[0005] The main purpose of this application is to provide a component invocation method, device, equipment, medium and product that can automatically execute component invocation without relying on manual operation.

[0006] To achieve the above objectives, firstly, this application provides a component invocation method, including:

[0007] The target component file is parsed to obtain the function characteristic information of the callable functions;

[0008] Build a RAG knowledge base;

[0009] Search the RAG knowledge base to obtain semantic information that matches the function feature information;

[0010] Based on semantic information and a pre-defined large model, executable invocation logic is generated to invoke the target component in the target component file.

[0011] In one embodiment, the target component file is parsed to obtain function characteristic information of callable functions, including:

[0012] Parse the file structure of the target component file to obtain the exported function table;

[0013] Based on the exported function table and the code segment of the target component file, obtain the callable functions;

[0014] Based on the disassembly results and the callable functions, the function characteristic information of the callable functions is obtained.

[0015] In one embodiment, the callable functions are obtained based on the exported function table and the code segment of the target component file, including:

[0016] Determine the initial function set based on the derived function table;

[0017] The validity and callability of each function in the initial function set are verified by the code snippets in the target component file, and a candidate function set is obtained.

[0018] Callable functions are selected from the candidate function set based on preset filtering criteria.

[0019] In one embodiment, based on the disassembly results and the callable functions, the function characteristic information of the callable functions is obtained, including:

[0020] Disassemble the binary code of the callable function to obtain the assembly instruction sequence;

[0021] The register operations and stack operations in the assembly instruction sequence are analyzed, and the analysis results are obtained.

[0022] Based on the preset calling convention rules, instruction semantics, and analysis results, the function characteristic information of the callable functions is obtained.

[0023] In one embodiment, after parsing the target component file to obtain the function characteristic information of the callable functions, the method further includes:

[0024] Obtain the disassembly instruction sequence of the callable function;

[0025] Scan the disassembled instruction sequence to obtain function call instructions;

[0026] Get the identifier of the called function corresponding to the function call instruction;

[0027] Establish call relationship edges with the callable function as the source node and the called function identifier as the target node;

[0028] Generate a function call graph based on the source node, target node, and call relationship edges.

[0029] In one embodiment, constructing a RAG knowledge base includes:

[0030] The function feature information is fused with a pre-defined instruction semantic library to generate function description information with calling semantics;

[0031] The function description information is structured and converted into semantic triples with functions as entities;

[0032] Encode the semantic triples to obtain the vectors corresponding to the semantic triples;

[0033] The vectors corresponding to semantic triples are associated with function feature information to form the RAG knowledge base.

[0034] In one embodiment, function feature information is fused with a preset instruction semantic library to generate function description information with call semantics, including:

[0035] The parameter passing method in the function feature information is matched with the preset instruction semantic library to obtain the data type and calling convention of the parameters;

[0036] By supplementing the data type of the parameters and the calling convention with the keywords contained in the function name, we can obtain function description information with calling semantics.

[0037] In one embodiment, the RAG knowledge base is searched to obtain semantic information that matches the function feature information, including:

[0038] Convert the function features in the function feature information into a query vector;

[0039] The query vector is input into the RAG knowledge base for similarity retrieval to obtain semantic information that matches the function feature information.

[0040] In one embodiment, based on semantic information and a pre-defined large model, executable invocation logic is generated, including:

[0041] Based on semantic information and function feature information, prompt words are constructed;

[0042] Input the prompt words into a preset large model, and output executable call logic.

[0043] Secondly, embodiments of this application provide a component invocation device, including:

[0044] The file parsing module is used to parse the target component file to obtain the function characteristic information of the callable functions;

[0045] The knowledge base building module is used to build the RAG knowledge base;

[0046] The retrieval module is used to search the RAG knowledge base and obtain semantic information that matches the function feature information;

[0047] The component invocation module is used to generate executable invocation logic based on semantic information and a pre-defined large model, so as to realize the invocation of the target component in the target component file based on the executable invocation logic.

[0048] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of any of the methods described above.

[0049] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of any of the methods described above.

[0050] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the methods described above.

[0051] This application provides a component invocation method, apparatus, device, medium, and product, comprising: first, parsing the target component file to obtain function feature information of callable functions; then, constructing a RAG knowledge base; and then, searching the RAG knowledge base to obtain semantic information matching the function feature information. Based on the semantic information and a pre-defined large model, executable invocation logic is generated to invoke the target component in the target component file. This application combines static analysis with dynamic semantic enhancement, which can automatically complete the semantic understanding and invocation encapsulation of function interfaces, directly outputting compilable and linkable invocation code, significantly improving integration efficiency. Simultaneously, by introducing RAG technology, vectorized retrieval dynamically supplements invocation specifications and business semantics from open semantic knowledge, reducing reliance on expert manual analysis while ensuring the reliability and engineering usability of the generated interface. This provides a practical and fully automated solution for the rapid integration and reuse of third-party closed-source components. Attached Figure Description

[0052] The accompanying drawings, which form part of this application, are used to provide a further understanding of the application and to make other features, objects, and advantages of the application more apparent. The illustrative embodiments and descriptions of this application are used to explain the application and do not constitute an undue limitation of the application. In the drawings:

[0053] Figure 1 This is a flowchart illustrating a component invocation method provided in an embodiment of this application;

[0054] Figure 2 This is a flowchart illustrating a method for obtaining function feature information provided in an embodiment of this application;

[0055] Figure 3 This is a flowchart illustrating a method for generating function description information provided in an embodiment of this application;

[0056] Figure 4 This is a flowchart illustrating a semantic information acquisition method provided in an embodiment of this application;

[0057] Figure 5This is a flowchart illustrating an executable call logic generation method provided in an embodiment of this application;

[0058] Figure 6 This is a schematic diagram of the structure of a component invocation device provided in an embodiment of this application;

[0059] Figure 7 This is a schematic diagram of the computer device provided in the embodiments of this application. Detailed Implementation

[0060] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0061] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein.

[0062] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0063] It should be understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0064] It should be understood that in this application, "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product or device.

[0065] It should be understood that in this application, "multiple" refers to two or more. "And / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, "and / or B" can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "Contains A, B, and C", "Contains A, B, and C" means that all three A, B, and C are contained; "Contains A, B, or C" means that one of A, B, and C is contained; "Contains A, B, and / or C" means that any one, two, or three of A, B, and C are contained.

[0066] It should be understood that in this application, "B corresponding to A", "B corresponding to A", "A corresponds to B", or "B corresponds to A" means that B is associated with A, and B can be determined based on A. Determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information. Matching A and B is defined as a similarity between A and B that is greater than or equal to a preset threshold.

[0067] Depending on the context, "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection."

[0068] The data involved in this application may be data authorized by the tester or fully authorized by all parties. The collection, dissemination, and use of the data shall comply with the relevant laws, regulations and standards of the relevant countries and regions. The implementation methods / executives of this application may be combined with each other.

[0069] The technical solutions of this application will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0070] The present application will now be described in conjunction with the accompanying drawings and specific embodiments.

[0071] In the field of computer software technology, especially in software integration, reverse engineering, and system interoperability scenarios, efficiently and accurately calling third-party provided binary components (such as dynamic link libraries, static libraries, and shared objects) is a fundamental and critical requirement. Traditionally, such calls have relied heavily on header files or detailed interface documentation provided by component vendors, which clearly define core information such as function names, parameter types, return values, and calling conventions.

[0072] However, in actual industrial practice and legacy system maintenance, many valuable commercial libraries, closed-source components, or historical legacy libraries often lack standardized documentation, or even have no documentation at all (i.e., "undocumented components"). The lack of documentation poses a huge integration barrier for developers: they have to spend a lot of time on manual reverse engineering, painstakingly inferring function behavior through disassembly, debugging, and other means. This process is not only inefficient and error-prone, but also highly dependent on the personal experience of experts and difficult to scale.

[0073] To address the challenge of undocumented programming, the industry has developed a technical approach centered on static decompilation. However, the core goal of traditional decompilation tools (such as IDA Pro and Ghidra) is to convert binary code into pseudocode or high-level language approximations that are easier for humans to read; their output is static, analytical text. While they can effectively reveal program logic and control flow, they do not solve the ultimate problem of "how to call," meaning they do not generate interface definitions (such as C function prototypes) or wrapper code that can be directly linked and executed by other programs.

[0074] Meanwhile, as Large Language Models (LLMs) have demonstrated powerful capabilities in code understanding and generation, emerging solutions based on large models for binary decompilation have appeared. These solutions attempt to train models by learning from "source code-binary" pairings to directly recover high-quality source code. However, these methods have fundamental limitations: first, their goal remains code recovery rather than interface generation, and they are not optimized for the calling scenario; second, they heavily rely on large-scale, high-quality, and precisely aligned labeled datasets for model fine-tuning. Building such datasets is extremely expensive, and it is difficult to cover the massive amounts of industrial-grade binary files with varying architectures and compilation options, resulting in insufficient model generalization ability and unstable performance on real-world undocumented binary files.

[0075] Therefore, there is a significant gap in the current technology ecosystem: there is an urgent need for an end-to-end solution that can automatically understand function semantics from raw binary files and directly generate executable call logic without relying on manually annotated documentation.

[0076] Currently, technologies for binary file analysis and understanding are developing mainly in two directions:

[0077] The first category consists of professional binary decompilation and static analysis tools such as IDA Pro, Ghidra, and Binary Ninja. These tools constitute the industry standard for reverse engineering. Their working principle is as follows: First, the binary file is parsed (e.g., ELF, PE), identifying structures such as code segments, data segments, and symbol tables; then, a disassembler engine converts machine instructions into assembly code; subsequently, based on static analysis techniques such as control flow analysis and data flow analysis, the assembly code is elevated to a higher-level, language-independent intermediate representation (IR), ultimately generating C-like pseudocode. The core value of these tools lies in greatly improving the readability of binary code, helping security researchers or developers understand the program's internal logic, algorithm implementation, and potential vulnerabilities. However, their output is essentially an analysis report, not a build instruction. The tools themselves do not care about or possess the ability to generate cross-language bindings, generate directly compileable wrapper functions, or adapt to different calling conventions. Users still need to manually interpret the pseudocode and write the calling code, resulting in low automation.

[0078] The second category comprises intelligent decompilation systems based on deep learning and large language models. This type of approach represents the cutting edge of current academic and industrial research. For example, a binary code decompilation system based on multi-stage fine-tuning of a large model employs a two-stage process: the first stage focuses on dataset construction, creating a massive "source code-binary" pairing dataset by extensively collecting source code from open-source projects and compiling it into binary files of different architectures and optimization levels, followed by preprocessing to ensure alignment quality; the second stage utilizes this dataset to perform multi-stage fine-tuning of the open-source large model, combining static analysis techniques such as function call graphs to provide context, ultimately training a domain-specific large model for decompilation. The goal of this model is to output high-level language code that is semantically and structurally as close as possible to the original source code from a given binary code or assembly sequence. While this type of method has the potential to improve the semantic fidelity and readability of decompiled code, its technical paradigm remains firmly rooted in the traditional goal of reproducing the source code, without considering the generation of directly callable interfaces as a design objective. The generated code focuses more on reproducing the algorithmic logic than providing a clean, secure, and convention-compliant API shell.

[0079] In summary, both existing mainstream technical solutions have significant shortcomings when addressing the specific engineering problem of calling undocumented components:

[0080] The fundamental flaw of decompilation tools like IDA lies in their misaligned functionalities. They are excellent tools for analysis and understanding, but not for building and integrating. They can extract function entry addresses and a rough estimate of the number of parameters (through stack analysis), but they cannot precisely infer the data types of the parameters (e.g., distinguishing between int*, char*, and structure pointers), call specification details (e.g., who is responsible for cleanup the stack), or the specific meaning of the return value. This lack of information creates a gap between the decompiled result and a working piece of calling code, requiring human experience to bridge, thus halting the automation process.

[0081] The core flaw of large-model-based decompilation systems lies in their data dependency and deviation from the target. First, their performance heavily relies on expensive and difficult-to-obtain labeled datasets. In real-world scenarios, this approach is unusable with a proprietary binary library lacking any corresponding source code, as the lack of matching data for fine-tuning leads to a significant drop in generalization ability in real-world undocumented environments. Second, and more critically, even if the model outputs high-quality decompiled code, the output is still a substitute for the source code, not a solution for invocation. Developers still need to manually extract and encapsulate interface information from potentially complex decompiled code containing numerous internal variables and logic, failing to achieve end-to-end automation from binary to callable interface. Furthermore, such solutions are computationally expensive, making it difficult to achieve a lightweight, real-time experience of parsing and invocation immediately.

[0082] Therefore, existing technologies either remain at the analysis stage and cannot generate calling logic, or are hampered by data bottlenecks and misaligned with the target, neither of which can effectively meet the industry's urgent need for rapid, automated, and low-cost integration of documentless binary components.

[0083] To address the aforementioned issues, this application proposes a component invocation method.

[0084] Please see Figure 1 , Figure 1 This is a flowchart illustrating a component invocation method provided in an embodiment of this application. Figure 1 As shown, it includes the following steps:

[0085] Step S101: Parse the target component file to obtain the function characteristic information of the callable functions.

[0086] To parse the target component file and obtain the function characteristic information of the callable functions, the file structure of the target component file must first be parsed to obtain the exported function table. Then, based on the exported function table and the code segment of the target component file, the callable functions are obtained. Finally, based on the disassembly results and the callable functions, the function characteristic information of the callable functions is obtained.

[0087] The process of obtaining callable functions based on the exported function table and the code segments of the target component file includes: determining an initial function set based on the exported function table; verifying the validity and callability of each function in the initial function set through the code segments of the target component file to obtain a candidate function set; and selecting callable functions from the candidate function set according to preset filtering conditions.

[0088] Specifically, based on the disassembly results and the callable functions, the function characteristic information of the callable functions is obtained, including: disassembling the binary code of the callable functions to obtain the assembly instruction sequence; analyzing the register operations and stack operations in the assembly instruction sequence to obtain the analysis results; and obtaining the function characteristic information of the callable functions based on the preset calling convention rules, instruction semantics, and analysis results.

[0089] Specifically, such as Figure 2 As shown, first, it is necessary to understand the organization of the target binary file. Taking the common ELF (Executable and Linkable Format) file as an example, the file is initially parsed by integrating static analysis tools (such as IDA Pro, Ghidra, or a custom parser).

[0090] The core objective at this stage is to locate all theoretically callable function entry points from external modules. The resolution process involves reading the ELF file header, section header table, and dynamic symbol table (.dynsym), extracting the exported function table, which contains the function's name (or name hash) in the symbol table and its virtual address in memory or the file.

[0091] After obtaining the exported function table, it is necessary to accurately identify the set of functions that can truly be called safely and effectively. This step involves three layers of filtering to ensure the reliability of the results:

[0092] First, based on the exported function table, obtain all function symbols marked as public (Global) and with exported attributes, along with their entry addresses, to form an initial function set.

[0093] Since not all exported symbols point to valid executable code, each function address in the initial function set is traversed to verify that it is located within an executable code segment (usually the .text segment). The instruction sequence starting at that address is then disassembled to confirm that it conforms to the function prologue (such as stack frame creation) and basic control flow structure. This process filters out invalid exports that point to data, null addresses, or are merely linker placeholders, resulting in a candidate function set.

[0094] Finally, the candidate function set is filtered using selection criteria to obtain callable functions. For example, functions must contain clear return instructions (such as RET, BX, LR); entry points must be unique and unobfuscated; and for some architectures, it is also necessary to check whether the functions follow specific alignment requirements. This step ultimately determines the callable functions, greatly improving the focus of subsequent analysis.

[0095] After obtaining the callable function, in-depth instruction-level analysis is performed to extract structured features. First, the binary code of the function is disassembled to obtain its corresponding assembly instruction sequence.

[0096] Analyze the assembly instructions line by line, focusing on the following two types of operations:

[0097] Register operations: Tracking the read and write behavior of general-purpose registers (such as EAX, ECX, EDX in x86 architecture; R0-R3 in ARM architecture) and purpose-specific registers (such as stack pointers SP / ESP / RSP, frame pointers BP / EBP / RBP). For example, observing which registers are loaded with data before function call instructions (CALL / BL) can help infer parameter passing.

[0098] Stack operations: Analyze the PUSH / POP instruction sequence and direct arithmetic operations on the stack pointer (such as SUB SP, #16) to determine the allocation and release of stack frames, the storage space of local variables, and possible stack parameter passing.

[0099] The above analysis results are combined with a pre-built calling convention rule base (covering cdecl, stdcall, fastcall, ARMAAPCS, etc.) and instruction semantic base to perform logical reasoning, thereby formally inferring function characteristic information, mainly including the following:

[0100] Parameter information: Infers the number of parameters, the method of passing them (registers or stack), and the basic type (such as integer, pointer, floating-point) inferred based on the data movement pattern and usage context. For example, under the ARM AAPCS convention, if a call is initiated after data is observed to be loaded into R0 and R1, it can be inferred that the function accepts at least two parameters, and R0 and R1 are the registers for passing the first two parameters.

[0101] Return value information: Identify which register (such as EAX in x86, R0 in ARM) or memory location was written to before the function returns, and infer the return value type by combining common patterns (such as EAX / R0 often being used for return pointers).

[0102] Stack frame characteristics: The size of the stack space allocated by the function for local variables and storage registers.

[0103] In one embodiment, after parsing the target component file to obtain the function feature information of the callable functions, the method further includes: obtaining the disassembly instruction sequence of the callable functions; scanning the disassembly instruction sequence to obtain function call instructions; obtaining the identifier of the called function corresponding to the function call instructions; establishing a call relationship edge with the callable function as the source node and the called function identifier as the target node; and generating an inter-function call graph based on the source node, target node, and call relationship edge.

[0104] Specifically, to understand the internal structure of components and support subsequent cross-function context analysis, after extracting individual function features, a function call graph is further constructed, and the following steps are performed:

[0105] The disassembly instruction sequence of each callable function is scanned to identify all function call instructions (such as CALL, BL, JMP to function addresses). The target addresses of these instructions are then parsed, and the identifier of the called function (function name or internal ID) is obtained through address mapping or symbol table resolution. Using the currently analyzed function as the source node and the called function as the target node, directed call relationship edges are established. All function nodes and their call relationship edges are integrated to finally generate a function call graph. This graph not only reveals the subroutine hierarchy and dependencies within a module but also helps identify critical path functions and library function call patterns.

[0106] Suppose we are resolving an undocumented dynamic library named libcrypto.so. First, we identify the address of its exported function AES_encrypt. After verifying that the address is located in the .text section and contains valid instructions, we confirm that it is a callable function.

[0107] At the start of the callable function, three parameters are loaded from the stack relative to the frame pointer into registers R0, R1, and R2. The function calls `memcpy` and the internal function `block_permute`. Finally, the result is returned via R0. Based on the ARMAAPCS calling convention, its characteristics are: three parameters (passed through the stack to R0-R2, presumably pointers to the input buffer, output buffer, and key structure), a return value of R0, and internal calls to `memcpy` and `block_permute`. Furthermore, in the call graph, `AES_encrypt` acts as the source node, pointing to both `memcpy` and `block_permute` as target nodes.

[0108] Step S102: Construct the RAG knowledge base.

[0109] To build a RAG knowledge base, the function feature information must first be fused with a pre-defined instruction semantic library to generate function description information with call semantics. Then, the function description information is structured and converted into semantic triples with functions as entities. The semantic triples are then encoded to obtain vectors corresponding to the semantic triples. Finally, the vectors corresponding to the semantic triples are associated with the function feature information to form the RAG knowledge base.

[0110] This involves integrating function feature information with a pre-defined instruction semantic library to generate function description information with call semantics. This includes: matching the parameter passing method in the function feature information with the pre-defined instruction semantic library to obtain the data type and calling convention of the parameters; and supplementing the data type and calling convention of the parameters with keywords contained in the function name to obtain function description information with call semantics.

[0111] Specifically, such as Figure 3 As shown, taking the feature information of the function `encrypt_str` extracted from a component without documentation as an example, its original feature table shows that: parameters are passed through registers R0 and R1; the return value is passed through register R0; and the functions `memcpy` and `crc32` are called internally.

[0112] First, knowledge fusion is performed to generate a call semantic description. The above features are matched and inferred with a preset instruction semantic library and call specification library. Specifically, according to the ARM architecture's AAPCS calling convention, R0 and R1 are usually used to pass the first two integer or pointer parameters. Combining the analysis in the instruction semantic library that the LDR (load) instruction is often used to prepare pointer parameters, it is inferred that: L0 is likely a pointer to input data (such as a string or buffer), and L1 is likely an integer value representing length (such as key length or data size).

[0113] The function name `encrypt_str` contains the keywords `encrypt` and `str` (a common abbreviation for string). Further description based on this suggests that `encrypt_str` is likely a string encryption function, where its L0 parameter is a pointer to the string to be encrypted, and its L1 parameter is an integer parameter related to the encryption process (such as key length or encryption mode flags).

[0114] The return value uses the R0 register, which is used as an encryption function. It internally calls memcpy (memory copy) and crc32 (cyclic redundancy check, often used for data integrity verification or as a simple hash). It can be inferred that its return value is a pointer to the encrypted result string, or a status code indicating whether the encryption operation was successful or not.

[0115] Through the above integration, function description information with clear call semantics that transcends the original binary features is generated: encrypt_str function: A string encryption routine that takes a string pointer and an integer parameter (possibly the key length), returns a pointer (to the encryption result) or a status code, and performs copy and verification operations internally.

[0116] Next, convert the above description information into semantic triples with functions as entities. For example: <encrypt_str, parameter type, [pointer, integer]>, <encrypt_str, function category, encryption>, <encrypt_str, internal call, [memcpy, crc32]>. These triples precisely capture the semantic core of the function.

[0117] Subsequently, use a pre-trained language model (such as Sentence-BERT) to encode these text triples into high-dimensional vectors, where each vector becomes a digital representation of a certain semantic feature of the function.

[0118] Finally, closely associate the generated semantic vectors with the original feature information of the function (entry address, parameter registers, stack frame size, etc.) and store them in a vector database (such as Milvus, Pinecone). In this process, a unique ID is established for the function, and a mapping relationship of "function ID, original features, semantic vector set" is constructed.

[0119] The resulting RAG knowledge base not only stores the static features of the function but also establishes a retrieval index based on semantic similarity. When it is necessary to infer the semantics of an unknown function subsequently, its features can be encoded as a query vector, and the known function with the most similar semantic vector (such as encrypt_str) can be quickly retrieved from the knowledge base, thereby "associating" and supplementing the key semantic context of "possibly an encryption function" for it, providing crucial semantic support for finally generating accurate callable interface code.

[0120] In summary, this embodiment demonstrates how to transform registers and instruction sequences into structured knowledge with rich business meanings through integrated reasoning with specifications, semantic libraries, and its own name, and further construct a semantically intelligent retrievable knowledge base through vectorization technology. This is the core link to achieve the leap from features to semantics in documentless calls.

[0121] Step S103: Retrieve the RAG knowledge base to obtain semantic information that matches the function feature information.

[0122] The RAG knowledge base is searched to obtain semantic information that matches the function feature information, including: converting the function features in the function feature information into query vectors; inputting the query vectors into the RAG knowledge base for similarity retrieval to obtain semantic information that matches the function feature information.

[0123] Specifically, such as Figure 4 As shown, after the RAG knowledge base is constructed, it possesses the ability to infer context for unknown functions based on semantic similarity. The subsequent retrieval process efficiently and accurately maps the structured features of the function to be parsed onto the semantic space of the knowledge base, thereby finding the most relevant prior knowledge. A specific implementation example is described below:

[0124] Taking a new, undocumented binary function (e.g., the function decrypt_buffer parsed from a newly loaded dynamic library) as an example, the aforementioned feature extraction steps will be performed first to obtain its structured feature information, such as: parameters are passed through registers R0 and R1; return value is passed through register R0; stack frame size: 32 bytes; internal call instructions: involve memcpy and an unknown internal function block_xor.

[0125] Next, the retrieval process will be initiated to obtain semantic information. The specific steps are as follows:

[0126] This application does not directly use the original feature text for retrieval. Instead, it mimics the processing method used in knowledge base construction, transforming the feature information of the new function into a machine-comparable mathematical representation. Specifically, it extracts key semantic elements from the function's features (such as parameter registers R0 and R1, and the internal call to memcpy), and may combine this with the function name decrypt_buffer to generate a concise text description fragment, for example: the function decrypt_buffer uses R0 and R1 to pass parameters and internally calls memcpy.

[0127] Subsequently, the same pre-trained text encoding model (such as Sentence-BERT) used when building the knowledge base is invoked to encode this description fragment into a fixed-length query vector. This vector encapsulates a distributed semantic representation of the features of the new function.

[0128] Database engines (such as Milvus) perform an efficient nearest neighbor search in a pre-constructed high-dimensional vector space, calculating the similarity (usually using cosine similarity) between the query vector and the semantic vectors of all known functions in the knowledge base. After a fast comparison, they return the top K (e.g., top-3) candidate vectors with the highest similarity and their corresponding function entities.

[0129] Suppose the most similar result returned by the search points to the known function encrypt_str in the knowledge base, and its associated semantic triple includes: <function category, encryption / decryption>, <parameter type, [pointer, integer]>, <common use, data block processing>.

[0130] Then, these matched semantic triples are extracted from the knowledge base. Since decrypt_buffer and encrypt_str are highly similar in characteristics (both use two registers to pass parameters, both call memcpy, and their names suggest cryptographic operations), the knowledge base associates and provides a strong semantic context for this new function decrypt_buffer: this function is likely also a data block processing function, belonging to decryption operations, and its two parameters may point to integer values ​​such as the data buffer to be decrypted and the key length, respectively.

[0131] In summary, this retrieval example demonstrates how to achieve "feature-as-semantics" associative capabilities. By transforming the features of a new function into standardized query vectors and performing similarity matching in the semantic vector space, the most relevant, pre-fused semantic descriptions can be retrieved in real time from the RAG knowledge base. This process not only automatically supplements undocumented functions with key business semantics (such as "decryption") but also provides specific calling convention references (such as parameter types), thus providing indispensable, high-quality contextual input for generating accurate and executable calling code logic for subsequent large-scale models. This effectively solves the semantic gap between pure binary analysis and general large-scale models.

[0132] Step S104: Based on semantic information and a pre-defined large model, generate executable calling logic to implement the calling of the target component in the target component file.

[0133] Based on semantic information and a pre-defined large model, executable calling logic is generated, including: constructing prompt words based on semantic information and function feature information; inputting the prompt words into the pre-defined large model and outputting executable calling logic.

[0134] Specifically, such as Figure 5 As shown, in the above embodiment, feature extraction (parameters are passed through R0 and R1, return to R0, and call memcpy) and RAG semantic retrieval (it is inferred that its function is decryption, and the parameters may be a data buffer pointer and an integer key length) have been completed for the documentless function decrypt_buffer.

[0135] Instead of directly feeding the raw data into a large model, it is integrated and arranged into a context-rich, clearly defined prompt. This prompt typically employs a modular structure, for example:

[0136] You are a binary interface generation expert. Based on the following information, generate a directly callable C language function prototype and its wrapper code.

[0137]

Characteristics of the Objective Function

[0138] Function name: decrypt_buffer

[0139] Parameter convention: Two parameters are passed through registers R0 and R1.

[0140] Return value convention: Returned via register R0.

[0141] Call graph relationship: internally calls `memcpy`.

[0142] [Semantic Context Provided by RAG]

[0143] Functional inference: This function is likely a data block decryption function.

[0144] Parameter inference: The first parameter may be a pointer to the buffer of the data to be decrypted; the second parameter (R1) may be an integer value representing the key length or data size.

[0145] Return inference: The return value may be a pointer to the decrypted data or an operation status code.

[0146]

Task Generation and Constraints

[0147] 1. Generate a C language function declaration, with parameters named appropriately and using suitable types such as void*, const void*, int, size_t, etc.

[0148] 2. Generate corresponding encapsulated call code examples, demonstrating how to prepare parameters and call this function (assuming it is located in the dynamic library libcrypto.so).

[0149] 3. Code should follow system call conventions and add necessary safety comments (such as pointer NOT NULL checks).

[0150] This prompt systematically embeds three layers of key information: underlying features (what it is), enhanced semantics (what it might do), and explicit task instructions and engineering constraints (what to generate and what the requirements are), providing a high-quality, low-noise generation context for large models.

[0151] Input the structured prompts mentioned above into a pre-defined large model (such as GPT-4, CodeLlama, etc.). Based on its powerful code understanding and generation capabilities, the large model integrates the specific constraints and semantic clues in the prompts to output a compliant, ready-to-use calling logic. The code generated by the large model not only provides accurate function prototypes (correctly using const void* and size_t types), but also generates complete loading and calling examples including error handling.

[0152] Ultimately, developers can directly integrate the generated interface definition and sample code into their own projects, compile and link the target component (such as libcrypto.so), and then successfully call the decrypt_buffer function to decrypt the encrypted data buffer without needing the original documentation.

[0153] In summary, this embodiment combines "structured hints of features and semantics" with "constrained code generation for large models," achieving automated and intelligent conversion from binary feature descriptions to executable interfaces of various high-level languages. This generates production-grade code that can be directly compiled, linked, and run, greatly improving the integration efficiency and usability of third-party binary components.

[0154] This application provides a component invocation method, comprising: first, parsing the target component file to obtain function feature information of callable functions; then, constructing a RAG knowledge base; and then, searching the RAG knowledge base to obtain semantic information matching the function feature information. Based on the semantic information and a pre-defined large model, executable invocation logic is generated to invoke the target component in the target component file. This application combines static analysis with dynamic semantic enhancement, which can automatically complete the semantic understanding and invocation encapsulation of function interfaces, directly outputting compilable and linkable invocation code, significantly improving integration efficiency. Simultaneously, by introducing RAG technology, vectorized retrieval is used to dynamically supplement invocation specifications and business semantics from open semantic knowledge, reducing reliance on expert manual analysis while ensuring the reliability and engineering usability of the generated interface. This provides a practical and fully automated solution for the rapid integration and reuse of third-party closed-source components.

[0155] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0156] The following are device embodiments of this application. For details not described in detail, please refer to the corresponding method embodiments described above.

[0157] Figure 6This diagram illustrates a component invocation device according to an embodiment of this application. For ease of explanation, only the parts relevant to the embodiment of this application are shown. The component invocation device includes:

[0158] The file parsing module 601 is used to parse the target component file to obtain the function characteristic information of the callable functions;

[0159] Knowledge base construction module 602 is used to build the RAG knowledge base;

[0160] The retrieval module 603 is used to retrieve semantic information from the RAG knowledge base and obtain semantic information that matches the function feature information.

[0161] The component invocation module 604 is used to generate executable invocation logic based on semantic information and a preset large model, so as to realize the invocation of the target component in the target component file based on the executable invocation logic.

[0162] In one embodiment, the file parsing module 601 is further configured to parse the file structure of the target component file and obtain the exported function table;

[0163] Based on the exported function table and the code segment of the target component file, obtain the callable functions;

[0164] Based on the disassembly results and the callable functions, the function characteristic information of the callable functions is obtained.

[0165] In one embodiment, the file parsing module 601 is further configured to determine an initial set of functions based on the exported function table;

[0166] The validity and callability of each function in the initial function set are verified by the code snippets in the target component file, and a candidate function set is obtained.

[0167] Callable functions are selected from the candidate function set based on preset filtering criteria.

[0168] In one embodiment, the file parsing module 601 is further configured to disassemble the binary code of the callable function to obtain an assembly instruction sequence;

[0169] The register operations and stack operations in the assembly instruction sequence are analyzed, and the analysis results are obtained.

[0170] Based on the preset calling convention rules, instruction semantics, and analysis results, the function characteristic information of the callable functions is obtained.

[0171] In one embodiment, the file parsing module 601 is further configured to include: a call graph generation module, which is configured to obtain the disassembly instruction sequence of the callable function;

[0172] Scan the disassembled instruction sequence to obtain function call instructions;

[0173] Get the identifier of the called function corresponding to the function call instruction;

[0174] Establish call relationship edges with the callable function as the source node and the called function identifier as the target node;

[0175] Generate a function call graph based on the source node, target node, and call relationship edges.

[0176] In one embodiment, the knowledge base construction module 602 is further configured to fuse function feature information with a preset instruction semantic library to generate function description information with calling semantics;

[0177] The function description information is structured and converted into semantic triples with functions as entities;

[0178] Encode the semantic triples to obtain the vectors corresponding to the semantic triples;

[0179] The vectors corresponding to semantic triples are associated with function feature information to form the RAG knowledge base.

[0180] In one embodiment, the knowledge base construction module 602 is further configured to match the parameter passing method in the function feature information with a preset instruction semantic library to obtain the data type and calling specification of the parameter;

[0181] By supplementing the data type of the parameters and the calling convention with the keywords contained in the function name, we can obtain function description information with calling semantics.

[0182] In one embodiment, the retrieval module 603 is further configured to convert the function features in the function feature information into a query vector;

[0183] The query vector is input into the RAG knowledge base for similarity retrieval to obtain semantic information that matches the function feature information.

[0184] In one embodiment, the component invocation module 604 is further configured to construct prompt words based on semantic information and function feature information;

[0185] Input the prompt words into a preset large model, and output executable call logic.

[0186] This application provides a component invocation device, specifically used for: first, parsing the target component file to obtain function feature information of callable functions; then, constructing a RAG knowledge base; and finally, searching the RAG knowledge base to obtain semantic information matching the function feature information. Based on the semantic information and a preset large model, executable invocation logic is generated to realize the invocation of the target component in the target component file. This application combines static analysis with dynamic semantic enhancement, which can automatically complete the semantic understanding and invocation encapsulation of function interfaces, directly outputting compilable and linkable invocation code, significantly improving integration efficiency. At the same time, by introducing RAG technology, vectorized retrieval is used to dynamically supplement invocation specifications and business semantics from open semantic knowledge, reducing reliance on expert manual analysis while ensuring the reliability and engineering usability of the generated interface, providing a practical and fully automated solution for the rapid integration and reuse of third-party closed-source components.

[0187] This application Figure 7 A schematic diagram of a computer device is provided. (Example) Figure 7 As shown, the computer device 7 in this embodiment includes a processor 701, a memory 702, and a computer program 707 stored in the memory 702 and executable on the processor 701. When the processor 701 executes the computer program 707, it implements the steps in the above-described component invocation method embodiments, for example... Figure 1 Steps 101 to 104 are shown. Alternatively, when processor 701 executes computer program 707, it implements the functions of each module / unit in the above-described component calling device embodiment, for example... Figure 6 The functions of modules 601 to 604 are shown.

[0188] This application also provides a readable storage medium storing a computer program, which, when executed by a processor, is used to implement the component invocation methods provided in the various embodiments described above.

[0189] The readable storage medium can be a computer storage medium or a communication medium. A communication medium includes any medium that facilitates the transfer of computer programs from one location to another. A computer storage medium can be any available medium accessible to a general-purpose or special-purpose computer. For example, a readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application-Specific Integrated Circuit (ASIC). Alternatively, the ASIC can be located in a user equipment. Of course, the processor and the readable storage medium can also exist as discrete components in a communication device. The readable storage medium can be a read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0190] This application also provides a program product including executable instructions stored in a readable storage medium. At least one processor of the device can read the executable instructions from the readable storage medium, and the execution of the executable instructions by the at least one processor causes the device to implement the component invocation methods provided in the various embodiments described above.

[0191] In the embodiments of the above-described device, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0192] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A component invocation method, characterized in that, include: The target component file is parsed to obtain the function characteristic information of the callable functions; The parameter passing method in the function feature information is matched with a preset instruction semantic library to obtain the data type and calling specification of the parameter; The data type and calling convention of the parameters are supplemented by the keywords contained in the function name to obtain function description information with calling semantics; The function description information is structured and converted into semantic triples with functions as entities; Encode the semantic triples to obtain the vectors corresponding to the semantic triples; The vectors corresponding to the semantic triples are associated with the function feature information to form the RAG knowledge base; The RAG knowledge base is searched to obtain semantic information that matches the function feature information; Based on the semantic information and the preset large model, an executable invocation logic is generated to invoke the target component in the target component file.

2. The component invocation method as described in claim 1, characterized in that, The process of parsing the target component file to obtain the function characteristic information of the callable functions includes: The file structure of the target component file is parsed to obtain the exported function table; Based on the exported function table and the code segment of the target component file, obtain the callable functions; Based on the disassembly results and the callable function, the function characteristic information of the callable function is obtained.

3. The component invocation method as described in claim 2, characterized in that, The step of obtaining callable functions based on the exported function table and the code segment of the target component file includes: Based on the derived function table, determine the initial function set; The validity and callability of each function in the initial function set are verified by the code segment of the target component file to obtain a candidate function set; The callable functions are selected from the candidate function set according to preset filtering criteria.

4. The component invocation method as described in claim 2, characterized in that, The process of obtaining the function characteristic information of the callable function based on the disassembly results and the callable function includes: The binary code of the callable function is disassembled to obtain a sequence of assembly instructions; The register operations and stack operations in the assembly instruction sequence are analyzed to obtain the analysis results; Based on the preset calling convention rules and instruction semantics and the analysis results, the function feature information of the callable function is obtained.

5. The component invocation method as described in any one of claims 1-4, characterized in that, After parsing the target component file to obtain the function characteristic information of the callable functions, the process further includes: Obtain the disassembly instruction sequence of the callable function; The disassembled instruction sequence is scanned to obtain function call instructions; Obtain the identifier of the called function corresponding to the function call instruction; Establish a calling relationship edge with the callable function as the source node and the called function identifier as the target node; Based on the source node, the target node, and the call relationship edges, a function call graph is generated.

6. The component invocation method as described in claim 1, characterized in that, The step of retrieving semantic information from the RAG knowledge base to obtain semantic information that matches the function feature information includes: Convert the function features in the function feature information into a query vector; The query vector is input into the RAG knowledge base for similarity retrieval to obtain semantic information that matches the function feature information.

7. The component invocation method as described in claim 1, characterized in that, The generation of executable invocation logic based on the semantic information and the preset large model includes: Based on the semantic information and the function feature information, prompt words are constructed; Input the prompt word into the preset large model, and output the executable call logic.

8. A component invocation device, characterized in that, include: The file parsing module is used to parse the target component file to obtain the function characteristic information of the callable functions; The knowledge base construction module is used to match the parameter passing method in the function feature information with a preset instruction semantic library to obtain the data type and calling specification of the parameter; The data type and calling convention of the parameters are supplemented by the keywords contained in the function name to obtain function description information with calling semantics; The function description information is structured and converted into semantic triples with functions as entities; Encode the semantic triples to obtain the vectors corresponding to the semantic triples; The vectors corresponding to the semantic triples are associated with the function feature information to form the RAG knowledge base; The retrieval module is used to retrieve semantic information that matches the function feature information from the RAG knowledge base. The component invocation module is used to generate executable invocation logic based on the semantic information and the preset large model, so as to realize the invocation of the target component in the target component file based on the executable invocation logic.

9. A computer device, characterized in that, Includes a memory, and one or more processors communicatively connected to the memory; The memory stores instructions that can be executed by the one or more processors to cause the one or more processors to implement the component invocation method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Includes a program or instruction that, when run on a computer, implements the component invocation method of any one of claims 1 to 7.

11. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the component invocation method of any one of claims 1 to 7.

Images