FirmVulLinker: Leveraging Multi-Dimensional Firmware Profiling for Identifying Homologous Vulnerabilities in Internet of Things Devices

Abstract

Identifying homologous vulnerabilities across diverse IoT firmware images is critical for large-scale vulnerability auditing and risk assessment. However, existing approaches often rely on coarse-grained components or single-dimensional metrics, lacking the semantic granularity needed to capture cross-firmware vulnerability relationships. To address this gap, we propose FirmVulLinker, a semantic profiling framework that holistically models firmware images across five dimensions: unpacking signature sequences, filesystem semantics, interface exposure, boundary binary symbols, and sensitive parameter call chains. These multi-dimensional profiles enable interpretable similarity analysis without requiring prior vulnerability labels. We construct an evaluation dataset comprising 54 Known Defective Firmware (KDF) images with 74 verified vulnerabilities and assess FirmVulLinker across multiple correlation tasks. Compared to state-of-the-art techniques, FirmVulLinker achieves higher precision with substantially lower false-positive and false-negative rates. Notably, it identifies and reproduces 53 previously undisclosed N-day vulnerabilities in firmware images not listed as affected at the time of public disclosure, effectively extending the known impact scope. Our results demonstrate that FirmVulLinker enables scalable, high-fidelity homologous vulnerability analysis, offering a new perspective on understanding cross-firmware vulnerability patterns in the IoT ecosystem.

1. Introduction

With the rapid proliferation of embedded systems and Internet of Things (IoT) devices in scenarios such as smart homes, industrial control systems, and traffic management, firmware has become the essential software foundation supporting these critical applications. Today, firmware is widely deployed in home routers, smart cameras, industrial controllers, and other key devices [1]. Against this backdrop, security vulnerabilities in firmware have emerged as a core risk that threatens system stability and user privacy [2,3]. Notably, common development practices such as code cloning, component reuse, and the integration of shared SDKs have led to the widespread presence of homologous vulnerabilities across multiple firmware versions [4]. Once attackers identify and exploit these vulnerabilities, they can launch large-scale attacks that result in system downtime, data breaches, and the formation of extensive botnets. Well-known examples include the Mirai and Bashlite botnet families, which compromised hundreds of thousands of IoT devices by exploiting only a few dozen homologous vulnerabilities, highlighting the real-world threat of cross-device vulnerability propagation [5,6].

To address this growing risk, prior research has explored homologous vulnerability analysis to identify how vulnerabilities propagate and are reused across different firmware samples [7,8,9,10]. These approaches typically rely on component-level feature matching, string signature comparison, or function-level semantic alignment, which can partially capture the behaviors of firmware clones. However, when analyzing firmware across platforms, architectures, or even different vendors, these methods face significant limitations. On the one hand, they often treat firmware merely as a collection of isolated components, lacking systematic modeling of the firmware’s overall structural semantics and attack surface information. This makes it challenging to represent the complete static behavioral logic and multi-dimensional characteristics of the firmware [11,12]. On the other hand, most existing techniques do not incorporate reachability analysis and therefore fail to evaluate whether a vulnerability is practically exploitable through real communication interfaces such as web APIs, parameter paths, or user inputs. As a result, they struggle to assess the actual threat boundaries of discovered vulnerabilities accurately [8,10]. More specifically, mainstream methods face three key challenges:

• Limited to component-level analysis without holistic semantic modeling. Current approaches typically focus on specific components, such as ELF binaries, functions, or third-party libraries [9,13]. Without modeling the firmware’s overall structure, path layout, symbolic context, and configuration logic, these methods rely on shallow component-level matching [14]. Given the diversity in component layouts across vendors and platforms, such strategies often fail to uncover truly homologous vulnerabilities.
• Heavy reliance on third-party components while overlooking vendor-specific logic. Many studies emphasize the reuse of open-source libraries and third-party modules as the primary source of vulnerability propagation [8]. However, in practice, IoT vendors frequently introduce substantial amounts of custom code tailored to their specific needs. This vendor-specific logic often becomes a concentrated source of previously unknown vulnerabilities [15]. Thus, analysis methods focused solely on standard components risk missing a significant number of impactful, real-world vulnerabilities.
• Lack of communication interface modeling is limiting the assessment of exploitability. In IoT scenarios, attacks are frequently launched via exposed communication interfaces [16,17,18]. If a vulnerability cannot be triggered through external network traffic, its practical security risk is substantially reduced. Existing methods generally do not model the network management interfaces, input parameter paths, or function call chains that connect to external inputs, making it challenging to identify vulnerabilities that are truly reachable or exploitable [13].

In summary, current homologous vulnerability analysis methods need to move beyond shallow, component-level matching toward in-depth modeling of firmware-wide structural semantics. At the same time, incorporating perspectives on communication interfaces and reachability is critical to enable more explainable, comprehensive, and practically meaningful vulnerability discovery.

Our Approach. To address these challenges, we propose FirmVulLinker, a framework designed explicitly for homologous vulnerability analysis of embedded firmware. The central idea behind FirmVulLinker is to treat the firmware as a unified modeling target and systematically capture its internal static structure, behavioral logic, and potential attack surfaces by constructing a multi-dimensional semantic profiling system. Based on semantic similarity measurements across these dimensions, FirmVulLinker identifies firmware samples that are likely to contain homologous vulnerabilities, even across large-scale datasets. The overall framework consists of two main stages:

• Stage One: Multi-dimensional semantic profiling. FirmVulLinker builds five complementary semantic profiles to represent the static behavioral characteristics of firmware, focusing on unpacking structure, filesystem layout, exposed communication interfaces, boundary binary symbols, and high-risk parameter call chains. Specifically: (i) Unpacking Signature Sequence Profile captures the hierarchical structure and nested relationships revealed during firmware unpacking; (ii) Filesystem Semantic Profile models path semantics and the distribution of sensitive resources; (iii) Interface Exposure Profile identifies reachable input paths and user-controlled parameters that define the external attack surface; (iv) Exposed Binary Symbolic Profile analyzes symbol tables, imported/exported functions, and other interface-related features of boundary binaries; (v) Vulnerability-oriented Call Chain Profile statically traces high-risk parameters to construct potential vulnerability trigger chains. Together, these unified semantic profiles capture diverse dimensions of firmware behavior, providing a rich semantic basis for downstream homologous similarity analysis.
• Stage Two: Semantic similarity computation and homologous vulnerability discovery. FirmVulLinker implements tailored similarity metrics for each of the five semantic profiles, allowing it to capture structural and sequence-level differences across multiple dimensions of firmware behavior. These dimension-specific similarity scores are then aggregated through a weighted fusion strategy to compute a global semantic similarity score for each firmware pair. Based on this comprehensive similarity analysis, FirmVulLinker can systematically identify homologous firmware samples and detect the same vulnerabilities within firmware that is highly similar to known vulnerable firmware.

To evaluate the effectiveness of FirmVulLinker, we developed a complete prototype system and constructed a homologous vulnerability dataset containing 74 real-world vulnerabilities across 54 embedded firmware samples. This dataset encompasses multiple mainstream architectures and vendor platforms, with each sample accompanied by standardized emulation environments, deployment scripts, and automated vulnerability verification tools. Using this dataset, we conducted comprehensive, large-scale experiments. The results show that FirmVulLinker outperforms existing state-of-the-art firmware analysis tools in terms of detection accuracy, false-negative rate, and false-positive rate, demonstrating significant improvements in both precision and robustness. Beyond identifying known homologous vulnerability samples, FirmVulLinker also discovered 53 previously undisclosed N-day vulnerabilities, effectively extending the known impact scope of existing vulnerabilities and confirming its strong potential for real-world vulnerability intelligence and supply chain security analysis.

Contributions. Overall, our main contributions are summarized as follows:

• New Framework: We present FirmVulLinker, a framework for homologous vulnerability propagation analysis built on multi-dimensional static semantic profiling. Distinct from prior approaches that focus narrowly on individual components, FirmVulLinker treats firmware as a unified analysis target, constructing comprehensive semantic profiles that capture both structural semantics and attack surface characteristics. This holistic modeling paradigm significantly improves detection accuracy, interpretability, and adaptability across heterogeneous platforms.
• New Dataset: We have constructed a high-quality evaluation dataset for homologous vulnerabilities, covering 74 verified vulnerabilities across 54 firmware samples. Each firmware sample is provided with a standardized emulation environment, startup scripts, and automated validation tools. This design ensures the reproducibility and comparability of vulnerability samples, offering a stable and reliable testing resource for subsequent research.
• Implementation and Evaluation: We implemented a complete prototype of FirmVulLinker and conducted systematic evaluations across multiple real-world vulnerability scenarios and actual firmware samples. Experimental results demonstrate the effectiveness, accuracy, and scalability of our approach in identifying homologous vulnerability propagation, revealing multiple vulnerable firmware samples that were previously missed by existing tools. This further underscores the practical value of our method.

Roadmap: The remainder of this paper is organized as follows. Section 2 reviews the background and related work on IoT firmware vulnerability analysis and homologous firmware correlation. Section 3 details the design rationale of FirmVulLinker and explains the construction of its multi-dimensional static semantic profiles across five core modeling dimensions. Section 4 describes the similarity measurement strategies for each profile and the multi-dimensional fusion method used to support cross-firmware vulnerability identification and propagation analysis. Section 5 presents the implementation details of the prototype system and its experimental evaluation, including comprehensive comparisons with state-of-the-art methods. Section 6 discusses the limitations identified during design and implementation and outlines potential directions for future work. Finally, Section 7 concludes the paper.

To facilitate future research, we will release the open-source implementation of FirmVulLinker at https://github.com/a101e-lab/FirmVulLinker (accessed on 29 July 2025).

2. Background and Related Work

Before detailing our technical approach, we provide an overview of existing methodologies for discovering IoT firmware vulnerabilities, with a particular focus on the background of homologous vulnerability analysis across firmware.

2.1. Vulnerability Discovery in IoT Firmware

Current techniques for identifying security vulnerabilities in IoT firmware generally fall into two broad categories: dynamic analysis and static analysis [15,19,20]. Each offers distinct advantages in terms of applicability, coverage, and engineering cost, while also facing unique challenges and limitations.

Dynamic Analysis-Based Approaches. Among various dynamic analysis techniques, fuzzing has emerged as a dominant method due to its high degree of automation, lack of reliance on prior knowledge, and strong path exploration capabilities [16,21]. Fuzzing involves repeatedly injecting malformed or partially valid inputs into a target program and monitoring its execution for abnormal behavior such as crashes or hangs, thereby revealing hidden flaws or vulnerabilities [22]. Depending on visibility into the program’s internal state and the guidance available during execution, fuzzing can be categorized as white-box, grey-box, or black-box [23].

However, applying fuzzing to IoT firmware poses substantial challenges. First, due to the strong dependence of firmware execution on hardware-specific environments, dynamic testing often requires emulation platforms such as QEMU [24], Firmadyne [25], or FirmAE [26] to simulate user-space or system-level execution [27]. In practice, firmware frequently contains low-level hardware interactions, proprietary drivers, or dependencies on NVRAM, which makes accurate emulation difficult and often results in crashes or incomplete behavior during testing, thereby undermining stability and effectiveness [26]. Moreover, as IoT firmware is typically distributed in a closed-source format, white-box fuzzing becomes infeasible [19]. While grey-box fuzzers can collect runtime feedback via instrumentation, they often require the firmware to run in user space or within a semi-virtualized setup [28,29]. These conditions are rarely met in real-world firmware, which limits their applicability. Consequently, black-box fuzzing is the most widely adopted in IoT scenarios due to its independence from source code and execution context [30,31].

Nevertheless, black-box fuzzing suffers from a critical drawback: lacking knowledge of target interfaces, communication protocols, or authentication mechanisms, generated test inputs often fail to pass the firmware’s initial validation checks, preventing them from reaching deeper logic branches [16]. This is further complicated by the presence of web interfaces, command-line tools, and other components in firmware that introduce additional layers of encoding, encryption, and multi-step verification, which significantly raise the barrier for constructing valid inputs [32]. In summary, while dynamic fuzzing offers powerful capabilities for vulnerability discovery, its high deployment cost, environmental dependence, and difficulty in adaptation continue to hinder its large-scale adoption in IoT firmware analysis.

Static Analysis-Based Approaches. In contrast to dynamic techniques, static analysis examines unpacked firmware images without executing the code, offering greater generalizability and scalability [20]. These methods typically extract executable binaries, configuration scripts, and resource files, then apply techniques such as syntax parsing, control flow modeling, data flow analysis, and taint tracking to identify potential vulnerabilities or construct behavioral models. Static analysis is especially advantageous in analyzing closed-source firmware, as it enables deep inspection of logic structures and non-exposed interfaces that are often unreachable via dynamic methods.

Despite its broader applicability, static analysis faces notable challenges in practice, particularly in terms of false-positive rates and computational complexity [14]. The lack of runtime context and real inputs makes it inherently difficult to determine whether identified issues are exploitable, often leading to an overwhelming number of false alarms that reduce the practical utility of the results [14]. In addition, core analysis procedures such as constructing control flow graphs (CFGs), generating data flow graphs (DFGs), and conducting path-sensitive analysis require substantial computing resources, which significantly hampers the efficiency of large-scale analysis on real-world firmware images [7].

Moreover, many static techniques depend heavily on accurate symbol resolution and function boundary recovery. In practice, however, firmware binaries are often stripped of symbols, optimized aggressively, or obfuscated. These conditions lead to ambiguous control flow and missing call relationships, which severely limit the precision and robustness of analysis [33]. Additionally, most existing approaches treat firmware as a collection of isolated components, such as individual binaries, third-party libraries, or exposed interfaces, without modeling the firmware system as an integrated whole [19]. This narrow perspective makes it difficult to reason about the interaction between components or to trace how vulnerabilities propagate through different firmware images.

Given the challenges of incomplete symbols, heterogeneous binary resources, and the large scale of real-world firmware, a key problem remains unresolved: how to accurately identify vulnerabilities in the absence of an execution context while minimizing false positives and keeping semantic modeling manageable. To address this, there is a growing need for a scalable and robust semantic profiling framework that treats firmware as a unified target for analysis and evaluation. By capturing global structure and behavior across multiple semantic dimensions, such a framework can provide a more complete context for vulnerability discovery. When combined with efficient similarity computation, it can also support large-scale analysis of homologous vulnerability propagation.

2.2. Static Analysis-Based Homologous Vulnerability Identification in Firmware

Due to their minimal dependence on execution environments and broad applicability across platforms, static analysis techniques have become a prominent approach for detecting firmware vulnerabilities and identifying homologous vulnerabilities across firmware samples [15]. These methods typically operate on unpacked firmware images, extracting multi-dimensional static features through structural modeling, semantic abstraction, or feature alignment. The extracted features are then used to perform cross-platform and cross-architecture similarity analysis, uncovering potential reuse paths and propagation patterns of known vulnerabilities [14,15,19]. Based on the nature of their modeling strategies, existing approaches can be broadly categorized into three groups: code structure modeling, resource feature modeling, and global semantic modeling.

Code Structure Modeling. Control flow graphs (CFGs) and function call graphs are widely adopted for their strong structural representation capabilities in function-level similarity analysis [34]. Representative works such as Genius [7] and FirmSec [8] utilize graph embedding over CFGs to learn structural representations and match functions across firmware samples. Subsequent efforts introduce local call graphs (LCGs) to enhance contextual modeling. Wang et al. further propose feature optimization via genetic algorithms to improve alignment accuracy [35]. While these techniques have demonstrated strong performance at the function granularity, they face two fundamental limitations in practical firmware analysis: (1) many firmware images contain custom or proprietary components that lack consistent structural semantics, making graph-based modeling fragile; and (2) by focusing on functions as the core unit of comparison, these methods fail to capture holistic firmware behaviors and attack surfaces. In particular, they struggle to account for high-level semantic features such as communication interfaces, configuration paths, and trigger conditions, which are essential for cross-vendor or cross-platform analysis.

Resource Feature Modeling. Beyond structural modeling, human-readable strings and scripts are often used for lightweight firmware clustering due to their interpretability and portability [36]. For instance, IHB employs string extraction, MinHash, and LSH indexing to quickly cluster similar firmware by identifying key symbols and paths in readable content [37]. UFO focuses on shell scripts and builds script dependency graphs to identify command sequences that may expose vulnerability trigger paths [38]. However, the effectiveness of these methods largely relies on the quality of extracted resources and their ability to be accurately parsed and analyzed. Obfuscation, encryption, and aggressive compilation often degrade the quality of strings, while script-based approaches lack structured semantics and are challenging to integrate into unified analytical pipelines. Moreover, these approaches typically ignore the interaction between resources and binary logic, limiting their ability to model the propagation path from external inputs to internal kernel logic.

