Firmware Acquisition · Platform Security · Offline Analysis

GGSec Firmware Toolkit

Security evidence below the operating system

GGFW is GGSEC's read-only firmware acquisition and platform-security framework for Windows and UEFI environments. It combines live hardware evidence, verified SPI and GPU firmware acquisition, offline binary analysis and configuration correlation in one reproducible workflow.

Version

v0.6.5 Beta

Operation

Read-only

Environments

Windows + UEFI
Three operating modes

One workflow across live systems and offline images

Unlike a simple configuration checker, GGFW records the detected platform profile, confidence level, raw evidence and interpretation path behind every security verdict.

Live Windows Assessment

Collect chipset, CPU, PCI, SPI, SMM, memory, Secure Boot and platform-lock evidence through the signed GGFW Windows driver.

  • Platform information
  • Platform-security checks
  • Secure Boot variable evidence
  • Live-to-image access comparison

Pre-OS UEFI Environment

Boot GGFW independently of the installed operating system to inspect the platform, acquire firmware evidence and store timestamped reports on USB media.

  • BOOTX64.EFI workflow
  • BIOS-region acquisition
  • GPU device enumeration
  • Pre-OS platform assessment

Offline Firmware Analysis

Analyse previously acquired SPI, BIOS, update and Option ROM images without accessing the source hardware.

  • SPI and BIOS-region images
  • Intel descriptor and FPT structures
  • UEFI volumes, NVRAM and FIT
  • GPU Option ROM chains
Evidence-driven platform security

Validate protections, then correlate the evidence

ggfw --platform-security
GGSec Firmware Toolkit v0.6.5 Beta Module: platform security checks [FAIL] common.bios_wp BLE=0 · SMM_BWP=0 · PR coverage incomplete [OK] common.spi_lock FLOCKDN=1 · controller configuration locked [OK] common.smrr range=0xDF800000-0xDFFFFFFF · valid=1 [FAIL] common.memconfig required locks: 0xFFF · locked: 0xFFD Security posture: FAIL PASS=7 · FAIL=6 · WARN=2 · PARTIAL=1

Controller lockdown alone does not prove BIOS write protection. GGFW correlates the complete protection state before issuing a verdict.

Core capabilities

From raw flash image to structured evidence

Platform Discovery

Automatic discovery of CPU, host bridge, PCH/eSPI and SPI-controller access model with explicit confidence grading.

  • EXACT / FAMILY / GENERIC / UNKNOWN confidence
  • PCI, CPUID and chipset evidence
  • JEDEC vendor and flash capacity

Verified Firmware Acquisition

Full and ranged SPI acquisition with automatic flash-size detection, resume support, read-back verification and SHA-256 evidence.

  • No erase or programming functionality
  • Progress and throughput monitoring
  • Windows hardware sequencing and UEFI acquisition

Platform Security Assessment

BIOS/SPI protection, SMM and CPU trust controls, PCH configuration, DMA evidence and Secure Boot configuration evidence.

  • PASS, FAIL, WARN, INFO, N/A, ERROR and PARTIAL states
  • Unsupported and not-applicable conditions stay explicit

Offline Firmware Analysis

Classify images and inspect Intel platform structures, UEFI volumes, NVRAM, FIT, microcode and integrity evidence.

  • Structural integrity is reported separately from cryptographic authenticity
  • Per-region and per-partition hashes

GPU Firmware

Enumerate display devices, acquire PCI Option ROMs, validate PC-AT and EFI/GOP image chains and extract embedded GPU firmware from larger images.

  • Two independent reads before saving
  • 55 AA, PCIR, VID:DID and checksum validation

Live/Image Correlation

Compare active SPI-controller access evidence with descriptor configuration stored inside the acquired firmware image.

  • MATCH does not automatically mean SECURE
  • VERIFIED does not automatically mean PROTECTED

Firmware Implant Triage

Heuristic PE/DXE/PEI module analysis across nested and compressed UEFI volumes to surface implants and dual-use persistence hiding among legitimate firmware.

  • W+X, entropy, host-OS API/DLL and injection-primitive scoring
  • Interesting-module extraction (.HIT) + YARA integration
  • Heuristic triage, reported separately from any verdict

