PaperlayerView exact revision on arXiv

Source-linked AI summary

Detecting Logic Vulnerabilities Across the Contract and Device Layers of Blockchain-Enabled IoT With Multi-Agent Heterogeneous Graph Attention

Minfeng Qi, Jialin Li, Tianqing Zhu, Lefeng Zhang, Zhe Sun

arXiv:2609.18344v1cs.CR

TL;DR

Blockchain-enabled IoT security depends on logic in both smart contracts and device firmware, while existing approaches often analyze layers or artifacts separately. This work extends MA-HGAT into a shared role-based framework for multiple detection tasks and gateway–cloud inference. The authors report effectiveness across contract and device layers, while the unseen-vendor evaluation identifies a generalization limitation.

  • Problem

    Contract and firmware logic can jointly violate system invariants, but existing approaches typically analyze these layers separately.

    Source: §I · p. 1, A. System Model · p. 4

  • Method

    MA-HGAT represents contracts, firmware evidence, device fleets, and transaction streams with a shared role-based structure and supports gateway–cloud inference.

    Source: C. Unified Heterogeneous Schema · p. 5, B. Tier 5: Gateway–Cloud Partitioning · p. 8, §VIII · p. 15

  • Results

    The evaluation reports effectiveness across contract and device layers, identifies the role-aligned multi-agent design as the main source of cross-layer transfer, and finds a clear unseen-vendor generalization limitation.

    Source: §VIII · p. 15

  • Takeaways & Limitations

    One framework supports contract auditing, vulnerability-report triage, fleet-level vulnerability linking, and transaction monitoring, with the device-action component running on resource-constrained gateways.

    Source: §VIII · p. 15

    The unseen-vendor evaluation reveals a clear generalization limitation.

    Source: §VIII · p. 15

Abstract

from arXiv · show

Blockchain-enabled Internet of Things (IoT) systems integrate smart contracts with embedded devices to support decentralized device management and access control. Their security therefore depends jointly on the logic of on-chain contracts and off-chain device firmware. Logic flaws in either layer can violate the same system invariants, such as unauthorized access, improper state changes, or unguarded privileged operations. Existing approaches rely on contract analysis, firmware analysis, and graph-based vulnerability detection. However, these methods typically focus on a single layer or artifact and often depend on predefined vulnerability patterns, emulation fidelity, or homogeneous representations that obscure security-relevant component roles. They also lack a unified architecture that supports different security tasks while remaining deployable on resource-constrained gateways. To address these limitations, we extend MA-HGAT into a cross-layer multi-agent heterogeneous graph attention framework that models contracts, firmware artifacts, device fleets, and transaction streams with a unified four-role, nine-relation schema. Role-aligned agents exchange heterogeneous evidence through cross-attention, while graph-, link-, and node-level heads support multiple detection tasks and a role-based gateway--cloud partition enables lightweight edge inference. MA-HGAT thus provides a unified and deployable framework for detecting logic vulnerabilities across the contract and device layers of blockchain-enabled IoT systems.

I. INTRODUCTION

Blockchain-enabled IoT security depends jointly on contract and firmware logic, but existing methods generally analyze the layers separately. The paper proposes a shared role-based framework for cross-layer reasoning and multiple security decisions, with inference divided between gateway and cloud.

I. INTRODUCTION

  • The article extends a contract-only conference version with a system-level formulation, task heads, gateway–cloud partitioning, and device-layer and deployment experiments.The evaluation includes component ablations and an unseen-vendor setting.Source: §I · pp. 1–2
  • A contract flaw or firmware flaw can violate the same system policy, such as by permitting unauthorized registration or device reconfiguration.Both layers jointly enforce system invariants, so logic mistakes on either side can break them.Source: §I · p. 1
  • Existing methods are fragmented across layers and can depend on predefined patterns, faithful emulation, or uniform representations that obscure component roles.They are also not designed around the gateway where contract and device activity meet.Source: §I · p. 1
  • Operators need one security view for contract auditing, vulnerability-report analysis, affected-device linking, and malicious-behavior monitoring.These decisions concern the same policies but are currently handled by separate tools.Source: §I · p. 1
  • Across contract and device layers, components repeatedly perform actions, hold state, guard access, or record observable traces.The paper treats a logic flaw as an incorrect or missing relationship among these roles rather than as a layer-specific code pattern.Source: §I · p. 2, Figure 1 · p. 2
  • The proposed framework represents contracts, firmware evidence, device fleets, and device–contract activity through a shared role-based structure for four security decisions.It places only the device-action processing component on the gateway, leaving broader system context in the cloud and avoiding transmission of raw device requests.Source: §I · p. 2

