C-lua cross-language code static taint analysis method, device and equipment

Abstract

The application relates to a C-Lua cross-language code static taint analysis method, device and equipment in the network security technical field, the method comprising the following steps: identifying a candidate registration function of a URI processor according to the characteristics of function parameters; filtering the candidate registration function of the URI processor to determine an actual registration function; taking all parameters of a URI processing program registered by the actual registration function as a candidate pollution point source; filtering the candidate pollution point source to determine a controllable Lua-C cross-language pollution point source; identifying a function call relationship from Lua to C and from C to Lua by analyzing API mapping relationships from Lua to C and from C to Lua; and realizing taint propagation of Lua-C cross-language by using the function call relationship. The method can identify specific pollution point sources of Lua language in C-Lua network services, supports tracking of cross-language taint propagation processes in the C-Lua network services, and helps to enhance the detection capability of taint class vulnerabilities.

Description

Technical Field

[0001] This invention belongs to the field of network security technology and relates to a method, apparatus and device for static taint analysis of C-Lua cross-language code. Background Technology

[0002] Internet of Things (IoT) devices have become deeply integrated into daily life, and inherent vulnerabilities in IoT (such as remote code execution and denial-of-service attacks) pose significant risks to production and living infrastructure (such as routers, IP cameras, and VPN devices). Security researchers are actively developing static and dynamic techniques to detect vulnerabilities in IoT network services. Technically, dynamic methods achieve vulnerability discovery by simulating environments or directly executing target services on physical devices and using fuzzing. However, these methods face challenges such as difficulty in firmware simulation and low code coverage. In contrast, static methods do not require the establishment of dynamic execution environments and have been considered an effective complementary solution for detecting vulnerabilities in IoT network services. Specifically, related research mainly uses taint analysis techniques to achieve this goal. This technique includes two aspects: ① source and sink identification, used to locate user-controllable input (source) and security-sensitive operations (sink); ② taint propagation stage, which verifies whether attacker-controlled data can flow from the source to the sink through the execution path, thereby potentially leading to exploitable security vulnerabilities.

[0003] While these taint analysis techniques have successfully identified many vulnerabilities in firmware web services, these studies simplify the Lua-C hybrid scenarios present in firmware, significantly reducing the effectiveness of vulnerability detection. Regarding Lua taint source identification, the recently proposed LuaTaint framework adopts an aggressive strategy, treating all input parameters of the URI processor as taint sources. Clearly, this heuristic approach leads to a large number of false positives. Worse still, LuaTaint's framework-specific design (i.e., only supporting services implemented based on the LuCI framework) will cause serious false negatives. Furthermore, there is often frequent and complex communication between C binary files and Lua scripts or Lua bytecode. Although there is research on cross-language taint propagation (such as C-Python, C-Java), there is currently no research on Lua-C cross-language taint propagation. Summary of the Invention

[0004] To address the problems existing in the above-mentioned traditional methods, this invention proposes a method, apparatus, and device for static taint analysis of C-Lua cross-language code, which can identify unique taint sources in the C-Lua environment and handle the propagation process of C-Lua cross-language taints.

[0005] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions:

[0006] On the one hand, a method for static taint analysis of C-Lua cross-language code is provided, including the following steps:

[0007] Based on the characteristics of the function parameters, identify candidate registration functions for the URI processor.

[0008] The candidate registration functions of the URI processor are filtered to determine the actual registration function; all parameters of the URI processor registered by the actual registration function are used as candidate pollution point sources.

[0009] Candidate contamination sources are filtered to identify controllable cross-language Lua-C contamination sources.

[0010] By analyzing the API mapping relationships between Lua and C and between C and Lua, we can identify the function call relationships between Lua and C and between C and Lua, and use these function call relationships to achieve taint propagation across Lua and C languages.

[0011] In one embodiment, identifying candidate registration functions for the URI processor based on the characteristics of the function parameters includes:

[0012] Analyze the parameters of all functions; if a parameter is a string corresponding to a function name, then that function is considered a candidate for registration as a URI processor.

[0013] If the parameter is a table with a registration structure containing an internal function object, and that contains the target URI processor function, then that function is also considered a candidate registration function for the URI processor.

