Lessons from the Hardware Hacking Competitions: Verification Techniques, Findings, and Insights

1

Lessons from the Hardware Hacking Competitions: Verification Techniques, Findings, and Insights

arXiv:2608.22202v1 [cs.CR] 23 Aug 2026

Sudipta Paria∗ , Aritra Dasgupta∗ , Raghul Saravanan† , Jayanth Thangellamudi† , Sai Manoj P D† , and Swarup Bhunia∗ ∗ Department of Electrical and Computer Engineering, University of Florida, Gainesville, FL, USA † Department of Electrical and Computer Engineering, George Mason University, Fairfax, VA, USA {sudiptaparia,aritradasgupta}@ufl.edu, {rsaravan,jthangel,spudukot}@gmu.edu, swarup@ece.ufl.edu

Abstract—Hardware hacking competitions have emerged as practical platforms for evaluating security weaknesses in complex System-on-Chip (SoC) designs while promoting security-aware verification and tool development. This paper presents a systematic study of SoC security verification through open-box hardware hacking competitions, focusing on practical vulnerability analysis strategies, observed findings, and lessons for securityaware verification. We present a multi-strategy vulnerability analysis methodology, combining simulation-based verification, formal verification, lint analysis, Large Language Model (LLM)assisted bug detection, and coverage-guided hybrid fuzzing. Representative vulnerability findings are analyzed to illustrate how different techniques expose complementary classes of security flaws, and we derive practical lessons for pre-silicon security verification. Finally, we discuss how competition benchmarks can support the reproducible evaluation of emerging hardware security techniques and guide future security-aware EDA research. Index Terms—Hardware Security, Capture The Flag, Systemon-Chip Security, RTL, Security Verification, Hack@DAC, Hack@DATE, Hack@CHES, Vulnerability Detection, CWE.

I. I NTRODUCTION The security of electronic systems fundamentally depends on the security guarantees provided by their underlying hardware stack. Traditionally, system security has relied on the assumption that the underlying hardware behaves correctly and acts as an immutable root of trust, focusing defensive efforts almost exclusively on software vulnerabilities. However, recent microarchitectural and physical exploits such as Meltdown, Spectre, and power/fault injection attacks have demonstrated that hardware design flaws can completely undermine software-level isolation mechanisms [1], [2]. Additionally, access control violations, inadequate privilege checking, incorrect key management, improper debug authentication, etc. may affect the security of the entire system. Vulnerabilities embedded within hardware implementation, either at the register transfer level (RTL) or gate-level netlist, cannot be easily patched post-silicon and remain exploitable after fabrication. Unlike software defects, such hardware flaws may require complex workarounds, firmware restrictions, or hardware redesign [2]. Consequently, the semiconductor industry is aggressively pursuing a shift-left strategy, which aims to identify and remediate hardware security weaknesses early in the pre-silicon RTL design phase. Despite the critical need for pre-silicon assurance, traditional electronic design automation (EDA) environments lack robust, security-aware verification flows. Standard functional verification pipelines are optimized

to validate whether a design performs its intended architectural specifications, but they rarely verify whether the design permits unintended, malicious behaviors. Manual RTL review, simulation-based verification, formal verification, static analysis, information-flow tracking, and hardware fuzzing have been proposed as complementary methodologies for detecting design defects and potential security vulnerabilities during the pre-silicon verification phase. However, the efficacy of the current verification methodologies depends on the generation of relevant security properties or assertions, test vectors, or automated tool flows to identify subtle corner-case errors, especially in complex or large-scale designs. Hardware hacking competitions provide a practical setting for addressing security verification challenges, allowing participants to analyze vulnerable designs under a defined threat model and within a limited period. This is effective for detecting previously unknown bugs and identifying specialized verification approaches because it exposes hardware designs to diverse adversarial strategies, revealing vulnerabilities that may not surface under traditional verification methodologies. The hackthesilicon initiative [3], including Hack@DAC, Hack@CHES, and Hack@DATE, co-located with highly regarded academic conferences, was established as open-box hardware hacking competitions. These competitions provide academic and industrial participants with a realistic, open-source SoC benchmark containing deliberately inserted CVE/CWE-inspired vulnerabilities. Unlike traditional software Capture the Flag (CTF) events or physical hardware hacking competitions that treat the target as a closed box, these hackathons provide participants with full visibility into a buggy SoC RTL design, its specification, and its intended threat model. Participants are allowed to utilize manual code reviews, formal property verification, dynamic simulation, and emerging automated tools to identify weaknesses, determine root causes, develop triggers or exploits, and evaluate the security impact. The open-box model supports early analysis of security weaknesses and promotes the detection of vulnerabilities during the design stage. The three major goals are identified as: (1) improving awareness of hardware weaknesses, (2) supporting security-aware design automation, and (3) shifting vulnerability detection toward the RTL design phase [4]. Existing studies [5]–[8] have discussed the organization of hardware security competitions, the construction of challenge designs, and individual methods developed for evaluating

2

respective benchmarks. However, they are generally limited to particular methodologies or threat models and provide limited guidance on systematically analyzing large SoCs, assessing candidate vulnerabilities, and validating identified bugs. The goal of this work is to formalize systematic methodologies for identifying subtle pre-silicon vulnerabilities, discuss corresponding mitigation strategies, and summarize practical lessons learned. By connecting adversarial analysis with hardware verification practices, this paper highlights how open-box competitions can support the development and evaluation of automated security-verification techniques for stronger hardware assurance. The main contributions of this paper include: We present a practical workflow for analyzing vulnerable SoCs from hardware hacking competitions, covering environment setup, threat modeling, vulnerability discovery and validation, exploit development, and bug analysis. • We present representative security vulnerabilities identified across multiple IPs, including their location, security weaknesses, validation methods, and observed impact. • We summarize technical lessons on verification-method selection, attack-surface prioritization, vulnerability validation, and effective use of complementary securityanalysis techniques. • We discuss the broader role of hardware hacking competitions in security education, benchmark development, tool evaluation, and hardware security research.

•

The remainder of this paper is organized as follows. Section II provides background on SoC security assurance and the evolution of hardware-security competitions. Section III presents different security analysis methodologies, including simulation, formal verification, lint analysis, LLM-assisted vulnerability analysis, fuzzing, along with the identified bug classes and distribution. Section IV summarizes the key lessons learned from the competitions, while Section V discusses the broader community impact, open challenges, and future research directions. Section VI concludes the paper. II. BACKGROUND A. Security Assurance for SoCs Modern SoC designs integrate a complex mix of third-party IP blocks and in-house cores connected via shared on-chip fabrics. This design paradigm introduces significant security verification challenges. If a single IP block contains an access control flaw or a hidden hardware Trojan, the security boundary of the entire system can be compromised. Hence, security verification holds utmost importance in modern IC design flow. SoC security also depends on the correct implementation of system-wide protection mechanisms. These mechanisms include secure boot, hardware root of trust, debug authentication, memory protection, key management, lifecycle control, secure data erasure, and error or alert handling. Such features usually involve several hardware and firmware components. A local implementation error can therefore create a system-level vulnerability. Conventional functional verification is necessary but not sufficient for establishing security. Functional verification primarily evaluates specified design behavior, whereas security

