Agent skill

Attacking Hardware Interfaces

by trilwu in trilwu/secskills

Assess the physical attack surface of embedded devices — finding and using UART consoles, JTAG/SWD debug, and SPI/I2C flash; dumping firmware off-chip; triaging secure boot; and studying sub-GHz RF…

MITAuto-check passedSecurity

Install Attacking Hardware Interfaces

skills CLI
$ npx skills add trilwu/secskills --skill attacking-hardware-interfaces -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install trilwu/secskills attacking-hardware-interfaces --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/trilwu/secskills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/secskills-offense/skills/attacking-hardware-interfaces .claude/skills/attacking-hardware-interfaces && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
attacking-hardware-interfaces
GitHub stars
156
Token cost
~1.8k tokens
SKILL.md length
988 words
Files
1
Skills in repo
50
Repo updated
First seen
Licence
MIT

At a glance

Assess the physical attack surface of embedded devices — finding and using UART consoles, JTAG/SWD debug, and SPI/I2C flash; dumping firmware off-chip; triaging secure boot; and studying sub-GHz RF…

  • You have physical access to a device
  • SKILL.md covers When to Use, When NOT to Use, Find the Interfaces and Turn an Interface Into Access, plus 5 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md
  • Need to identify test pads and get a serial/root shell

What it does

Attacking Hardware Interfaces is an agent skill from trilwu/secskills. Assess the physical attack surface of embedded devices — finding and using UART consoles, JTAG/SWD debug, and SPI/I2C flash; dumping firmware off-chip; triaging secure boot; and studying sub-GHz RF replay feasibility with an SDR. Use when you have physical access to a device or board, need to identify test pads and get a serial/root shell, want to read a flash chip with flashrom, or are evaluating a fixed- vs rolling-code radio in a shielded lab.

Its SKILL.md is about 1.8k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Security, covering Threat modeling. The repository describes itself as: Transform Claude Code into your personal security engineer. The licence is MIT.

When your agent uses it

  • You have physical access to a device
  • Need to identify test pads and get a serial/root shell
  • Want to read a flash chip with flashrom
  • Are evaluating a fixed- vs rolling-code radio in a shielded lab

Example prompts

  • “/attacking-hardware-interfaces”

What it can do on your machine

Read from SKILL.md and the folder at commit ca53957. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Attacking Hardware Interfaces loads about 1.8k tokens when it runs. Until then it costs about 120 tokens; SKILL.md has 988 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~120
When it runs · the whole SKILL.md, loaded when a task matches
~1.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from trilwu/secskills at commit ca53957, republished under its MIT licence (© trilwu). 988 words, ~1,826 tokens.