[0014] In one embodiment, the candidate registration function for the URI processor includes: a registry-based URI processor candidate registration function and a name-binding-based URI processor candidate registration function.

[0015] The candidate registration functions for URI processors are filtered to determine the actual registration functions; all parameters of the URI processors registered by the actual registration functions are used as candidate pollution point sources, including:

[0016] For a registry-based URI handler candidate registration function, if the registry-based URI handler candidate registration function is detected as a parameter of a CALL instruction, then the registry-based URI handler candidate registration function is registered as the actual registration function.

[0017] For a name-bound URI processor candidate registration function, this type of registration logic is identified by detecting whether the Lua SETABLE class directive uses a constant string. If so, the name-bound URI processor candidate registration function is the actual registration function.

[0018] All parameters of the URI handler registered by the actual registration function are used as candidate taint sources.

[0019] In one embodiment, filtering candidate contamination sources to determine controllable Lua-C cross-language contamination sources includes:

[0020] Iterate through the candidate taint sources, and determine the candidate taint sources whose parameters have a hierarchical structure and use Lua table structure as controllable Lua-C cross-language taint sources; determine the candidate taint sources whose parameters are stored in basic types such as numbers and strings as uncontrollable taint sources.

[0021] In one embodiment, by analyzing the API mapping relationships between Lua and C and between C and Lua, function call relationships between Lua and C and between C and Lua are identified. These function call relationships are then used to implement cross-language taint propagation in Lua-C, including:

[0022] It iterates through all C Library dynamic libraries, identifies the function tables registered through the luaRegister() method, parses and identifies the mapping relationship between C function names called in Lua and C function addresses, then analyzes the function call sequence lua_loadfile() -> lua_getglobal() -> luaPushNumber() -> lua_pcall() in the C language binary file, parses and identifies the Lua functions called in the C language binary, obtains the function call relationship from Lua to C and from C to Lua, and uses the function call relationship to realize the taint propagation of Lua-C cross-language.

[0023] On the other hand, a C-Lua cross-language code static taint analysis apparatus is also provided, the apparatus comprising:

[0024] The candidate registration function determination module is used to identify candidate registration functions for the URI processor based on the characteristics of the function parameters.

[0025] The candidate pollution source determination module is used to filter the candidate registration functions of the URI processor and determine the actual registration function; all parameters of the URI processor registered by the actual registration function are used as candidate pollution source.

[0026] The Controllable Lua-C Cross-Language Pollution Source Determination Module is used to filter candidate pollution sources and determine controllable Lua-C cross-language pollution sources.

[0027] The Lua-C cross-language taint propagation module is used to analyze the API mapping relationships between Lua and C and between C and Lua, identify the function call relationships between Lua and C and between C and Lua, and use the function call relationships to implement taint propagation across Lua and C.

[0028] In one embodiment, the candidate registration function determination module is further configured to analyze the parameters of all functions. If the parameter is a string corresponding to the function name, the function is considered a candidate registration function for the URI processor. If the parameter is a table with a registration structure containing an internal function object and containing the target URI processor function, the function is also considered a candidate registration function for the URI processor.

[0029] In one embodiment, the candidate registration functions for a URI processor include: a registry-based URI processor candidate registration function and a name-binding-based URI processor candidate registration function; the candidate taint source determination module is further configured to, for a registry-based URI processor candidate registration function, register it as an actual registration function if the registry-based URI processor candidate registration function is detected as a parameter of a CALL instruction; for a name-binding-based URI processor candidate registration function, identify such registration logic by detecting whether a Lua SETABLE-class instruction uses a constant string, and if so, register it as an actual registration function; and use all parameters of the URI processor registered by the actual registration function as candidate taint sources.

[0030] In one embodiment, the controllable Lua-C cross-language taint source determination module is further used to traverse candidate taint sources, determine candidate taint sources whose parameters have a hierarchical structure and use Lua table structure as controllable Lua-C cross-language taint sources, and determine candidate taint sources whose parameters are stored in basic types such as numbers and strings as uncontrollable taint sources.