verification additionally considers adversarial inputs, privilege violations, invalid states, and cross-component interactions. B. Evolution of Hardware Security Competitions Hardware-security competitions provide a controlled setting for studying vulnerabilities in processors, system-onchip (SoC) designs, firmware, and physical devices. These events combine security analysis with hands-on design and verification tasks. Depending on the competition, participants may analyze a fabricated device, inspect RTL source code, develop an exploit, or propose a mitigation. 1) Software CTFs vs. Hardware CTFs: Capture-the-flag competitions are widely used in software and system security [9], [10]. Participants solve security challenges and obtain a flag or other proof that the challenge has been completed. Common tasks include software exploitation, reverse engineering, cryptography, web security, and digital forensics. Hardware security competitions [3], [11]–[13] use a related model but often require different forms of evidence. A hardware weakness may not produce a simple textual flag. Participants may instead need to provide: the affected RTL module or hardware component; the security property that is violated; the sequence required to trigger the weakness; simulation, formal, or physical evidence; the resulting security impact; and a proposed mitigation. Therefore, some hardware hacking events are closer to structured vulnerability-discovery exercises than conventional flag-based CTFs. The result is usually a technical report, exploit, waveform, counterexample, or proof-of-concept test. Hardware competitions also require additional hardware-specific skills, including experience in RTL design, computer architecture, firmware, simulation, formal verification, FPGA prototyping, physical attacks, and security analysis. Designers can explain the intended hardware behavior, verification engineers can construct test cases and properties, and security researchers can identify adversarial conditions that may not be considered during normal functional verification. 2) Closed-Box vs. Open-Box Hardware CTFs: Many hardware security competitions follow a closed-box model. Participants receive a physical device or development board but have little or no access to its internal implementation. They interact with the target through exposed ports, firmware, communication interfaces, or physical measurements. Typical methods include protocol analysis, fault injection, side-channel analysis, signal probing, firmware extraction, and hardware reverse engineering. Closed-box competitions are useful for studying attacks against deployed hardware. They represent the view of an external attacker who has physical or logical access to a device. However, they provide limited support for studying the original RTL root cause. Participants may demonstrate that a device is vulnerable without being able to identify the exact design error that caused the weakness. Hack@DAC was introduced as an open-box model in 2018. Participants received a vulnerable SoC at the RTL level together with supporting specifications and design artifacts. The task was to inspect the implementation and use simulation, formal verification, static analysis, emulation, or manual review to identify potential bugs. The main objective was not only to

3

TABLE I C OMPARISON BETWEEN CLOSED VS . OPEN - BOX HARDWARE CTF S Characteristic Primary target Internal visibility Common interfaces Main techniques Typical attacker view Main evidence Primary lifecycle stage Main outcome

Closed-box competition Fabricated chip or physical board Limited or unavailable Debug ports, communication links, firmware, physical signals Probing, fault injection, side-channel analysis, reverse engineering External or physical attacker Device output, extracted data, fault response, side-channel trace Post-silicon Demonstrated attack against a device

Open-box competition RTL implementation of a processor or SoC Design hierarchy and RTL are available RTL modules, registers, buses, firmware, specifications Simulation, formal verification, static analysis, emulation, manual review Design-time adversary / security analyst Waveform, assertion failure, formal counterexample, exploit test Pre-silicon Root-cause analysis and design-level mitigation

TABLE II C OMPARISON OF OPEN - BOX HARDWARE SECURITY COMPETITIONS Competition

Target and access model

Participant task

CSAW Logic Locking Conquest (LLC)

Locked or redacted RTL and gate-level designs

Recover keys or functionality and evaluate protection methods

CSAW AI Hardware Attack Challenge

Open-source RTL designs with required AI-assisted modification

Insert and exploit hardware Trojans or security weaknesses

HeLLO: CTF

Logic-locked or obfuscated hardware IP provided for independent evaluation

Break the protection, recover functionality or keys, and report security weaknesses

Downloadable white-box AES or ECDSA implementations containing embedded secret keys Open-box RTL SoC with specifications, firmware, and security objectives

Develop implementations resistant to key extraction or attack submitted implementations to recover their keys Find vulnerabilities, construct exploits, assess impact, and propose mitigations

WhibOx Contest

HackTheSilicon @(DAC, DATE, CHES)

observe a failure but also to locate the root cause, determine its security impact, and propose a design-level correction. The organizers described this as a designer-centered approach to hardware hacking. These two models are complementary. Closed-box competitions examine the security of implemented systems under realistic physical constraints. Open-box competitions examine whether security weaknesses can be detected and corrected before fabrication. Therefore, the exploration of hardware security benefits from both pre-silicon and post-silicon analysis. Table I summarizes the key differences between closed-box and open-box hardware security competitions in terms of target access, analysis techniques, attacker perspective, validation evidence, and other related features. • Hackthesilicon Initiative: Hack@DAC was introduced in 2018 as an open-box hardware-security competition. Following the first Hack@DAC event, the competition continued through later Design Automation Conference (DAC) editions. The HackTheSilicon event also records expansions to HACK@SEC, HACK@CHES, and HACK@DATE. HACK@SEC events were organized from 2020 to 2022, HACK@CHES events were held in 2021 and 2025, and HACK@DATE was introduced in 2025 [3]. C. Comparing popular Hardware Security Competitions Community-driven hardware-security competitions provide a common platform for evaluating attacks, defenses, and analysis tools under shared assumptions. As summarized in Table II, these competitions differ mainly in their target abstraction and security objectives. The CSAW Logic Locking Conquest [7], [8] and HeLLO: CTF [6] focus on the independent evaluation of Logic Locking, obfuscation and redaction techniques through key recovery, functional reconstruction, and

Common techniques SAT attacks, oracle-less attacks, structural analysis, machine learning LLM-based code modification, simulation, synthesis, verification-tool evasion Logic-locking attacks, structural analysis, functional recovery, key recovery, and obfuscation analysis Program analysis, reverse engineering, dynamic analysis, cryptanalysis, implementation-specific attacks RTL review, simulation, formal verification, static analysis, fuzzing, custom automation

Primary focus Hardware IP protection benchmarking Security risks of AI-assisted hardware design Independent evaluation of logic locking and hardware obfuscation Public developer-vs-attacker competition organized as a challenge Pre-silicon SoC security and security-aware EDA