Download SKILL.mdSave it as .claude/skills/attacking-hardware-interfaces/SKILL.md (or your agent's skills folder).
name
attacking-hardware-interfaces
description
Assess the physical attack surface of embedded devices — finding and using UART consoles, JTAG/SWD debug, and SPI/I2C flash; dumping firmware off-chip; triaging secure boot; and studying sub-GHz RF replay feasibility with an SDR. Use when you have physical access to a device or board, need to identify test pads and get a serial/root shell, want to read a flash chip with flashrom, or are evaluating a fixed- vs rolling-code radio in a shielded lab.
verified
2026-08-07

Attacking Hardware Interfaces

Physical access changes the game: the debug ports, flash chips, and boot process the vendor assumed were private are all reachable. The work is finding the interfaces on the board, using them to reach a shell or dump the firmware, and judging whether the device's secure-boot and RF designs actually hold. Almost everything here needs the device in hand and permission to open it.

When to Use

  • You have physical access to an embedded device or PCB and need to find its debug/serial/flash interfaces
  • Getting a UART console or root shell, interrupting a bootloader, or halting the CPU over JTAG/SWD
  • Dumping firmware off a SPI/I2C flash chip for analysis
  • Triaging a secure-boot / chain-of-trust design for bypass feasibility
  • Studying sub-GHz RF replay feasibility (fixed vs rolling code) in a lab

When NOT to Use

  • Analyzing firmware you already dumped — extraction, filesystem carving, binary analysis — is analyzing-firmware-images; this skill gets the bytes off the device and hands them there.
  • Wi-Fi attacks — attacking-wireless-networks.
  • Bluetooth/BLE and NFC/RFID specifically — attacking-bluetooth-nfc.
  • Reversing a specific binary pulled from the device — analyzing-binaries.

Find the Interfaces

Boards expose more than they should through unlabeled test pads and headers:

  • UART. The most common win — a serial console, often a bootloader prompt or a root shell. Identify the four lines (TX, RX, GND, VCC) with a multimeter and a logic analyzer, then connect a USB-TTL adapter (FTDI/CP2102) and open the console with screen/minicom/picocom. Detect the baud rate (115200 is common) if it is not obvious.
  • JTAG / SWD. Full debug access — halt the CPU, read/write memory and registers, dump firmware, patch. Identify the pinout (a JTAGulator brute- forces it) and drive it with OpenOCD and an adapter (Bus Pirate, J-Link, Black Magic Probe).
  • SPI / I2C flash. The firmware lives on an external flash chip you can read directly — clip a SOIC8 test clip on and dump with flashrom via a CH341A or Bus Pirate, in-circuit or after chip-off.
  • Logic analyzer (Saleae, or sigrok/PulseView with cheap hardware) to identify and decode any of the above when the protocol or pinout is unknown.

Turn an Interface Into Access

  • UART → shell. Many devices drop straight to a root shell or an authenticated console. If not, interrupt the bootloader (U-Boot often takes a keypress) to change the kernel command line — booting into single-user mode or spawning a shell (init=/bin/sh) is a frequent, high-impact bypass.
  • JTAG → firmware and control. Halt and dump flash/RAM, read secrets, or patch a check. JTAG left enabled on production is a full compromise of the device's software protections.
  • Flash dump → firmware. A SPI dump is the firmware image; hand it to analyzing-firmware-images for extraction and analysis. This path works even when UART and JTAG are locked.

Secure Boot and Fault Injection

Judge whether the chain of trust actually holds:

  • Chain of trust. ROM verifies the bootloader, which verifies the kernel, and so on. The break is usually an unverified link — an unsigned stage, a debug path, or a check that can be skipped.
  • Fuses / lock bits. Whether JTAG-disable and secure-boot fuses are actually blown on production units is a common oversight; an unblown fuse reopens the debug port.
  • Fault injection (glitching). Voltage or clock glitches (ChipWhisperer-class tooling) can skip a signature check or a comparison at the exact instruction. This is advanced and often the only route past a correctly-implemented secure boot; scope it as a feasibility study, not a guaranteed result.
Show full SKILL.md (425 more words)Show less

RF Replay Feasibility (SDR)

For sub-GHz radios (remotes, sensors, alarms on ISM bands like 315/433/868/915 MHz):

  • Receive and analyze with an RTL-SDR (receive-only) and Universal Radio Hacker or GNU Radio — capture the signal, recover the modulation and encoding.
  • The security question is fixed vs rolling code. A fixed code replays trivially; a rolling code (KeeLoq-style) changes every press and resists naive replay. Determine which the target uses — that is the finding.
  • Transmitting (with a HackRF or similar) is where the law lives: you may only transmit in a shielded enclosure / RF-isolated lab, never over the air on bands you are not licensed for. Frame active RF work as a lab feasibility study, because you cannot confine a real transmission to the target.

Scope and Authorization

This skill assumes a device you own or are explicitly authorized to open and modify — opening hardware is destructive-adjacent and voids assumptions the owner may care about, so get that in scope in writing. Two hard edges:

  • RF transmission is regulated. Receiving is generally passive; transmitting on licensed or safety-critical bands is a legal matter and a safety one. Keep active RF in a shielded lab, and treat spectrum law as a constraint you do not argue with.
  • Physical modification can brick the device. Chip-off, glitching, and bootloader changes can be irreversible. Confirm the owner accepts that risk on the specific unit before you start.

Rationalizations to Reject

  • "No labeled debug header, so there's no debug access." UART and JTAG live on unlabeled test pads constantly. Probe with a multimeter and logic analyzer before concluding the interface is absent.
  • "The flash is encrypted / locked, so I can't get firmware." Try the other paths — a UART bootloader, an enabled JTAG, or an unblown fuse often bypasses a locked flash entirely.
  • "Secure boot is enabled, so the chain is sound." Enabled is not the same as complete. Check every link for an unsigned stage, a debug path, or an unblown fuse — and glitching may skip the check outright.
  • "I'll just transmit to test the remote." Over-the-air transmission is regulated and can affect safety systems. Do active RF in a shielded lab, or keep the assessment to receive-and-analyze.
  • "A rolling code means replay is impossible, done." Confirm it is genuinely rolling and correctly implemented; naming fixed vs rolling code is the deliverable, and weak rolling-code schemes have their own flaws.

References

  • analyzing-firmware-images — analyzing firmware once dumped off the device
  • attacking-bluetooth-nfc — BLE and NFC/RFID RF surfaces
  • attacking-wireless-networks — Wi-Fi
  • analyzing-binaries — reversing a specific binary recovered from the device
  • maintaining-engagement-state — recording physical access and irreversible changes

© trilwu, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in secskills-offense/skills/attacking-hardware-interfaces of trilwu/secskills.

Open the folder on GitHubat commit ca53957

Compare with similar skills

Attacking Hardware Interfaces next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Attacking Hardware Interfaces compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Attacking Hardware Interfaces this skilltrilwu/secskills156—~1.8kAutomated safety check: PassMIT
Fla Ascend Performancefla-org/flash-linear-attention5.8k—~6.3kAutomated safety check: PassMIT
Forensifyalexgreensh/repo-forensics188—~2.5kAutomated safety check: NotesCustom licence
Create Rulecartography-cncf/cartography4.1k—~3kAutomated safety check: PassApache-2.0
Commit Security Scancodexstar69/bug-hunter519—~629Automated safety check: PassMIT
Threat Mitigation Mappingwshobson/agents40k8 repos~742Automated safety check: PassMIT

Similar skills

  • Fla Ascend Performance

    fla-org/flash-linear-attention

    Guidelines for Ascend NPU kernel / Triton-Ascend backend performance work in the FLA repo.

    5.8k GitHub stars~6.3k tokensUpdated today
    SecurityAuto-check passed
  • Forensify

    alexgreensh/repo-forensics

    Cross-agent self-inspection of your AI-agent stack. An agent skill from alexgreensh/repo-forensics.

    188 GitHub stars~2.5k tokensUpdated 11 days ago
    SecurityAuto-check: notes
  • Create Rule

    cartography-cncf/cartography

    Author a Cartography security rule (one or more Cypher Facts plus a Pydantic Finding output model) under cartography/rules/data/rules/.

    4.1k GitHub stars~3k tokensUpdated today
    SecurityAuto-check passed
  • Commit Security Scan

    codexstar69/bug-hunter

    Scan code changes for security vulnerabilities using Bug Hunter-native artifacts and STRIDE context.

    519 GitHub stars~629 tokensUpdated 1 mo ago
    SecurityAuto-check passed
  • Match identified threats to preventive, detective and corrective controls across network, application, data, endpoint and process layers to plan remediation.

    40k GitHub starsUsed in 8 repos~742 tokens
    SecurityAuto-check passed
  • Audit Browser Security Boundaries

    nordstjernen-web/northstar-browser

    Audit browser-engine changes that process untrusted content or cross native-memory, origin, network, storage, extension, decoder, sandbox, or operating-system boundaries.

    116 GitHub stars~920 tokensUpdated 2 days ago
    SecurityAuto-check passed

More from trilwu/secskills

All 50 skills in this repo
  • Audit source code for exploitable vulnerabilities using threat-model-driven review, taint tracing, invariant checking, and variant analysis.

    156 GitHub stars~3.2k tokensUpdated 1 mo ago
    Auto-check passed
  • Perform OSINT, subdomain enumeration, port scanning, web reconnaissance, email harvesting, and cloud asset discovery for initial access.

    156 GitHub stars~3.1k tokensUpdated 1 mo ago
    Auto-check: notes
  • Securing AI Systems

    trilwu/secskills

    Assess and harden LLM applications and agentic systems against prompt injection, tool misuse, excessive agency, memory poisoning, RAG data leakage, and model supply-chain risk, mapped to the OWASP…

    156 GitHub stars~2.9k tokensUpdated 1 mo ago
    Auto-check passed
  • Analyzing Binaries

    trilwu/secskills

    Reverse engineer compiled binaries, firmware, and mobile app packages using triage, static disassembly, decompilation, and dynamic instrumentation.

    156 GitHub stars~2.9k tokensUpdated 1 mo ago
    Auto-check passed
  • Analyzing Go Binaries

    trilwu/secskills

    Reverse engineer Go binaries by recovering function names and types from pclntab and moduledata using GoReSym, redress, and IDA/Ghidra Go plugins, and by reading Go's non-standard calling…

    156 GitHub stars~2k tokensUpdated 1 mo ago
    Auto-check passed
  • Analyzing iOS Binaries

    trilwu/secskills

    Analyze iOS applications at the binary level — decrypting FairPlay-protected IPAs with frida-ios-dump or bagbak, inspecting Mach-O load commands, recovering Objective-C headers with class-dump, and…

    156 GitHub stars~2k tokensUpdated 1 mo ago
    Auto-check passed

Categories

Questions about Attacking Hardware Interfaces

What does Attacking Hardware Interfaces do?

Assess the physical attack surface of embedded devices — finding and using UART consoles, JTAG/SWD debug, and SPI/I2C flash; dumping firmware off-chip; triaging secure boot; and studying sub-GHz RF…. Attacking Hardware Interfaces is an agent skill from trilwu/secskills. Assess the physical attack surface of embedded devices — finding and using UART consoles, JTAG/SWD debug, and SPI/I2C flash; dumping firmware off-chip; triaging secure boot; and studying sub-GHz RF replay feasibility with an SDR.

When should I use Attacking Hardware Interfaces?

Attacking Hardware Interfaces fits situations like: you have physical access to a device; need to identify test pads and get a serial/root shell; want to read a flash chip with flashrom; are evaluating a fixed- vs rolling-code radio in a shielded lab.

How do I install Attacking Hardware Interfaces in Claude Code?

Run `npx skills add trilwu/secskills --skill attacking-hardware-interfaces -a claude-code`. Or copy the skill folder (secskills-offense/skills/attacking-hardware-interfaces in trilwu/secskills) into .claude/skills/attacking-hardware-interfaces in your project. Claude Code loads it when a task matches its description.

How do I install Attacking Hardware Interfaces in Codex?

Run `npx skills add trilwu/secskills --skill attacking-hardware-interfaces -a codex`. Or copy the skill folder (secskills-offense/skills/attacking-hardware-interfaces in trilwu/secskills) into .agents/skills/attacking-hardware-interfaces in your project. Codex loads it when a task matches its description.

Can I use Attacking Hardware Interfaces in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add trilwu/secskills --skill attacking-hardware-interfaces -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/attacking-hardware-interfaces, .gemini/skills/attacking-hardware-interfaces, .github/skills/attacking-hardware-interfaces and .opencode/skills/attacking-hardware-interfaces in your project.

What does Attacking Hardware Interfaces need to run?

SKILL.md names no scripts, command-line tools or credentials: Attacking Hardware Interfaces is instructions for the agent only.

Does Attacking Hardware Interfaces access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Attacking Hardware Interfaces safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Attacking Hardware Interfaces use?

Attacking Hardware Interfaces is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Attacking Hardware Interfaces use?

About 1.8k tokens (SKILL.md is roughly 7.3k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Attacking Hardware Interfaces?

Skills that share tags, products or a category with Attacking Hardware Interfaces: Fla Ascend Performance (fla-org/flash-linear-attention, 5.8k stars), Forensify (alexgreensh/repo-forensics, 188 stars), Create Rule (cartography-cncf/cartography, 4.1k stars) and Commit Security Scan (codexstar69/bug-hunter, 519 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Attacking Hardware Interfaces?

trilwu (a GitHub user) maintains it in trilwu/secskills, which has 156 GitHub stars. The repository holds 50 skills in this directory. The repository was last updated on September 4, 2026.

Source: trilwu/secskills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.