[0031] In another aspect, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the C-Lua cross-language code static taint analysis method described above.

[0032] One of the above technical solutions has the following advantages and beneficial effects:

[0033] The aforementioned C-Lua cross-language code static taint analysis method, apparatus, and device include the following steps: identifying candidate registration functions for URI processors based on the characteristics of function parameters; filtering the candidate registration functions to determine the actual registration functions; using all parameters of the URI processors registered by the actual registration functions as candidate taint sources; filtering the candidate taint sources to determine controllable Lua-C cross-language taint sources; and identifying Lua-C and C-Lua function call relationships by analyzing the API mapping relationships between Lua and C, and using these function call relationships to achieve Lua-C cross-language taint propagation. Compared to existing methods, this method can identify specific taint sources in the Lua language within C-Lua web services and supports tracing the cross-language taint propagation process within C-Lua web services, thus enhancing the detection capability for taint-type vulnerabilities. Attached Figure Description

[0034] To more clearly illustrate the technical solutions in the embodiments of this application or the conventional technology, the drawings used in the description of the embodiments or the conventional technology will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 This is a flowchart illustrating a method for static taint analysis of C-Lua cross-language code in one embodiment. Detailed Implementation

[0036] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0037] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

[0038] It should be noted that, in this document, the reference to "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The presentation of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will understand that the embodiments described herein can be combined with other embodiments. The term "and / or" as used herein refers to any combination of one or more of the associated listed items, and all possible combinations, including such combinations.

[0039] Static taint analysis has become a key technique for detecting potential vulnerabilities in network device firmware. However, existing research generally oversimplifies the way network services are combined in firmware, specifically including only C language binary files (i.e., files extracted from the target firmware) in the scope of vulnerability detection. Modern firmware widely uses Lua scripts or a combination of Lua bytecode and C language binary files to implement hybrid network services. Obviously, taint analysis techniques that are C language binary-oriented are unlikely to achieve ideal results.

[0040] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0041] In one embodiment, such as Figure 1 As shown, a static taint analysis method for C-Lua cross-language code is provided. This method is for IoT device firmware and is a static analysis method specifically for the propagation of taints in C-Lua cross-language code. It may include the following processing steps 100 to 103:

[0042] Step 100: Identify candidate registration functions for the URI processor based on the characteristics of the function parameters.

[0043] Specifically, in network device firmware, functions registered with Lua URI handlers are used to process various network requests and are crucial backend logic for handling these requests. Therefore, identifying these URI handler registration functions is essential for taint analysis. The URI handler registration functions carry parameters describing the URI handler to be registered at the function call location, and these parameters are key to taint analysis.

[0044] Specifically, two types of function parameters were observed: the first type directly passed the function name, and the second type indirectly stored the URI processor through a registry structure. The URI processor can be obtained by analyzing both types of parameters. Specifically, by analyzing the characteristics of the function parameters, candidate registered functions are identified, and registered candidate URI processors are recorded for subsequent analysis (Algorithm 1, line 2).

[0045] Step 101: Filter the candidate registration functions of the URI processor to determine the actual registration function; use all parameters of the URI processor registered by the actual registration function as candidate pollution point sources.

[0046] Specifically, by analyzing the behavior of candidate registration functions of the URI handler, registration functions are identified in two ways (see line 3 of Algorithm 1 for details). The first is for registry-based registration functions. Registry-based registration functions should contain logic to execute the registered function. This method detects this by checking whether the registered function is used as a parameter in the CALL instruction. The second is for name-bound registration functions. These functions store their function names in Lua constant strings. When the request path matches the registered path, the system will call the corresponding URI handler. This method identifies this type of registration logic by checking whether the Lua SETABLE class instruction uses a constant string to determine if the function is a registration function. At this stage, the actual registration function RealR has been located, and all parameters of the URI handler registered by the actual registration function have been identified as candidate taint sources.

[0047] Step 102: Filter the candidate contamination sources to determine controllable Lua-C cross-language contamination sources.