structural attacks. The WhibOx Contest [11] applies a similar open-box model to cryptographic implementations, where attackers receive full access to protected AES or ECDSA implementations and attempt to recover embedded keys. The CSAW AI Hardware Attack Challenge [13] studies the security risks introduced by AI-assisted hardware design by requiring participants to insert and exploit hardware Trojans or design weaknesses. In contrast, HackTheSilicon competitions [3], including Hack@DAC, Hack@DATE, and Hack@CHES, use complete RTL-based SoCs and cover a broader range of security flaws, such as access-control violations, privilegechecking errors, and firmware–hardware interaction bugs. Together, these efforts support independent validation, expose weaknesses in existing evaluation methods, and promote more reproducible hardware-security research. D. Role in Research, Training, and Tool Development Hardware-security competitions serve three main purposes. First, they provide practical training for participants to learn realistic SoC architectures, security requirements, RTL implementations, verification environments, and attack scenarios. This hands-on setting allows participants to develop practical skills in RTL analysis, simulation, formal verification, security-property development, exploit construction, and vulnerability reporting. Second, the competition artifacts provide evaluation benchmarks for research. Rather than evaluating a new technique only on small synthetic circuits or manually created bugs, researchers can use competition designs containing known security weaknesses and realistic SoC interactions. These benchmarks have supported the evaluation of diverse approaches, including information-flow tracking [14], [15], CWE-guided RTL analysis [16], [17], assertion-based verification, LLM-assisted vulnerability detection [18]–[23],

4

TABLE III OVERVIEW OF THE SECURITY- ANALYSIS STRATEGIES Strategy Simulation-based verification

Tools Synopsys VCS / DVSim

Formal property verification

Synopsys VC Formal

Formal security verification

Synopsys VC Formal

RTL Lint analysis

Synopsys VC Spyglass Lint

LLM-assisted bug detection

Commercial LLMs

Hybrid Fuzzing

Synopsys VCS

Main objective Identify failures under executable test scenarios Check functional and security properties exhaustively within the formal model Detect unauthorized information flow between security domains Detect structural and coding issues that may cause security-relevant behavior Identify bugs, CWE mappings, and generate security properties Explore untested design states and input sequences

Primary input RTL, UVM environment, DVSim tests, input seeds

Analysis output Failed tests, unexpected outputs, abnormal state transitions

Validation evidence Simulation logs and waveform traces

RTL, SystemVerilog Assertions

Proven properties or counterexamples

Formal trace and failed assertion

RTL, Security Primitives

Confidentiality or integrity violations

Source-to-destination propagation trace

RTL source code and lint rules

Warnings related to assignments, widths, resets, and control logic

Manual RTL review and error logs

RTL fragments, design specifications, context Random seeds, coverage database

Candidate bugs, CWE categories, SVAs, and test ideas New tests, assertion violations, and coverage improvements

Conventional simulation or formal verification Coverage reports, logs, and waveforms

Fig. 1. Illustration of the proposed DVSim-based simulation verification workflow.

and symbolic fuzzing [24]. The availability of shared vulnerable designs, known bug sets, specifications, and verification infrastructure is particularly useful for security-aware EDA research. It enables researchers to measure whether a proposed method can identify known vulnerabilities, analyze different classes of weaknesses, study false positives, and compare complementary verification strategies on a common target. Third, the competitions support interaction between academia and industry. Academic teams can test new analysis methods on realistic designs. Industry participants can study weakness classes that may not be covered by traditional functional verification. Tool vendors can evaluate whether existing design automation tools support security-specific use cases. III. S ECURITY A NALYSIS M ETHODOLOGIES To address the diverse categories of vulnerabilities, we adopted a multi-strategy methodology for security analysis that combines simulation, formal verification, structural analysis, LLM-assisted reasoning, fuzzing, and exploit development. Each strategy generates candidate vulnerabilities from a different view of the design. The candidates are then validated using independent evidence before they are reported. The methodologies were applied during Hack@DAC (2024,2025) and Hack@CHES (2025) competitions to the buggy OpenTitan SoC design. The provided infrastructure included RTL source code, design verification environments, security properties, simulation tests, and commercial EDA tools. The security verification analysis strategies are summarized in Table III. A. Analysis Workflow The methodology consists of four main phases. First, the design environment is built and the available test, formal, and lint flows are executed to establish a baseline. Second, each analysis strategy is used to generate vulnerability candidates. Third, the candidates are reviewed to remove tool errors,

invalid assumptions, and duplicate findings. Finally, confirmed vulnerabilities are reproduced using a custom test or formal trace, mapped to a relevant hardware CWE, and documented with their security impact and possible mitigation. The strategies are not treated as independent experiments. Results from one method guide the use of another method. For example, a failing regression test may identify a suspicious state transition that is later expressed as an assertion. A lint warning may identify a width or assignment error that is validated through simulation. An LLM-generated security property may be checked using formal verification. This cross-validation reduces false positives and provides stronger evidence for each reported vulnerability. B. Simulation-Based Security Verification Dynamic simulation-based verification aims to identify functional deviations and security-relevant behaviors by utilizing regression test suites to systematically evaluate target IPs. The strategy utilizes Synopsys VCS combined with the DVSim framework available with the existing OpenTitan [25] design verification environment and custom automation scripts. Smoke tests and regression tests were run across the selected IP blocks. The goal was to identify failing tests, unexpected output values, assertion failures, timeouts, and abnormal state transitions. Fig. 1 illustrates the automated DVSim-based verification workflow, including test configuration, regression execution, failure detection, and analysis. We developed an HJSON-based orchestration layer to systematically execute the existing DVSim tests across selected SoC IPs. For each IP, the configuration specifies the native DVSim configuration file, individual tests or regressions to execute (set true or false), and fixed simulation seeds for reproducibility. The wrapper invokes DVSim for each enabled test and preserves the corresponding simulation results for subsequent failure analysis. DVSim internally performs the

5

required build and simulation stages and supports independently seeded test instances and regression-level reporting. Listing 1 presents the generic HJSON-based test orchestration configuration used to specify the target IP, selected tests or regressions, and simulation seeds for automated execution. 1 { 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 }

repo_root: "<PATH_TO_OPENTITAN_DIRECTORY>" // Design under evaluation design_variant: "buggy" // Simulator used by the DV environment simulator: "vcs" // IPs selected for security analysis test_ip_list: [ { name: "<IP_NAME>" // e.g. hmac sim_cfg: "hw/ip/<IP_NAME>/dv/\ <IP_NAME>_sim_cfg.hjson" has_mask: false // Optional test_list: [ { type: "regression" name: "smoke" skip: true/false } { type: "run_test" name: "<IP_NAME>_smoke" skip: true/false } { type: "run_test" name: "<SECURITY_TEST_1>" //name (e.g. hmac_wipe_secret) skip: false seeds: [101, 102, 103] } ] } ]

The failed cases that were examined using simulation logs and traces may not be directly classified as vulnerabilities unless they violate defined security requirements. The associated logs, assertions, scoreboard results, and waveform traces are analyzed to determine the RTL root cause and whether the observed behavior violates a defined security requirement. For example, a test failure related to a protected register was considered security relevant only when an unauthorized component could update or observe protected data. This distinction was important because regression failures can also result from incorrect constraints, unsupported configurations, or testbench errors. As summarized in Table IV, simulation exposed vulnerabilities involving incomplete secret wiping, incorrect FSM behavior, improperly enabled debug functionality, and delayed error handling. These bugs were identified through failed DVSim smoke, stress, and securitycountermeasure tests, followed by RTL-level analysis of the corresponding failure conditions. C. Formal Property and Security Verification