Global Semantic Modeling. To move beyond shallow features, several studies have proposed end-to-end semantic modeling frameworks that link frontend interfaces with backend processing logic. Firmalice, for example, constructs data dependency graphs (DDGs) to model how key variables propagate through configuration logic, identifying instruction sequences that may lead to behavioral deviations [10]. SaTC combines web frontend forms, CGI parameters, and backend logic to build full-stack input path graphs, enabling the identification of semantically reachable attack points [39]. These approaches demonstrate early efforts to bridge communication interfaces and internal logic and provide a semantic basis for vulnerability reachability analysis. However, they are typically tailored to specific scenarios or data sources and lack general-purpose modeling capabilities. In the absence of a unified feature space or abstract representation, these methods are not yet scalable or automated enough for large-scale propagation analysis.

In addition to function-level and component-level approaches, there have also been attempts to extend such methods to the firmware level. This typically involves incorporating automated unpacking pipelines, extracting binary modules from the unpacked images, and then aggregating module-level similarity results to derive a firmware-level correlation score. Such extensions provide a practical way to reuse existing analysis techniques at a broader granularity, but they remain conceptually distinct from other research directions.

On one hand, function-level or component-level approaches often achieve finer-grained feature selection within their chosen dimensions, making them effective for capturing localized structural or syntactic similarities. However, they provide a weaker description of firmware as a whole, as they lack modeling of higher-level semantics and global organization. On the other hand, multi-dimensional firmware-level profiling approaches emphasize a holistic description of the entire firmware by integrating features such as structural unfolding, resource layout, communication interfaces, symbolic information, and call-chain semantics. These approaches are stronger in capturing global characteristics across heterogeneous firmware ecosystems. However, due to the large number of profiling dimensions, the feature refinement within each dimension is typically less fine-grained compared to function-level methods. This contrast highlights both the differences in granularity and the potential complementarity between the two perspectives.

In summary, current static approaches to homologous vulnerability detection have explored multiple feature dimensions, including control flow structures, script resources, and frontend–backend semantic paths. However, despite recent firmware-level extensions, most existing techniques remain largely component-centric. They lack a unified modeling paradigm that comprehensively captures the global firmware structure, communication entry points, and symbolic semantics. When applied to customized logic, heterogeneous platforms, or complex communication interfaces, these limitations often result in inaccurate matching and incomplete discovery of propagation paths due to the absence of contextual reachability reasoning and structural constraint inference. Furthermore, most existing techniques fall short in modeling detailed vulnerability trigger chains, making it difficult to assess the exploitability or real-world impact of discovered homologous vulnerabilities. To address these challenges, future research must shift toward holistic firmware-level modeling. This requires the construction of multi-dimensional static semantic profiles that treat the firmware as a unified analysis target. By integrating communication context and reachability modeling, such approaches can support more interpretable, accurate, and generalizable homologous vulnerability identification across diverse firmware ecosystems.

3. Multi-Dimensional Firmware Semantic Profiling

To enable the large-scale analysis of homologous vulnerability propagation across heterogeneous embedded firmware images, we propose FirmVulLinker. This unified static profiling framework models firmware semantics in a structured, platform-independent manner. The framework performs multi-dimensional profiling to capture key features of firmware, facilitating cross-sample semantic alignment and homologous vulnerability discovery. The overall system architecture of FirmVulLinker is illustrated in Figure 1.

FirmVulLinker operates in two main stages: multi-dimensional semantic profiling and similarity computation. In the first stage, each input firmware image is profiled across five semantic dimensions, capturing structural organization, resource layout, input interfaces, symbolic structure, and vulnerability propagation paths. These features are then integrated into a unified firmware semantic profile. In the second stage, intra-dimensional similarity evaluation and cross-dimensional fusion strategies are employed to generate a global semantic similarity score for detecting homologous vulnerability.

We formally define the semantic profile of a firmware image $F$ as a five-tuple, as shown in Equation (1):

$$\mathcal{P}\left(F\right)=\left(P_1,P_2,P_3,P_4,P_5\right)$$

(1)

Each $P_i$ represents an independent feature subspace:

• P₁: Unpacking Signature Sequence Profile. Captures the sequence of structural signatures identified during the firmware unpacking process and models their nesting order as a trajectory, reflecting the firmware’s packaging layers and organizational patterns.
• P₂: Filesystem Semantic Profile. Analyzes the extracted filesystem layout to model path topology, sensitive resource distribution, and binary component fingerprints. This profile characterizes the deployment logic, exposure surface, and potential code reuse.
• P₃: Interface Exposure Profile. Identifies external communication paths and associated parameter keys. This profile models the input attack surface and interface naming behaviors to reflect exposed functionality and entry points.
• P₄: Exposed Binary Symbolic Profile. Extracts symbolic information from boundary binaries along communication paths, including imported and exported symbols, function signatures, and symbol table structures. This profile captures visible semantic labels and inter-module dependencies.
• P₅: Vulnerability-oriented Call-Chain Profile. Traces the propagation of high-risk parameters and reconstructs multi-path call chains from entry points to sensitive functions. This profile models vulnerability trigger paths and the corresponding propagation context.

These five profiling dimensions collectively capture the firmware’s structural layout, input behavior, symbolic semantics, and vulnerability-related context. The profiles offer fine-grained representations, complementary semantic perspectives, and cross-platform compatibility. Among them, $P_1$ and $P_2$ emphasize structural and behavioral organization, while $P_3$ and $P_4$ characterize communication interfaces and symbolic visibility. $P_5$ provides deeper insight into control dependencies and parameter flows associated with potential vulnerability triggers. The modular and extensible nature of this profiling system enables FirmVulLinker to accommodate diverse architectures, formats, and compilation styles. This unified abstraction layer establishes a robust semantic foundation for subsequent cross-firmware analysis and homologous vulnerability identification.

In the remainder of this section, we present the modeling and extraction methodology for each semantic dimension in Section 3.1, Section 3.2, Section 3.3, Section 3.4 and Section 3.5. The similarity computation strategies and fusion mechanisms are discussed in detail in Section 4.

3.1. Unpacking Signature Sequence Profile

Embedded firmware images are typically packaged in aggregate or compressed formats, encapsulating multiple structured content segments, such as filesystem images, kernel binaries, initialization scripts, configuration blocks, or key storage regions. Unlike conventional operating system images, the nesting relationships and encapsulation order in embedded firmware vary significantly across implementations, posing substantial challenges for structural analysis and content reuse detection.

To address this, we propose the Unpacking Signature Sequence Profile, a semantic behavior trace that captures the structural unfolding process of a firmware image. This profile models the nesting patterns and component organization by extracting a sequence of structural signatures encountered during the unpacking process. Specifically, we treat the firmware image as a linear byte stream and apply a semantic signature matching mechanism to identify boundaries of nested components. These structural signatures are symbolically encoded based on their appearance order, forming a discrete trace that reflects the logical decomposition path of the firmware. This sequence offers a stable and comparable representation of structural behavior across samples, without relying on complete filesystem mounting or parsing.

To facilitate computational analysis and practical application, we introduce a formal modeling approach that transforms the unpacking sequence into a vectorizable representation within a structural feature space. This modeling process is divided into three stages:

Signature Trace Extraction. Given a firmware image $F$, we apply structural matching techniques to identify embedded components and assign each with a unique semantic signature identifier. To achieve this, we construct a global dictionary of magic byte patterns commonly used to indicate nested structures, such as filesystems, kernel segments, or certificate data. Each magic byte feature in this dictionary is predefined and uniquely assigned with an identifier prior to the unpacking process. During structural matching, whenever a magic byte pattern is detected within the firmware, the corresponding identifier is retrieved from this dictionary. These identifiers are then sequentially arranged according to their appearance in the byte stream, forming a structural signature sequence as defined in Equation (2):

$$S\left(F\right)=\left[s_1,s_2,\dots ,s_n\right],\hspace{1em}{s}_i\in \mathsf{\Sigma }$$

(2)

Here, $\mathsf{\Sigma }$ denotes a finite set of structural signature symbols, where each symbol $s_i$ represents the identifier of a specific structural component recognized during the unpacking process, such as a filesystem, kernel segment, certificate data, or path marker. The resulting sequence thus encodes the logical unpacking behavior of the firmware, capturing the order in which components appear and the organizational layout of their internal structures. As this representation does not rely on filesystem mounting or complete extraction, it provides strong adaptability and generality across diverse architectures and packaging formats.

Structural Behavior Abstraction. To enhance the expressiveness of the trace sequence and improve semantic alignment across firmware samples, we abstract $S\left(F\right)$ into a structural behavior path that represents the sequence of structural states traversed by nested components during the unpacking process. Each signature symbol $s_i\in \mathsf{\Sigma }$ denotes an explicit unpacking operation, and the overall combination pattern reveals the encapsulation strategies, module partitioning, or distribution templates adopted during firmware construction. This abstraction disregards the actual physical offsets or sizes of components within the byte stream. Instead, it focuses on the execution order, nesting hierarchy, and the stability and commonality of semantic patterns. These factors form a robust structural foundation for subsequent tasks.

Sequence Pattern Modeling and Vectorization. To transform the structural behavior sequence into a computable feature vector, we apply an n-gram modeling strategy to the sequence $S\left(F\right)$ defined in Equation (2). Specifically, we extract all contiguous subsequences of length k to construct the following pattern set:

$$G_k\left(F\right)=\left\{\left(s_i,s_{i+1},\dots ,s_{i+k-1}\right)\mid 1\le i\le n-k+1\right\}$$

(3)

Here, $G_k\left(F\right)$ represents the set of all local structural fragments of length $k$ extracted from the signature trace. We then compute the frequency distribution over this set to obtain a vectorized representation of the n-gram patterns:

$${\varphi }_k\left(F\right)=\left[f_1,f_2,\dots ,f_m\right]\in {ℝ}^m$$

(4)

In this vector, each element $f_j$ denotes the occurrence count of the $j$-th pattern in $S\left(F\right)$, and $m$ is the total number of distinct patterns in the feature space. The resulting vector ${\varphi }_k\left(F\right)$ serves as the structural representation of firmware $F$ under this profiling dimension and will be used for subsequent similarity measurement and cross-sample clustering.

This modeling strategy offers three key advantages. First, it does not depend on filesystem mounting or semantic recovery, making it robust to damaged or packed samples. Second, it enables the discovery of standard structural encapsulation and reuse patterns across firmware images. Third, it yields a sparse and efficient representation, suitable for large-scale indexing, retrieval, and analysis. This structural profile will be integrated into the firmware similarity analysis module introduced in Section 4.

3.2. Filesystem Semantic Profile

Once unpacked, embedded firmware typically contains a complete or nearly complete filesystem structure. This structure not only governs the organization and invocation of system components but also exposes a wide range of static information through path naming, file content, and resource layout—information that attackers may leverage. To capture the structural and semantic behaviors present in the filesystem, we propose the Filesystem Semantic Profile, which models static characteristics across multiple dimensions, such as path topology, sensitive resource distribution, configuration exposure, and binary file layout. This profile consists of three modeling phases: structural layout modeling, sensitive resource annotation and modeling, and binary resource signature profiling. The outputs are ultimately fused into a unified structural feature vector that supports similarity analysis and clustering across firmware samples based on deployment patterns, information leakage risks, and resource reuse behaviors.

Structural Layout Modeling. To characterize structural differences in component organization and directory deployment, we treat the root of the unpacked firmware filesystem as $R$, and formalize its structure as a directed tree $T\left(R\right)=\left(D,E\right)$, where $D$ is the set of reachable directories and $E\subseteq D\times D$ encodes parent-child relationships between directories. For each directory $d\in D$, we define four structural metrics:

• The depth δ(d), indicating the length of the path from the root to d.
• The executable density ρ(d), defined as the proportion of executable files among all files in d.
• The aggregation degree γ(d), measuring the number of files and subdirectories contained in d.
• The global directory entropy H(D), quantifying the uniformity and organizational complexity of the overall filesystem layout.

We compute statistical summaries (e.g., mean $\mu$ and standard deviation $\sigma$) over these metrics to form the structural feature vector:

$${\varphi }_s\left(R\right)=\left[{\mu }_{\delta },{\sigma }_{\delta },{\mu }_{\rho },{\mu }_{\gamma },H\left(D\right)\right]\in {ℝ}^5$$

(5)

Here, ${\mu }_{\delta }$ and ${\sigma }_{\delta }$ represent the mean and standard deviation of directory depths, ${\mu }_{\rho }$ and ${\mu }_{\gamma }$ denote the average executable density and aggregation degree, and $H\left(D\right)$ is the normalized Shannon entropy over the distribution of file counts across directories. This vector encodes the organizational behavior of the firmware’s filesystem and provides a basis for analyzing its component deployment practices and directory construction patterns.

Sensitive Resource Annotation and Modeling. This stage focuses on static assets within the firmware filesystem that may lead to information leakage, authentication bypass, or system exposure. We design a semantic path labeling framework tailored for firmware content, covering three high-risk resource categories: credential artifacts, static information indicators, and sensitive configuration files. These resources are uniformly modeled through a rule-based tagging mechanism that standardizes the representation of static attack surfaces across diverse firmware samples.

We denote the set of all reachable paths in the unpacked filesystem as $\mathcal{P}= \{p_1,p_2,\dots ,p_N\}$, where each path $p_i$ corresponds to a file or directory node. To identify the potential semantics of each path, we define a set of regular expression rules $\mathcal{M}$, each associated with a semantic label $l\in \mathcal{L}$. A matching function $\mathrm{Match}\left(p_i,\mathcal{M}\right)\Rightarrow l_i$ maps each path $p_i$ to a label $l_i\in \mathcal{L}$. The label space is organized into the following three categories:

• Credential and Cryptographic Artifact Disclosure. This category targets paths related to authentication and cryptographic secrets. It includes: (1) files such as .key, .pem, .crt, .cer indicating private keys and certificates; (2) known password storage files such as .htpasswd, shadow, and passwd; and (3) configuration paths for SSH and TLS services like .ssh/, sshd_config, ssl.conf, and authorized_keys. The exposure of these resources directly undermines remote access control, encrypted communication, and device authentication.
• Static Information Leakage Indicators. These labels capture hardcoded static information that can assist adversaries in target fingerprinting, attack tailoring, or device tracking. We define matching patterns for IP addresses, hardcoded URLs, email addresses, MAC addresses, and device identifiers. Although such paths may not directly trigger vulnerabilities, they frequently serve as side channels for intelligence gathering during real-world attacks.
• Security-sensitive Configuration Artifact Detection. This category identifies configuration paths tied to system components, service modules, or runtime logic. We include rules for standard web services, databases, automation scripts, and startup configuration files, matching paths such as .conf, .ini, .sql, .db, and .sh. The exposure of these files can disclose execution logic, hardcoded credentials, or automation entry points, thus expanding the attack surface.

We count the number of occurrences of each label $l_j\in \mathcal{L}$ within the path set $\mathcal{P}$ to form a sensitive resource semantic feature vector:

$${\varphi }_l\left(R\right)=\left[c_1,c_2,\dots ,c_n\right]\in {\mathbb{N}}^n$$

(6)

Here, $c_j$ denotes the frequency of label $l_j$ in the firmware filesystem, and $n=\left|\mathcal{L}\right|$ is the dimensionality of the label space. This vector characterizes the semantic footprint of credential, configuration, and information exposure within the sample, providing a quantitative basis for downstream similarity analysis tasks.

Binary Resource Signature Profiling. This profiling dimension focuses on the deployment locations, content structures, and potential reuse characteristics of executable binaries extracted from the unpacked firmware filesystem. We propose binary resource signature profiling to statically model the path semantics, string features, and fuzzy hash fingerprints of typical executables. This supports cross-firmware analysis of binary similarity and component-level clustering. We define the set of all executable files with either execution permissions or semantically significant paths as $\mathcal{B}=\left\{b_1,b_2,\dots ,b_M\right\}$, where each $b_i$ represents a distinct binary. For each binary, we define three signature functions to capture its key attributes:

$$\mathrm{SigProfile}\left(b_i\right)=\left(p_i,s_i,h_i\right)$$

(7)

Here, $p_i$ is a binary path pattern match flag, $s_i$ is the set of printable ASCII strings extracted from the binary, and $h_i$ is the fuzzy hash fingerprint. Specifically:

• Path Semantic Feature. We use a predefined path pattern set $\mathcal{R}$_bin to determine whether b_i is deployed in common locations (e.g., /bin/httpd,/usr/sbin/telnetd,/lib/libcrypto.so). If matched, we set p_i = 1; otherwise, p_i = 0. The total number of path-matched binaries provides a structural representation of deployment patterns.
• String Summary Feature. We extract the printable ASCII string set $\mathcal{S}$(b_i) from each binary and retain only those strings with length greater than a threshold n (default n = 10). This set captures high-level semantic content embedded within the binary.
• Fuzzy Hash Fingerprint. We compute the ssdeep [40] hash h_i = ssdeep(b_i) for each binary, yielding a fingerprint of its raw content. The complete fingerprint set $\mathcal{H}$ (R) = {h1, …, h_M} serves as a basis for subsequent cross-firmware fuzzy matching.

Finally, we aggregate these features into a unified resource signature vector:

$${\varphi }_r\left(R\right)=\left({\mathcal{P}}_R, {\mathcal{S}}_R, {\mathcal{H}}_R\right)$$

(8)

Here, ${\mathcal{P}}_R=\left\{p_i\mid p_i=1\right\}$ denotes the set of binaries with path semantics matches, ${\mathcal{S}}_R={\bigcup }_{i=1}^M\mathcal{S}\left(b_i\right)$ is the union of all printable string sets, and ${\mathcal{H}}_R={\left\{h_i\right\}}_{i=1}^M$ is the complete set of ssdeep fingerprints. This signature profile serves as a lightweight and semantically rich input for downstream analyses such as path alignment, string-set similarity, and fuzzy fingerprint matching. It enables efficient large-scale binary reuse analysis and similarity-based firmware clustering.

Feature Fusion and Vectorized Representation. To unify the structural and semantic features modeled across the three sub-dimensions above, we concatenate the structural layout vector ${\varphi }_s\left(R\right)$, the sensitive resource vector ${\varphi }_l\left(R\right)$, and the binary resource signature vector ${\varphi }_r\left(R\right)$ in a fixed order to construct a holistic semantic representation of the firmware’s filesystem dimension:

$${\Phi }_{\mathrm{fs}}\left(F\right)=\left[{\varphi }_s\left(R\right)\parallel {\varphi }_l\left(R\right)\parallel {\varphi }_r\left(R\right)\right]$$

(9)

Here, $\parallel$ denotes the vector concatenation operator. The resulting vector ${\Phi }_{\mathrm{fs}}\left(F\right)$ provides a consistent and interpretable feature representation across different firmware samples, supporting direct engagement in downstream tasks such as structural similarity comparison and cluster analysis.

The Filesystem Semantic Profile offers a multi-perspective, lightweight, and highly interpretable modeling paradigm. Its construction does not rely on decrypted file contents, filesystem mounting, or dynamic execution, making it broadly applicable across diverse firmware types. This profile serves as a foundational component in tasks such as structural reuse detection and configuration exposure assessment, providing robust analytical support under both scalable and adversarial analysis conditions.

3.3. Interface Exposure Profile

Communication interfaces serve as the primary entry points through which external entities interact with embedded devices. The presence and structure of such interfaces, along with their associated parameter semantics, reveal the functional exposure and input control boundaries of the underlying system. In embedded firmware, these interfaces are often embedded in configuration scripts, HTML forms, or hardcoded strings, with limited or no accompanying documentation or source code. To systematically recover the externally accessible communication surface, we introduce the Interface Exposure Profile, which extracts reachable interface paths and input parameters from firmware images and models the corresponding exposure structure. This profile is constructed in three stages: Interface Identifier Extraction, Interface Structural Summary Modeling, and Interface Exposure Profile Representation.

Interface Identifier Extraction. We begin by statically scanning the unpacked firmware filesystem for communication-related indicators. Specifically, we focus on HTML pages, CGI handler paths, shell scripts, and string constants embedded within binary files. From these sources, we extract two types of semantic identifiers: (i) interface paths that serve as functional endpoints for communication, and (ii) parameter names that represent user-controlled input keys. Examples of such indicators include CGI paths (e.g., /cgi-bin/upload_firmware.cgi, boafrm/formUpload) and form parameters (e.g., action, modelName) commonly found in embedded web interfaces. Formally, we define:

$$\mathcal{U}\left(F\right)=\left\{u_1,u_2,\dots ,u_m\right\},\hspace{1em}\mathcal{K}\left(F\right)=\left\{k_1,k_2,\dots ,k_n\right\}$$

(10)

Here, $\mathcal{U}\left(F\right)$ denotes the set of all reachable interface paths, and $\mathcal{K}\left(F\right)$ denotes the set of parameter keys identified in firmware $F$. We preserve the raw string representation of these identifiers to retain semantic fidelity and naming consistency.

Interface Structural Summary Modeling. To enable compact representation and cross-firmware comparison, we construct a five-dimensional statistical vector to summarize the structural characteristics of the extracted interface elements. These features capture the scale, nesting complexity, and naming diversity of the communication surface:

• Number of interface paths N_u = |$𝒰$(F)|: number of distinct interface paths.
• Number of parameter names N_k = |$𝒦$(F)|: number of unique parameter names.
• Average path depth ${\mu }_d={\displaystyle \frac{1}{N_u}}{\sum }_{i=1}^{N_u}\mathrm{Depth}\left(u_i\right)$: average path depth, where Depth(u_i) counts the number of slashes in u_i.
• Prefix entropy of interface paths $H_{\mathrm{prefix}}=-{\sum }_{j=1}^k{p}_j{\log }_2{p}_j$: measuring the distribution dispersion of interface deployment across different top-level path prefixes (e.g., cgi-bin, boafrm, goform), where p_j is the probability of prefix j.
• Character-level entropy of parameter names $H_{\mathrm{key}}=-{\sum }_{c\in \mathcal{C}}p\left(c\right){\log }_{2}p\left(c\right)$: reflecting the lexical diversity and naming consistency across all extracted input keys, where $𝒞$ is the set of characters and p(c) is the frequency of character c.

Formally, the structural summary vector is defined as:

$${\varphi }_{\mathit{intf}}\left(F\right)=\left[N_u, N_k, {\mu }_d, H_{\mathit{prefix}}, H_{\mathit{key}}\right]\in {ℝ}^5$$

(11)

This representation offers a holistic view of the input surface in terms of interface scale, structural organization, and naming semantics, supporting clustering and complexity evaluation tasks across firmware samples.

Interface Exposure Profile Representation. Finally, we define the complete Interface Exposure Profile of a firmware sample as:

$${\Phi }_{\mathit{intf}}\left(F\right)=\left(\mathcal{U}\left(F\right), \mathcal{K}\left(F\right), {\varphi }_{\mathit{intf}}\left(F\right)\right)$$

(12)

Here, $\mathcal{U}\left(F\right)$ and $\mathcal{K}\left(F\right)$ preserve raw semantic information, and ${\varphi }_{\mathit{intf}}\left(F\right)$ provides a structured summary. Together, these components capture the content, range, and distributional properties of the firmware’s communication surface.

This profile has three key advantages: (i) it retains original identifiers for semantic interpretability and traceability; (ii) it supports alignment and comparison across new firmware samples; and (iii) its structural features enable multi-granularity analysis of communication surface complexity and design consistency. In Section 4, we leverage Interface Exposure Profiles for similarity computation and functional clustering across firmware samples, facilitating large-scale analysis of input structures and attack surfaces.

3.4. Exposed Binary Symbolic Profile

In embedded firmware, boundary binaries serve as the critical bridge between external communication interfaces and internal control logic. These binaries are responsible for input processing, protocol parsing, and system interactions. Their internal structures, such as function definitions, symbol tables, and identifiable semantic elements, directly reflect the device’s entry points and functional layout. In particular, such binaries are typically located at the forefront of the system execution path. As a result, their exposed symbolic features are central indicators of module boundaries and play a pivotal role in defining the attack surface and guiding the propagation of potential vulnerabilities.

To systematically model the symbolic-level structure of these binaries, we propose the Exposed Binary Symbolic Profile, which statically extracts multi-dimensional symbolic features including import tables, export symbols, reconstructed internal symbols, and identifiable function signatures. This modeling process is guided by the communication paths and parameter sets extracted in the Interface Exposure Profile, from which we select the top-n binaries that expose the most communication entry points:

$$\mathcal{B}=\left\{B_1,B_2,\dots ,B_n\right\}$$

(13)

We then analyze each $B_i\in \mathcal{B}$ using static disassembly tools. In this process, we extract four key categories of symbolic features, namely the import table, export symbols, reconstructed internal symbols, and identifiable function signatures.

Import Table Modeling. We extract the set of imported functions required by $B_i$, representing its dependencies on external libraries and system interfaces:

$$\mathrm{Imp}\left(B_i\right)=\left\{f_1^{\mathit{imp}},f_2^{\mathit{imp}},\dots ,f_{m_i}^{\mathit{imp}}\right\}$$

(14)

This set reflects the runtime behavior intent of the binary. We retain the raw function names for cross-sample comparison and compute the total number of imports:

$${\varphi }_{\mathit{imp}}\left(B_i\right)=\left|\mathrm{Imp}\left(B_i\right)\right|$$

(15)

Export Table Modeling. We extract the set of functions and global symbols exported by $B_i$, which define the binary’s external interfaces:

$$\mathrm{Exp}\left(B_i\right)=\left\{f_1^{\mathit{exp}},f_2^{\mathit{exp}},\dots ,f_{r_i}^{\mathit{exp}}\right\}$$

(16)

These entries represent callable entry points for other components. We preserve the original names and record the export count:

$${\varphi }_{\exp }\left(B_i\right)=\left|\mathrm{Exp}\left(B_i\right)\right|$$

(17)

Symbol Table Recovery. We attempt to reconstruct internal function symbols within $B_i$, yielding a set of recoverable symbols:

$$\mathrm{Sym}\left(B_i\right)=\left\{f_1^{\mathrm{sym}},f_2^{\mathrm{sym}},\dots ,f_{s_i}^{\mathrm{sym}}\right\}$$

(18)

These may include internal or static functions detected via debugging residues or symbol recovery algorithms. We compute the total number:

$${\varphi }_{\mathrm{sym}}\left(B_i\right)=\left|\mathrm{Sym}\left(B_i\right)\right|$$

(19)

Function Identifier Extraction. We extract identifiable function signatures from all functions within $B_i$, forming a set of matched function fingerprints:

$$\mathrm{FID}\left(B_i\right)=\left\{f_1^{\mathrm{id}},f_2^{\mathrm{id}},\dots ,f_{t_i}^{\mathrm{id}}\right\}$$

(20)

These signatures support comparison with known vulnerability handlers and protocol logic. We record their count:

$${\varphi }_{\mathrm{id}}\left(B_i\right)=\left|\mathrm{FID}\left(B_i\right)\right|$$

(21)

Symbolic Feature Representation. We concatenate the four symbolic statistics into a symbolic feature vector:

$${\varphi }_{\mathrm{symb}}\left(B_i\right)=\left[{\varphi }_{\mathrm{imp}}\left(B_i\right),{\varphi }_{\exp }\left(B_i\right),{\varphi }_{\mathrm{sym}}\left(B_i\right),{\varphi }_{\mathrm{id}}\left(B_i\right)\right]\in {\mathbb{N}}^4$$

(22)

Additionally, we retain the corresponding raw function sets for advanced symbolic matching:

$${\mathsf{\Psi }}_{\mathrm{symb}}\left(B_i\right)=\left(\mathrm{Imp}\left(B_i\right),\mathrm{Exp}\left(B_i\right),\mathrm{Sym}\left(B_i\right),\mathrm{FID}\left(B_i\right)\right)$$

(23)

To construct the complete symbolic profile for firmware $F$, we aggregate the features across all selected boundary binaries:

$${\mathsf{\Phi }}_{\mathrm{symb}}\left(F\right)=\bigcup _{i=1}^n\left({\varphi }_{\mathrm{symb}}\left(B_i\right),{\mathsf{\Psi }}_{\mathrm{symb}}\left(B_i\right)\right)$$

(24)

This representation is both scalable and semantically expressive: it provides quantitative indicators of symbolic exposure while preserving the symbolic-level matching granularity. The Exposed Binary Symbolic Profile serves as a crucial foundation for downstream tasks such as component identification, protocol analysis, semantic attribution, and vulnerability propagation modeling.

3.5. Vulnerability-Oriented Call-Chain Profile

In embedded firmware, communication parameters often serve as key control entry points for triggering functionality and orchestrating protocols. Their propagation paths within a binary may reveal critical interaction chains between external input and internal processing logic. When such parameters reach security-sensitive functions, particularly those related to memory operations or command execution, they can pose serious risks such as buffer overflows or command injection. To capture these behaviors, we introduce the Vulnerability-oriented Call-Chain Profile. This static modeling approach traces parameter-dependent function call paths within boundary binaries to highlight potential high-risk interactions. This profile consists of three modeling stages: Sensitive Parameter-Oriented Trace Extraction, Address Normalization and Chain Reconstruction, and Path Sampling and Sequence Modeling. Together, they provide a unified structural foundation for reconstructing parameter-driven execution contexts and supporting semantic-level comparison across firmware samples.

Sensitive Parameter-Oriented Trace Extraction. We begin by identifying a predefined set of security-sensitive functions (e.g., strcpy, system, memcpy, snprintf) within the top-n boundary binaries. These functions are treated as sink points for potential unsafe input propagation. Using static taint analysis, we reverse-trace their input parameters to identify a subset of communication keys involved in such flows:

$$\mathcal{K}\left(F\right)=\left\{k_1,k_2,\dots ,k_m\right\}$$

(25)

Each key $k_i$ in $\mathcal{K}\left(F\right)$ represents a parameter that appears at least once in a taint path reaching a sensitive function. For every $k\in \mathcal{K}\left(F\right)$, we extract all function-level call chains along which the parameter propagates:

$${\mathcal{C}}_k=\left\{C_1^k,C_2^k,\dots ,C_{t_k}^k\right\}$$

(26)

Each call chain $C_i^k$ is a sequence of function nodes representing the invocation path from input reception to the sensitive function:

$$C_i^k=\left[f_{i,1}^k,f_{i,2}^k,\dots ,f_{i,l_i}^k\right]$$

(27)

Each function node $f_{i,j}^k$ may contain the function name and disassembly address, describing concrete transfer steps of the parameter through function calls.

Address Normalization and Chain Reconstruction. Due to differences in compilation, loading addresses, and symbol availability across firmware samples, direct use of raw function paths hinders cross-sample alignment. To address this, we normalize each chain by removing address information and preserving only semantically meaningful function names:

$$\mathrm{Norm}\left(C_i^k\right)=\left[{f^{\prime }}_1,{f^{\prime }}_2,\dots ,{f^{\prime }}_{l_i}\right], {f^{\prime }}_j=\mathrm{Name}\left(f_{i,j}^k\right)$$

(28)

Here, $\mathrm{Name}\left(\cdot \right)$ extracts the symbolic name of a function. If no name is available, a placeholder is inserted. The normalized call chains are aggregated as:

$${\widehat{\mathcal{C}}}_k=\left\{\mathrm{Norm}\left(C_i^k\right)\mid 1\le i\le t_k\right\}$$

(29)

This set of address-independent sequences forms a canonical representation for parameter propagation paths, ensuring alignment across diverse firmware environments.

Path Sampling and Sequence Modeling. In practice, a single parameter may propagate through a large number of call chains. To reduce redundancy while preserving structural diversity, we group ${\widehat{\mathcal{C}}}_k$ by path length and retain up to five representative sequences for each length. Let $\mathcal{L}$ denote the set of all observed path lengths, and the final sampled set is defined as:

$${\tilde{\mathcal{C}}}_k=\bigcup _{l\in \mathcal{L}}{\mathrm{Top}}_5\left(\left\{C\in {\widehat{\mathcal{C}}}_k\mid \left|C\right|=l\right\}\right)$$

(30)

Here, ${\mathrm{Top}}_5\left(\cdot \right)$ selects up to five chains per group, prioritizing path order or function importance heuristics. This sampling reduces modeling complexity while preserving core behavioral signals.