[0048] Specifically, after collecting candidate data sources, it is necessary to further distinguish between controllable and uncontrollable data sources. Observation revealed that controllable taint source parameters have a hierarchical structure (such as the inputs_table in row 2 of Table 2) and typically use Lua table structures; while uncontrollable parameters are stored in basic types such as numbers and strings (such as URI_path in row 2 of Table 2). Specifically, firstly, all URI processors (HandlerList) are extracted and categorized into RegF (line 5 of Algorithm 1). Then, each parameter of each URI processor is traversed to identify controllable taint sources (line 6 of Algorithm 1). Finally, the controllable taint sources are stored (line 7 of Algorithm 1). The controllable taint sources identified in this process can then be used as taint sources in taint analysis algorithms (such as MangoDFA and LuaTaint).

[0049] Step 103: By analyzing the API mapping relationships from Lua to C and from C to Lua, identify the function call relationships from Lua to C and from C to Lua, and use the function call relationships to realize the propagation of taints across languages ​​in Lua-C.

[0050] Specifically, by analyzing the API mapping relationships between Lua and C and between C and Lua, we can identify the function call patterns between the two languages ​​to handle taint propagation across Lua and C. For Lua to C, we first need to identify the C functions registered by the C Library for the Lua interpreter. These functions are registered using the `luaRegister()` method, which registers a function table with parameters, maintaining a mapping between C function names and their addresses. For C to Lua, the C binary file first loads the Lua source code or Lua bytecode by calling `lua_loadfile()`, then obtains references to Lua functions using `lua_getglobal()`, subsequently passes parameters through functions like `luaPushNumber()`, and finally calls the Lua function using `lua_pcall()`. Therefore, by identifying these API call sequences, we can identify C to Lua function calls. This taint propagation method can then be used to handle cross-language taint propagation issues in taint analysis algorithms (such as MangoDFA and LuaTaint).

[0051] Table 1. Pseudocode for Algorithm 1

[0052]

[0053] The aforementioned static taint analysis method for C-Lua cross-language code includes: identifying candidate registration functions for URI processors based on the characteristics of function parameters; filtering the candidate registration functions to determine the actual registration functions; using all parameters of the URI processors registered by the actual registration functions as candidate taint sources; filtering the candidate taint sources to determine controllable Lua-C cross-language taint sources; identifying Lua-C and C-Lua function call relationships by analyzing the API mapping relationships between Lua and C, and using these function call relationships to achieve Lua-C cross-language taint propagation. Compared to existing methods, this method can identify specific taint sources in the Lua language within C-Lua web services and supports tracing the cross-language taint propagation process within C-Lua web services, thus enhancing the detection capability for taint-type vulnerabilities.

[0054] In a C-Lua cross-language environment, the methods for identifying Lua taint sources and for propagating Lua-C cross-language taints, combined with current mainstream taint analysis methods (such as MangoDFA and LuaTaint), result in a 6.82 to 14.5 times higher number of vulnerabilities identified.

[0055] In one embodiment, step 100 includes: analyzing the parameters of all functions; if the parameter is a string corresponding to a function name, the function is considered a candidate registered function for the URI processor; if the parameter is a table with a registration structure containing an internal function object and containing the target URI processor function, the function is also considered a candidate registered function for the URI processor.

[0056] In one embodiment, the candidate registration functions for a URI processor include: a registry-based URI processor candidate registration function and a name-binding-based URI processor candidate registration function; step 101 includes: for a registry-based URI processor candidate registration function, if the registry-based URI processor candidate registration function is detected as a parameter of a CALL instruction, then the registry-based URI processor candidate registration function is registered as an actual registration function; for a name-binding-based URI processor candidate registration function, this type of registration logic is identified by detecting whether a Lua SETABLE class instruction uses a constant string, and if so, the name-binding-based URI processor candidate registration function is registered as an actual registration function; all parameters of the URI processor registered by the actual registration function are used as candidate taint sources.

[0057] In one embodiment, step 102 includes: traversing candidate taint sources, identifying candidate taint sources whose parameters have a hierarchical structure and use Lua table structure as controllable Lua-C cross-language taint sources; and identifying candidate taint sources whose parameters are stored in basic types such as numbers and strings as uncontrollable taint sources.

