# RepFTI: Representation-Fused Function-Type Inference for Vehicular Secure Software Systems
## 3 Proposed RepFTI Framework
### Dataset Generation  
In this section, we begin to solve the challenges of the high dynamic tracking loss rate from Section 2.5.2. To reduce the risk of losing the pointer that is linked to the currently executed instruction, we propose an innovative approach that uses a stack and queue data structure to record the program stack. The queue stores function attributes with the address as the key and the full-function call order. The stack simulates the program stack-execution process, which records the _ebp_ and _esp_ register values, and target addresses of a call instruction to closely track the target binary execution process. When calling the _%ret_ instruction, the tracker compares the most recently recorded _ebp_, _esp_ register value in the stack with the address to which the return is jumping. If the two values are equal or the difference between the two values falls within 15 bytes (the maximum instruction length), that value is recorded. Otherwise, the jump target address is recorded. Similarly, when calling the _%call_ instruction, the tracker compares the most recent _ebp_ and _esp_ register value with the address to which the _%call_ instruction jumps and follows the same rules as above. Through the above rule, all adopted values are recorded in the dictionary. This rule ensures that the tracked call and return addresses are accurate and removes some factors that affect the construction of the function call graph.  
To meet the requirements of RepFIT for constructing function labels, the mapping of the function name and assembly is the next problem that must be solved. Typically, the initial preference is to dynamically obtain the function name. However, the process of querying the _plt_ and _got_ table makes dynamic analysis obtain the function names complexly. Subsequently, we found that Pintools [40] refers to _Routine Object_ : \(RTN\)[41] (a kind of granularity defined by Pin) during both static analysis and dynamic analysis, and it assigns a unique symbol to \(RTN\). By our verification, \(RTN\) is an equivalent function (we compare \(RTN\) assembly codes with assembly codes of functions of the same symbolic name at static analysis). The unique symbol of the \(RTN\) can be used as an index for function names and function assembly codes. After finding a unique symbol of the function, the function call graph can integrally be constructed with steps (b) and (e), as shown in Figure 2. When calling a _call_ instruction, a directed edge is generated from the node of the calling function to the called function. When calling a _ret_ instruction, in order to find the call instruction corresponding to the return instruction, the adopted address is traversed through the dictionary. If there is no corresponding value, the return instruction is discarded. The above is the complete process of mapping function names and function assembly codes.  
Figure 2: The RepFIT is divided into two parts: (1) extracting the multi-representation features, and (2) inferring the function types. In the first part, a novel dynamic tracking strategy is proposed to obtain the semantic representation within functions and the node representation in function call graphs at one-time execution, respectively. And then the semantic learning model extracts short-span data-dependency features within a function, while the graph-embedding model extracts long-span data-dependency features among functions. In the second part, the multi-representation feature fusion model fuses the above two kinds of data dependencies.