The Anomaly

The PAAX fixture contained a valid PE header but an adversarial .text section with SizeOfRawData = 0xFFFFFFFF, a pattern commonly produced by packers, loaders, and malware staging pipelines. Windows treats this as loadable in data-mapping mode but many tools do not.

PAAX classified the sample under its anomaly taxonomy:

• VRD‑I — Raw‑truncated section
• STI‑A — Stale or inconsistent metadata
• LPM‑3 — Loadable as data image, not executable
• AIL‑3 — Minimal, controlled samples designed to probe loader semantics

These codes refer to the PAAX anomaly taxonomy .

Cross‑Loader Behaviour

PAAX validated the fixture across Windows, independent parsers, and Ghidra to reveal the divergence:

This is the exact class of divergence PAAX is designed to uncover: Windows loads it — your tool fails.

Root Cause

Ghidra trusted the declared SizeOfRawData without validating it against file length. It attempted to allocate and read a region far beyond the end of the file, triggering an uncaught exception and aborting import.

Windows, by contrast:

• maps available bytes
• zero‑fills the remainder
• treats the image as valid when mapped as a data file

This mismatch is a classic loader–tool divergence .

Resolution

After the adversarial context was clarified, Ghidra maintainers accepted the issue, scheduled it for the 12.2 milestone, and implemented a fix that:

• treats negative or clearly invalid SizeOfRawData as suspicious and substitutes VirtualSize
• clamps oversized SizeOfRawData so reads never extend beyond the end of file
• maps available bytes and zero‑fills the remainder
• emits warnings instead of aborting import
• aligns behaviour with Windows' permissive data‑mapping semantics

This is a direct example of PAAX driving correctness improvements in a major RE platform.

Why This Matters

Malformed‑but‑valid PE structures appear in:

• packer mutation pipelines
• malware staging chains
• custom loaders and crypters
• exploit‑chain payloads

Tools that mishandle these structures suffer:

• incorrect disassembly and decompilation
• broken feature extraction
• silent misclassification
• crashes in production pipelines

PAAX provides deterministic, Windows‑aligned adversarial testing to prevent these failures.

Test Your Loader with PAAX

If you maintain a loader, ship a detection engine, or build an RE platform, PAAX gives you a systematic way to validate correctness under adversarial PE conditions.

Request vendor evaluation →

The DFIR Reality

Modern incidents involve binaries that:

• abuse section tables and RVA/Raw mapping
• misreport sizes, alignments, and metadata
• embed Windows‑tolerant corruption
• use packer‑style anomalies to evade tooling

Windows maps these structures, but many DFIR tools don’t. That mismatch leads to silent misanalysis - the most dangerous failure mode in incident response.

What PAAX gives DFIR Teams

• Correctness under adversarial conditions: PAAX models real packer and loader behaviours, not synthetic fuzz noise.
• Cross‑tool clarity: See where Windows, Ghidra, IDA, Binary Ninja, r2, and your internal tools disagree. (cross‑tool differentials)
• Fewer mid‑incident failures: Identify crash‑class and misanalysis‑class behaviours before they derail investigations.
• Windows‑aligned analysis: Treat Windows loader semantics as the ground truth, because attackers do.

Why This Matters for DFIR

When a tool silently misinterprets a malformed‑but‑valid PE, analysts lose hours chasing ghosts. Worse, reports become unreliable. PAAX gives DFIR teams a way to validate their toolchain against the exact adversarial structures seen in:

• packer mutation pipelines
• malware staging chains
• custom loaders
• exploit‑chain payloads

If Windows loads it, PAAX tests it.

Outcome for DFIR teams

• more reliable triage under pressure
• fewer false leads and dead-ends
• more trustworthy disassembly and decompilation
• clear understanding of tool behaviour under adversarial stress

Request DFIR evaluation →

The Vendor Problem

Attackers increasingly rely on malformed‑but‑valid PE structures, the kind Windows maps without complaint in data-mapping mode, but most analysis pipelines mishandle. These structures appear in:

• packer mutation pipelines
• custom loaders and crypters
• malware staging chains
• exploit‑chain payloads
• fuzz‑resistant or fuzz-hostile obfuscators

If your loader diverges from Windows semantics, you get:

• broken feature extraction
• mis‑mapped sections and RVAs
• incorrect disassembly or decompilation
• silent misclassification
• crashes in production pipelines

PAAX is built to surface these failures before your customers do.

What PAAX Does for Vendors

• Deterministic adversarial corpus: Every anomaly is intentional, reproducible, and grounded in Windows‑aligned semantics, not fuzz noise.
• Cross‑tool behavioural mapping: Compare your loader to Windows, Ghidra, IDA, Binary Ninja, r2, and others. (cross‑tool differentials)
• CI/CD regression harness: Prevent correctness regressions across releases with a curated adversarial suite.
• Custom anomaly design: Target your proprietary loader code paths with vendor‑specific fixtures.
• Loader‑model validation: Ensure your tool matches Windows behaviour where it matters, and intentionally diverges where your threat model requires.