[0058] In one embodiment, step 103 includes: traversing all C Library dynamic libraries, identifying the function table registered through the luaRegister() method, parsing and identifying the mapping relationship between C function names called in Lua and C function addresses, then analyzing the function call sequence lua_loadfile() -> lua_getglobal() -> luaPushNumber() -> lua_pcall() in the C language binary file, parsing and identifying the Lua functions called in the C language binary, obtaining the function call relationship from Lua to C and from C to Lua, and using the function call relationship to realize the taint propagation of Lua-C cross-language taints.

[0059] In one specific embodiment, the taint source examples shown in Tables 2 and 3 are used as examples to illustrate the method for identifying Lua taint sources in a C-Lua cross-language environment and the method for taint propagation in a C-Lua cross-language environment.

[0060] Table 2 Examples of Stain Sources (I)

[0061]

[0062] Table 3 Examples of Stain Sources (II)

[0063]

[0064] (1) Method for identifying Lua taint sources in C-Lua cross-language environment.

[0065] Step 1: Identify candidate URI processor registration functions based on the parameter characteristics of the functions.

[0066] Analyze the parameters of all functions. If a parameter is a string corresponding to the function name (e.g., wol_wake in row 12 of Table 3), then the function is considered a candidate for registration. If a parameter is a table with a registration structure containing internal function objects and containing the target URI processor function (e.g., port_speed_suppoted in row 5 of Table 3), then the function is also considered a candidate for registration.

[0067] Step 2: Filter candidate registration functions to determine the registration functions and candidate taint sources.

[0068] Analyze all candidate registration functions and identify the following two types: The first type is registry-based registration functions (such as ctl.dispatch in row 10 of Table 3). If the ctl.dispatch function contains a CALL instruction whose parameter is a registered function (such as port_speed_supported), then the ctl.dispatch function is a registration function. The second type is name-bound registration functions (such as register_keyword_action in row 13 of Table 3). To determine if the register_keyword_action function is a registration function, use the constant string "wol_wake" to check if it contains a SETABLE-type instruction.

[0069] Step 3: Filter candidate stain sources to identify controllable stain sources.

[0070] After collecting candidate data sources, it is necessary to further distinguish between controllable and uncontrollable taint sources. Traverse the candidate taint sources; for those with hierarchical parameters and using Lua table structures (such as inputs_table in row 2 of Table 2), determine them as controllable taint sources; for those with parameters stored in basic types such as numbers and strings (such as URI_path in row 2 of Table 2), determine them as uncontrollable taint sources.

[0071] (2) The method of taint propagation in C-Lua cross-language environment.

[0072] First, all C Library dynamic libraries are traversed to identify the function tables registered via the `luaRegister()` method. This allows for the parsing and identification of the mapping relationship between C function names and addresses called in Lua. Next, the function call sequence `lua_loadfile() -> lua_getglobal() -> luaPushNumber() -> lua_pcall()` in the C binary file is analyzed to identify the Lua functions called in the C binary. This process determines the function call relationships from Lua to C and from C to Lua, thus identifying the taint propagation mechanism across C and Lua languages.

[0073] In an evaluation of a dataset of 73 firmware images from 11 vendors, the number of vulnerabilities detected using this method was 6.82 to 14.5 times higher than that of current mainstream methods (such as MangoDFA and LuaTaint).

[0074] It should be understood that, although the above Figure 1 The steps are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise explicitly stated in this document, there is no strict order in which these steps are executed; they can be performed in other orders. Furthermore, the above... Figure 1 At least some of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0075] In one embodiment, a C-Lua cross-language code static taint analysis apparatus is also provided, the apparatus comprising:

[0076] The candidate registration function determination module is used to identify candidate registration functions for the URI processor based on the characteristics of the function parameters.

[0077] The candidate pollution source determination module is used to filter the candidate registration functions of the URI processor and determine the actual registration function; all parameters of the URI processor registered by the actual registration function are used as candidate pollution source.

[0078] The Controllable Lua-C Cross-Language Pollution Source Determination Module is used to filter candidate pollution sources and determine controllable Lua-C cross-language pollution sources.