Formal Property Verification (FPV) is used to check whether the selected functional and security requirements hold for all behaviors represented by the formal model, whereas Formal security verification (FSV) is used to analyze unintended information flow from security-sensitive sources to unauthorized destinations. For FPV, security requirements were translated into assertions describing the expected behavior of the target RTL. The properties were formally checked against the design, and failed properties were analyzed using the generated counterexamples to identify the corresponding RTL conditions. This analysis exposed weaknesses involving secret-wipe control, unauthorized register access, and incorrect parity-error handling. FSV was applied to security-sensitive data paths Listing 1. Generic HJSON configuration for automated simulation-based by defining protected sources and unauthorized destinations security verification. and checking whether information could propagate between The execution sequence consists of the following phases: them. This analysis identified an unintended path exposing 1) Exhaustive Smoke Regression: Automated scripts run AES key shares and input-data values through the softwarestandard regression smoke tests across all SoC IP blocks visible register read interface. to isolate failing test instances. Table V summarizes representative vulnerabilities identified 2) Configuration Automation: An automation wrapper file using FPV and FSV. FPV exposed incorrect security-control (.hjson) dynamically configures the simulation parame- dependencies and register-access behavior through assertion ters, adjusting tests across specific target IPs. checking, while FSV identified an unauthorized information3) Log File Diagnostics: Analysis of runtime logs deter- flow path from security-sensitive AES registers to a softwaremines the precise cycles where the design under test visible destination. These findings demonstrate the comple(DUT) deviates from expected architectural behaviors. mentary use of property-based and information-flow-oriented TABLE IV R EPRESENTATIVE VULNERABILITIES IDENTIFIED USING SIMULATION - BASED SECURITY VERIFICATION .

Target IP AES CSRNG LC CTRL OTBN KMAC

Security Weakness Sensitive state and key registers are not properly wiped during the security-clear operation. The default state handling the CSRNG read-data return is missing. DFT and debug functionality are enabled in the LcStProd state. Secure-wipe control permits secure_wipe_req_o to be asserted after a wipe operation has already started. The sparse-FSM error indication is delayed until an inserted counter exceeds a threshold.

RTL Location aes_cipher_core.sv

Observed Impact Sensitive AES state or key information may remain exposed instead of being cleared. csrng_reg_top.sv Correct read data, error codes, or alert signals may not be generated as required. lc_ctrl_signal_decode.svDebug and DFT functionality can remain accessible during the production lifecycle state. otbn_controller.sv The secure-wipe control flow may enter an inconsistent state and result in incomplete or incorrect wiping. kmac_core.sv Error detection is delayed, allowing incorrect operation before the sparse-FSM error is reported.

6

TABLE V R EPRESENTATIVE VULNERABILITIES IDENTIFIED USING FORMAL VERIFICATION TECHNIQUES . Target IP AES

Method FSV

Security Weakness Key-share and input-data values are propagated to the software-visible register read path.

RTL Location aes_reg_top.sv

HMAC

FPV

hmac_reg_top.sv

HMAC

FPV

UART

FPV

wipe_secret_we is asserted under an incorrect dependency on reg_error. HMAC key registers reg2hw.key[0:2] are assigned to reg_rdata_next. The receiver parity-error signal does not depend on parity_enable.

formal analysis for detecting control and confidentialityrelated weaknesses. D. RTL Lint and Syntax Checking Structural RTL analysis was performed using Synopsys VC SpyGlass Lint. The design IPs were built using the available lint flow, and the resulting warnings and errors were reviewed for possible security relevance. Lint analysis can identify several implementation patterns that may contribute to vulnerabilities, including incomplete assignments and unintended latch inference, width mismatches, constant or unreachable conditions, uninitialized registers, multiple signal drivers, incorrect reset values, truncated arithmetic operations, unused control signals, inconsistent case statements, and combinational loops. Most lint warnings are not security vulnerabilities by themselves. Each warning was therefore analyzed in the context of the affected module and its security function. Higher priority was given to warnings involving key registers, privilege checks, error logic, access-control signals, state machines, and externally visible outputs. A security-relevant lint finding was confirmed through RTL inspection and, where possible, simulation or formal verification. This step prevented general coding-style warnings from being reported as vulnerabilities. Lint analysis provides fast coverage across many modules and is useful for identifying simple but high-impact design errors. However, lint analysis lacks system-level security context, as structural analysis alone cannot determine whether a suspicious signal relationship is exploitable. Table VI includes examples involving incorrect error-signal usage, secret-wipe control, and missing integrity-related FSM logic. E. LLM-Assisted Vulnerability Analysis LLMs have been increasingly applied to hardware design and verification tasks, including natural-language specification interpretation, HDL generation, RTL analysis, and verification

hmac_reg_top.sv uart_rx.sv

Observed Impact Secret key and plaintext-related data can be exposed through unauthorized register reads. Internal secret registers can be wiped under an unintended register-error condition. The HMAC hashing key can be exposed through the register read-data path. Incorrect parity-error reporting affect FIFO sync and generate false interrupts.

automation [26]. Their adoption has enabled applications such as vulnerability analysis, CWE mapping, security property generation, and bug localization [27]. However, directly applying LLMs to large SoCs remains challenging due to design complexity, context limitations, and potentially incorrect or unsupported outputs. The proposed LLM-assisted analysis focuses on identifying candidate bugs and related CWEs and validating security properties using conventional EDA tools, as depicted in Fig. 2. 1) Security-Aware Design Decomposition: The first step limits the analysis to security-relevant regions of the SoC. Each target IP is decomposed into modules or submodules based on the design hierarchy. The analysis prioritizes modules containing security-sensitive assets or controls, such as cryptographic keys, privilege signals, lifecycle states, debug authorization, register access controls, integrity checks, masking logic, reset controls, and error-handling signals. Table VIII summarizes the context provided during LLM-guided analysis. 2) CWE Identification: The next step identifies hardware CWEs that are relevant to the functionality of the selected module. Instead of comparing every RTL module against the complete CWE database, the design context is used to narrow the candidate weakness classes. For example, a cryptographic block may be analyzed for weaknesses related to the protection of secret data, masking, key handling, or unauthorized access, while a lifecycle controller may require greater emphasis on state-transition and privilege-control weaknesses. 3) CWE-Guided Bug Analysis: The identified CWEs are used to guide targeted RTL analysis. For each candidate CWE, the LLM is prompted to determine whether the corresponding weakness pattern appears in the selected RTL region. Typical checks include missing or incorrect access-control checks, improper dependencies on authorization or error signals, unintended propagation of protected data, disabled cryptographic countermeasures, insecure hardcoded parameters, invalid FSM

