## 3 Theoretical Background
### Graph Construction  
Graphs consist of nodes (or states) and edges (or relationships) that connect the nodes. The created nodes and edges can have specific attributes or properties associated with them [26]. In our graph representation, nodes correspond to both API calls and DLLs extracted from executable files. Each API or DLL encountered during static analysis is treated as a unique node in the graph structure. Relationships between API calls are represented as edges in the graph structure. Edges represent relationships between these nodes. For API nodes, a directed edge is drawn from one API to the next based on their sequential appearance in the call trace. Similarly, edges between DLLs or API and DLL nodes represent functional associations or co-usage patterns. In addition to temporal edges between API calls, we construct edges from API nodes to the corresponding DLLs that implement or invoke those functions. This dual relationship modeling enhances the semantic richness of the graph and enables more accurate behavior profiling. For example, if software calls the API \"CreateFile\" and then calls the API \"WriteFile\", a directed edge is created between these two nodes. Edges are designed to reflect the temporal order of API calls. Alternatively, relationships can be established between APIs called within the same transaction. However, since static analysis data are used in this study, a control flow relationship based on temporal order is preferred. This approach is practical in understanding behavioral patterns that are frequently seen in malware. We can model DLL and API Calls using graph theory to represent software behavior. The rationale behind using a graph representation lies in its ability to reflect the behavioral flow of a program. By modeling API call sequences and DLL usages as connected nodes, the framework understands meaningful execution patterns. Each API Call and DLL is considered as a node, while the relationships between these nodes are represented by edges (Equation (1)). The following explains how to define this graph structure:  
\[G=(V,E) \tag{1}\]  
Node Set (\(V\) ): each API call is defined as a node (Equation (2)). The consecutive calls or operations performed in a specific order between the API calls constitute the node set. Similarly, DLL files are defined as nodes (Equation (3)). DLLs are dynamic libraries associated with specific API calls. \[V_{\text{API}}=\{v_{1},v_{2},\dots,v_{i}\} \tag{2}\]  
\[V_{\text{DLL}}=\{d_{1},d_{2},\dots,d_{i}\} \tag{3}\]  
Here, \(v_{i}\) represents the \(i^{th}\) API call, and di represents the \(i^{th}\) DLL. Edge Set (\(E\)): whenever an API call follows another API call, a directed edge is drawn between these two nodes (Equation (4)). For example, if the API call \"CreateFile\" is followed by \"WriteFile\", an edge is created between these two nodes:  
\[E_{\text{API}}=\{(v_{i},v_{j})\mid v_{i}\to v_{j}\} \tag{4}\]  
For instance, if a software makes three consecutive API calls \"CreateFile\" \(\rightarrow\) \"WriteFile\" \(\rightarrow\) \"CloseHandle\", we represent these calls with three nodes (\(v_{1},v_{2},v_{3}\)) and two edges (\((v_{1},v_{2})\), \((v_{1},v_{3})\)). If a DLL implements multiple API calls or is used in conjunction with another DLL, directional edges can be created between these DLLs (Equation (5)). \[E_{\text{DLL}}=\{(d_{i},d_{j})\mid d_{i}\to d_{j}\} \tag{5}\]  
For example, in cases where the files \"kernel32.dll\" and \"user32.dll\" work together, an edge is drawn between these two DLLs. Figure 1 presents an example API call sequence graph constructed from a PE file. Each node corresponds to an individual API function, and directed edges indicate the chronological order in which these functions are invoked. For instance, GetFileSize is followed by PostMessage, which is then succeeded by FreeLibrary and subsequently by GetCurrentProcess. This sequence continues through various file and process-related API calls, capturing the behavioral flow of the executable.