[0079] The Lua-C cross-language taint propagation module is used to analyze the API mapping relationships between Lua and C and between C and Lua, identify the function call relationships between Lua and C and between C and Lua, and use the function call relationships to implement taint propagation across Lua and C.

[0080] In one embodiment, the candidate registration function determination module is further configured to analyze the parameters of all functions. If the parameter is a string corresponding to the function name, the function is considered a candidate registration function for the URI processor. If the parameter is a table with a registration structure containing an internal function object and containing the target URI processor function, the function is also considered a candidate registration function for the URI processor.

[0081] In one embodiment, the candidate registration functions for a URI processor include: a registry-based URI processor candidate registration function and a name-binding-based URI processor candidate registration function; the candidate taint source determination module is further configured to, for a registry-based URI processor candidate registration function, register it as an actual registration function if the registry-based URI processor candidate registration function is detected as a parameter of a CALL instruction; for a name-binding-based URI processor candidate registration function, identify such registration logic by detecting whether a Lua SETABLE-class instruction uses a constant string, and if so, register it as an actual registration function; and use all parameters of the URI processor registered by the actual registration function as candidate taint sources.

[0082] In one embodiment, the controllable Lua-C cross-language taint source determination module is further used to traverse candidate taint sources, determine candidate taint sources whose parameters have a hierarchical structure and use Lua table structure as controllable Lua-C cross-language taint sources, and determine candidate taint sources whose parameters are stored in basic types such as numbers and strings as uncontrollable taint sources.

[0083] In one embodiment, the Lua-C cross-language taint propagation module is also used to traverse all C Library dynamic libraries, identify the function tables registered through the luaRegister() method, parse and identify the mapping relationship between C function names called in Lua and C function addresses, then analyze the function call sequence lua_loadfile() -> lua_getglobal() -> luaPushNumber() -> lua_pcall() in the C language binary file, parse and identify the Lua functions called in the C language binary, obtain the function call relationship from Lua to C and from C to Lua, and use the function call relationship to realize the Lua-C cross-language taint propagation.

[0084] It is understood that for a detailed explanation of the C-Lua cross-language code static taint analysis device, please refer to the corresponding explanations of the various embodiments of the C-Lua cross-language code static taint analysis method above, and will not be repeated here. Each module in the above-described C-Lua cross-language code static taint analysis device can be implemented entirely or partially through software, hardware, or a combination thereof. Each module can be embedded in hardware or independently of a device with data processing capabilities, or stored in software in the memory of the aforementioned device, so that the processor can call and execute the operations corresponding to each module. The aforementioned device can be, but is not limited to, various types of data processing computer devices already existing in the art.

[0085] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiment.

[0086] It is understood that, in addition to the memory and processor mentioned above, the computer equipment described above also includes other hardware and software components not listed in this specification. The specific components can be determined according to the model of the image processing computer in different application scenarios, and will not be listed and described in detail in this specification.

[0087] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0088] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of protection of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and all such modifications and improvements fall within the scope of protection of this application.

Claims

1. A method for static taint analysis of C-Lua cross-language code, characterized in that, Including the following steps: Based on the characteristics of the function parameters, candidate registration functions for URI processors are identified; the candidate registration functions for URI processors include: URI processor candidate registration functions based on the registry and URI processor candidate registration functions based on name binding; The process involves filtering candidate registration functions for URI processors to determine the actual registration function; and using all parameters of the URI processors registered by the actual registration function as candidate taint sources. Specifically, this includes: for a registry-based URI processor candidate registration function, if it is detected as a parameter of a CALL directive, then the registry-based URI processor candidate registration function is registered as the actual registration function; for a name-binding-based URI processor candidate registration function, this type of registration logic is identified by detecting whether Lua's SETABLE class directives use constant strings; if so, the name-binding-based URI processor candidate registration function is registered as the actual registration function; and using all parameters of the URI processors registered by the actual registration function as candidate taint sources. The candidate contamination sources are filtered to determine controllable Lua-C cross-language contamination sources; By analyzing the API mapping relationships from Lua to C and C to Lua, the function call relationships from Lua to C and C to Lua are identified, and these function call relationships are used to achieve taint propagation across Lua and C. Specifically, this includes: traversing all C library dynamic libraries, identifying the function tables registered through the luaRegister() method, parsing and identifying the mapping relationship between C function names called in Lua and C function addresses, then analyzing the function call sequence lua_loadfile() -> lua_getglobal() -> luaPushNumber() -> lua_pcall() in the C language binary file, parsing and identifying the Lua functions called in the C language binary, obtaining the function call relationships from Lua to C and C to Lua, and using these function call relationships to achieve taint propagation across Lua and C.