Why Vendors Choose PAAX

• Detection integrity: Your ML features, heuristics, and signatures depend on correct parsing.
• Competitive correctness profile: Demonstrate that your loader handles adversarial structures better than others.
• Reduced support burden: Fewer “your tool crashed on this sample” tickets from customers.
• Better engineering visibility: Understand exactly which PE anomalies your loader tolerates, rejects, or mishandles.

Outcome for Vendors

• stronger detection under adversarial PE structures
• fewer silent failures in production pipelines
• more reliable unpacking and feature extraction
• loader correctness aligned with real‑world Windows mapping semantics
• a correctness story you can confidently tell customers

Request vendor evaluation →

PAAX Core

For: small research teams, internal RE units, academic groups.

• Access to the curated PAAX adversarial corpus (e.g. PAAX‑300)
• Annual corpus updates
• Baseline cross‑tool behavioural map
• Email support

PAAX Enterprise

For: AV/EDR vendors, RE tool vendors, sandbox providers.

• Full anomaly set (PAAX‑1000+)
• Quarterly updates
• Full cross‑tool behavioural matrix
• CI/CD regression harness
• Windows loader differential suite
• Baseline custom anomaly design for proprietary loaders
• Priority support

PAAX Enterprise+

For: high‑assurance environments and vendors with strict correctness guarantees.

• Everything in Enterprise
• Monthly updates
• Integration support
• Dedicated Slack/Teams channel
• Unlimited custom anomaly design for proprietary loaders
• Annual hardening workshop
• Vendor-specific research collaboration

Pricing is scoped per organisation and per toolchain. If you’re evaluating PAAX for your loader or detection pipeline, reach out and we’ll define a package that fits your environment.

Start a pricing conversation →

Our Mission

Enterprise security depends on accurate binary analysis. But malformed‑but‑valid PE structures, the kind routinely produced by packers, loaders, and malware staging chains, expose blind spots in RE tools, detection engines, and DFIR pipelines. PAAX exists to systematically identify and eliminate these blind spots through reproducible, Windows‑aligned adversarial testing.

What We Build

• Deterministic adversarial PE corpus: engineered fixtures that model real attacker behaviours, not fuzz noise.
• Loader‑correctness validation: differential testing against Windows’ actual mapping semantics.
• Cross‑tool behavioural analysis: visibility into how Ghidra, IDA, Binary Ninja, r2, and proprietary loaders diverge.
• Custom anomaly design: enterprise‑specific fixtures targeting proprietary loader code paths.
• CI/CD hardening: regression harnesses that prevent correctness failures from reaching production.

The PAAX Taxonomy

The PAAX taxonomy is a formally defined classification system composed of five orthogonal categories, each representing a distinct class of adversarial PE behaviour.

• VRD — Virtual–Raw Divergence: Structural inconsistencies between virtual memory layout and raw file layout. VRD covers anomalies such as overlapping sections, misaligned raw offsets, and mismatched virtual sizes.
• STI — Section Table Inconsistency Families: Errors, contradictions, or pathological patterns within the section table. STI includes out‑of‑order sections, zero‑length sections, impossible flags, and malformed section metadata.
• LPM — Loader‑Permissive Mutations: Mutations that Windows' loader accepts under permissive semantics but that many tools reject or misinterpret. LPM captures the gap between specification, implementation, and ecosystem assumptions.
• EMD — Execution‑Model Distortion: Anomalies that alter or obscure the execution model without introducing malicious behaviour. Examples include entry points in non‑executable regions, in overlays, or in structurally ambiguous locations.
• AIL — Adversarial Intent Levels: A meta‑layer describing the *intentionality* of a fixture — from benign malformed structures to fully adversarial constructs designed to probe loader boundaries.

Orthogonality and Composition

Each category is independent and can be combined to describe complex adversarial structures. For example:

• A fixture may be classified as VRD‑I + STI‑III + EMD‑II
• A case study may involve LPM‑II + VRD‑III
• A synthetic adversarial sample may span all five categories

This composability is what makes the PAAX taxonomy suitable for:

• engineering teams
• DFIR analysts
• tool vendors
• academic researchers
• automated fuzzing pipelines

Applied Example

(See the taxonomy in action in the Ghidra case study)

Why Enterprises Choose PAAX

• Correctness you can trust: PAAX aligns analysis behaviour with Windows - the only ground truth that matters in adversarial environments.
• Reduced operational risk: fewer crashes, fewer silent misinterpretations, fewer escalations.
• Vendor‑grade assurance: validate loaders, unpackers, and detection pipelines before customers encounter failures.
• Strategic visibility: understand exactly where your tooling diverges from Windows and why.

Our Philosophy

Security tooling fails in the margins - the malformed, the ambiguous, the adversarial. PAAX focuses exclusively on those margins. We believe correctness under adversarial conditions is not optional for enterprise‑grade security products. It is foundational.