TABLE VI R EPRESENTATIVE VULNERABILITIES IDENTIFIED USING RTL LINT AND STRUCTURAL ANALYSIS . Target IP HMAC Primitive Shadow Register Power Manager

Security Weakness The secret-wipe control depends incorrectly on reg_error. err_update and err_storage depend on error_s, although error_s is not initialized or updated. The rom_intg_chk_good check is bypassed in FastPwrStateRomCheckGood, and the default terminal-state handling is removed.

RTL Location hmac_reg_top.sv prim_subreg_shadow.sv

pwrmgr_fsm.sv

Observed Impact Internal secret registers can be wiped under an unintended register-error condition. The intended error-detection logic can operate incorrectly. ROM integrity checking is disabled under the affected lifecycle test condition.

7

Fig. 2. Flow diagram of the proposed LLM-assisted vulnerability-analysis workflow. TABLE VII R EPRESENTATIVE VULNERABILITIES ANALYZED USING THE LLM- ASSISTED APPROACH . Target IP AES HMAC HMAC

Security Weakness The SecAllowForcingMasks parameter is hardcoded to 1, disabling the intended masking protection. wipe_secret_we is asserted when reg_error is active. The reg2hw.key_* values are propagated to reg_rdata_next.

RTL Location aes.sv:180

Observed Impact The masking countermeasure can be disabled, resulting in the reported side-channel vulnerability.

hmac_reg_top.sv:2121

Internal secret registers can be wiped under an unintended register-error condition. A malicious register read can expose the HMAC secret key.

hmac_reg_top.sv:2419, 2423, 2623

transitions, unauthorized modification of secret registers, and security violations triggered by reset, error, or exceptional conditions. 4) Targeted Security-Property Generation: For each candidate bug, the LLM generates a security property that expresses the expected behavior of the affected logic. The property is generated after a candidate weakness has been identified. Therefore, the assertion is targeted toward confirming a specific hypothesis instead of broadly generating properties for the entire module. The generated properties are translated into equivalent SVAs. Existing studies [28], [29] show that LLMgenerated assertions may contain incorrect clocking, reset semantics, signal references, or temporal operators ; therefore, every generated SVA has been validated syntactically and semantically. Table VII presents representative vulnerabilities analyzed using the LLM-assisted workflow with pre-trained GPT-4o as the baseline LLM. The analysis identified security-relevant RTL patterns involving disabled cryptographic masking, incorrect secret-wipe control, and the propagation of secret key values to a software-visible register path. These findings were used to generate targeted security properties that could subsequently be validated using conventional simulation or formal verification tools. F. Hybrid Fuzzing Coverage-guided fuzzing (CGF) is used to systematically verify hardware designs and quantify verification completeness [30], [31]. In this methodology, a hardware fuzzer automatically generates and mutates input sequences (e.g., instruction streams, transaction sequences, or test vectors) and executes

TABLE VIII C ONTEXT P ROVIDED FOR LLM-G UIDED B UG A NALYSIS Context

Information Provided

Design hierarchy

Target IP, module, submodule, and interfaces Keys, protected registers, privilege states, configuration data, and security-critical control signals Expected access rules, legal state transitions, reset behavior, and confidentiality/integrity requirements Relevant control/data logic and dependent signals Register map, bus signals, privilege information, interrupts, alerts, and debug interfaces Failed test logs, assertion failures, lint warnings, counterexamples, or waveform observations Relevant CWE descriptions and common patterns

Security assets Security intent RTL slice Interface context Verification evidence Weakness knowledge

them on the design-under-test (DUT). During execution, coverage metrics information [32] is collected and stored in a coverage database, as shown in Fig. 3. This feedback guides the fuzzer toward unexplored design behaviors by prioritizing inputs that exercise new states, control paths, or functional regions. The primary objective is to maximize exploration of the code coverage of the hardware and expose functional errors or security-critical vulnerabilities that may remain undetected through conventional verification approaches. Unlike conventional coverage-guided fuzzers that rely primarily on mutation strategies to explore uncovered areas, the proposed hybrid fuzzing first analyzes the coverage database to identify regions that remain unexplored or are difficult to activate. These uncovered coverage points are then provided as context to the LLM, which generates targeted verification artifacts, such as SVAs, directed test scenarios, or input constraints designed to exercise the corresponding design

8

TABLE IX R EPRESENTATIVE VULNERABILITIES IDENTIFIED USING FUZZING - BASED ANALYSIS . Target IP

Security Weakness

Entropy Source

Both test_fail_hi_pulse_o and test_fail_lo_pulse_o are forced to constant values, bypassing the intended failure signaling. The trigger logic is modified such that triggering occurs unconditionally. The locality check uses an incorrect comparison with NumLocality.

UART SPI TPM

Fig. 3. Coverage-guided Fuzzing approach.

behaviors. The generated assertions or constraints are subsequently analyzed by verification tools to ensure syntactic correctness and eliminate invalid specifications. The validated artifacts are then incorporated into the fuzzing framework to guide input generation toward the previously uncovered regions. Fig. 4 illustrates the integration of LLMs into the hardware fuzzing loop to improve the exploration of hard-toreach design regions. The representative findings in Table IX include incorrect UART triggering and faulty TPM locality checking in SPI, illustrating the usefulness of input-driven exploration for exposing abnormal behavior.

RTL Location entropy_src_ markov_ht.sv

Observed Impact

uart_core.sv

Unintended execution, glitches, or incorrect interrupt generation can occur. The invalid_locality condition can be set incorrectly.

spi_tpm.sv

Health-test failure signaling is bypassed, affecting detection of randomized-threshold violations.

the generated changes included extending an existing UVM verification sequence, introducing a lightweight custom UVM sequence, adding verification-side monitoring mechanisms such as SystemVerilog Assertions (SVAs), or incorporating functional checks to observe the exploit outcome. The generated modifications were integrated into the OpenTitan [25] project and executed using the existing UVM-based verification environment. The exploit execution was validated by analyzing simulation outputs, including assertion failures, register state changes, interrupt status, protocol responses, and simulation logs, to confirm that the reported vulnerability was successfully reproduced. 1) Application to the UART lsio_trigger_o Exploit: For the UART vulnerability, the bug description and project hierarchy were provided to the LLM to identify the components involved in the DMA trigger generation logic. The corresponding RTL and verification files were then supplied to the LLM, which modified the existing uart_fifo_reset_vseq.sv sequence to generate the FIFO conditions required to trigger the reported vulnerability and generated an SVA to automatically detect incorrect assertions of lsio_trigger_o. The generated sequence also included UVM_INFO messages that report the executed test case and FIFO levels, providing the operating conditions under which each assertion failure occurred. The resulting simulation output is shown in Listing 2. 1 UVM_INFO uart_fifo_reset_vseq.sv: Test 1: Sending

5 TX bytes below watermark 2 Error: Assertion LsioTriggerInvalid_A failed:

lsio_trigger_o is 1 when TX FIFO (5) >= 8 or RX FIFO (0) < 16 3 UVM_INFO uart_fifo_reset_vseq.sv: TX FIFO level: 5, RX FIFO level: 0 Fig. 4. Hybrid fuzzing approach with feedback-driven exploration of uncovered hardware regions.

G. Custom Exploit Development The exploit development process began with the reported bug description, which provided information including the affected module, vulnerable code location, triggering conditions, expected behavior, security impact, and proposed mitigation. This information, together with the OpenTitan [25] project directory hierarchy, was provided to the LLM to identify the RTL and verification components associated with the reported vulnerability. After identifying the relevant components, the corresponding RTL and verification source files were retrieved and supplied to the LLM for further analysis. Based on the bug description and the implementation of the identified components, the LLM generated the modifications required to reproduce the vulnerability while preserving the original design behavior. Depending on the reported vulnerability,

4 5 UVM_INFO uart_fifo_reset_vseq.sv: Test 2: Sending

10 RX bytes below watermark 6 Error: Assertion LsioTriggerInvalid_A failed:

lsio_trigger_o is 1 when TX FIFO (0) >= 8 or RX FIFO (10) < 16 7 UVM_INFO uart_fifo_reset_vseq.sv: TX FIFO level: 0, RX FIFO level: 10 8 9 UVM_INFO uart_fifo_reset_vseq.sv: Test 3: Checking

lsio_trigger_o after FIFO operations 10 Error: Assertion LsioTriggerInvalid_A failed:

lsio_trigger_o is 1 when TX FIFO (0) >= 8 or RX FIFO (0) < 16 11 UVM_INFO uart_fifo_reset_vseq.sv: TX FIFO level: 0, RX FIFO level: 0 Listing 2. UART lsio_trigger_o exploit simulation output

As shown in Listing 2, the assertion failures indicate that lsio_trigger_o remained asserted under invalid FIFO conditions, while the accompanying UVM_INFO messages identify the FIFO occupancy that produced each failure.

9

2) Application to the HMAC WIPE_SECRET Exploit: For the HMAC vulnerability, the bug description and project hierarchy were provided to the LLM to identify the RTL and verification components associated with the WIPE_SECRET register write logic. After analyzing the relevant source files, the LLM generated a lightweight custom UVM sequence to configure the HMAC module, issue the malformed TLUL write transaction, and perform functional checks on the resulting digest registers and interrupt status. The generated sequence also included UVM_INFO messages that report the execution stages together with the observed digest values and interrupt status used by the functional checks. The resulting simulation output is shown in Listing 3. 1 UVM_INFO @ <time>: SEQ [SEQ] DIGEST_7: 0x<

valid_digest_7> 2 UVM_INFO @ <time>: SEQ [SEQ] Triggering buggy

WIPE_SECRET write... 3 UVM_INFO @ <time>: SEQ [SEQ] SUCCESS: HmacErr

interrupt triggered. 4 UVM_INFO @ <time>: SEQ [SEQ] DIGEST after buggy

write: 5 UVM_INFO @ <time>: SEQ [SEQ] DIGEST_0: 0xffffffff 6 UVM_INFO @ <time>: SEQ [SEQ] DIGEST_1: 0xffffffff

(a)

Listing 3. HMAC WIPE_SECRET exploit simulation output

As shown in Listing 3, the reported digest values and HmacErr interrupt confirm that the malformed transaction successfully reproduced the reported vulnerability. H. Bug Classes and Distribution The reported vulnerabilities were grouped into seven security classes based on their primary root cause and security impact: data sanitization failures, sensitive data exposure, accesscontrol violations, FSM/control-flow issues, incorrect error handling, integrity weaknesses, and data-path/signal-control errors. Fig. 5a illustrates the resulting taxonomy, while Fig. 5b summarizes the distribution. The classes provide an analysisoriented grouping of the observed bugs and do not replace their individual CWE mappings. Each distinct bug was assigned once to the class that best represented its primary RTL root cause to avoid double counting across overlapping security effects. Data sanitization failures and sensitive data exposure represent the largest fractions, followed by FSM/control-flow issues and incorrect error handling. Access-control violations, integrity weaknesses, and data-path/signal-control errors account for the remaining findings. The distribution indicates that a substantial portion of the observed bugs originated from the incorrect handling of sensitive state, security-critical control logic, and error conditions rather than from isolated syntaxlevel defects. The taxonomy also highlights the diversity of security failures encountered across the competitions. The findings span confidentiality-related leakage, improper secret clearing, lifecycle and privilege violations, faulty state transitions, weakened countermeasures, and incorrect RTL signal dependencies. This diversity further supports the need for complementary verification techniques, as different bug classes are exposed more effectively by different forms of simulation, formal analysis, linting, fuzzing, and LLM-assisted inspection.

(b) Fig. 5. (a) Taxonomy of observed security bugs; (b) distribution of the identified bug classes.

IV. L ESSONS L EARNED The following subsections summarize the key lessons related to security intent, complementary verification, cross-layer analysis, and reproducible vulnerability validation. 1) Security Intent Is Critical for Bug Identification: A functional failure does not necessarily indicate a security vulnerability. The analysis must include the protected assets, trust boundaries, privilege rules, and expected security behavior before interpreting a failed test or RTL code as a security vulnerability. Several important bugs arise from logic that is functionally valid under normal operation but violates a security requirement under unauthorized, error, or exceptional conditions. Therefore, security analysis should begin with identifying the intended protection mechanisms and then checking whether the RTL correctly enforces them.

10

2) Combine Complementary Verification Methods: No single verification method provides sufficient coverage for all SoC security weaknesses. Simulation is effective for reproducing executable attack sequences, while formal verification is better suited for temporal properties and hard-to-reach states. Static analysis provides scalable structural screening, and information-flow analysis can directly examine confidentiality and integrity violations [2], [5], [14], [15]. A practical direction is therefore to develop hybrid verification flows in which findings from one technique automatically guide another, rather than applying each method independently. 3) Verification Infrastructure Requires Security-Aware Guidance: Existing regression environments, assertions, testbenches, and lint flows provide a useful starting point for vulnerability discovery. However, functional regressions mainly exercise expected design behavior and may not target unauthorized access, malicious transitions, or abnormal error conditions. Lint-based analysis can be combined with manual inspection and targeted tests when analyzing SoC security bugs [33], [34]. An important direction is therefore to augment existing verification infrastructure with security-directed stimulus generation and coverage metrics that measure security-relevant states and behaviors rather than functional coverage alone. 4) Automated Findings Require Independent Validation: Lint warnings, LLM-generated bug hypotheses, failed assertions, and fuzzing anomalies should be treated as vulnerability candidates rather than confirmed bugs. Each candidate should be traced to an RTL root cause and reproduced through a simulation trace, formal counterexample, information-flow path, or custom exploit. This is particularly important for LLM-assisted analysis, where generated properties can be syntactically valid but semantically incorrect [27], [28]. A useful direction is, therefore, closed-loop AI-assisted verification, where LLM reasoning generates candidates while simulation or formal tools provide the acceptance criterion. 5) Cross-Layer Analysis Is Necessary for SoC-Level Bugs: Many security vulnerabilities cannot be detected by analyzing isolated RTL modules. Their activation may depend on register transactions, firmware operations, privilege states, or translation to gate-level netlists [2], [35]. Future verification techniques should therefore support cross-module verification across different abstraction levels. 6) Tool Automation and Parallelization Improve Coverage: Large SoCs contain many IPs and security-critical interfaces, making exhaustive manual analysis impractical under the time constraints during competitions. Automation of test execution, log collection, property checking, and result triage reduces repetitive effort. A coordinated multi-method agentic LLMdriven workflow [21], [36], [37] provides better coverage than sequential analysis by a single technique. V. B ROADER I MPACT AND R ESEARCH D IRECTIONS Hardware hacking competitions provide benefits beyond vulnerability discovery by creating shared platforms for security training, tool evaluation, and benchmark development. Their open-box structure allows participants from hardware