Finally, we define the overall call-chain profile of the firmware as:

$${\mathsf{\Phi }}_{\mathrm{chain}}\left(F\right)=\left\{{\tilde{\mathcal{C}}}_k\mid k\in \mathcal{K}\left(F\right)\right\}$$

(31)

This structure aggregates normalized call paths for all relevant parameters, offering stable, interpretable representations suitable for downstream analysis. For similarity comparison, we adopt edit distance as a path-level metric, enabling robust sequence alignment and behavioral clustering across firmware samples.

4. Firmware Similarity Computation Across Multi-Dimensional Semantic Profiles

In Section 3, we constructed five types of semantic profiles, focusing on distinct aspects of firmware behavior: structural unpacking signatures, filesystem semantic layouts, interface and parameter exposure, symbolic structures of boundary binaries, and parameter-dependent call chains. These profiles are highly complementary, compensating for the limitations of any single analytical dimension. They also exhibit strong generalizability and stability across heterogeneous architectures, providing a semantic foundation for downstream tasks such as firmware clustering, functionality transfer, and reasoning about vulnerability patterns.

To enable semantic alignment and similarity computation across firmware samples, this chapter presents a unified Multi-dimensional Semantic Profile Similarity Computation Framework. Given a pair of firmware samples $\left(F_i,F_j\right)$, the framework computes dedicated similarity scores ${\mathrm{Sim}}_{\mathsf{\Phi }}\left(F_i,F_j\right)$ for each profile $\mathsf{\Phi }\left(F\right)$, adopting customized strategies according to the feature type, such as sequence sets, path structures, statistical vectors, or function call chains. The framework then integrates these individual scores using a profile fusion mechanism to produce a unified semantic similarity metric. The remainder of this chapter elaborates on the representation and comparison methods for each profile, detailing the similarity metrics and computation procedures for all semantic dimensions.

4.1. Unpacking Signature Sequence Profile Similarity

The Unpacking Signature Sequence Profile captures structural behaviors exhibited during firmware unpacking. It represents each firmware sample using a sequence of signature identifiers $S\left(F\right)$, an n-gram structure set $G_k\left(F\right)$, and a corresponding frequency vector ${\varphi }_k\left(F\right)$. To support similarity measurement under this dimension, we design a two-level strategy that combines set-based and frequency-based comparisons.

Let $F_1$ and $F_2$ be the two firmware samples under comparison. Their respective n-gram structure sets are:

$$G_k\left(F_1\right)=\left\{g_1^{\left(1\right)},g_2^{\left(1\right)},\dots ,g_{n_1}^{\left(1\right)}\right\},\hspace{1em}{G}_k\left(F_2\right)=\left\{g_1^{\left(2\right)},g_2^{\left(2\right)},\dots ,g_{n_2}^{\left(2\right)}\right\}$$

(32)

Here, each $g_i^{\left(*\right)}$ is a length-$k$ structural sub-sequence extracted from the unpacking signature stream. We first compute the overlap between the two sets using the Jaccard similarity:

$${\mathrm{Sim}}_{\mathrm{sig}}^{\mathrm{set}}\left(F_1,F_2\right)={\displaystyle \frac{\left|G_k\left(F_1\right)\cap G_k\left(F_2\right)\right|}{\left|G_k\left(F_1\right)\cup G_k\left(F_2\right)\right|}}$$

(33)

This metric reflects the extent to which the two firmware samples share common unpacking patterns, which indicates alignment in nested component structures.

To further assess their behavior on shared patterns, we construct a unified vocabulary $\mathcal{G}=\left\{g_1,g_2,\dots ,g_m\right\}$ over the union $G_k\left(F_1\right)\cup G_k\left(F_2\right)$, and derive the frequency vectors:

$${\varphi }_k^{\prime }\left(F_1\right)=\left[f_1^{\left(1\right)},f_2^{\left(1\right)},\dots ,f_m^{\left(1\right)}\right],\hspace{1em}{\varphi }_k^{\prime }\left(F_2\right)=\left[f_1^{\left(2\right)},f_2^{\left(2\right)},\dots ,f_m^{\left(2\right)}\right]$$

(34)

Here, $f_j^{\left(i\right)}$ denotes the frequency of $g_j\in \mathcal{G}$ in firmware $F_i$. Based on these vectors, we compute the cosine similarity in the frequency space:

$${\mathrm{Sim}}_{\mathrm{sig}}^{\mathrm{vec}}\left(F_1,F_2\right)={\displaystyle \frac{{\varphi }_k^{\prime }\left(F_1\right)\cdot {\varphi }_k^{\prime }\left(F_2\right)}{\Vert {\varphi }_k^{\prime }\left(F_1\right)\Vert \cdot \Vert {\varphi }_k^{\prime }\left(F_2\right)\Vert }}$$

(35)

This captures the similarity in usage tendencies over common structural patterns, revealing shared unpacking behaviors and semantic bias.

Finally, we integrate the structural and frequency perspectives with equal weight to define the overall similarity under the unpacking profile:

$${\mathrm{Sim}}_{\mathrm{sig}}\left(F_1,F_2\right)={\displaystyle \frac{1}{2}}\cdot \left({\mathrm{Sim}}_{\mathrm{sig}}^{\mathrm{set}}\left(F_1,F_2\right)+{\mathrm{Sim}}_{\mathrm{sig}}^{\mathrm{vec}}\left(F_1,F_2\right)\right)$$

(36)

This dual-layer computation combines structural alignment and behavioral affinity, providing a stable, interpretable, and generalizable metric for modeling unpacking-based firmware similarity. It serves as a key component in the multi-dimensional similarity integration that follows.

4.2. Filesystem Semantic Profile Similarity

The Filesystem Semantic Profile captures firmware deployment patterns and potential attack surfaces from three static perspectives: structural layout, sensitive resource exposure, and binary resource composition. To compute the similarity of two firmware samples under this profile, we decompose the overall representation ${\mathsf{\Phi }}_{\mathrm{fs}}\left(F\right)$ into three heterogeneous feature categories. Each category is processed using a dedicated similarity function, and its results are aggregated into a unified similarity score at the vector level. The complete method is detailed below.

Structural Layout Similarity. Let the structural layout vectors of two firmware samples $F_i$ and $F_j$ be defined as:

$${\varphi }_s\left(F_i\right)=\left[{\mu }_{\delta }^{\left(i\right)}, {\sigma }_{\delta }^{\left(i\right)}, {\mu }_{\rho }^{\left(i\right)}, {\mu }_{\gamma }^{\left(i\right)}, H^{\left(i\right)}\right],\hspace{1em}{\varphi }_s\left(F_j\right)=\left[{\mu }_{\delta }^{\left(j\right)}, {\sigma }_{\delta }^{\left(j\right)}, {\mu }_{\rho }^{\left(j\right)}, {\mu }_{\gamma }^{\left(j\right)}, H^{\left(j\right)}\right]$$

(37)

We adopt the normalized Euclidean distance as the base metric for comparing these layout vectors, defined as:

$${\mathrm{Sim}}_{\mathrm{layout}}\left(F_i,F_j\right)=1-{\displaystyle \frac{\parallel {\varphi }_s\left(F_i\right)-{\varphi }_s\left(F_j\right){\parallel }_2}{\parallel {\varphi }_s\left(F_i\right){\parallel }_2+\parallel {\varphi }_s\left(F_j\right){\parallel }_2}}$$

(38)

The similarity score lies within the range $\left[0,1\right]$, with larger values indicating greater structural similarity. Normalization mitigates bias caused by vector magnitude and is suitable for low-dimensional dense feature vectors.

Sensitive Resource Tag Similarity. Sensitive resources are modeled as frequency vectors defined over a unified label space $\mathcal{L}$, where each label corresponds to a specific category of files or directories with potential security significance. Given two firmware samples $F_i$ and $F_j$, we represent their tag distributions as:

$${\varphi }_l\left(F_i\right)=\left[c_1^{\left(i\right)}, c_2^{\left(i\right)}, \dots , c_n^{\left(i\right)}\right],\hspace{1em}{\varphi }_l\left(F_j\right)=\left[c_1^{\left(j\right)}, c_2^{\left(j\right)}, \dots , c_n^{\left(j\right)}\right]$$

(39)

Here, $c_k^{\left(i\right)}$ denotes the occurrence frequency of label $l_k\in \mathcal{L}$ in firmware $F_i$. Since $\mathcal{L}$ is predefined and consistent across all samples, the vectors ${\varphi }_l\left(F_i\right)$ and ${\varphi }_l\left(F_j\right)$ share identical dimensionality. We use cosine similarity to evaluate the alignment between the two label frequency vectors:

$${\mathrm{Sim}}_{\mathrm{tags}}\left(F_i,F_j\right)={\displaystyle \frac{{\varphi }_l\left(F_i\right)\cdot {\varphi }_l\left(F_j\right)}{\parallel {\varphi }_l\left(F_i\right){\parallel }_2\cdot \parallel {\varphi }_l\left(F_j\right){\parallel }_2}}$$

(40)

This similarity score reflects the degree of overlap in sensitive resource exposure between the two firmware images. It is particularly effective for comparing sparse high-dimensional vectors and highlights consistency in sensitive asset usage patterns.

Binary Resource Signature Similarity. The representation of binary resources consists of three distinct components: the set of matched file paths denoted as ${\mathcal{P}}_R$, the set of printable strings denoted as ${\mathcal{S}}_R$, and the set of fuzzy hash digests denoted as ${\mathcal{H}}_R$. These components, respectively, characterize the semantic properties of the binary in terms of deployment location, textual content, and structural fingerprint.

• Path Semantic Matching Similarity. Let $𝒫$_i and $𝒫$_i denote the sets of matched file paths extracted from firmware F_i and F_j, respectively. The path-based similarity is quantified using the Jaccard index, defined as:

$${\mathrm{Sim}}_{\mathrm{path}}\left(F_i,F_j\right)={\displaystyle \frac{\left|{\mathcal{P}}_i\cap {\mathcal{P}}_j\right|}{\left|{\mathcal{P}}_i\cup {\mathcal{P}}_j\right|}}$$

(41)

• String Set Similarity. Let $𝒮$_i and $𝒮$_j denote the sets of printable strings extracted from firmware F_i and F_j, respectively. Their semantic similarity is computed by:

$${\mathrm{Sim}}_{\mathrm{str}}\left(F_i,F_j\right)={\displaystyle \frac{\left|{\mathcal{S}}_i\cap {\mathcal{S}}_j\right|}{\left|{\mathcal{S}}_i\cup {\mathcal{S}}_j\right|}}$$

(42)

• Fuzzy Hash Matching Similarity. Let $\mathcal{H}$_i and $\mathcal{H}$_j represent the sets of fuzzy hash digests generated from the binary files of F_i and F_j, respectively. To compare structural similarity, we use the maximum fuzzy hash similarity for each element in $\mathcal{H}$_i against all elements in $\mathcal{H}$_j, as provided by the ssdeep hash similarity function ssdeep_sim(h, h′) ∈ [0, 100], which is normalized to the range [0, 1]:

$${\mathrm{Sim}}_{\mathrm{hash}}\left(F_i,F_j\right)={\displaystyle \frac{1}{\left|{\mathcal{H}}_i\right|}}\sum _{h\in {\mathcal{H}}_i}\underset{h^{\prime }\in {\mathcal{H}}_j}{\max }\mathrm{ssdeep}\_\mathrm{sim}\left(h,h^{\prime }\right)$$

(43)

Finally, we aggregate the three signature components using a weighted sum. By default, we assign equal weights $\alpha =\beta =\gamma ={\displaystyle \frac{1}{3}}$, but these can be adjusted based on task-specific priorities:

$${\mathrm{Sim}}_{\mathrm{bin}}\left(F_i,F_j\right)=\alpha \cdot {\mathrm{Sim}}_{\mathrm{path}}+\beta \cdot {\mathrm{Sim}}_{\mathrm{str}}+\gamma \cdot {\mathrm{Sim}}_{\mathrm{hash}},\hspace{1em}\alpha +\beta +\gamma =1$$

(44)

Integrated Similarity Fusion. Finally, we compute the overall similarity under the Filesystem Semantic Profile by fusing the three sub-scores:

$${\mathrm{Sim}}_{\mathrm{fs}}\left(F_i,F_j\right)=w_s\cdot {\mathrm{Sim}}_{\mathrm{layout}}+w_l\cdot {\mathrm{Sim}}_{\mathrm{tags}}+w_r\cdot {\mathrm{Sim}}_{\mathrm{bin}},\hspace{1em}{w}_s+w_l+w_r=1$$

(45)

Here, $w_s$, $w_l$, and $w_r$ represent the weights assigned to structural layout, label frequency, and binary signature similarity, respectively. By default, we adopt uniform weighting to balance the contributions. This integrated strategy ensures that multi-source semantic features are jointly modeled, providing a robust metric for structural comparison and behavioral clustering at the filesystem level.

4.3. Interface Exposure Profile Similarity

The Interface Exposure Profile ${\Phi }_{\mathit{intf}}\left(F\right)$ is designed to capture the structural organization and complexity of external communication surfaces in embedded firmware. It incorporates three components: the interface path set $\mathcal{U}\left(F\right)$, the parameter name set $\mathcal{K}\left(F\right)$, and a structural summary vector ${\varphi }_{\mathit{intf}}\left(F\right)$. To compute semantic similarity under this profile, we jointly consider two classes of features: symbolic identifier sets and statistical structural vectors. These features are assessed independently and then integrated under a unified similarity space.

Path and Key Set Similarity. We begin by comparing the sets of extracted interface paths and parameter names between firmware $F_i$ and $F_j$, using Jaccard similarity for both components:

$${\mathrm{Sim}}_{\mathrm{url}}\left(F_i,F_j\right)={\displaystyle \frac{\left|\mathcal{U}\left(F_i\right)\cap \mathcal{U}\left(F_j\right)\right|}{\left|\mathcal{U}\left(F_i\right)\cup \mathcal{U}\left(F_j\right)\right|}},\hspace{1em}{\mathrm{Sim}}_{\mathrm{key}}\left(F_i,F_j\right)={\displaystyle \frac{\left|\mathcal{K}\left(F_i\right)\cap \mathcal{K}\left(F_j\right)\right|}{\left|\mathcal{K}\left(F_i\right)\cup \mathcal{K}\left(F_j\right)\right|}}$$

(46)

Here, $\mathcal{U}\left(F\right)$ denotes the set of statically extracted communication paths, while $\mathcal{K}\left(F\right)$ refers to the corresponding input parameter names. Both are retained in their original string form to preserve semantic traceability. These metrics quantify the degree of overlap in externally exposed endpoints and input semantics, serving as the foundation for structural alignment and shared functionality identification.

Structural Summary Vector Similarity. To assess structural alignment at an abstract level, we represent each firmware using a five-dimensional structural vector ${\varphi }_{\mathrm{intf}}\left(F\right)=\left[N_u,N_k,{\mu }_d,H_{\mathrm{prefix}},H_{\mathrm{key}}\right]\in {ℝ}^5$, which encodes the number of distinct paths and keys, average path depth, prefix entropy of deployment locations, and character-level entropy of parameter names. Since the vector resides in continuous space, we compute similarity using cosine distance:

$${\mathrm{Sim}}_{\mathrm{stat}}\left(F_i,F_j\right)={\displaystyle \frac{{\varphi }_{\mathrm{intf}}\left(F_i\right)\cdot {\varphi }_{\mathrm{intf}}\left(F_j\right)}{\parallel {\varphi }_{\mathrm{intf}}\left(F_i\right)\parallel \cdot \parallel {\varphi }_{\mathrm{intf}}\left(F_j\right)\parallel }}$$

(47)

This metric captures higher-level structural and naming trends, reflecting deployment complexity, input diversity, and design consistency across firmware samples.

Integrated Interface Exposure Similarity. To combine the above three scores into a unified similarity indicator, we define a weighted aggregation scheme:

$${\mathrm{Sim}}_{\mathrm{intf}}\left(F_i,F_j\right)={\lambda }_1\cdot {\mathrm{Sim}}_{\mathrm{url}}\left(F_i,F_j\right)+{\lambda }_2\cdot {\mathrm{Sim}}_{\mathrm{key}}\left(F_i,F_j\right)+{\lambda }_3\cdot {\mathrm{Sim}}_{\mathrm{stat}}\left(F_i,F_j\right)$$