2. The C-Lua cross-language code static taint analysis method according to claim 1, characterized in that, Based on the characteristics of the function parameters, candidate registration functions for the URI processor are identified, including: Analyze the parameters of all functions; if a parameter is a string corresponding to a function name, then that function is considered a candidate for registration as a URI processor. If the parameter is a table with a registration structure containing an internal function object, and that contains the target URI processor function, then that function is also considered a candidate registration function for the URI processor.

3. The C-Lua cross-language code static taint analysis method according to claim 1, characterized in that, Filtering the candidate contamination sources to determine controllable Lua-C cross-language contamination sources includes: Traverse the candidate taint sources, and determine the candidate taint sources whose parameters have a hierarchical structure and use Lua table structure as controllable Lua-C cross-language taint sources; determine the candidate taint sources whose parameters are stored as numbers or strings as uncontrollable taint sources.

4. A C-Lua cross-language code static taint analysis device, characterized in that, The device includes: The candidate registration function determination module is used to identify candidate registration functions for URI processors based on the characteristics of function parameters; the candidate registration functions for URI processors include: URI processor candidate registration functions based on the registry and URI processor candidate registration functions based on name binding; The candidate taint source determination module is used to filter candidate registration functions of URI processors and determine the actual registration function; all parameters of the URI processor registered by the actual registration function are used as candidate taint sources; specifically, it includes: for a registry-based URI processor candidate registration function, if the registry-based URI processor candidate registration function is detected as a parameter of the CALL instruction, then the registry-based URI processor candidate registration function is registered as the actual registration function; for a name-binding-based URI processor candidate registration function, this type of registration logic is identified by detecting whether the Lua SETABLE class instruction uses a constant string; if so, the name-binding-based URI processor candidate registration function is registered as the actual registration function; all parameters of the URI processor registered by the actual registration function are used as candidate taint sources. A controllable Lua-C cross-language pollution source determination module is used to filter the candidate pollution sources and determine controllable Lua-C cross-language pollution sources; The Lua-C cross-language taint propagation module analyzes the API mapping relationships between Lua and C, identifies function call relationships between Lua and C, and uses these relationships to propagate taints across Lua and C. Specifically, it involves: traversing all C libraries, identifying function tables registered via the `luaRegister()` method, parsing and identifying the mapping relationship between C function names and addresses called in Lua, then analyzing the function call sequence `lua_loadfile() -> lua_getglobal() -> luaPushNumber() -> lua_pcall()` in the C binary file, parsing and identifying the Lua functions called in the C binary, obtaining the function call relationships between Lua and C, and using these relationships to propagate taints across Lua and C.

5. The C-Lua cross-language code static taint analysis device according to claim 4, characterized in that, The candidate registration function determination module is also used to analyze the parameters of all functions. If the parameter is a string corresponding to the function name, the function is considered as a candidate registration function for the URI processor. If the parameter is a table with a registration structure containing an internal function object, and that contains the target URI processor function, the function is also considered as a candidate registration function for the URI processor.

6. The C-Lua cross-language code static taint analysis device according to claim 4, characterized in that, The controllable Lua-C cross-language taint source determination module is also used to traverse candidate taint sources, and to determine the candidate taint sources whose parameters have a hierarchical structure and use Lua table structure as controllable Lua-C cross-language taint sources; and to determine the candidate taint sources whose parameters are stored as numbers or strings as uncontrollable taint sources.

7. A computer device, comprising a memory and a processor, characterized in that, The memory stores a computer program, and when the processor executes the computer program, it implements the steps of the C-Lua cross-language code static taint analysis method according to any one of claims 1 to 3.

Images