design, verification, firmware, and security backgrounds to analyze the target SoC under common threat models and evaluation criteria. This promotes cross-domain collaboration and exposes participants to practical security-analysis workflows that are difficult to reproduce through isolated classroom or laboratory exercises. 1) Security Training and Community Development: These competitions provide hands-on experience in threat modeling, RTL analysis, simulation, formal verification, exploit development, and vulnerability reporting. The interaction between participants with different technical backgrounds also supports knowledge transfer across hardware design, verification, and security domains. Such exposure is particularly useful for developing security-aware design and verification skills and for training researchers entering the hardware-security field. 2) Reusable Benchmarks for Security Research: Competition artifacts can serve as reusable benchmarks after the event. Vulnerable RTL designs, known bug sets, security properties, test environments, and exploit cases provide common targets for evaluating new analysis methods. Hack@DAC benchmarks, for example, have been reused to evaluate static analysis, information-flow tracking, symbolic and concolic execution, formal verification, and LLM-assisted bug detection [14], [16], [21], [22], [24]. This enables more consistent comparisons across techniques and reduces dependence on small synthetic benchmarks. 3) Security-Aware EDA Tool Development: The diversity of competition bugs provides useful test cases for evaluating security-aware EDA tools. Existing simulation, lint, and formal flows can be assessed against realistic security failures, while new techniques can be evaluated for detection capability, scalability, false-positive rate, and verification effort. Competition results can therefore reveal gaps in current design-automation flows and motivate tighter integration of security analysis into conventional RTL verification. 4) Open Challenges and Research Directions: Several technical challenges remain for scalable SoC security assurance. First, security intent must be extracted and translated into executable verification properties with limited manual effort. Second, many vulnerabilities require cross-IP and hardwaresoftware interaction that are difficult to capture using modulelevel verification alone. Third, conventional functional coverage does not directly measure whether security-critical assets, privilege transitions, and adversarial scenarios have been adequately explored. Security-oriented coverage metrics are therefore needed. Future work should also investigate tighter integration of simulation, formal verification, static analysis, and fuzzing so that results from one technique can guide another. LLMassisted analysis provides another promising direction, but generated bug hypotheses and properties should remain grounded in RTL semantics and validated through EDA tools. Finally, future competition benchmarks should include larger heterogeneous SoCs, AI accelerators, chiplet-based systems, and cross-abstraction vulnerabilities to better reflect emerging hardware-security challenges.

11

VI. C ONCLUSION Hardware hacking competitions provide a practical environment for evaluating SoC security verification methods against realistic design weaknesses. This paper examined multiple analysis strategies, including simulation-based verification, formal property and security verification, RTL lint analysis, CWE-guided bug detection using LLMs, and hybrid fuzzing. The findings indicate that these techniques provide complementary capabilities, while reliable vulnerability discovery requires explicit security intent, systematic failure analysis, and independent validation of candidate bugs. Beyond the competition setting, the released designs and known vulnerabilities provide useful benchmarks for evaluating security-aware EDA tools and emerging automated analysis techniques. The lessons from these competitions can therefore help improve pre-silicon vulnerability detection, cross-layer security verification, and reproducible assessment of future SoC security methodologies. ACKNOWLEDGMENTS The authors would like to thank Dr. Atri Chatterjee, Dr. Rajat Sadhukhan, and Dr. Arnab Bag for their participation and contributions across different competition editions, and Dr. Debdeep Mukhopadhyay for his valuable insights and guidance. The authors also acknowledge the organizers from Texas A&M University, TU Darmstadt, Intel Corporation, and Synopsys for successfully organizing the competitions over the years and for providing a valuable platform for advancing hardware security research. R EFERENCES [1] X. Lou, T. Zhang, J. Jiang, and Y. Zhang, “A survey of microarchitectural side-channel vulnerabilities, attacks, and defenses in cryptography,” ACM Comput. Surv., Jul. 2021. [2] G. Dessouky, D. Gens, P. Haney, G. Persyn, A. Kanuparthi, H. Khattri, J. M. Fung, A.-R. Sadeghi, and J. Rajendran, “HardFails: Insights into Software-Exploitable hardware bugs,” in 28th USENIX Security Symposium (USENIX Security 19), Santa Clara, CA, 2019, pp. 213–230. [3] HackTheSilicon, https://hackthesilicon.com, accessed: 2025-05-04. [4] A. Kanuparthi, H. Khattri, J. J. Rajendran, J. Fung, and A.-R. Sadeghi, “The hack@dac story: Learnings from organizing the world’s largest hardware hacking competition,” in Black Hat Asia 2024. [Online]. Available: https://blackhat.com/asia24/briefings/schedule/#the-hackdac-story-learnings-from-organizingthe-worlds-largest-hardware-hacking-competition-37994 [5] A.-R. Sadeghi, J. Rajendran, and R. Kande, “Organizing the world’s largest hardware security competition: Challenges, opportunities, and lessons learned,” in Proceedings of the 2021 Great Lakes Symposium on VLSI, ser. GLSVLSI ’21, 2021, p. 95–100. [6] S. Paria, Z. Han, A. Dasgupta, H. Rahaman, D. Halder, R. Almawzan, D. Xing, K. Amberiadis, S. Ray, A. Srivastava, J. Rajendran, and S. Bhunia, “Toward enhanced hardware ip security: Community evaluation of logic locking, state space transformation, redaction, and noc routing table configuration,” ACM Trans. Des. Autom. Electron. Syst., May 2026. [7] B. Tan et al., “Benchmarking at the frontier of hardware security: Lessons from logic locking,” 2020. [8] M. M. Rahman, J. Geist, D. Xing, Y. Liu, A. Srivastava, T. Meade, Y. Jin, and S. Bhunia, “Security evaluation of state space obfuscation of hardware ip through a red team-blue team practice,” ACM Trans. Des. Autom. Electron. Syst., May 2024. [9] “DEF CON Capture the Flag,” https://defcon.org/, accessed: 2025-04-14. [10] “PlaidCTF,” https://plaidctf.com/, accessed: 2025-05-18. [11] “WhibOx Contest: An ECRYPT White-Box Cryptography Competition,” https://whibox.io/contests/, 2024. [12] “CSAW Embedded Security Challenge (ESC),” https://csaw.io/ competition/embedded-security-challenge, 2025, hardware and embedded systems security competition. [13] “CSAW AI Hardware Challenge,” https://www.csaw.io/, 2025, AI hardware security challenge.

