## 5 Design and Implementation
### Progressive Taint Analysis  
Once user-controllable variables have been identified, FLuaScan employs taint analysis to expose vulnerabilities. However, the current limitation of semgrep [44] is that it exclusively supports intraprocedure analysis, potentially leading to false positives in vulnerability detection. To overcome this issue, we designed a progressive taint analysis engine. This engine divides multiple Lua files into segments and conducts taint analysis on each segment. It also records taint propagation across various functions and files to establish their relationships. _FLuaScan_ initially employs the ctags [48] syntax analysis tool to parse each Lua file and assigns a distinct identifier to each object. Subsequently, this identifier is utilized for correlation analysis. Next, as shown in Figure 2, FLuaScan performs three rounds of taint analysis on all files: (a) handler analysis, (b) taint propagation, and (c) sink analysis. During the (a) handler analysis process, _FLuaScan_ aims to identify the data flow from user input to middle nodes. Middle nodes are defined as analysis nodes that have the potential to facilitate taint propagation between different functions. These nodes can be categorized into two types: (1)Invocation of subfunctions; during this process, taint can  
Figure 2: The overview of progressive taint analysis engine. potentially propagate with the transfer of parameters. (2) Database write operations; during this process, taint can potentially propagate after being written to a database, then retrieved again. The _type_ field of the middle mode is set as M (like M2 in Figure 2). The semgrep configuration used to accomplish this task is illustrated as Listing 4. We employed the taint mode of semgrep and designated the three user-controllable parts in the HTTP protocol as the sources of tainted data. As for the sink points, in Listing 4, lines 11-17 aim to find the invocation of subfunctions, while line 18 aims to find the database write operations. In Listing 4, lines 21-22 show the designs of sanitizers, including two categories: (1) vendor-customized security filtering functions, which perform security checks and filtering on variable content, and (2) string conversion functions, such as _tounmber_, making the user input unable to trigger vulnerabilities after the conversion. During the (b) taint propagation process, _FLuaScan_ aims to identify data flows within the invocation of subfunctions. The semgrep configuration utilized to achieve this task is depicted in Listing 5. The taint mode of semgrep is consistently used, while the configuration of sinks and sanitizers remains unchanged. However, the taint sources are been changed, consisting of two types: (1) parameters passed when a subfunction is called (lines 5-10 in Listing 5) and (2) data retrieved from the database (line 12 in Listing 5). The taint sources from subfunctions are defined as propagation nodes (like P1 in Figure 2), with their _type_ field set to P.  
```
1 rules:
2-id:fluascan-taint-propagation
3 mode:tain
4 pattern-sources:
5-patterns:
6-pattern-inside:function$FNAME($VAR,...)...end
7-focus-metavariable:$VAR
8-patterns:
9-pattern-inside:function$FNAME($VAR)...end
10-focus-metavariable:$VAR
11-patterns:
12-uci:get(...)
```  
**Listing 5**. Code snippet to execute handler analysis utilizing semgrep. There is ample evidence to suggest that the incorrect utilization of vulnerable functions serves as the root cause of numerous vulnerabilities. Hence, precise modeling of vulnerable functions is imperative to detect vulnerabilities effectively. Current methods disregard the specificities of IoT scenarios, only perceiving a limited number of sensitive system APIs as vulnerable. During the development process, it has been observed that numerous manufacturers tend to encapsulate low-level system APIs into higher-level custom APIs. Overlooking these interfaces can lead to erroneous identification of vulnerabilities.