(48)

Here, ${\lambda }_1,{\lambda }_2,{\lambda }_3\in \left[0,1\right]$ are fusion weights satisfying ${\lambda }_1+{\lambda }_2+{\lambda }_3=1$. By default, equal weights ${\lambda }_1={\lambda }_2={\lambda }_3={\displaystyle \frac{1}{3}}$ are used, though these may be adjusted for task-specific requirements.

This similarity formulation provides three key advantages. First, Jaccard similarity over original string sets enables clustering and generalization across vendor-specific interface conventions. Second, the statistical vector captures global structural patterns in a compact, computable form. Third, the fusion mechanism supports multi-source feature coordination, enhancing the alignment of interface semantics across architectures. This similarity score serves as an integral component in the overall cross-firmware similarity computation pipeline.

4.4. Exposed Binary Symbolic Similarity

In embedded firmware, boundary binaries are responsible for protocol parsing and system interaction, and their symbolic-level structures reflect both external dependencies and internal functional layouts. In the modeling described previously, we extract for each top-n boundary binary $B_i\in \mathcal{B}$ a four-dimensional statistical feature vector ${\varphi }_{\mathrm{symb}}\left(B_i\right)\in {\mathbb{N}}^4$, along with a corresponding symbol set ${\mathsf{\Psi }}_{\mathrm{symb}}\left(B_i\right)$. These features jointly capture the exposed import functions, export symbols, reconstructed internal symbols, and function identifiers. To assess similarity under this semantic dimension, we design two complementary modeling strategies based on aggregated statistics and original symbolic content.

Statistical Vector Similarity. Given two firmware samples $F_a$ and $F_b$, let their respective sets of boundary binaries be ${\mathcal{B}}_a=\{B_1^a,\dots ,B_{n_a}^a\}$, ${\mathcal{B}}_b=\left\{B_1^b,\dots ,B_{n_b}^b\right\}$. For each sample, we apply average pooling over the statistical feature vectors of all its binaries to form a global representation:

$${\overline{\varphi }}_{\mathrm{symb}}\left(F_a\right)={\displaystyle \frac{1}{n_a}}\sum _{i=1}^{n_a}{\varphi }_{\mathrm{symb}}\left(B_i^a\right),\hspace{1em}{\overline{\varphi }}_{\mathrm{symb}}\left(F_b\right)={\displaystyle \frac{1}{n_b}}\sum _{j=1}^{n_b}{\varphi }_{\mathrm{symb}}\left(B_j^b\right)$$

(49)

We then measure their similarity using cosine similarity, where $\parallel \cdot {\parallel }_2$ denotes the L2 norm:

$${\mathrm{Sim}}_{\mathrm{symb}}^{\mathrm{vec}}\left(F_a,F_b\right)={\displaystyle \frac{{\overline{\varphi }}_{\mathrm{symb}}\left(F_a\right)\cdot {\overline{\varphi }}_{\mathrm{symb}}\left(F_b\right)}{\parallel {\overline{\varphi }}_{\mathrm{symb}}\left(F_a\right){\parallel }_2\cdot \parallel {\overline{\varphi }}_{\mathrm{symb}}\left(F_b\right){\parallel }_2}}$$

(50)

Symbol Set Similarity. To further incorporate raw symbolic identifiers, we aggregate all four categories of symbols from the boundary binaries of each firmware into a unified set:

$${\mathcal{S}}_{\mathrm{symb}}\left(F_a\right)=\bigcup _{i=1}^{n_a}\mathrm{Imp}\left(B_i^a\right)\cup \mathrm{Exp}\left(B_i^a\right)\cup \mathrm{Sym}\left(B_i^a\right)\cup \mathrm{FID}\left(B_i^a\right)$$

(51)

$${\mathcal{S}}_{\mathrm{symb}}\left(F_b\right)=\bigcup _{i=1}^{n_a}\mathrm{Imp}\left(B_i^a\right)\cup \mathrm{Exp}\left(B_j^b\right)\cup \mathrm{Sym}\left(B_j^b\right)\cup \mathrm{FID}\left(B_j^b\right)$$

(52)

Here, Imp, Exp, Sym, and FID respectively denote the sets of imported functions, exported symbols, reconstructed internal symbols, and function identifiers. We compute the Jaccard similarity between these unified symbol sets:

$${\mathrm{Sim}}_{\mathrm{symb}}^{\mathrm{set}}\left(F_a,F_b\right)={\displaystyle \frac{\left|{\mathcal{S}}_{\mathrm{symb}}\left(F_a\right)\cap {\mathcal{S}}_{\mathrm{symb}}\left(F_b\right)\right|}{\left|{\mathcal{S}}_{\mathrm{symb}}\left(F_a\right)\cup {\mathcal{S}}_{\mathrm{symb}}\left(F_b\right)\right|}}$$

(53)

Hybrid Similarity Fusion. We integrate the statistical and symbolic-level similarities into a final similarity score using a weighted combination:

$${\mathrm{Sim}}_{\mathrm{symb}}\left(F_a,F_b\right)=\alpha \cdot {\mathrm{Sim}}_{\mathrm{symb}}^{\mathrm{vec}}\left(F_a,F_b\right)+\left(1-\alpha \right)\cdot {\mathrm{Sim}}_{\mathrm{symb}}^{\mathrm{set}}\left(F_a,F_b\right)$$

(54)

Here, $\alpha \in \left[0,1\right]$ is a tunable parameter that adjusts the trade-off between structural statistics and raw symbolic semantics. The value of $\alpha$ can be selected based on validation performance under different evaluation tasks.

This similarity modeling approach balances computational efficiency and representational fidelity, combining the stability of statistical abstraction with the expressiveness of symbolic identifiers. It is suitable for cross-firmware comparison tasks such as functional module alignment and behavior-based clustering.

4.5. Vulnerability-Oriented Call-Chain Similarity

The Vulnerability-oriented Call-Chain Profile captures the semantic propagation paths of communication parameters to security-sensitive functions within embedded firmware. It reflects the internal execution chains that may trigger potential vulnerabilities such as buffer overflows or command injections. To assess the structural similarity of such propagation patterns across different firmware samples, we leverage normalized function call sequences and adopt edit distance as the primary metric for measuring pairwise path similarity. A cross-set alignment strategy is introduced to compute similarity at the firmware level.

Let the Vulnerability-oriented Call-Chain Profile of firmware $F_i$ and $F_j$ be represented as:

$${\mathsf{\Phi }}_{\mathrm{chain}}\left(F_i\right)=\left\{C_1^i,C_2^i,\dots ,C_m^i\right\},\hspace{1em}{\mathsf{\Phi }}_{\mathrm{chain}}\left(F_j\right)=\left\{C_1^j,C_2^j,\dots ,C_n^j\right\}$$

(55)

Here, $C_p^i$ and $C_p^j$ denote individual normalized function call chains represented as ordered sequences of function names:

$$C_p^i=\left[f_{p,1}^i,f_{p,2}^i,\dots ,f_{p,l_i}^i\right],\hspace{1em}{C}_q^j=\left[f_{q,1}^j,f_{q,2}^j,\dots ,f_{q,l_j}^j\right]$$

(56)

The similarity between any pair of paths $C_p^i\in {\mathsf{\Phi }}_{\mathrm{chain}}\left(F_i\right)$ and $C_q^j\in {\mathsf{\Phi }}_{\mathrm{chain}}\left(F_j\right)$ is defined as:

$${\mathrm{Sim}}_{\mathrm{edit}}\left(C_p^i,C_q^j\right)=1-{\displaystyle \frac{\mathrm{EditDist}\left(C_p^i,C_q^j\right)}{\max \left(\left|C_p^i\right|,\left|C_q^j\right|\right)}}$$

(57)

Here, $\mathrm{EditDist}\left(\cdot ,\cdot \right)$ denotes the minimum edit distance between two function sequences, computed using insertion, deletion, and substitution operations. The length $\left|\cdot \right|$ denotes the number of functions in each path. This normalized formulation bounds the similarity score within the range $\left[0,1\right]$, where a value of 1 indicates identical chains and 0 reflects complete dissimilarity.

To compute the overall similarity between firmware $F_i$ and $F_j$, we adopt a max-alignment weighted averaging strategy. For each call chain in $F_i$, we select the most similar counterpart in $F_j$, and average the resulting similarities:

$${\mathrm{Sim}}_{\mathrm{chain}}\left(F_i,F_j\right)={\displaystyle \frac{1}{\left|{\mathsf{\Phi }}_{\mathrm{chain}}\left(F_i\right)\right|}}\sum _{C_p^i\in {\mathsf{\Phi }}_{\mathrm{chain}}\left(F_i\right)}\underset{C_q^j\in {\mathsf{\Phi }}_{\mathrm{chain}}\left(F_j\right)}{\max }{\mathrm{Sim}}_{\mathrm{edit}}\left(C_p^i,C_q^j\right)$$

(58)

This strategy enhances structural comparison accuracy while mitigating risks from unmatched path lengths, varying call-chain counts, and inconsistent function naming. By incorporating the similarity of call chains as a semantic representation of vulnerability propagation behavior, this metric provides a robust foundation for identifying firmware samples with analogous vulnerability paths. It also supports cross-architecture vulnerability migration modeling and reproducibility analysis.

4.6. Multi-Profile Fusion and Global Similarity Computation

In the previous sections, we introduced independent similarity metrics across five key semantic dimensions of firmware, including structural signature sequences, filesystem layout, interface exposure, symbolic representation, and Vulnerability-oriented Call-Chains. For each pair of firmware samples $\left(F_i,F_j\right)$, we compute semantic similarity scores under the corresponding profiles: ${\mathrm{Sim}}_{\mathrm{sig}}\left(F_i,F_j\right),{ \mathrm{Sim}}_{\mathrm{fs}}\left(F_i,F_j\right)$, ${\mathrm{Sim}}_{\mathrm{intf}}\left(F_i,F_j\right),$ ${\mathrm{Sim}}_{\mathrm{symb}}\left(F_i,F_j\right)$, ${\mathrm{Sim}}_{\mathrm{chain}}\left(F_i,F_j\right)$. To support unified similarity assessment across firmware samples, we adopt a linearly weighted fusion strategy that aggregates scores from all semantic dimensions. The global semantic similarity is defined as follows:

$$\begin{gathered} {\mathrm{Sim}}_{\mathrm{global}}\left(F_i,F_j\right)={\lambda }_1\cdot {\mathrm{Sim}}_{\mathrm{sig}}\left(F_i,F_j\right)+{\lambda }_2\cdot {\mathrm{Sim}}_{\mathrm{fs}}\left(F_i,F_j\right)+{\lambda }_3\cdot {\mathrm{Sim}}_{\mathrm{intf}}\left(F_i,F_j\right)+ \\ {\lambda }_4\cdot {\mathrm{Sim}}_{\mathrm{symb}}\left(F_i,F_j\right)+{\lambda }_5\cdot {\mathrm{Sim}}_{\mathrm{chain}}\left(F_i,F_j\right) \end{gathered}$$

(59)

Here, the weights ${\lambda }_1,{\lambda }_2,\dots ,{\lambda }_5\in \left[0,1\right]$ control the contribution of each semantic profile and satisfy the following normalization constraint ${\sum }_{i=1}^5{\lambda }_i=1$. By default, we suggest the following weight configuration to balance structural stability, semantic expressiveness, and computational efficiency:

$${\lambda }_1=0.1,\hspace{1em}{\lambda }_2=0.2,\hspace{1em}{\lambda }_3=0.3,\hspace{1em}{\lambda }_4=0.1,\hspace{1em}{\lambda }_5=0.3$$

(60)

Among these dimensions, the Interface Exposure Profile ${\Phi }_{\mathit{intf}}\left(F\right)$ and the Vulnerability-oriented Call-Chain Profile ${\mathsf{\Phi }}_{\mathrm{chain}}\left(F\right)$ are assigned the highest weights. This is because they directly model the firmware’s attack surface, input boundaries, and potential vulnerability trigger paths, which are critical for homologous vulnerability discovery. The Filesystem Semantic Profile ${\Phi }_{\mathit{fs}}\left(F\right)$ is also given a relatively high weight due to its stable directory topology and rich static feature representation, which yield strong discriminative power across scenarios. The remaining dimensions, the Unpacking Signature Sequence ${\varphi }_k\left(F\right)$ and the Exposed Binary Symbolic Profile ${\mathsf{\Phi }}_{\mathrm{symb}}\left(F\right)$, serve as foundational and complementary features with lower weights, ensuring a comprehensive and balanced analysis.

5. Implementation and Evaluation

In this section, we present the prototype implementation of FirmVulLinker and conduct a comprehensive evaluation of its effectiveness. We assess the system based on the following research questions:

RQ1 Compared with existing approaches for analyzing firmware with homologous vulnerabilities, does FirmVulLinker offer a more comprehensive set of analysis dimensions?

RQ2 How effective is FirmVulLinker in identifying homologous vulnerabilities across firmware samples?

RQ3 Do the multi-dimensional semantic features employed by FirmVulLinker contribute to improved analysis results?

RQ4 Can FirmVulLinker identify real but previously overlooked vulnerabilities?

5.1. Framework Implementation

We have developed and released a fully functional prototype system named FirmVulLinker, which validates the feasibility and practicality of our semantic profiling and homologous vulnerability discovery framework. The system integrates the entire analysis pipeline, from semantic profile construction to cross-sample similarity computation. The source code is available on GitHub to facilitate reproducibility and future extension.

Multi-dimensional Semantic Profiling Module. The semantic profiling module in FirmVulLinker implements five core modeling components, corresponding to the five proposed semantic feature dimensions: Unpacking Signature Sequence Profile, Filesystem Semantic Profile, Interface Exposure Profile, Exposed Binary Symbolic Profile, and Vulnerability-oriented Call Chain Profile.

For Unpacking Signature Sequence Profiling, FirmVulLinker performs recursive scanning of firmware images using the Binwalk [41] tool to extract sequences of embedded magic signatures. These sequences reflect the unpacking path and nesting order, forming a structural trace of the unpacking process. After n-gram modeling, the resulting signature vectors capture semantic differences in unpacking structures across samples.

For the Filesystem Semantic Profile, FirmVulLinker statically traverses the extracted filesystem using the Firmwalker [42] tool, combined with custom pattern-matching rules, to automatically annotate sensitive resources based on path and file characteristics. The system further integrates directory layout, critical configuration files, and binary signature metadata to generate unified semantic feature vectors that support cross-sample comparison of filesystem structures and sensitive asset placement.

For the Interface Exposure Profile, the system integrates and extends the SaTC [39] tool to identify potential external communication entry points, including HTML pages, CGI scripts, and associated parameterized paths. The extracted results are then structurally modeled to capture the number of interfaces, path templates, and parameter name patterns. These features are aggregated into high-dimensional interface exposure vectors, which serve as key inputs to subsequent vulnerability propagation analysis.

For Exposed Binary Symbolic Profiling, FirmVulLinker first ranks boundary binaries based on the number of exposed interfaces and parameters, selecting the top-n candidates for further inspection. Using the Ghidra [43] reverse engineering suite, the system extracts each binary’s import table, export table, symbol table, and function identifiers. These symbolic features are then encoded into vectors and statistical descriptors, enabling semantic comparison between boundary modules across firmware.

For the Vulnerability-oriented Call-Chain Profile, FirmVulLinker conducts a deeper analysis of the previously identified boundary binaries. The system employs a predefined set of sensitive functions and uses the SaTC tool to trace the origin of its arguments through static backward slicing. Each extracted path undergoes address normalization, symbol replacement, and sequence reconstruction. Paths of varying lengths are retained to support chain-level sequence alignment and edit-distance comparison. The final representations serve as semantic encodings of potential vulnerability propagation paths at the firmware level.

Firmware Similarity Computation Module. To support the discovery of homologous vulnerabilities across firmware, FirmVulLinker implements a similarity computation and fusion module covering all five semantic dimensions. This module is implemented in Python 3.12.8 and applies tailored matching strategies for each profile, including n-gram and Jaccard-based sequence similarity, vector-based structural comparison, and edit-distance computation for call chains. The final similarity score is generated through feature normalization and weighted fusion, allowing for global comparison between firmware samples and facilitating the identification of homologous vulnerability propagation paths.

5.2. Experimental Setup

We begin by outlining the experimental setup, including the baseline tools used for comparison, hardware configurations, and the evaluation datasets.

