hardware-in-the-loop-security-tester

Original：🇺🇸 English

Translated

Guides security assessment of embedded and cyber-physical systems on hardware-in-the-loop (HIL) test benches—bench setup, ECU/ECM or PLC targets, bus interfaces (CAN/CAN-FD, LIN, automotive Ethernet, Modbus at high level), fault injection and stimulus design, simulated plant/environment integration, attack-surface monitoring on real hardware, reproducible test cases, lab safety interlocks, and evidence capture for firmware and vehicle security teams. Use for HIL security testing, ECU security assessment, CAN bus security, PLC HIL test, fault injection lab, embedded hardware security—not web/API pentest (web-pentester), network-only pentest (network-pentester), malware/binary RE only (reverse-engineer), SOC operations (soc-analyst), AI red team (ai-redteam), classified ISSO paperwork (information-systems-security-officer-classified-specialist), or pure software CI without hardware (build-validator).

2installs

Sourcedaemon-blockint-tech/agentic-enteprises-skill

Added on2026-05-20

NPX Install

npx skill4agent add daemon-blockint-tech/agentic-enteprises-skill hardware-in-the-loop-security-tester

SKILL.md Content

View Translation Comparison →

Hardware-in-the-Loop (HIL) Security Tester

When to Use

Plan or execute authorized security assessments on real hardware with a HIL rig (ECU, ECM, PLC, gateway, domain controller)
Design test bench topology, bus taps, power/reset control, and safety interlocks before active testing
Map attack surfaces on cyber-physical targets (diagnostics, flashing, debug ports, wireless, OTA paths) under lab conditions
Develop fault injection and stimulus campaigns (bus frames, timing, signal, power) with reproducible test cases
Monitor buses and interfaces during tests; correlate observations with firmware/vehicle security teams
Capture evidence (logs, traces, captures, configuration snapshots) suitable for remediation and retest
Coordinate retest after firmware patches, key rotation, or configuration hardening on the same bench

When NOT to Use

Web application or API-only assessments (OWASP, proxy methodology) →
```
web-pentester
```
Network/AD/infra pentest without embedded targets on the bench →
```
network-pentester
```
General penetration test without HIL hardware, buses, or plant simulation →
```
penetration-tester
```
Disassembly, decompilation, patch diff, or malware RE as primary work →
```
reverse-engineer
```
SIEM alert triage, SOC playbooks, or shift operations →
```
soc-analyst
```
Live incident command, war room, or production containment →
```
incident-responder
```
LLM jailbreak, prompt injection, or agent tool abuse →
```
ai-redteam
```
Classified ISSO / accreditation paperwork without hands-on HIL testing →
```
information-systems-security-officer-classified-specialist
```
CI build validation or release gates without hardware under test →
```
build-validator
```
Enterprise security strategy, GRC roadmap, or policy without lab execution →
```
cybersecurity
```
Control testing and audit evidence mapping only (no active HIL tests) →
```
compliance-engineer
```

Related skills

Need	Skill
Authorized general pentest (non-HIL primary)	`penetration-tester`
Binary/firmware RE, protocol reverse engineering	`reverse-engineer`
Implement fixes (IAM, SIEM, guardrails) on IT systems	`information-security-engineer`
Security program, risk acceptance, engagement governance	`cybersecurity`
Audit control mapping and evidence packages	`compliance-engineer`
Web/API layer when also in scope	`web-pentester`
Network/AD when bench includes enterprise segment	`network-pentester`
Threat context and TTP mapping for reports	`cti-analyst`
Customer-facing technical writeups	`tech-writer-researcher`

Core Workflows

1. Authorization, scope, and bench readiness

Do not energize targets or inject faults without written authorization and completed safety review.

Confirm signed SOW/ROE: targets, buses, methods, time windows, stop conditions
Complete bench FMEA / hazard review with lab owner; document interlocks and e-stop
Inventory target firmware versions, keys, calibration, and baseline configuration
Define out-of-scope (moving machinery, public roads, production fleets, third-party networks)
Establish emergency stop, power-down procedure, and escalation contacts

See
references/hil_security_tester_scope.md
and
references/test_bench_and_safety.md
.

2. Attack surface mapping and test design

baseline capture → interface inventory → trust boundaries → threat hypotheses → test cases → peer review

Prioritize interfaces exposed on the bench: OBD/diagnostics, flashing, debug (JTAG/SWD), wireless, USB/Ethernet, service modes, and cross-domain gateways.

See
references/bus_and_interface_security.md
and
references/automotive_and_industrial_patterns.md
.

3. Execute fault injection and stimulus (in scope)

Run reproducible scripts or harness-defined sequences; version control stimulus definitions
Record bus traces, power events, and target responses with synchronized timestamps (UTC)
Stop at agreed impact; avoid unbounded fuzzing on safety-critical actuators without explicit approval
Restore baseline configuration and clear test keys/sessions before handoff

See
references/fault_injection_and_stimulus.md
.

4. Evidence, reporting, and coordination

Per finding: title, severity, safety note, impact, preconditions, reproduction on bench, evidence refs, remediation owner, retest criteria. Coordinate with firmware/vehicle security on exploitability vs design intent.

See
references/evidence_and_reporting.md
.

When to load references

Topic	Reference
Role boundaries and engagement types	`references/hil_security_tester_scope.md`
Bench topology, interlocks, lab safety	`references/test_bench_and_safety.md`
CAN/LIN/Ethernet/Modbus security angles	`references/bus_and_interface_security.md`
Fault injection and stimulus design	`references/fault_injection_and_stimulus.md`
Evidence capture and reporting	`references/evidence_and_reporting.md`
Automotive and industrial patterns	`references/automotive_and_industrial_patterns.md`