[14] F. Solt, B. Gras, and K. Razavi, “CellIFT: Leveraging cells for scalable and precise dynamic information flow tracking in RTL,” in 31st USENIX Security Symposium (USENIX Security 22), Boston, MA, 2022. [15] A. Meza, F. Restuccia, J. Oberg, D. Rizzo, and R. Kastner, “Security verification of the opentitan hardware root of trust,” IEEE Security & Privacy, vol. 21, no. 3, pp. 27–36, 2023. [16] B. Ahmad, W.-K. Liu, L. Collini, H. Pearce, J. M. Fung, J. Valamehr, M. Bidmeshki, P. Sapiecha, S. Brown, K. Chakrabarty, R. Karri, and B. Tan, “Don’t CWEAT It: Toward CWE Analysis Techniques in Early Stages of Hardware Design,” in Proceedings of the 41st IEEE/ACM International Conference on Computer-Aided Design, ser. ICCAD ’22. [17] S. Paria, A. Dasgupta, and S. Bhunia, “SPELL: An End-to-End Tool Flow for LLM-Guided Secure SoC Design for Embedded Systems,” IEEE Embedded Systems Letters, vol. 16, no. 4, pp. 365–368, 2024. [18] X. Meng, A. Srivastava, A. Arunachalam, A. Ray, P. H. Silva, R. Psiakis, Y. Makris, and K. Basu, “Unlocking hardware security assurance: The potential of llms,” 2023. [Online]. Available: https: //arxiv.org/abs/2308.11042 [19] B. Ahmad, H. Pearce, R. Karri, and B. Tan, “Lashed: Llms and static hardware analysis for early detection of rtl bugs,” 2025. [Online]. Available: https://arxiv.org/abs/2504.21770 [20] S. Paria, “LAMBDA: LLM-Assisted Malicious Bug Detection and Analysis in Hardware Designs,” in 2025 IEEE International Test Conference (ITC), 2025, pp. 563–565. [21] L. Collini, B. Ahmad, J. Ah-kiow, and R. Karri, “MARVEL: MultiAgent RTL Vulnerability Extraction using Large Language Models,” 2025. [22] D. R. Ankireddy, S. Paria, A. Dasgupta, S. Ray, and S. Bhunia, “LASSO: LLM-Aided Security Property Generation for Assertion-based SoC Verification,” in 2025 ACM/IEEE 7th Symposium on Machine Learning for CAD (MLCAD), 2025, pp. 1–10. [23] I. Tashdid, K. Tasnia, A. Garcia, J. Valamehr, and S. Rahman, “Atlas: Ai-assisted threat-to-assertion learning for system-on-chip security verification,” arXiv preprint arXiv:2603.01170, 2026. [24] S. S. Miftah, A. Srivastava, H. Kim, S. Wei, and K. Basu, “Symbfuzz: Symbolic execution guided hardware fuzzing,” in Proceedings of the 58th IEEE/ACM International Symposium on Microarchitecture, ser. MICRO ’25, 2025, p. 1477–1490. [25] lowRISC, “Opentitan: Open source silicon root of trust.” [Online]. Available: https://opentitan.org/ [26] S. Paria, A. Dasgupta, and S. Bhunia, “Navigating SoC Security Landscape on LLM-Guided Paths,” in Proceedings of the Great Lakes Symposium on VLSI 2024, ser. GLSVLSI ’24. New York, NY, USA: Association for Computing Machinery, 2024, p. 252–257. [27] S. Paria and S. Bhunia, “Harnessing the Power of LLMs for Enhancing Hardware Security,” SN Computer Science, vol. 7, no. 2, p. 218, 2026. [28] D. R. Ankireddy, S. Paria, A. Dasgupta, S. Ray, and S. Bhunia, “LASA: Enhancing SoC Security Verification with LLM-Aided Property Generation,” 2025. [Online]. Available: https://arxiv.org/abs/2506.17865 [29] S. Paria, A. Dasgupta, and S. Bhunia, “DIVAS: An LLM-based End-toEnd Framework for SoC Security Analysis and Policy-based Protection,” 2023. [30] R. Saravanan, S. Paria, J. Thangellamudi, S. Bhunia, and S. M. P. D., “Fuzzing-based verification of hardware designs: A comprehensive survey,” IEEE Access, vol. 14, pp. 100 456–100 476, 2026. [31] R. Saravanan and S. M. Pudukotai Dinakarrao, “The fuzz odyssey: A survey on hardware fuzzing frameworks for hardware design verification,” 2024. [32] ——, “Exploring coverage metrics in hardware fuzzing: A comprehensive analysis,” in Proceedings of the Great Lakes Symposium on VLSI 2024, ser. GLSVLSI ’24, 2024, p. 240–245. [33] M. M. Bidmeshki, Y. Zhang, M. Zaman, L. Zhou, and Y. Makris, “Hunting security bugs in soc designs: Lessons learned,” IEEE Design & Test, vol. 38, no. 1, pp. 22–29, 2021. [34] N. Corteggiani, G. Camurati, M. Muench, S. Poeplau, and A. Francillon, “Soc security evaluation: Reflections on methodology and tooling,” IEEE Design & Test, vol. 38, no. 1, pp. 7–13, 2021. [35] R. Saravanan, S. Paria, A. Dasgupta, V. N. Patnala, S. Bhunia, and S. M. P. D, “SynFuzz: Leveraging Fuzzing of Netlist to Detect Synthesis Bugs,” 2025. [36] S. Paria and S. Bhunia, “Exploring agentic llm paradigms for hardware verification across abstraction levels,” in 2026 IEEE 44th VLSI Test Symposium (VTS), 2026, pp. 1–5. [37] D. Saha, S. Tarek, H. A. Shaikh, K. T. Hasan, P. S. Nalluri, M. A. Hasan, N. Alam, J. Zhou, S. K. Saha, M. Tehranipoor, and F. Farahmandi, “SVLLM: An Agentic Approach for SoC Security Verification using Large Language Models,” 2025.

Related documents

• NIST SP 1800-34: Validating the Integrity of Computing Devices#2843
• Data Protection: A Friend or Foe of the Competition Law#403271
• The Illusion of Secure LLM Code: Closing the Security Gap via Iterative Reprompting#405561
• Cooperation of Mutually Suspicious Subsystems in a Computer Utility#436498
• Uncovering Logit Suppression Vulnerabilities in LLM Safety Alignment#152988