II. RELATED WORK

Prior research addresses blockchain-IoT, contract, firmware, graph-learning, and edge–cloud security problems through distinct approaches. This work positions its contribution as applying a security-oriented heterogeneous representation across contract and device layers and partitioning inference by observed roles.

A. Security of Blockchain-Enabled IoT

  • Blockchain-IoT security studies often treat contract correctness and device integrity as assumptions, while this work analyzes both as places where logic mistakes can break system policy.Prior work includes access-management designs, surveys, and simulated device–contract transaction logs.Source: A. Security of Blockchain-Enabled IoT · p. 3

B. Smart Contract Vulnerability Detection

  • Contract analyzers use static, dynamic, formal, and language-model methods, but pattern dependence, path or specification limits, and prompt sensitivity constrain their settings.Formal verification also requires substantial specification effort and assumes the specification is sound.Source: B. Smart Contract Vulnerability… · p. 3

C. IoT Firmware and Device Security Analysis

  • Firmware analysis spans static, emulation-based dynamic, and recurring-vulnerability search methods, while this work learns over exposed heterogeneous relations without replacing binary analysis or emulation.Emulation fidelity and crash observability remain obstacles; the paper also partitions its approach between gateways and cloud.Source: C. IoT Firmware and Device Security… · p. 3

D. Graph Neural Networks for Code and Security Analysis

  • Graph models capture program structure, but existing heterogeneous models are described as domain-agnostic and not focused on state-transition semantics or component-specific reasoning.The paper evaluates homogeneous counterparts on the same graphs.Source: D. Graph Neural Networks for Code and… · p. 3

E. Attention, Multi-Agent Reasoning, and Edge–Cloud Inference

  • Prior edge–cloud partitioning targets layer boundaries in homogeneous networks, whereas MA-HGAT exposes a semantic boundary based on the role whose entities a gateway observes.The cited background connects this design to role-specialized agents and intermediate representations crossing the network.Source: E. Attention, Multi-Agent Reasoning,… · p. 4

III. SYSTEM MODEL, THREAT MODEL, AND UNIFIED SCHEMA

The system model treats contract, gateway, and device logic as jointly enforcing system invariants, while the threat model assigns offline analyses to the cloud and online monitoring’s first stage to the gateway. A four-role, nine-relation graph schema instantiates these security roles across four artifact types.

A. System Model

  • Contracts, gateways, and firmware jointly enforce invariants such as registered-device access, authorized configuration changes, and traces for privileged actions.An unchecked contract registration and a firmware handler that omits session validation illustrate distinct logic flaws that can violate those invariants.Source: A. System Model · p. 4

B. Threat Model

  • The adversary can submit contract transactions, send requests to reachable device interfaces, and fully control compromised devices, but cannot break consensus or cryptography, tamper with gateways, or alter the model or its inputs.Tasks A–C run offline in the cloud; task D is online and begins at the gateway.Source: B. Threat Model · p. 4
  • EdgeChainGuard is used only to measure gateway–cloud inference cost on a realistic graph shape, not detection accuracy, because its synthetic attack labels coincide with transaction failure.Its attack subtypes are assigned at random.Source: B. Threat Model · p. 5

C. Unified Heterogeneous Schema

  • Every artifact is represented with four node roles and nine relation types, distinguishing functions, state, modifiers, and events alongside execution, data access, guarding, and observability links.The roles and relations preserve security-relevant distinctions such as whether an operation is guarded.Source: C. Unified Heterogeneous Schema · p. 5
  • The schema maps proof-of-concept requests, device fleets, and transaction streams to role-specific entities, with logic flaws represented as wrong or missing relations between roles.Examples include a configuration handler missing a guard, an image not yet linked to a relevant CVE, and an identity’s transaction burst differing from its history.Source: C. Unified Heterogeneous Schema · p. 5

D. Learning Objectives

The learning objectives attach graph classification, link prediction, and node classification to one role-specific encoder. The tasks use different prediction units while depending jointly on component attributes and typed relations.