Deep NVRAM & Variable Store

Parse and export EDK2 VSS/VSS2, AMI NVAR (dual-bank dedupe), Phoenix EVSA and Insyde FDC recovery stores, with Secure Boot variable evidence and primary-vs-recovery diff.

  • Per-variable SHA-256 and attribute policy
  • Live Secure Boot vs offline store correlation

Runtime ME / HECI

Query the Intel Management Engine version at runtime over HECI (MKHI GET_FW_VERSION), with offline ME/CSE version candidates from the SPI image as fallback.

  • HECI device inventory and Host Firmware Status
  • Advisory SA-era hints only — never an auto-confirmed CVE

Engagement Package

One command produces a client-ready evidence bundle: offline analysis, PE hits, NVRAM export, Secure Boot correlation, S3 boot script, MEI, and an executive SUMMARY + hashed MANIFEST.

  • Optional golden-vs-suspect image diff
  • Reproducible, timestamped, SHA-256 artifacts
See it in action

Finding a firmware-resident implant in a real BIOS

Offline engagement against a real OEM notebook BIOS image. The PE/DXE triage flagged one high-interest module among 188 legitimate ones; analyst identification confirmed a firmware-resident anti-theft persistence agent (Absolute Computrace / LoJack) — a legitimate OEM feature that behaves, technically, like an implant.

ggfw --engagement bios.bin --offline-only --yara tools/yara
GGSec Firmware Toolkit v0.6.5 Beta UEFI PE/DXE module risk scan scanned: volumes=3 files=225 executables=188 pe_te=188 findings: high=1 medium=1 interesting_modules=1 Interesting PE/DXE modules (triage priority) [WARN] #1 score=53 guid=9E69ABDE-...-C60F666D96B6 type=APPLICATION pe=PE32+ reasons=pe_suspicious_string, pe_host_injection_api hot_imports=CreateRemoteThread, VirtualAllocEx, WriteProcessMemory [OK] YARA: GGFW_HostImplant_ApiStrings (1 match) -- analyst identification -- "Computrace V90.915" rpcnetp.exe AUTOCHK.EXE:BAK -> svchost injection -> HTTP C2 VERDICT: Absolute Computrace / LoJack anti-theft persistence (dual-use)

Heuristic triage surfaced the module in seconds; identification is analyst-led. Image vendor anonymised — the component ships across many notebook brands.

Acquisition trust boundary

Software evidence and hardware reference dumps

GGFW provides read-only software-side evidence collection and correlation. In suspected firmware compromise cases, external hardware acquisition may still be required as the forensic reference method.

Hardware Dump vs. Software Dump of SPI Flash

Learn why a software dump is useful for trusted systems and diagnostics, but should not be treated as final proof of firmware integrity on a potentially compromised host.

Read methodology note →
Safe by design

Built to collect evidence, not modify the platform

Read-only architecture

No SPI erase, no SPI programming, no general-purpose MMIO write interface, no general-purpose PCI write interface and no public MSR write interface.

Restricted low-level access

Driver operations are restricted to allowlisted reads and accessible only to Administrators and SYSTEM.

Evidence preservation

Read-back verification, SHA-256 artifact hashes, timestamped names, anonymous machine IDs and non-overwriting report output.

Reporting and automation

From raw registers to reproducible evidence

Human-readable output

Clear module verdicts such as [FAIL] common.bios_wp, [OK] common.spi_lock and [N/A] common.smm_lock.

JSON automation

Stable module identifiers, schema-based results, evidence fields, confidence levels and machine-readable status values.

Audit artifacts

Timestamped reports, firmware dumps, SHA256 files, offline-analysis JSON and release manifests for repeatable review.

Read-onlyplatform evidence collection
SPI + GPUfirmware acquisition
Text + JSONreporting outputs
Betaprivate evaluation access

Request a firmware security assessment

GGSEC performs acquisition, platform-security validation and analyst-led firmware investigation using GGFW and complementary laboratory tooling.