Baseline Tool. For evaluating homologous vulnerability analysis across firmware, we selected LibAM [44] as the primary baseline. LibAM is a state-of-the-art, open-source binary similarity analysis framework widely adopted for clone detection and reuse analysis across various architectures. As LibAM was originally designed for stand-alone binary analysis, it lacks native support for firmware-level inputs. To bridge this gap, we extended LibAM with additional modules to support automatic firmware unpacking, batch binary extraction, and input preprocessing, enabling direct operation on complete firmware images. To adapt LibAM’s output for firmware-level evaluation, we constructed a reuse correlation matrix that captures matched binary pairs across firmware samples. Based on the number of matched binary modules between two firmware images, we computed the mean squared error (MSE) and Pearson correlation coefficient. We fused these results to generate a unified firmware-level similarity score. This enables a fair comparison between LibAM and FirmVulLinker in terms of detecting shared components and potential vulnerability propagation.

Hardware Configuration. Experiments were conducted on two server environments. FirmVulLinker was executed on a CPU-based server equipped with two common KVM processor CPUs (32 physical cores in total), 128 GB RAM, running 64-bit Ubuntu 22.04.5 LTS. LibAM was executed on a GPU-based server with two Intel(R) Xeon(R) Platinum 8358 CPUs at 2.60 GHz (64 physical cores in total), 256 GB RAM, running 64-bit Ubuntu 22.04 LTS, and 8 × NVIDIA A800-SXM4-80GB GPUs (each with 80 GB of memory, CUDA 12.2). Thanks to its lightweight design, FirmVulLinker is capable of efficiently processing large-scale firmware entirely on the CPU, without requiring GPU support. In contrast, LibAM is GPU-dependent for inference and similarity computation.

Dataset. To evaluate FirmVulLinker’s effectiveness in discovering real-world homologous vulnerabilities across firmware samples, we curated datasets entirely from real-world sources. All firmware samples were historical versions officially released by major vendors, and each vulnerability included has a corresponding CVE identifier. Although FirmVulLinker performs purely static analysis without relying on emulation environments, we conducted full emulation and manual vulnerability validation for each firmware sample before inclusion. Specifically, for each firmware, we first built a complete containerized emulation environment using Docker to provide the necessary runtime for vulnerability validation. We then constructed a dedicated proof-of-concept (PoC) script for each vulnerability. To further improve automation, we developed corresponding validation code based on our prior framework, IoTBenchSL [45], which enabled us to trigger and confirm vulnerabilities automatically. Only those samples that could be successfully emulated and whose vulnerabilities were reproducibly triggered were included in the final dataset, ensuring the accuracy and credibility of the ground truth. This additional validation step, though not required by the static analysis workflow, further strengthens the reliability of our evaluation.

In total, we selected 54 firmware images, covering 74 unique vulnerabilities, with each vulnerability appearing in at least two different firmware samples. The vulnerabilities primarily include memory corruption flaws and command injection vulnerabilities, which represent two of the most prevalent categories in IoT firmware security. The dataset also spans the most widely used embedded architectures, namely MIPS and ARM, ensuring that the evaluation reflects the diversity of real-world deployment environments. To further assess FirmVulLinker’s capability in discovering previously undisclosed vulnerabilities, we additionally constructed a second dataset comprising 78 firmware images. These samples could also be fully emulated but had no known vulnerabilities recorded in the National Vulnerability Database (NVD). As discussed in Section 5.6, this dataset was used to explore FirmVulLinker’s potential for identifying latent vulnerabilities that have not yet been reported.

5.3. Comparative Analysis of Feature Dimensions

To answer RQ1, this section comprehensively evaluates FirmVulLinker’s feature modeling capabilities in the context of homology-based firmware vulnerability analysis. We perform a comparative study against several representative static analysis tools that cover different mainstream paradigms, including classic static analysis systems (e.g., Firmalice [10] and FirmRec [9]), structural embedding methods (e.g., Asm2Vec [11]), and integrated vulnerability analysis frameworks (e.g., SaTC [39] and FirmSec [8]). The evaluation focuses on five critical semantic dimensions to determine whether each tool supports corresponding modeling capabilities:

• Unpacking Signature Sequence Modeling: Captures the structural trace and magic byte sequences during firmware unpacking, reflecting packaging formats, nesting structures, and build regularity.
• Filesystem Structure Modeling: Represents the organization of the unpacked filesystem, including directory hierarchies, path semantics, and resource density, to assist in identifying deployment-related configurations and behavior scripts.
• Communication Interfaces and Parameters: Models externally exposed input vectors, such as web endpoints, CGI paths, and parameter names, to characterize attack surfaces and accessible entry points.
• Boundary Binary Modeling: Extracts symbols, function signatures, or control flow information from core binaries to analyze component-level reuse relationships and potential clone characteristics.
• Sensitive Call-Chain Modeling: Performs static backward analysis to identify propagation paths of parameters flowing into security-sensitive functions, reconstructing the triggering context of potential vulnerability paths.

Table 1. Comparison of semantic feature coverage across firmware analysis tools.

Feature Dimension	FirmVulLinker	Firmalice [10]	FirmRec [9]	Asm2Vec [11]	SaTC [39]	FirmSec [8]
Unpacking Signatures	✔	✘	✘	✘	✘	✘
Filesystem Structure	✔	✘	✘	✘	✘	✘
Communication Interfaces	✔	✘	✔	✘	✔	✘
Binary Feature Modeling	✔	✔	✔	✔	✔	✔
Sensitive Call Chains	✔	✔	✔	✘	✔	✘
Vulnerability Discovery	✔	✔	✔	✘	✔	✔

✔: Feature present. ✘: Feature absent.

summarizes the modeling capabilities of FirmVulLinker and other tools across these five dimensions.

As shown in Table 1, FirmVulLinker is the only framework that supports all five static semantic dimensions. Existing approaches typically suffer from structural constraints that hinder the construction of stable and comparable semantic representations for homology analysis. For example, FirmSec and Asm2Vec focus on function-level embeddings based on control flow graphs or assembly instructions but lack awareness of communication entry points and reachable paths, thereby failing to capture vulnerability exploitation contexts. Firmalice and FirmRec emphasize clone detection and sensitive path tracing but do not integrate multi-dimensional features or perform structural abstraction. SaTC supports partial interface extraction but is limited to frontend-backend path matching and does not model unpacking sequences or filesystem layouts, nor does it perform cross-dimensional feature integration.

In contrast, FirmVulLinker demonstrates clear advantages in systematic modeling. Its unified five-dimensional profiling design enables comprehensive semantic representation of both firmware structure and attack surfaces. Moreover, it supports interpretability in component decoupling, path modeling, and context reconstruction. This design provides a robust foundation for subsequent tasks such as firmware homology comparison and variant vulnerability tracing, significantly enhancing the framework’s stability and scalability across architectures and vendors.

5.4. Homologous Vulnerability Correlation Across Firmware Images

To address RQ2, we evaluate the effectiveness of FirmVulLinker in analyzing homologous vulnerability correlation from a vulnerability-centric perspective. We conduct a comparative study against LibAM, a state-of-the-art firmware homology analysis tool, to evaluate both the accuracy and interpretability of identifying correlated vulnerabilities across different firmware images.

To support this evaluation, we curated a vulnerability-driven dataset comprising 54 firmware images from mainstream vendors, covering 74 validated CVE vulnerabilities. Each vulnerability is associated with at least two distinct firmware images. These firmware images, in which the presence of the corresponding vulnerabilities has been manually verified, are hereafter referred to as Known Defective Firmware (KDF). To ensure the reliability of the ground truth, all firmware images were fully emulated, and vulnerabilities were manually verified for reachability and triggering conditions. This process enabled us to establish accurate mappings between KDF images and their corresponding vulnerabilities. For each vulnerability, we randomly selected one associated firmware image as the representative reference firmware. In the subsequent correlation analysis, all other firmware images were treated as candidates and compared against these reference firmware images to evaluate semantic similarity. Metadata of the firmware images is summarized in Appendix A 

Table A1. Metadata of firmware images used in the homologous vulnerability correlation evaluation.

ID	Device Type	Hardware Version	ID	Device Type	Hardware Version
KDF-1	TL-WR940N	V4(us)	KDF-28	TL-WR802N	V1
KDF-2	DIR-823G A1	v1.0.2B03	KDF-29	TL-WR940N	V3(150206)
KDF-3	DIR-825 B1	v2.10NAb02	KDF-30	TL-WR940N	V1(120201)
KDF-4	Archer C20i(UN)	V1	KDF-31	TL-WR940N	V3(161107)
KDF-5	TL-WR841N	V10	KDF-32	TL-WR940N	V4(eu)
KDF-6	DIR-846 A1	v1.0.0(A43)	KDF-33	TL-WR940N	V6
KDF-7	TL-WR740N	V1	KDF-34	TL-WR940N	V3(151102)
KDF-8	TL-WR810N	V2	KDF-35	TL-WR841N	V7(120201)
KDF-9	TL-WR840N	V4	KDF-36	Archer-C2	v1(0.9.1_4.0)
KDF-10	TL-WR845N	V3	KDF-37	Archer-C2	v1(0.9.1_4.1)
KDF-11	TL-WR841N	V8(3_15_9)	KDF-38	Archer-C20	v1(0.9.1_0.2)
KDF-12	TL-WR940N	V2	KDF-39	DIR-823G	v1.02B01
KDF-13	TL-WR1043	V2(150717)	KDF-40	TL-WR743ND	V1(110829)
KDF-14	TL-WR841N	V9(150104)	KDF-41	TL-WR743ND	V1(111212)
KDF-15	TL-WR841N	V9(150310)	KDF-42	TL-WR841N	V7(111228)
KDF-16	Archer_C2	V1	KDF-43	TL-WR940N	V1(111228)
KDF-17	TL-WR841N	V8(3_16_9)	KDF-44	TL-WR940N	V2(3_15_9)
KDF-18	TL-WR841N	V9(us_150401)	KDF-45	TL-WR1042N	V1(120618)
KDF-19	DIR-615 C1	v3.14NA	KDF-46	TL-WR1042N	V1(130117)
KDF-20	TL-WR940N	V1(111228)	KDF-47	DIR-823G	v1.00B02
KDF-21	TL-WR941ND	V6	KDF-48	DIR-823G	v1.0.2B05
KDF-22	TL-WR1043	V2(150910)	KDF-49	TL-WR902AC_US	V1
KDF-23	TL-WR810N	V1	KDF-50	TL-WR1042ND	V1
KDF-24	TL-WR743ND	V1(130109)	KDF-51	TL-WR1041N	V2
KDF-25	Archer-C2	V1	KDF-52	TL-WR841ND	V9
KDF-26	Archer-C20	V1	KDF-53	Archer C20i(EU)	V1_220107
KDF-27	Archer-C50	V1	KDF-54	DIR-846 A1	v1.0.0(A35)

, and the ground truth mappings between firmware images and vulnerabilities are provided in Appendix A 

Table A2. Ground truth of the homologous vulnerability correlation.

Vulnerability ID	Reference Firmware Image ID	Associated Firmware Image IDs
CVE-2023-36356	KDF-23	KDF-32	KDF-29	KDF-11	KDF-50	KDF-20	KDF-49
		KDF-1	KDF-35	KDF-15	KDF-45	KDF-5	KDF-33
		KDF-14	KDF-43	KDF-7	KDF-21	KDF-52	KDF-24
		KDF-34	KDF-41	KDF-13	KDF-51	KDF-17	KDF-46
		KDF-18	KDF-12	KDF-8	KDF-44	KDF-22	KDF-31
		KDF-40	KDF-30	KDF-42	KDF-28
CVE-2023-37080	KDF-17	KDF-32	KDF-23	KDF-29	KDF-11	KDF-50	KDF-20
		KDF-49	KDF-1	KDF-35	KDF-15	KDF-45	KDF-5
		KDF-33	KDF-14	KDF-43	KDF-7	KDF-21	KDF-52
		KDF-24	KDF-34	KDF-41	KDF-13	KDF-51	KDF-46
		KDF-18	KDF-12	KDF-8	KDF-44	KDF-22	KDF-31
		KDF-40	KDF-30	KDF-42
CVE-2023-36358	KDF-18	KDF-32	KDF-23	KDF-29	KDF-11	KDF-50	KDF-20
		KDF-49	KDF-1	KDF-35	KDF-15	KDF-45	KDF-5
		KDF-33	KDF-14	KDF-43	KDF-7	KDF-21	KDF-52
		KDF-24	KDF-34	KDF-41	KDF-13	KDF-51	KDF-17
		KDF-46	KDF-12	KDF-8	KDF-44	KDF-22	KDF-31
		KDF-40	KDF-30	KDF-42
CVE-2023-39745	KDF-31	KDF-32	KDF-23	KDF-11	KDF-29	KDF-50	KDF-20
		KDF-49	KDF-1	KDF-35	KDF-15	KDF-45	KDF-5
		KDF-33	KDF-14	KDF-43	KDF-7	KDF-21	KDF-52
		KDF-24	KDF-34	KDF-41	KDF-13	KDF-51	KDF-17
		KDF-46	KDF-18	KDF-12	KDF-8	KDF-44	KDF-22
		KDF-40	KDF-30	KDF-42
CNVD-2023-48042	KDF-32	KDF-23	KDF-11	KDF-29	KDF-50	KDF-20	KDF-49
		KDF-1	KDF-35	KDF-15	KDF-45	KDF-5	KDF-33
		KDF-14	KDF-43	KDF-7	KDF-21	KDF-52	KDF-24
		KDF-34	KDF-41	KDF-13	KDF-51	KDF-17	KDF-46
		KDF-18	KDF-12	KDF-8	KDF-44	KDF-22	KDF-31
		KDF-40	KDF-30	KDF-42
CVE-2023-33536	KDF-1	KDF-32	KDF-23	KDF-11	KDF-29	KDF-50	KDF-20
		KDF-49	KDF-35	KDF-15	KDF-45	KDF-5	KDF-33
		KDF-14	KDF-43	KDF-7	KDF-21	KDF-52	KDF-24
		KDF-34	KDF-41	KDF-13	KDF-51	KDF-17	KDF-46
		KDF-18	KDF-12	KDF-8	KDF-44	KDF-22	KDF-31
		KDF-40	KDF-30	KDF-42
CVE-2023-36354	KDF-12	KDF-32	KDF-23	KDF-11	KDF-29	KDF-50	KDF-20
		KDF-1	KDF-49	KDF-35	KDF-15	KDF-45	KDF-5
		KDF-33	KDF-14	KDF-43	KDF-7	KDF-21	KDF-24
		KDF-52	KDF-34	KDF-41	KDF-13	KDF-51	KDF-17
		KDF-46	KDF-18	KDF-8	KDF-44	KDF-22	KDF-31
		KDF-40	KDF-30	KDF-42
CVE-2023-37081	KDF-50	KDF-32	KDF-23	KDF-11	KDF-29	KDF-20	KDF-1
		KDF-49	KDF-35	KDF-15	KDF-45	KDF-5	KDF-33
		KDF-14	KDF-43	KDF-7	KDF-21	KDF-24	KDF-52
		KDF-34	KDF-41	KDF-13	KDF-51	KDF-17	KDF-46
		KDF-12	KDF-18	KDF-8	KDF-44	KDF-22	KDF-31
		KDF-40	KDF-30	KDF-42
CVE-2023-36357	KDF-34	KDF-32	KDF-23	KDF-11	KDF-29	KDF-50	KDF-20
		KDF-1	KDF-49	KDF-35	KDF-15	KDF-45	KDF-5
		KDF-33	KDF-14	KDF-43	KDF-7	KDF-21	KDF-24
		KDF-52	KDF-41	KDF-51	KDF-13	KDF-17	KDF-46
		KDF-12	KDF-18	KDF-8	KDF-44	KDF-22	KDF-31
		KDF-40	KDF-30	KDF-42
CVE-2023-37079	KDF-8	KDF-32	KDF-11	KDF-23	KDF-29	KDF-50	KDF-20
		KDF-1	KDF-49	KDF-35	KDF-15	KDF-45	KDF-5
		KDF-33	KDF-14	KDF-43	KDF-7	KDF-24	KDF-52
		KDF-34	KDF-41	KDF-51	KDF-13	KDF-17	KDF-46
		KDF-12	KDF-18	KDF-44	KDF-22	KDF-31	KDF-40
		KDF-30	KDF-42
