Skip to content
Get packs

Guide · Agent skill

How to use the Auditing UEFI Firmware with CHIPSEC agent skill

Updated · written with AI from the project's own documentation and checked against our catalogue data

This guide explains what the auditing-uefi-firmware-with-chipsec agent skill does, how to install it, and how to ask an agent for a firmware-security check using Intel's open-source CHIPSEC framework. It is written for readers who have not used agent skills before. By the end you will know how to install the skill, which prerequisites your machine needs, how to phrase requests, and which safety limits to respect.

Auditing UEFI Firmware with CHIPSECmukul975/Anthropic-Cybersecurity-Skills · Apache-2.0

Quick start

  1. 1Download and unzip the skill. Download the ZIP from this page and unzip it. You should see the auditing-uefi-firmware-with-chipsec folder containing SKILL.md, scripts/agent.py and the references folder.
  2. 2Place or upload the skill. Copy the folder into ~/.claude/skills/ for personal use or into .claude/skills/ in a project. Alternatively, upload the ZIP in the Claude apps under Settings → Capabilities → Skills.
  3. 3Install CHIPSEC. Run pip install chipsec, or build from source. Then confirm with sudo chipsec_main --help and sudo chipsec_util --help.
  4. 4Confirm authorization and hardware. Check that you own the machine or have written authorization, and that it is dedicated test hardware if you plan to run anything beyond read-only checks.
  5. 5Ask for the check in plain language. Describe the goal, such as a baseline or a flash dump, and name the machine. The agent will choose the matching CHIPSEC commands.
  6. 6Review the results. Look at PASS, FAIL and WARNING results. Treat a FAIL on bios_wp or spi_lock as a high-priority finding to investigate.

What this skill makes the agent do

CHIPSEC is Intel's open-source Platform Security Assessment Framework. It inspects the firmware layer below the operating system, meaning the BIOS/UEFI image stored on the SPI flash chip, to check whether protections against firmware tampering are switched on.

This skill teaches the agent to run the CHIPSEC test suite, interpret PASS, FAIL and WARNING results, dump the firmware image for offline comparison, and list UEFI variables. A bundled helper script wraps the CHIPSEC command-line tools to run a baseline and parse the output.

  • Check BIOS write protection (BIOS_CNTL BLE/SMM_BWP and SPI Protected Ranges)
  • Check the SPI flash descriptor lock (FLOCKDN)
  • Check SMRAM/SMRR and SMM BIOS write protection
  • Check Secure Boot variable protection and S3 boot-script protection
  • Dump SPI flash and decode it for offline analysis
  • Enumerate and triage UEFI variables

How do you install the skill?

Skills are folders of instructions and scripts that an agent loads when a task matches them. This skill is distributed as a ZIP file from this page. You can install it in one of two ways.

Option 1 is a personal install for Claude Code. Download the ZIP, unzip it, and place the skill folder in ~/.claude/skills/. Option 2 is a project install: put it in the .claude/skills/ folder of a specific project. Option 3 is to upload the ZIP in the Claude apps under Settings → Capabilities → Skills.

  • Personal: ~/.claude/skills/
  • Project: .claude/skills/ inside your project folder
  • Claude apps: Settings → Capabilities → Skills, then upload the ZIP

What do you need before running it?

The skill runs CHIPSEC on the local machine, so you need a Python environment and CHIPSEC itself. The source lists these requirements: Python 3.8 or newer, CHIPSEC (installed with pip or built from source), root or Administrator access, and on Linux a C compiler to build the kernel driver. The target must be an x86 platform. Dedicated test hardware is recommended.

You can install CHIPSEC from PyPI or from source. The source-build route also builds the kernel helper and driver.

  • Python 3.8+
  • CHIPSEC via pip or from source
  • Root (Linux) or Administrator (Windows)
  • C compiler and build tools for the Linux kernel driver
  • x86 platform (Intel or AMD)
pip install chipsec # Or from source git clone https://github.com/chipsec/chipsec cd chipsec python setup.py install # Verify sudo chipsec_main --help sudo chipsec_util --help

How do you ask the agent to run it?

You do not need to type CHIPSEC commands yourself. Describe the outcome you want in plain language and name the machine and the kind of check. The agent should pick the matching workflow from the skill.

Requests work best when they say whether the goal is a baseline, a single control, a firmware dump, or variable triage. If you want a report, say so, because the skill saves machine-readable output such as JSON, XML and a log.

  • "Run a firmware-security baseline on this laptop and tell me which checks failed."
  • "Check whether BIOS write protection and the SPI flash lock are enabled on this test server."
  • "Dump the SPI flash to rom.bin and decode it so we can compare it with the vendor image."
  • "List the UEFI variables on this machine and flag anything unexpected."
  • "Verify Secure Boot variable protection, read-only, without modifying anything."