D. Learning Objectives

  • Tasks A and B use graph classification to label contracts or proof-of-concept traces, including binary contract vulnerability and multi-label IoTVulBench weakness types.IoTVulBench labels include command injection, buffer overflow, denial of service, and remote code execution.Source: D. Learning Objectives · p. 5
  • Task C uses link prediction to score image–CVE pairs and rank candidate firmware images for each disclosed weakness.The ranking retrieves registered images that share the weakness.Source: D. Learning Objectives · p. 5
  • Task D uses node classification to label each transaction function node in a stream.The label is produced from that node’s embedding.Source: D. Learning Objectives · p. 5
  • All four decisions depend jointly on component attributes and typed relations connecting state, guards, and observable traces.The encoder keeps the four roles as streams, exchanges evidence through cross-attention, fuses them, and attaches task heads.Source: D. Learning Objectives · p. 5, Figure 2 · p. 6

IV. MA-HGAT ARCHITECTURE

MA-HGAT encodes heterogeneous graph components through role-specific projections and relation-aware attention. Its encoder retains typed information while aggregating context across the nine relations.

IV. MA-HGAT ARCHITECTURE

  • The encoder combines role-specific feature projection, two heterogeneous graph-attention layers, state-centered KVQ attention, four role-aligned agents, and gated cross-type fusion.Task heads attach to the encoder output; the gated fusion, link scorer, and strictly per-graph attention and fusion computations are additions in this version.Source: §IV · p. 6

A. Feature Projection Layer

  • Each node type uses its own projection into a common hidden dimension, preserving type-level inductive biases and accommodating distinct device and gateway feature domains.Firmware byte profiles, HTTP-parameter descriptors, and vendor indicators enter through their respective type-specific projections.Source: A. Feature Projection Layer · p. 6

B. Heterogeneous Graph Attention Layers

  • Two stacked heterogeneous attention layers use relation-specific parameters and multi-head attention, retaining one- and two-hop context while weighting each of nine relations differently.For example, a modifies edge from an unauthenticated handler can receive different weight from a depends edge that only reads a parameter.Source: B. Heterogeneous Graph Attention Layers · p. 6

C. State Attention Module (Key–Value–Query)

MA-HGAT applies attention to state-node representations to emphasize potentially important state transitions. Four role-aligned agents then exchange graph-level context and selectively incorporate other roles’ perspectives.

C. State Attention Module (Key–Value–Query)

  • State-centered KVQ attention emphasizes state transitions associated with inconsistent privileged-variable updates, invariant violations, or improper sequencing of persistent operations.Queries search for transition points, keys encode candidate points, and values carry state-entity context; learned positional encoding follows declaration or request-parameter order.Source: C. State Attention Module… · p. 6

D. Multi-Agent Decision Module

  • Four agents aligned with functions, states, modifiers, and events refine their own node embeddings and exchange information through cross-attention over per-graph role summaries.Each role summary is the mean over that role’s nodes in the graph.Source: D. Multi-Agent Decision Module · p. 7
  • A learned gate controls how much exchanged context each agent’s nodes absorb, supporting complementary views such as anomalous calls, unguarded writes, and missing audit traces.The design aims to avoid collapsing all evidence into one homogeneous embedding.Source: D. Multi-Agent Decision Module · p. 7

E. Gated Cross-Type Fusion Layer

Gated fusion injects cross-type context into node embeddings without overwriting them. The resulting representations support graph-, link-, and node-level tasks, with task-specific losses and training procedures.

E. Gated Cross-Type Fusion Layer

  • Gated cross-type fusion injects global context into each corresponding node type without overwriting node-specific embeddings, supporting node- and link-level heads.This replaces the conference version’s plain concatenation and projection.Source: E. Gated Cross-Type Fusion Layer · p. 7

F. Task Heads

  • Task heads support graph classification by learned gated pooling across node types, link prediction between firmware images and CVEs, and node classification of function nodes.Link inference ranks candidate images for each CVE; training uses positive links and uniformly sampled negative images.Source: F. Task Heads · p. 7

G. Loss Function and Training

  • The binary contract task combines binary cross-entropy and focal loss to emphasize rare positives, while IoT typing, link prediction, and node classification use task-specific cross-entropy losses.Models use AdamW, with dropout and either early stopping or fixed epoch budgets; segmented masks make batched-graph computations equivalent to per-graph processing up to 2 × 10^-7 rounding.Source: G. Loss Function and Training · p. 7