CVE-2023-37082	KDF-13	KDF-32	KDF-11	KDF-23	KDF-29	KDF-50	KDF-20
		KDF-1	KDF-49	KDF-35	KDF-15	KDF-45	KDF-5
		KDF-33	KDF-14	KDF-43	KDF-7	KDF-21	KDF-24
		KDF-52	KDF-34	KDF-51	KDF-17	KDF-46	KDF-12
		KDF-18	KDF-8	KDF-44	KDF-22	KDF-40	KDF-31
		KDF-30	KDF-42
CVE-2023-37083	KDF-51	KDF-32	KDF-11	KDF-23	KDF-29	KDF-50	KDF-20
		KDF-1	KDF-49	KDF-35	KDF-15	KDF-45	KDF-5
		KDF-33	KDF-14	KDF-43	KDF-7	KDF-21	KDF-24
		KDF-52	KDF-34	KDF-13	KDF-17	KDF-46	KDF-12
		KDF-18	KDF-8	KDF-44	KDF-22	KDF-40	KDF-31
		KDF-30	KDF-42
CVE-2023-33537	KDF-7	KDF-32	KDF-11	KDF-23	KDF-29	KDF-50	KDF-20
		KDF-1	KDF-49	KDF-35	KDF-15	KDF-45	KDF-5
		KDF-33	KDF-14	KDF-43	KDF-21	KDF-24	KDF-52
		KDF-34	KDF-51	KDF-13	KDF-17	KDF-46	KDF-12
		KDF-18	KDF-8	KDF-44	KDF-22	KDF-40	KDF-31
		KDF-30	KDF-42
CVE-2023-36359	KDF-11	KDF-32	KDF-23	KDF-29	KDF-50	KDF-20	KDF-1
		KDF-49	KDF-35	KDF-15	KDF-45	KDF-5	KDF-33
		KDF-14	KDF-43	KDF-21	KDF-52	KDF-34	KDF-13
		KDF-17	KDF-46	KDF-12	KDF-18	KDF-8	KDF-44
		KDF-22	KDF-31	KDF-30	KDF-42
CNVD-2021-81545	KDF-40	KDF-11	KDF-29	KDF-50	KDF-20	KDF-35	KDF-15
		KDF-45	KDF-5	KDF-7	KDF-43	KDF-14	KDF-24
		KDF-52	KDF-41	KDF-51	KDF-17	KDF-46	KDF-12
		KDF-18	KDF-44	KDF-30	KDF-42
CNVD-2021-81533	KDF-52	KDF-11	KDF-29	KDF-50	KDF-20	KDF-35	KDF-15
		KDF-45	KDF-5	KDF-7	KDF-43	KDF-14	KDF-24
		KDF-41	KDF-51	KDF-17	KDF-46	KDF-12	KDF-44
		KDF-40	KDF-30	KDF-42
CVE-2024-9284	KDF-5	KDF-32	KDF-23	KDF-29	KDF-1	KDF-49	KDF-15
		KDF-33	KDF-14	KDF-52	KDF-34	KDF-13	KDF-17
		KDF-12	KDF-18	KDF-8	KDF-22	KDF-31
CVE-2017-13772	KDF-49	KDF-32	KDF-23	KDF-29	KDF-1	KDF-15	KDF-5
		KDF-33	KDF-14	KDF-52	KDF-34	KDF-13	KDF-17
		KDF-12	KDF-18	KDF-8	KDF-22	KDF-31
CVE-2019-6989	KDF-15	KDF-32	KDF-23	KDF-29	KDF-1	KDF-49	KDF-5
		KDF-33	KDF-14	KDF-52	KDF-34	KDF-13	KDF-17
		KDF-12	KDF-18	KDF-8	KDF-22	KDF-31
CNVD-2021-35879	KDF-29	KDF-32	KDF-23	KDF-1	KDF-49	KDF-15	KDF-5
		KDF-33	KDF-14	KDF-52	KDF-34	KDF-13	KDF-17
		KDF-12	KDF-18	KDF-8	KDF-22	KDF-31
CVE-2020-8423	KDF-14	KDF-32	KDF-23	KDF-29	KDF-1	KDF-49	KDF-15
		KDF-5	KDF-33	KDF-52	KDF-34	KDF-13	KDF-17
		KDF-12	KDF-18	KDF-8	KDF-22	KDF-31
CVE-2023-33538	KDF-22	KDF-32	KDF-23	KDF-29	KDF-1	KDF-49	KDF-15
		KDF-5	KDF-33	KDF-14	KDF-52	KDF-34	KDF-13
		KDF-17	KDF-12	KDF-18	KDF-8	KDF-31
CVE-2024-46313	KDF-33	KDF-32	KDF-23	KDF-29	KDF-1	KDF-49	KDF-15
		KDF-5	KDF-14	KDF-52	KDF-34	KDF-13	KDF-17
		KDF-12	KDF-18	KDF-8	KDF-22	KDF-31
CVE-2014-9350	KDF-46	KDF-11	KDF-50	KDF-20	KDF-35	KDF-45	KDF-7
		KDF-43	KDF-24	KDF-41	KDF-51	KDF-44	KDF-40
		KDF-30	KDF-42
CVE-2021-44864	KDF-11	KDF-50	KDF-20	KDF-35	KDF-45	KDF-7	KDF-43
		KDF-24	KDF-41	KDF-51	KDF-46	KDF-44	KDF-40
		KDF-30	KDF-42
CVE-2021-26827	KDF-30	KDF-50	KDF-20	KDF-35	KDF-45	KDF-7	KDF-43
		KDF-24	KDF-41	KDF-51	KDF-46	KDF-40	KDF-42
CVE-2023-39748	KDF-45	KDF-51	KDF-50	KDF-20	KDF-35	KDF-7	KDF-43
		KDF-24	KDF-46	KDF-40	KDF-30	KDF-42
CVE-2021-29302	KDF-26	KDF-36	KDF-53	KDF-38	KDF-10	KDF-25	KDF-37
		KDF-16	KDF-27	KDF-4	KDF-9
CVE-2022-26641	KDF-16	KDF-36	KDF-53	KDF-38	KDF-26	KDF-10	KDF-25
		KDF-37	KDF-27	KDF-4	KDF-9
CVE-2022-25062	KDF-38	KDF-36	KDF-53	KDF-26	KDF-10	KDF-25	KDF-37
		KDF-16	KDF-27	KDF-4	KDF-9
CVE-2022-26640	KDF-37	KDF-36	KDF-53	KDF-38	KDF-26	KDF-10	KDF-25
		KDF-16	KDF-27	KDF-4	KDF-9
CVE-2022-24355	KDF-18	KDF-1	KDF-49	KDF-15	KDF-5	KDF-14	KDF-52
		KDF-17	KDF-12
CVE-2022-26639	KDF-4	KDF-36	KDF-53	KDF-26	KDF-10	KDF-25	KDF-37
		KDF-16	KDF-9
CVE-2022-25064	KDF-36	KDF-26	KDF-10	KDF-25	KDF-37	KDF-16	KDF-4
		KDF-9
CVE-2022-42156	KDF-6	KDF-47	KDF-48	KDF-2	KDF-39	KDF-54
CVE-2021-46314	KDF-54	KDF-47	KDF-48	KDF-6	KDF-39	KDF-2
CVE-2018-16408	KDF-6	KDF-47	KDF-48	KDF-39	KDF-54	KDF-2
CVE-2023-51984	KDF-48	KDF-47	KDF-6	KDF-39	KDF-54	KDF-2
CVE-2024-41622	KDF-47	KDF-6	KDF-39	KDF-54	KDF-2
CVE-2023-33735	KDF-6	KDF-39	KDF-54	KDF-2
CVE-2020-25367	KDF-39	KDF-48	KDF-47	KDF-2
CVE-2023-26613	KDF-48	KDF-47	KDF-39	KDF-2
CVE-2019-15528	KDF-2	KDF-48	KDF-47	KDF-39
CVE-2022-43109	KDF-39	KDF-48	KDF-47	KDF-2
CVE-2018-17880	KDF-47	KDF-48	KDF-39	KDF-2
CVE-2019-13481	KDF-48	KDF-47	KDF-39	KDF-2
CVE-2019-15529	KDF-48	KDF-47	KDF-39	KDF-2
CVE-2019-15530	KDF-47	KDF-48	KDF-39	KDF-2
CVE-2019-7298	KDF-2	KDF-48	KDF-47	KDF-39
CVE-2021-43474	KDF-47	KDF-48	KDF-39	KDF-2
CVE-2018-19986	KDF-39	KDF-48	KDF-47	KDF-2
CVE-2018-19989	KDF-2	KDF-48	KDF-47	KDF-39
CVE-2018-19990	KDF-2	KDF-48	KDF-47	KDF-39
CVE-2020-25368	KDF-39	KDF-48	KDF-47	KDF-2
CVE-2018-17787	KDF-39	KDF-48	KDF-47	KDF-2
CVE-2019-12786	KDF-48	KDF-47	KDF-39	KDF-2
CVE-2019-15526	KDF-2	KDF-48	KDF-47	KDF-39
CVE-2019-13128	KDF-48	KDF-47	KDF-39	KDF-2
CVE-2018-19987	KDF-47	KDF-48	KDF-39	KDF-2
CVE-2019-13482	KDF-39	KDF-48	KDF-47	KDF-2
CVE-2023-36355	KDF-32	KDF-1	KDF-31
CVE-2023-39746	KDF-24	KDF-7	KDF-40
CVE-2018-19988	KDF-48	KDF-39	KDF-2
CVE-2022-44808	KDF-39	KDF-48	KDF-2
CVE-2019-12787	KDF-2	KDF-48	KDF-39
CVE-2019-7297	KDF-2	KDF-47	KDF-39
CVE-2020-25366	KDF-2	KDF-48	KDF-39
CVE-2023-39747	KDF-11	KDF-44
CVE-2019-17510	KDF-54	KDF-6
CVE-2023-43284	KDF-6	KDF-54
CVE-2020-10215	KDF-3	KDF-19
CVE-2020-10216	KDF-19	KDF-3
CVE-2022-25061	KDF-10	KDF-9
CVE-2022-46642	KDF-6	KDF-54

.

FirmVulLinker and LibAM were then used to compute the semantic similarity between each candidate firmware image and the reference firmware. A similarity threshold was applied to determine potential homologous relationships. The predictions were compared against the ground truth to evaluate three core metrics: precision, false-positive rate (FPR), and false-negative rate (FNR).

Table 2. Performance comparison on homologous vulnerability correlation accuracy.

Metric	FirmVulLinker	LibAM
Precision	0.9564	0.7825
False-Negative Rate	0.0215	0.0745
False-Positive Rate	0.0305	0.4379

presents the comparative performance of FirmVulLinker and LibAM. The results show that FirmVulLinker significantly outperforms LibAM across all metrics, particularly in reducing false positives. Further analysis reveals that the multi-dimensional semantic profiling adopted by FirmVulLinker provides greater expressive power in modeling static behavior, interface exposure, and sensitive code paths. This enables FirmVulLinker to capture the deeper semantics behind homologous vulnerability correlation, rather than relying solely on superficial function or instruction-level clone detection.

Beyond accuracy, the five-dimensional similarity scoring mechanism introduced by FirmVulLinker further enables interpretable analysis of homologous vulnerability correlation among firmware images. As shown in Figure 2, we visualize the semantic similarity distribution of representative vulnerability scenarios using radar charts, where each axis corresponds to one of the five semantic dimensions modeled by FirmVulLinker: M1 denotes the Unpacking Signature Sequence Profile; M2, the Filesystem Semantic Profile; M3, the Interface Exposure Profile; M4, the Exposed Binary Symbolic Profile; and M5, the Vulnerability-oriented Call-Chain Profile. In each subplot, the red line represents the average similarity curve across all firmware image pairs that are correlated in the ground truth concerning the given vulnerability, providing a reference for typical semantic alignment. In contrast, the blue line depicts the similarity distribution of a specific candidate firmware image compared to its reference.

In Figure 2a, firmware image KDF-18 exhibits above-average similarity across all five dimensions (M1–M5), with particularly high scores from M1 to M3. This indicates substantial semantic alignment between the target and reference firmware images, suggesting a high likelihood of homologous vulnerability correlation. In Figure 2b, KDF-9 demonstrates significantly lower similarity in M4 but a notably high score in M5, while maintaining near-average similarity in the remaining dimensions. This suggests that KDF-4 and KDF-9 differ in their exposed binary symbolic representations but are highly consistent in their Vulnerability-oriented Call-Chain structures. Considering the overall similarity pattern, KDF-4 and KDF-9 may originate from homologous firmware and potentially exhibit a homologous vulnerability correlation. In Figure 2c,d, the target firmware images consistently show low similarity across all semantic dimensions, indicating considerable divergence from their respective reference firmware images and a low probability of homologous vulnerability correlation. The radar chart visualization provides a clear depiction of multi-dimensional similarity distributions across firmware image pairs and supports interpretable analysis of vulnerability correlation based on semantic profiling.

Figure 3 presents a heatmap illustrating the similarity scores between different firmware images and a baseline firmware image containing a specific vulnerability, evaluated across all five profiling dimensions. As shown in the figure, KDF-1, KDF-32, KDF-33, KDF-34, and KDF-29 all contain this vulnerability and exhibit consistently high similarity scores across the five dimensions accordingly. In contrast, KDF-19, KDF-3, KDF-9, KDF-10, and KDF-38 are not affected by this vulnerability, and their similarity scores are significantly lower across all dimensions. This visualization highlights FirmVulLinker’s ability to distinguish vulnerable firmware from non-vulnerable ones based on multi-dimensional semantic profiling.

These results collectively demonstrate FirmVulLinker’s effectiveness in accurately identifying homologous firmware images within the context of vulnerability propagation. By employing structured and interpretable profiling across five orthogonal semantic dimensions, FirmVulLinker consistently outperforms traditional methods in both precision and robustness. Moreover, its explainable multi-dimensional scoring framework provides actionable insights into the correlation of homologous vulnerabilities, facilitating risk assessment and informing firmware update strategies. This highlights the practical applicability and engineering significance of FirmVulLinker in real-world firmware security scenarios.

5.5. Ablation Study of Semantic Profiling Dimensions

To address RQ3, which investigates the individual contribution of each semantic profiling dimension to the identification of homologous vulnerability correlation, we conduct a component-level ablation study. This study quantitatively evaluates the independent and joint effectiveness of the five profiling dimensions proposed in FirmVulLinker, thereby validating the necessity of each module in semantic modeling and cross-firmware alignment.

This experiment is conducted on the same evaluation dataset used in Section 5.4, encompassing 54 real-world firmware images and 74 verified vulnerabilities, each observed in at least two firmware images. To systematically assess the impact of each profiling dimension, we construct six comparative models. The FullModel incorporates all five profiling dimensions and serves as the most comprehensive configuration. Each of the other five models, Ablated-M1 through Ablated-M5, omits one specific dimension while keeping the others unchanged. The definitions of M1 through M5 are consistent with those described in Section 5.4. To ensure fair comparison, the weights of the remaining dimensions in each ablation model are normalized proportionally to maintain a consistent total weight.

Figure 4 presents the performance of each model across three key metrics: precision, FPR, and FNR. The FullModel achieves the highest performance, with a precision of 0.9564, FPR of 0.0305, and FNR of 0.0215. These results confirm that integrating all five profiling dimensions yields the most accurate detection of homologous vulnerability correlation.

Figure 4a illustrates the precision performance of all models. Notably, Ablated-M1, Ablated-M2, and Ablated-M4 exhibit a substantial drop in precision, highlighting the critical role of unpacking structure, filesystem semantics, and binary symbol context in enhancing alignment accuracy. These dimensions capture high-level firmware organization, resource layout, and symbolic interaction semantics, all of which are essential for distinguishing fine-grained homology. Figure 4b depicts the changes in both false-positive rate and false-negative rate. Ablated-M1, Ablated-M3, and Ablated-M4 exhibit increased FPRs, indicating that unpacking signatures, interface structures, and symbol semantics help to suppress incorrect matches. The absence of these dimensions notably weakens the system’s ability to filter non-homologous firmware images, especially under customized interface or symbol mutations. Conversely, Ablated-M2, Ablated-M3, and Ablated-M5 show an increase in FNRs, suggesting that filesystem layouts, interface parameters, and call-chain paths are indispensable for capturing real vulnerability propagation paths. These dimensions encompass critical reachability, parameter dependency, and behavioral semantics that are essential for identifying actual attack vectors.