What commands does the agent run?

For a full run, the agent uses chipsec_main with no module argument, which checks every applicable control for the detected platform. It can save results as JSON, XML and a log. The core firmware-protection checks can be run one at a time, for example the common.bios_wp module for BIOS write protection and common.spi_lock for the flash descriptor lock.

To inspect flash regions and access permissions, the agent uses chipsec_util. A FAIL on common.bios_wp or common.spi_lock means firmware could be rewritten from the OS, which is the precondition for the MITRE ATT&CK technique T1542.001 (Pre-OS Boot: System Firmware).

sudo chipsec_main sudo chipsec_main -j results.json -x results.xml -l chipsec.log sudo chipsec_main -m common sudo chipsec_main -m common.bios_wp sudo chipsec_main -m common.spi_lock sudo chipsec_main -m common.secureboot.variables sudo chipsec_util spi info

How do you dump firmware and triage UEFI variables?

Dumping the SPI flash gives you a file you can decode and compare against a known-good OEM image. The agent dumps the flash, decodes the firmware volumes, and can hash firmware volumes to look for unauthorized changes. Any difference is a reason to investigate, not automatic proof of an implant.

For UEFI variables, the agent lists runtime variables, finds named variables in the SPI image, and decodes the UEFI structure.

  • Compare the dump against the OEM's known-good image
  • Record the platform, BIOS version and every FAIL or WARNING with relevant register values
sudo chipsec_util spi dump rom.bin sudo chipsec_util decode rom.bin sudo chipsec_util uefi var-list sudo chipsec_util uefi var-find PK sudo chipsec_util uefi decode rom.bin

What safety limits should you follow?

CHIPSEC loads a kernel driver and reads and writes low-level hardware registers, SPI flash and SMM. Run it only on systems you own or are explicitly authorized to assess, ideally on dedicated test hardware. The skill warns that misuse, especially write or modify modules, can brick a machine.

Never run write-capable modules on production systems. The active write test on Secure Boot variables should only be run on test hardware. If the driver cannot load, you can use the no-driver option for a limited, read-only subset of checks.

  • Use only on machines you own or have written authorization to test
  • Do not run write or modify modules (such as -a modify) on production systems
  • Expect some checks to be unavailable under locked-down Secure Boot
  • Scripts run locally; the source says this skill does not use the network
sudo chipsec_main -n sudo chipsec_main -p <PLATFORM>

What people use it for

  • Establishing a firmware-security baseline for a new laptop or server image before deployment
  • Checking that OEM firmware has BIOS write protection and the SPI flash lock enabled
  • Dumping SPI flash from a suspect machine and comparing it with a known-good vendor image
  • Verifying Secure Boot variable protection and S3 boot-script protection on test hardware
  • Teaching how UEFI write protection and Secure Boot variable protection are verified

Frequently asked questions

How do I install the auditing UEFI firmware with CHIPSEC skill?

Download the ZIP from this page and unzip it. Place the folder in ~/.claude/skills/ for personal use or in .claude/skills/ in a project, or upload the ZIP in the Claude apps under Settings → Capabilities → Skills.

What do I need to run CHIPSEC with this skill?

You need Python 3.8 or newer, CHIPSEC installed with pip or from source, root or Administrator access, and on Linux a C compiler for the kernel driver. The target should be an x86 platform, and dedicated test hardware is recommended.

Is the skill free to use?

The skill is licensed under Apache-2.0, as stated on this page. CHIPSEC is described in the source as open-source, and the skill's source lists its project and documentation links. Check the license files in each project for the full terms.

Does CHIPSEC work without a kernel driver?

Partly. Running chipsec_main with the -n (--no_driver) flag skips checks that need the driver, so some read-only checks still run. Locked-down Secure Boot can prevent the driver from loading.

What should I do if CHIPSEC cannot detect my platform?

Force the platform code with the -p option, for example sudo chipsec_main -p <PLATFORM>. The source says this is for when auto-detection fails.

How does CHIPSEC compare with other firmware tools?

The source does not compare CHIPSEC with other tools. It focuses on checking hardware and firmware protection controls on x86 platforms and on dumping and listing firmware data. The source lists UEFITool as a related tool for working with UEFI images.

New agent skills, repos and AI tools — every week

The best new skills and open-source projects, the fastest-growing repos, and one free prompt. Five minutes to read. Unsubscribe anytime.

Our verdict

This skill suits security engineers, forensic analysts and students who need repeatable firmware-protection checks on hardware they own or are authorized to test. It is not suited to production machines where write-capable modules would be run, to non-x86 platforms, or to anyone without root or Administrator access.

Download the skill