H. Contract Graph Construction

The workflow converts contract, device, and transaction artifacts into heterogeneous graphs for detection and triage. A role-based gateway–cloud split moves part of stream monitoring to gateways while retaining cloud processing and stating limits on what the boundary protects.

H. Contract Graph Construction

  • Contract graphs derive function, state-variable, modifier, and event nodes and their attributes from Solidity syntax and control flow, with edges representing calls, state access, constraints, returns, invocations, and event effects.The graph construction uses compiler output, invocation sites, state reads and writes, modifier control transfers, and event emissions and indexed parameters.Source: H. Contract Graph Construction · p. 7

V. DETECTION WORKFLOW AND GATEWAY–CLOUD DEPLOYMENT

  • The five-tier workflow normalizes artifacts, constructs heterogeneous graphs, runs parallel detection engines, and triages outputs into analyst-facing results; gateway deployment is its new fifth tier.Device-layer experiments evaluate MA-HGAT independently and use the rule-based detector as a baseline rather than combining engines.Source: §V · p. 7, A. Tiers 1–4: Ingestion, Graph… · p. 8

A. Tiers 1–4: Ingestion, Graph Construction, Detection, and Triage

  • Ingestion normalizes contracts, PoC traces, firmware images, and transaction logs before graph construction, parallel detection, and dataset-aware triage.Triage produces vulnerability-type probabilities, ranked firmware-image candidates per CVE, and transaction alerts tied to devices and contracts.Source: A. Tiers 1–4: Ingestion, Graph… · p. 8

B. Tier 5: Gateway–Cloud Partitioning

  • Gateways compute the function-role projection and calls attention over each device’s transaction chain, then upload event embeddings; the cloud completes the remaining roles, relations, layers, attention, fusion, and task head.The role-based boundary keeps raw request features on the gateway and sends fixed-size embeddings upstream; gateway work runs in parallel without coordination.Source: B. Tier 5: Gateway–Cloud Partitioning · p. 8

C. What the Split Protects and What It Does Not

  • The split does not prevent a compromised device from shaping its transaction chain, and embeddings are not a privacy guarantee; the threat model assumes gateways are untampered.A compromised gateway can upload arbitrary embeddings into the shared graph, and the boundary does not bound their influence; calibrated noise or per-gateway controls would add mechanisms not measured here.Source: C. What the Split Protects and What It… · pp. 8–9

D. Device- and Gateway-Layer Graph Constructions

The section constructs graphs for device vulnerability reports, firmware fleets, and device–contract transactions, then reports contract-layer benchmark results. The reported contract evaluation uses DeFi datasets rather than IoT-specific contracts.

D. Device- and Gateway-Layer Graph Constructions

  • IoTVulBench vulnerability reports become request graphs linking handlers, parameters, authentication gates, and expected service events; advisory text supplies labels while payloads supply features.The advisory CVSS score is not used as a feature.Source: D. Device- and Gateway-Layer Graph… · p. 9
  • FirmVulLinker represents firmware images, CVEs, vendors, and device families in a fleet graph, while EdgeChainGuard represents transactions, contracts, devices, and time windows.The EdgeChainGuard graph is used as a deployment workload.Source: D. Device- and Gateway-Layer Graph… · p. 9

VI. CONTRACT-LAYER RESULTS; A. Setup

  • The contract-layer evaluation uses DeFiHack and Web3Bugs because no labeled corpus of IoT-specific contracts exists; the evaluated defects include access-control, state-update-ordering, and arithmetic logic.DeFiHack contains 663 annotated contracts; the evaluation uses a 72-project Web3Bugs subset and a 70/15/15 train-validation-test split.Source: §VI · p. 9, A. Setup · p. 9

B. Main Results and Baseline Comparison

  • 87.04% accuracy, 86.55% precision, 83.51% recall, and 85.35% F1 on DeFiHack; Web3Bugs records 87.45% accuracy, 88.97% precision, 85.54% recall, and 88.42% F1.The framework also reports consistently higher recall and F1 than symbolic and fuzzing tools, and a 4.08-point F1 improvement over the stronger learning-based baseline.Source: B. Main Results and Baseline Comparison · p. 10, Table IV · p. 10

C. Comparison with LLM-Based Detectors