An interesting observation is that the performance gap between the FullModel and Ablated-M5 appears relatively small compared with other ablation groups. Upon closer analysis, we found that specific parameter-related semantics encoded in the Vulnerability-oriented Call-Chain Profile (M5) are also partially captured by the sensitive parameter profile (M3). Since parameter features are particularly effective for modeling vulnerability correlation, the presence of M3 compensates for part of the information loss when M5 is removed. Nevertheless, including M5 in the FullModel consistently improves accuracy, demonstrating the benefit of retaining all profiling dimensions and further underscoring the robustness of our design.

Taken together, the results across all three metrics demonstrate the strong complementarity of FirmVulLinker’s five-dimensional semantic profiling framework. From structural unfolding and resource semantics to interface behavior and symbolic execution context, each dimension models a distinct aspect of firmware behavior. The absence of any one dimension leads to measurable degradation in performance, reinforcing both the design rationale and practical robustness of our framework. These findings affirm the effectiveness of our multi-dimensional profiling strategy in modeling homologous vulnerability correlation and provide a solid foundation for large-scale reuse detection and threat propagation analysis.

5.6. Discovery of Previously Undisclosed Vulnerabilities

To address RQ4, this section evaluates the capability of FirmVulLinker to discover previously undisclosed vulnerabilities in real-world settings, with a particular focus on its effectiveness in expanding the scope of known vulnerability impacts and revealing homologous vulnerability correlations across firmware images. Specifically, we selected the 74 verified vulnerabilities from Section 5.4 as known vulnerability sources and examined whether the corresponding vulnerable logic could be identified in other firmware images through correlation analysis. To this end, we curated an evaluation set consisting of 78 firmware images, none of which have been reported to contain any of the 74 known vulnerabilities in the CVE or NVD databases, thereby representing typical “unknown-state” targets for homologous vulnerability correlation analysis. Each firmware image was validated via emulation using our in-house open-source tool, FirmEmuHub [46], ensuring successful boot and interaction for subsequent vulnerability verification.

The experiment proceeds as follows. We use the 74 verified vulnerabilities and their corresponding reference firmware images from Section 5.4 as the known vulnerability sources. FirmVulLinker is then employed to perform pairwise correlation analysis between each target firmware image and all known source images. By computing multi-dimensional global semantic similarity scores, FirmVulLinker automatically determines whether a target firmware image is a potential homologous carrier of a known vulnerability. A similarity score exceeding a predefined threshold triggers further validation, under the hypothesis that the target may reuse vulnerable logic from the reference.

At the candidate identification stage, FirmVulLinker produced 283 potentially correlated firmware pairs. These were further validated using the integrated FirmEmuHub and IoTVulBench [47] toolchain, which automates large-scale firmware emulation and vulnerability verification. Through static configuration, dynamic interaction, and automated exploit testing, we refined the candidate set by eliminating redundant matches and reconstructing exploit paths. To validate the identified vulnerabilities, we constructed dedicated emulation environments for each firmware image using Docker-based containerization provided by FirmEmuHub. For every vulnerability, we implemented or reused PoC scripts that trigger the suspected flaw. During validation, IoTVulBench automatically deployed each firmware in the emulated environment, injected the corresponding PoC payloads, and monitored the firmware’s service behavior. A vulnerability was confirmed if observable state changes occurred in the target, such as abnormal responses, service crashes, or the execution of unauthorized commands. This validation pipeline was fully automated through configuration files, enabling reproducible and scalable verification across all candidate firmware images. By combining FirmEmuHub and IoTVulBench, we ensured both the accuracy and efficiency of confirming vulnerabilities at scale. Ultimately, we confirmed and reproduced 53 exploitable vulnerabilities within the target firmware set, each with verifiable impact and valid triggering conditions. We refer to firmware images identified by FirmVulLinker as containing vulnerable logic similar to known sources, despite lacking prior vulnerability disclosures, as Unknown Anomaly Firmware (UAF). Detailed metadata for these firmware images are provided in

Table 3. Metadata of representative UAF.

UAF ID	Vendor	Device Type	Firmware Version
UAF-1	D-Link	DIR-822 B1	v2.02KRb06
UAF-2	TP-Link	TL-WR802N	V2
UAF-3	TP-Link	Archer-C2	V5
UAF-4	D-Link	DIR846	100A43
UAF-5	D-Link	DIR-823G	v1.01B02
UAF-6	D-Link	DIR-825 B1	v2.02SSb13
UAF-7	TP-Link	TL-WR940N	v3(151102)
UAF-8	TP-Link	TL-WR743ND	v1(110829)
UAF-9	TP-Link	TL-WR940N	v2(140627)

.

Detailed results are summarized in

Table 4. Matched UAF and their associated vulnerabilities identified via FirmVulLinker.

UAF ID	Associated Vulnerabilities
UAF-1	CVE-2020-27600	CVE-2019-17510	CVE-2021-46314	CVE-2021-46315
	CVE-2022-46641	CVE-2022-46642
UAF-2	CVE-2023-36356	CVE-2014-9350	CVE-2021-44864	CVE-2024-9284
	CVE-2023-33536	CVE-2017-13772	CVE-2023-37080	CVE-2023-36354
	CVE-2023-36358	CVE-2023-36357	CVE-2023-37082	CVE-2023-37083
	CVE-2019-6989	CVE-2023-36359	CNVD-2021-35879	CVE-2020-8423
	CVE-2023-39745	CNVD-2023-48042	CVE-2023-37079	CVE-2023-37081
	CVE-2023-33537	CVE-2023-39747	CVE-2023-33538	CVE-2024-46313
UAF-3	CVE-2021-29302	CVE-2022-26641	CVE-2022-25062	CVE-2022-26640
	CVE-2022-25061	CVE-2022-26639	CVE-2022-25064
UAF-4	CVE-2020-27600	CVE-2022-46641	CVE-2019-17510	CVE-2021-46314
	CVE-2021-46315	CVE-2022-46642
UAF-5	CVE-2019-7297	CVE-2019-7298	CVE-2019-15528	CVE-2019-15529
	CVE-2020-25367	CVE-2020-25368	CVE-2021-43474	CVE-2022-43109
	CVE-2019-15530	CVE-2020-25366	CVE-2023-26613
UAF-6	CVE-2020-10215	CVE-2020-10213	CVE-2020-10216	CVE-2020-10214
UAF-7	CVE-2023-36356	CVE-2024-9284	CVE-2023-39745	CNVD-2023-48042
	CVE-2017-13772	CVE-2023-37080	CVE-2023-36354	CVE-2023-37079
	CVE-2023-36358	CVE-2023-36357	CVE-2023-37082	CVE-2023-37083
	CVE-2023-36359	CNVD-2021-35879	CVE-2020-8423	CVE-2023-33538
	CVE-2023-36355	CVE-2023-33536	CVE-2023-37081	CVE-2022-24355
	CVE-2023-33537	CVE-2019-6989	CVE-2024-46313
UAF-8	CVE-2023-36356	CVE-2014-9350	CVE-2021-44864	CVE-2023-39745
	CVE-2023-37080	CVE-2023-36354	CVE-2021-26827	CNVD-2021-81545
	CVE-2023-37081	CVE-2023-36358	CVE-2023-36357	CVE-2023-37082
	CVE-2023-39746	CVE-2023-39748	CNVD-2023-48042	CVE-2023-33536
	CNVD-2021-81533	CVE-2023-37079	CVE-2023-37083	CVE-2023-33537
UAF-9	CVE-2023-36356	CVE-2014-9350	CVE-2021-44864	CVE-2023-39745
	CVE-2023-37080	CVE-2023-36354	CNVD-2021-81545	CNVD-2021-81533
	CVE-2023-36358	CVE-2023-36357	CVE-2023-37082	CVE-2023-37083
	CVE-2023-36359	CNVD-2023-48042	CVE-2023-33536	CVE-2023-33537
	CVE-2023-37079	CVE-2023-37081	CVE-2023-39747

, which presents the matched UAF and their associated vulnerabilities identified via homologous correlation analysis. It is important to note that although these 53 vulnerabilities are documented in existing databases (i.e., N-day vulnerabilities), the specific firmware versions identified in our experiment are not listed in any official disclosures. This finding underscores FirmVulLinker’s capability to uncover undocumented yet affected firmware images, thereby augmenting public vulnerability intelligence. By accurately identifying homologous firmware exhibiting shared propagation chains, FirmVulLinker provides practical support for extending vulnerability coverage and refining the assessed impact scope.

Overall, these findings strongly validate the effectiveness of FirmVulLinker in discovering real-world vulnerabilities under unsupervised conditions. By leveraging semantic profiling and structural similarity analysis, FirmVulLinker captures deep logical correlations across firmware images. Beyond its detection accuracy, FirmVulLinker demonstrates strong potential as an automated tool for expanding the impact boundaries of known vulnerabilities. It facilitates rapid risk identification for security analysts. It empowers vulnerability disclosure platforms, device vendors, and supply chain managers with more accurate and comprehensive impact assessments, thereby advancing firmware security awareness and proactive defense strategies.

6. Discussion and Future Work

Although FirmVulLinker demonstrates promising progress in multi-dimensional semantic modeling and homologous vulnerability correlation analysis across firmware images, and has been empirically validated on real-world firmware datasets, it still faces several limitations and opportunities for further enhancement when applied to larger-scale or more complex deployment scenarios. This section discusses the current capability boundaries and outlines potential future research directions.

Finer-grained Semantic Feature Modeling. The current semantic profiling framework of FirmVulLinker incorporates five major dimensions: unpacking signature sequences, filesystem structure layout, interface exposure profiles, boundary binary symbolic structure, and sensitive parameter call chains. These profiles collectively describe the static structure and behavioral semantics of most generic firmware images. However, finer-grained semantic elements such as control flow graphs (CFGs), data flow graphs (DFGs), system call sequences, and inter-file dependencies are not explicitly modeled. This may limit the system’s semantic resolution capability when dealing with refactored, obfuscated, or structurally evolved firmware. In future work, we plan to further refine static semantic profiling by incorporating representation learning techniques. Specifically, we will explore the use of machine learning and deep embedding models to capture latent relationships across heterogeneous static features, such as CFG fragments, system call contexts, and inter-file dependencies. These methods can provide more expressive semantic embeddings and improve the robustness of similarity computation under code refactoring, obfuscation, and structural variations. Moreover, we recognize that the current framework adopts heuristic parameter settings when integrating different feature dimensions. While this provides a reasonable starting point, future research will investigate data-driven parameter optimization and sensitivity analysis, which can further justify and adaptively balance the contributions of different profiling dimensions. By combining taint-based control dependency modeling, static semantic embeddings, and learning-based similarity metrics, FirmVulLinker will be able to capture fuzzy function boundaries, composite component structures, and implicit vulnerability paths with higher accuracy. These enhancements are expected to substantially improve both the precision and interpretability of homologous vulnerability correlation across diverse firmware images.

Extending Compatibility to Non-Linux Embedded Firmware. FirmVulLinker is currently designed for embedded firmware images running Linux, relying on standardized filesystem layouts and ELF-format binaries for feature extraction. However, in practical industrial contexts, bare-metal architectures, RTOS-based systems, and customized boot logics are prevalent. These systems often adopt fundamentally different program organizations, entry point definitions, and symbol table layouts, which restrict the portability of the current model. Migrating FirmVulLinker to such environments introduces several challenges: the absence of standardized filesystem structures and executable formats complicates consistent feature extraction; the frequent lack of symbol or debugging information in RTOS and bare-metal binaries hinders semantic recovery; and heterogeneous bootstrapping mechanisms, interrupt handling, and peripheral initialization logic introduce significant variability in control and data flow structures. To address these challenges, we plan to design a pluggable abstraction framework targeting non-Linux firmware, integrating techniques such as image structure recognition, heuristic function boundary recovery, and binary context clustering. This extension will enhance FirmVulLinker’s adaptability and robustness across heterogeneous embedded platforms, enabling broader applicability in real-world scenarios.

Managing False Positives and Negatives. Another limitation lies in the potential false positives and negatives introduced by multi-dimensional profiling. For example, structurally similar features across different firmware images may lead to spurious correlations, while incomplete or noisy feature extraction may cause homologous vulnerabilities to be overlooked. These issues stem from the inherent trade-offs between sensitivity and specificity in static semantic modeling. To mitigate such risks, we plan to refine our profiling framework by incorporating adaptive weighting across feature dimensions, introducing contextual constraints to filter out irrelevant matches, and integrating lightweight dynamic validation to cross-check critical cases. These enhancements will improve the balance between precision and recall, thereby strengthening the reliability of FirmVulLinker in large-scale vulnerability correlation tasks.

Structural Modeling of Cross-Firmware Vulnerability Propagation. FirmVulLinker currently focuses on pairwise semantic similarity analysis, which is effective for discovering homologous vulnerability correlations. However, real-world vulnerability propagation often manifests in more complex patterns, such as chained transfers, component-level reuse, and semantic evolution of interfaces. The current model does not explicitly capture causal paths or propagation chains across firmware images. As a future direction, we intend to construct a cross-firmware vulnerability propagation graph by leveraging function slicing, call graph normalization, and path reconstruction techniques. We will further incorporate graph matching algorithms to support path alignment, source inference, and multi-point co-origin recognition, thereby enabling structurally explainable modeling of vulnerability propagation across firmware images.

Enhancing Vulnerability Intelligence and Practical Deployment. FirmVulLinker has demonstrated strong capabilities in identifying homologous vulnerability correlations, offering automated and structured mechanisms for extending the impact scope and bridging version gaps of known vulnerabilities. Moving forward, we plan to develop a comprehensive vulnerability analysis toolchain centered on FirmVulLinker, tailored explicitly for security practitioners. This toolchain will provide end-to-end support for firmware unpacking, feature extraction, similarity analysis, and identification of affected versions, enabling researchers to pinpoint high-risk targets within large-scale firmware collections. Despite these promising results, we acknowledge several limitations that point to directions for future work. First, while our evaluation demonstrates solid accuracy, we have not yet performed systematic measurements of throughput, runtime efficiency, and memory consumption at larger scales. Second, we have not conducted robustness testing under conditions such as symbol stripping, compiler-based obfuscation, or atypical packing. These transformations are increasingly present in real firmware and may degrade the discriminative power of specific profiling dimensions. Exploring their impact on F1, recall, and failure modes will help refine our profiling strategies and improve resilience against adversarial or obfuscated binaries. Additionally, our current evaluation is limited by the scarcity of baseline tools. Many recent approaches in this field have not released source code, and even when code is available, non-trivial adaptation is often required to apply it to our evaluation setting. These constraints restricted the number of baselines we could incorporate in the present study. We view this as an important avenue for future work and plan to extend our evaluation once more baselines become accessible or can be feasibly adapted. To support continuous benchmarking, we will also update the open-source repository of FirmVulLinker with extended results, including both performance and robustness experiments. Ultimately, we aim to integrate the planned toolchain with existing vulnerability disclosure platforms and supply chain risk assessment systems. By enriching vulnerability databases with missing information on affected versions, FirmVulLinker can enhance the completeness and timeliness of vulnerability intelligence. This, in turn, will promote automation in vulnerability lifecycle management and contribute to strengthening the overall security of the firmware ecosystem.

7. Conclusions

In this paper, we propose and implement FirmVulLinker, a multidimensional semantic profiling framework for identifying homologous vulnerability correlations across firmware images. FirmVulLinker models each firmware holistically across five static dimensions, including unpacking signature sequences, filesystem semantics, interface exposure, boundary binary symbols, and sensitive parameter call chains. This design enables robust similarity computation and the reconstruction of vulnerability propagation paths. We evaluated FirmVulLinker on two real-world datasets and validated its effectiveness across multiple tasks. Experimental results demonstrate that it outperforms state-of-the-art approaches in terms of precision, false-positive rate, and coverage. Notably, FirmVulLinker successfully identified and reproduced 53 previously undisclosed N-day vulnerabilities in firmware images exhibiting homologous vulnerability correlations. These findings underscore FirmVulLinker’s capability to extend existing vulnerability intelligence and support scalable analysis of firmware-level vulnerability propagation. By providing a unified and interpretable semantic modeling approach, FirmVulLinker delivers practical and extensible support for large-scale IoT firmware security auditing and homologous vulnerability discovery.