chipsec
Static analysis of UEFI/BIOS firmware dumps using Intel's chipsec framework. Decode firmware structure, detect known malware and rootkits (LoJax, ThinkPwn, HackingTeam, MosaicRegressor), generate EFI executable inventories with hashes, extract NVRAM variables, and parse SPI flash descriptors. Use when analyzing firmware .bin/.rom/.fd/.cap files offline without requiring hardware access.
- Installs
- 50
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/brownfinesecurity/iothackbot --skill chipsec- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads chipsec automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Chipsec - UEFI Firmware Static Analysis
You are helping the user perform static security analysis of UEFI/BIOS firmware dumps using Intel's chipsec framework. This skill focuses exclusively on offline analysis capabilities that do not require kernel driver access or root privileges.
Tool Overview
Chipsec is Intel's Platform Security Assessment Framework. For static analysis of firmware dumps, it provides:
- EFI executable inventory generation with cryptographic hashes
- Detection of known UEFI malware and vulnerabilities
- Firmware structure decoding and extraction
- NVRAM/UEFI variable extraction
- SPI flash descriptor parsing
- Baseline comparison for change detection
Prerequisites
One-Time Setup (Fix Logging Permission)
Chipsec writes into a logs/ directory inside its install location. Create it once. The Python version in the path varies by system, so derive the path instead of hardcoding it:
CHIPSEC_DIR="$(find /usr/lib/python3*/site-packages ~/.local/lib/python3*/site-packages -maxdepth 1 -name chipsec -type d 2>/dev/null | head -1)"
sudo mkdir -p "$CHIPSEC_DIR/logs"
sudo chmod 777 "$CHIPSEC_DIR/logs"
Verify Installation
chipsec_main --version
Core Commands
All static analysis commands use these flags:
-i: Ignore platform check (required for offline analysis)-n: No kernel driver (required for static analysis)
1. Malware and Vulnerability Scan (Primary Use)
Scan firmware for known threats including UEFI rootkits and SMM vulnerabilities:
chipsec_main -i -n -m tools.uefi.scan_blocked -a <firmware.bin>
Detected Threats:
| Threat | Description | Reference |
|---|---|---|
| HT_UEFI_Rootkit | HackingTeam commercial UEFI rootkit | McAfee ATR |
| MR_UEFI_Rootkit | MosaicRegressor APT UEFI implant | Kaspersky |
| LoJax | First UEFI rootkit found in the wild (Sednit/APT28) | ESET |
| ThinkPwn | SystemSmmRuntimeRt SMM code execution vulnerability | cr4.sh |
| FirmwareBleed | SMM Return Stack Buffer stuffing vulnerability | Binarly |
Example Output (Threat Found):
[!] match 'ThinkPwn.SystemSmmRuntimeRt'
GUID : {7c79ac8c-5e6c-4e3d-ba6f-c260ee7c172e}
[!] found EFI binary matching 'ThinkPwn'
MD5 : 59f5ba825911e7d0dffe06ee0d6d9828
SHA256: 7f0e16f244151e7bfa170b7def014f6a225c5af626c223567f36a8b19f95e3ab
WARNING: Blocked EFI binary found in the UEFI firmware image
2. Generate EFI Executable Inventory
Create a JSON manifest of all EFI modules with cryptographic hashes:
chipsec_main -i -n -m tools.uefi.scan_image -a generate <output.json> <firmware.bin>
Use Cases:
- Create baseline for change detection
- Inventory all DXE drivers, PEI modules, applications
- Generate hashes for threat intelligence lookup
Output Format (efilist.json):
{
"sha256_hash": {
"sha1": "...",
"guid": "EFD652CC-0E99-40F0-96C0-E08C089070FC",
"name": "S3Resume",
"type": "S_PE32"
}
}
3. Compare Against Baseline
Check firmware against a known-good inventory:
chipsec_main -i -n -m tools.uefi.scan_image -a check <baseline.json> <firmware.bin>
Use Cases:
- Detect unauthorized firmware modifications
- Verify firmware update integrity
- Incident response - compare compromised vs clean
4. Decode Firmware Structure
Extract and analyze firmware volumes, files, and sections:
chipsec_util -i -n uefi decode <firmware.bin>
Creates output directory containing:
firmware.bin.dir/
├── firmware_volumes/ # Extracted FV regions
├── efi_files/ # Individual EFI binaries
├── nvram/ # NVRAM variables (if found)
└── ...
5. Extract NVRAM Variables
NVRAM variables are extracted as part of the uefi decode command:
chipsec_util -i -n uefi decode <firmware.bin>
NVRAM output location:
firmware.bin.dir/
├── nvram_.nvram.lst # List of NVRAM variables
├── nvram/ # Extracted variable files (if present)
└── FV/ # Firmware volumes
View extracted variables:
cat firmware.bin.dir/nvram_.nvram.lst
Note: The standalone uefi nvram command requires driver access and cannot be used for static analysis. Use uefi decode instead, which extracts NVRAM as part of the full firmware decode process.
6. Parse SPI Flash Descriptor
Analyze SPI flash regions (requires platform hint):
chipsec_util -p <PLATFORM> spidesc <firmware.bin>
Common Platform Codes:
| Code | Platform |
|---|---|
| SNB | Sandy Bridge (2nd Gen Core) |
| IVB | Ivy Bridge (3rd Gen Core) |
| HSW | Haswell (4th Gen Core) |
| BDW | Broadwell (5th Gen Core) |
| SKL | Skylake (6th Gen Core) |
| KBL | Kaby Lake (7th Gen Core) |
| CFL | Coffee Lake (8th/9th Gen Core) |
| ICL | Ice Lake (10th Gen Core) |
| TGL | Tiger Lake (11th Gen Core) |
| ADL | Alder Lake (12th Gen Core) |
| RPL | Raptor Lake (13th Gen Core) |
Shows:
- Flash regions (Descriptor, BIOS, ME, GbE, PDR)
- Region base addresses and sizes
- Flash component information
- Master access permissions
Supported Firmware Formats
| Extension | Description |
|---|---|
.bin | Raw firmware/SPI flash dumps |
.rom | SPI flash ROM dumps |
.fd | UEFI Firmware Descriptor (OVMF, EDK2) |
.cap | UEFI Capsule update files |
.scap | Signed UEFI Capsule updates |
.fv | UEFI Firmware Volume |
.flash | Full flash dumps |
Workflows
Workflow 1: Standard Security Audit
Complete firmware security assessment:
TARGET="firmware.bin"
OUTPUT_DIR="./chipsec-analysis"
mkdir -p "$OUTPUT_DIR"
# Step 1: Scan for known threats (most important)
echo "[+] Scanning for known malware/vulnerabilities..."
chipsec_main -i -n -m tools.uefi.scan_blocked -a "$TARGET" 2>&1 | tee "$OUTPUT_DIR/threat_scan.txt"
# Step 2: Generate EFI inventory
echo "[+] Generating EFI executable inventory..."
chipsec_main -i -n -m tools.uefi.scan_image -a generate "$OUTPUT_DIR/efi_inventory.json" "$TARGET"
# Step 3: Decode firmware structure
echo "[+] Decoding firmware structure..."
chipsec_util -i -n uefi decode "$TARGET"
# Step 4: Check for NVRAM in decoded output
echo "[+] Checking for extracted NVRAM variables..."
cat "$TARGET.dir/nvram_.nvram.lst" 2>/dev/null || echo "No NVRAM variables extracted"
echo "[+] Analysis complete. Results in: $OUTPUT_DIR/"
echo "[+] Decoded firmware in: $TARGET.dir/"
Workflow 2: Malware Detection Focus
Quick check for known threats:
# Run blocklist scan
chipsec_main -i -n -m tools.uefi.scan_blocked -a firmware.bin 2>&1 | tee scan_results.txt
# Check for any matches
echo "[+] Checking for threat matches..."
grep -E "match|found|WARNING" scan_results.txt
# If threats found, get details
grep -A10 "found EFI binary matching" scan_results.txt
Workflow 3: Firmware Update Verification
Compare before/after firmware update:
# Before update - create baseline
chipsec_main -i -n -m tools.uefi.scan_image -a generate baseline_before.json firmware_original.bin
# After update - compare
chipsec_main -i -n -m tools.uefi.scan_image -a check baseline_before.json firmware_updated.bin
# Also generate new inventory for diff analysis
chipsec_main -i -n -m tools.uefi.scan_image -a generate baseline_after.json firmware_updated.bin
# Compare inventories
diff baseline_before.json baseline_after.json
Workflow 4: Incident Response
Analyze potentially compromised firmware:
SUSPECT="compromised_dump.bin"
KNOWN_GOOD="golden_image.bin"
OUTPUT_DIR="./ir-analysis"
mkdir -p "$OUTPUT_DIR"
# 1. Immediate threat scan
echo "[!] Scanning for known implants..."
chipsec_main -i -n -m tools.uefi.scan_blocked -a "$SUSPECT" 2>&1 | tee "$OUTPUT_DIR/threat_scan.txt"
# 2. Generate inventory of suspect firmware
chipsec_main -i -n -m tools.uefi.scan_image -a generate "$OUTPUT_DIR/suspect_inventory.json" "$SUSPECT"
# 3. If golden image available, compare
if [ -f "$KNOWN_GOOD" ]; then
chipsec_main -i -n -m tools.uefi.scan_image -a generate "$OUTPUT_DIR/golden_inventory.json" "$KNOWN_GOOD"
echo "[+] Comparing against known-good baseline..."
chipsec_main -i -n -m tools.uefi.scan_image -a check "$OUTPUT_DIR/golden_inventory.json" "$SUSPECT"
fi
# 4. Full decode for manual analysis
chipsec_util -i -n uefi decode "$SUSPECT"
echo "[+] IR analysis complete. Review: $OUTPUT_DIR/"
Workflow 5: IoT Device Firmware Analysis
Analyze firmware extracted from IoT device:
# After extracting firmware with ffind or binwalk
IOT_FIRMWARE="extracted_firmware.bin"
# Quick threat check
chipsec_main -i -n -m tools.uefi.scan_blocked -a "$IOT_FIRMWARE"
# Generate inventory for documentation
chipsec_main -i -n -m tools.uefi.scan_image -a generate iot_efi_list.json "$IOT_FIRMWARE"
# Extract structure for deeper analysis
chipsec_util -i -n uefi decode "$IOT_FIRMWARE"
# NVRAM variables extracted as part of decode - check output
cat "$IOT_FIRMWARE.dir/nvram_.nvram.lst" 2>/dev/null
Output Interpretation
Exit Codes
| Code | Meaning |
|---|---|
| 0 | All checks passed, no issues found |
| 2 | Security issues detected (FAILED tests) |
| 16 | Module execution errors |
| 128 | Module not applicable |
Result States
| State | Meaning | Action |
|---|---|---|
| PASSED | No known threats detected | Document and proceed |
| WARNING | Potential issue found | Investigate further |
| FAILED | Security vulnerability confirmed | Remediate immediately |
| NOT APPLICABLE | Test couldn't run | Check firmware format |
Interpreting Threat Matches
When scan_blocked finds a match:
[!] match 'ThinkPwn.SystemSmmRuntimeRt'
GUID : {7c79ac8c-5e6c-4e3d-ba6f-c260ee7c172e}
regexp: bytes '...' at offset 1184h
[!] found EFI binary matching 'ThinkPwn'
MD5 : 59f5ba825911e7d0dffe06ee0d6d9828
SHA1 : 4979bc7660fcf3ab5562ef2e1c4c45097ecb615e
SHA256: 7f0e16f244151e7bfa170b7def014f6a225c5af626c223567f36a8b19f95e3ab
Key Information:
- Threat Name: Which known threat was matched
- GUID: Unique identifier of the affected EFI module
- Hashes: For further threat intelligence lookup
- Offset: Location in binary where pattern matched
Integration with IoTHackBot Tools
With ffind (Firmware Extraction)
# Find firmware files in extracted filesystem
ffind /path/to/extracted -a
# Analyze found UEFI firmware
chipsec_main -i -n -m tools.uefi.scan_blocked -a found_firmware.bin
With binwalk (Pre-processing)
# Extract firmware components first
binwalk -e firmware_package.bin
# Find and analyze UEFI images
find _firmware_package.bin.extracted -name "*.fd" -o -name "*.rom" | while read fw; do
echo "[+] Analyzing: $fw"
chipsec_main -i -n -m tools.uefi.scan_blocked -a "$fw"
done
Troubleshooting
Permission Denied on Logs
PermissionError: [Errno 13] Permission denied: '.../site-packages/logs/...'
Solution: create the logs directory inside the chipsec install (the Python version in the path varies, so derive it):
CHIPSEC_DIR="$(find /usr/lib/python3*/site-packages ~/.local/lib/python3*/site-packages -maxdepth 1 -name chipsec -type d 2>/dev/null | head -1)"
sudo mkdir -p "$CHIPSEC_DIR/logs"
sudo chmod 777 "$CHIPSEC_DIR/logs"
Module Not Found
ERROR: No module named 'chipsec.modules.tools.uefi.scan_blocked'
Solution: Verify chipsec installation:
pip show chipsec
pip install --upgrade chipsec
Invalid Firmware Format
[CHIPSEC] Found 0 EFI executables in UEFI firmware image
Possible Causes:
- File is not valid UEFI firmware
- File is encrypted or compressed
- File needs pre-processing (binwalk extraction)
Diagnosis:
file firmware.bin
binwalk firmware.bin
Platform Required for spidesc
ERROR: This module requires a configuration to be loaded.
Solution: Specify platform with -p:
chipsec_util -p SKL spidesc firmware.bin
NVRAM Not Extracted
If nvram_.nvram.lst is empty or shows an error after decode:
Possible Causes:
- Firmware doesn't contain standard NVRAM format
- NVRAM region is encrypted or compressed
- Non-standard vendor format
Alternative Analysis:
# Search for variable-like patterns in decoded output
grep -r "Setup\|Boot\|SecureBoot" firmware.bin.dir/
# Use binwalk to find NVRAM signatures
binwalk -R "\x06\x00\x00\x00" firmware.bin
Best Practices
1. Always Run Threat Scan First
The blocklist scan is quick and catches known threats:
chipsec_main -i -n -m tools.uefi.scan_blocked -a firmware.bin
2. Generate Inventory for Every Firmware
Create baselines for future comparison:
chipsec_main -i -n -m tools.uefi.scan_image -a generate "$(basename firmware.bin .bin)_inventory.json" firmware.bin
3. Save All Output
Redirect output for documentation:
chipsec_main -i -n -m tools.uefi.scan_blocked -a firmware.bin 2>&1 | tee analysis_$(date +%Y%m%d).txt
4. Verify Firmware Format First
Before running chipsec:
file firmware.bin
binwalk firmware.bin | head -20
5. Use Organized Output Directories
mkdir -p analysis/{threats,inventories,decoded,nvram}
6. Cross-Reference with Other Tools
- UEFITool: Visual firmware structure analysis
- binwalk: Entropy analysis and extraction
- strings: Quick secrets/URL discovery
Command Reference
Quick Reference Table
| Task | Command |
|---|---|
| Scan for malware | chipsec_main -i -n -m tools.uefi.scan_blocked -a <fw> |
| Generate inventory | chipsec_main -i -n -m tools.uefi.scan_image -a generate <out.json> <fw> |
| Compare baseline | chipsec_main -i -n -m tools.uefi.scan_image -a check <base.json> <fw> |
| Decode structure + NVRAM | chipsec_util -i -n uefi decode <fw> |
| Parse SPI descriptor | chipsec_util -p <PLAT> spidesc <fw> |
Flag Reference
| Flag | Purpose |
|---|---|
-i | Ignore platform check (required for offline) |
-n | No kernel driver (required for static analysis) |
-m | Specify module to run |
-a | Module arguments |
-p | Specify platform (for spidesc) |
-j | JSON output file |
Security and Ethics
IMPORTANT: Only analyze firmware you own or have explicit authorization to analyze.
- Respect intellectual property and licensing
- Follow responsible disclosure for vulnerabilities found
- Document all analysis activities
- Be aware that some firmware may contain proprietary code
- Use findings for defensive security purposes only
Success Criteria
A successful chipsec static analysis includes:
- Threat scan completed (PASSED or findings documented)
- EFI inventory JSON generated with module hashes
- Firmware structure decoded (if applicable)
- NVRAM variables extracted (if present)
- All findings documented with:
- Threat name and severity
- Affected module GUID and hashes
- Recommendations for remediation
- Output files organized and saved for reporting
FAQ
What does the chipsec skill do?
Static analysis of UEFI/BIOS firmware dumps using Intel's chipsec framework. Decode firmware structure, detect known malware and rootkits (LoJax, ThinkPwn, HackingTeam, MosaicRegressor), generate EFI executable inventories with hashes, extract NVRAM variables, and parse SPI flash descriptors. Use when analyzing firmware .bin/.rom/.fd/.cap files offline without requiring hardware access.
How do I install chipsec?
Run npx skills add https://github.com/brownfinesecurity/iothackbot --skill chipsec in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/chipsec/ (personal) or .claude/skills/chipsec/ (project).
Which AI agents can use chipsec?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is chipsec safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains chipsec?
It is published by brownfinesecurity in brownfinesecurity/iothackbot. It has 50 recorded installs.
More from brownfinesecurity/iothackbot
apktool
brownfinesecurity/iothackbot
Android APK unpacking and resource extraction tool for reverse engineering. Use when you need to decode APK files, extract resources, examine AndroidManifest.xml, analyze smali code, or repackage modified APKs.
jadx
brownfinesecurity/iothackbot
Android APK decompiler that converts DEX bytecode to readable Java source code. Use when you need to decompile APK files, analyze app logic, search for vulnerabilities, find hardcoded credentials, or understand app behavior through readable source code.
nmap
brownfinesecurity/iothackbot
Professional network reconnaissance and port scanning using nmap. Supports various scan types (quick, full, UDP, stealth), service detection, vulnerability scanning, and NSE scripts. Use when you need to enumerate network services, detect versions, or perform network reconnaissance.
telnetshell
brownfinesecurity/iothackbot
Use telnet to interact with IoT device shells for pentesting operations including device enumeration, vulnerability discovery, credential testing, and post-exploitation. Use when the user needs to interact with network-accessible shells, IoT devices, or telnet services.
Popular security skills
azure-compliance
microsoft/azure-skills
Run Azure compliance and security audits with azqr plus Key Vault expiration checks. Covers best-practice assessment, resource review, policy/compliance validation, and security posture checks. WHEN: compliance scan, security audit, BEFORE running azqr (compliance cli tool), Azure best practices, Key Vault expiration check, expired certificates, expiring secrets, orphaned resources, compliance assessment.
minimal-run-and-audit
lllllllama/rigorpilot-skills
Rigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation command and write standardized reprooutputs/ files, including patch notes when repository files changed. Do not use for training execution, initial repo intake, generic environment setup, paper lookup, target selection, hidden scientific-meaning changes, or end-to-end orchestration by itself.
seo-audit
coreyhaines31/marketingskills
When the user wants to audit, review, or diagnose SEO issues on their site. Also use when the user mentions "SEO audit," "technical SEO," "why am I not ranking," "SEO issues," "on-page SEO," "meta tags review," "SEO health check," "my traffic dropped," "lost rankings," "not showing up in Google," "site isn't ranking," "Google update hit me," "page speed," "core web vitals," "crawl errors," "indexing issues," "stuck on page 2," "striking distance keywords," "title tag rewrite," "low CTR," "local SEO," "Google Business Profile," or "map pack." Use this even if the user just says something vague like "my SEO is bad" or "help with SEO" — start with an audit. For building pages at scale to target keywords, see programmatic-seo. For adding structured data, see schema. For AI search optimization, see ai-seo.
firebase-security-rules-auditor
firebase/agent-skills
Audits Firebase (Firestore, Cloud Storage) security rules for vulnerabilities, privilege escalation, role bypasses, create vs update inconsistencies, resource exhaustion, type safety, size limits, and hasOnly ownership checks. Use when auditing/reviewing rules, running red-team rule assessments, or scoring against auditor checklists. Don't use for Firebase CLI (login, deploy), Auth, Crashlytics, Remote Config, or database queries.
audit
pbakaus/impeccable
Run technical quality checks across accessibility, performance, theming, responsive design, and anti-patterns. Generates a scored report with P0-P3 severity ratings and actionable plan. Use when the user wants an accessibility check, performance audit, or technical quality review.
competitors
coreyhaines31/marketingskills
When the user wants to create competitor comparison or alternative pages for SEO and buyer-facing use. Also use when the user mentions 'alternative page,' 'vs page,' 'competitor comparison,' 'comparison page,' '[Product] vs [Product],' '[Product] alternative,' 'competitive landing pages,' 'how do we compare to X,' 'competitor teardown,' 'audit our competitor pages,' 'are our comparison pages out of date,' or 'competitive asset audit.' Use this for any content that positions your product against competitors. Covers four formats: singular alternative, plural alternatives, you vs competitor, and competitor vs competitor. For auditing existing claims (not researching competitors from scratch, which is competitor-profiling; not technical SEO on these pages, which is seo-audit), use the asset audit here. For internal battle cards and sales-specific competitor docs, see sales-enablement.