On contract datasets, MA-HGAT outperforms the compared LLM-based detectors, while component ablations show accuracy drops when graph and fusion components are removed. The device-layer evaluation uses separate public datasets and treats EdgeChainGuard as a deployment workload, not a detection benchmark.

C. Comparison with LLM-Based Detectors

  • 87.04% accuracy on DeFiHack exceeded Smart-LLaMA-DPO (82.35%), GPTScan (79.68%), VulnHunt-GPT (76.42%), DeepSeek-R1 (85.23%), and GPT-4 (80.36%).Five-fold mean accuracies were 87.04% (±0.42) on DeFiHack and 87.45% (±0.89) on Web3Bugs; bootstrap intervals supported differences to LLM baselines.Source: C. Comparison with LLM-Based Detectors · p. 10

D. Component Integration and Ablation

A. Datasets, Tasks, and Protocol

  • The evaluation uses four datasets because no public dataset couples contracts, firmware, and transaction streams from one blockchain-enabled IoT system.Each dataset is described as the largest public one found for its layer.Source: A. Datasets, Tasks, and Protocol · pp. 10–11
  • IoTVulBench task B uses 95 CVEs with advisory-derived multi-label targets and payload-only graphs; FirmVulLinker task C tests held-out firmware-to-CVE links across random splits and seeds.The IoTVulBench labels cover command injection, buffer overflow, denial of service, and remote code execution; the linking evaluation reports ranking and AUC measures.Source: A. Datasets, Tasks, and Protocol · p. 11
  • EdgeChainGuard’s 500-transaction graph measures gateway–cloud deployment cost, not detection accuracy; its generated binary attack label coincides with transaction failure.Detectors stay within a few points of the 53% majority rate, so the workload is not reported as a detection result.Source: A. Datasets, Tasks, and Protocol · p. 11
  • Graph baselines receive the same graphs as MA-HGAT, while tabular and rule baselines use payload statistics; task B and C comparisons use paired statistical tests.The significance criteria combine bootstrap intervals with a Wilcoxon test for rank-based linking comparisons.Source: A. Datasets, Tasks, and Protocol · p. 11

B. RQ1, Task B: Vulnerability-Report Triage on IoTVulBench

On IoTVulBench, MA-HGAT outperforms the rule-based detector but is not significantly better than most learned baselines. On FirmVulLinker, graph learning beats non-graph heuristics, while homogeneous GraphSAGE leads MA-HGAT.

B. RQ1, Task B: Vulnerability-Report Triage on IoTVulBench

  • MA-HGAT reaches 81.6% sample accuracy, 78.1% macro-F1, and 55.8% exact match on IoTVulBench, clearly beating the rule-based detector.The rule-based detector has 89.8% recall at 57.5% precision and labels only 9.5% of CVEs completely correctly.Source: B. RQ1, Task B: Vulnerability-Report… · pp. 11–12, Table VI · p. 12
  • MA-HGAT has the highest macro-F1 among graph models and ties GraphSAGE on exact match, but most learned-baseline differences are not significant.It beats homogeneous GAT on exact match in a paired test; random forest is strongest for buffer overflow, while MA-HGAT variants lead on remote code execution.Source: B. RQ1, Task B: Vulnerability-Report… · p. 12, Table VI · p. 12
  • On the secondary severity target, learned models reach 71.6–75.8% accuracy and 72.3–78.9% F1, but fold variation exceeds pairwise differences.The payload-only majority rate is 50.5%.Source: B. RQ1, Task B: Vulnerability-Report… · p. 12

C. RQ1, Task C: Fleet Linking on FirmVulLinker

  • MA-HGAT reaches 0.586 MRR and 91.6% Hits@10 on FirmVulLinker, significantly exceeding raw profile similarity and the vendor/family rule on per-CVE MRR.The random forest falls between MA-HGAT and the heuristics, with no significant difference from MA-HGAT.Source: C. RQ1, Task C: Fleet Linking on… · p. 12
  • Homogeneous GraphSAGE is best on every FirmVulLinker metric, reaching 0.628 MRR, 96.5% Hits@10, and 0.976 AUC.The authors attribute the graph models’ advantage over heuristics to graph structure that propagates CVE membership across related images.Source: C. RQ1, Task C: Fleet Linking on… · p. 12

D. RQ2: Ablation Across Tasks

Ablations identify a small multi-agent benefit across device tasks, while fusion and state attention help inconsistently. Vendor holdout exposes weak transfer; gateway–cloud inference has modest latency and payload overhead, but its tested workload is near chance.

D. RQ2: Ablation Across Tasks

  • Removing the multi-agent module lowers IoTVulBench exact match from 55.8% to 52.6% and FirmVulLinker MRR from 0.586 to 0.574.On FirmVulLinker, Hits@3 also falls from 65.2% to 62.8%; the effect is small and its bootstrap interval includes zero.Source: D. RQ2: Ablation Across Tasks · pp. 12–13, Figure 6 · p. 13, Table VII · p. 13
  • Removing cross-type fusion is neutral or slightly beneficial: IoTVulBench changes are nonsignificant, and FirmVulLinker MRR rises from 0.586 to 0.602 nonsignificantly.The authors note that graph-level context is identical for every pair in the single fleet graph.Source: D. RQ2: Ablation Across Tasks · p. 13
  • State attention helps on IoTVulBench parameter graphs, where removing KVQ costs 0.4 macro-F1 points and 4.6 command-injection F1 points, but slightly hurts FirmVulLinker.The fleet task represents each CVE state with a single year attribute; the authors conclude typed heterogeneity pays when informative roles and sufficiently large graphs are present.Source: D. RQ2: Ablation Across Tasks · p. 13

E. RQ3: Generalization to an Unseen Vendor

  • Neither task transfers across vendors: MA-HGAT IoTVulBench exact match falls from 55.8% to 21.1%, and learned models lose 19–25 macro-F1 points.Fleet-linking holdout results also weaken or favor a vendor metadata shortcut, leading the authors to recommend retraining rather than transfer outside the training vendor population.Source: E. RQ3: Generalization to an Unseen… · p. 14

F. RQ4, Task D: Gateway–Cloud Deployment

  • The gateway Function agent uses 5,120 parameters, 20.5 KB of weights, and at most 1.04 MB of activations for a 500-event window.The paper states that this footprint fits gateway-class devices that relay device transactions.Source: F. RQ4, Task D: Gateway–Cloud Deployment · p. 14
  • Split inference takes 31.66 ms end to end versus 31.22 ms cloud-only, within 1.5%, with 1.2–1.7 ms gateway time across 1–64 gateways.Timing used a general-purpose CPU pinned to one thread, so the authors say ratios, not absolute times, transfer to gateway hardware.Source: F. RQ4, Task D: Gateway–Cloud Deployment · p. 14, Figure 7 · p. 15
  • The gateway sends a 256-byte embedding instead of raw requests averaging 2,100 B, an 8.2× average and 184× worst-case reduction.The embedding is larger than a pre-extracted 40-byte feature vector; the stated benefit is avoiding a domain-specific gateway feature extractor while keeping request contents local.Source: F. RQ4, Task D: Gateway–Cloud Deployment · pp. 14–15, Figure 7 · p. 15
  • The split and cloud-only models have similar accuracy, but both are near chance on this workload’s synthetic labels, making the result a parity check rather than a detection result.Split training reaches 56.5% accuracy and 55.8% macro-F1; cloud-only training reaches 57.5% and 57.0%, respectively.Source: F. RQ4, Task D: Gateway–Cloud Deployment · pp. 14–15

VIII. CONCLUSION

The conclusion presents MA-HGAT as a unified framework for security tasks spanning contracts and device layers, with a gateway–cloud option for device actions. It reports effectiveness across both layers while identifying unseen-vendor generalization as a limitation.

VIII. CONCLUSION

  • MA-HGAT uses one role-based structure to represent contracts, firmware evidence, device fleets, and device–contract transactions across four security tasks.The supported tasks are contract auditing, vulnerability-report triage, fleet-level vulnerability linking, and transaction monitoring.Source: §VIII · p. 15
  • The evaluation identifies role-aligned multi-agent design as the main source of cross-layer transfer and reports that gateway–cloud partitioning reduces local computation while avoiding raw-request transmission with little latency impact.The conclusion also notes a clear generalization limitation under unseen-vendor evaluation.Source: §VIII · p. 15
  • Future work will focus on richer firmware-derived representations, broader labeled datasets, and end-to-end evaluation on real deployments.Source: §VIII · p. 15

Related papers

Loading 2609.18344v1…