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‑C — Backing range that extends beyond EOF
• 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 Pilot

For: vendors evaluating PAAX against a specific loader or detection pipeline.

£4,950 — 6 weeks — fixed scope.

• Up to 30 PAAX fixtures from the existing corpus, classified under the PAAX taxonomy
• Behavioural testing against one of your loaders or detection engines
• Written report: per-fixture observations, divergences from Windows mapping semantics, and prioritised findings
• One follow-up call to walk the engineering team through the results
• Pilot fee creditable against a Vendor Subscription within 60 days of pilot close

Engagement model: I work with one pilot at a time. Slots are scheduled in advance.

PAAX Vendor Subscription

For: AV/EDR vendors, RE tool vendors, and sandbox providers running PAAX as an ongoing correctness programme.

From £18,000/year — annual term — one vendor organisation.

• Access to the full PAAX corpus, currently 99 fixtures and growing (target: 200+ by end of 2027)
• Taxonomy classification (VRD / STI / LPM / EMD / AIL) for every delivered fixture
• Generation recipes for every delivered fixture (separate licence; not under MPL-2.0)
• Quarterly cross-tool behavioural deltas: how each fixture behaves under new releases of major RE platforms (Ghidra, IDA, Binary Ninja, radare2), and against major AV/EDR engines on request
• Quarterly corpus additions: new fixtures developed during the subscription period
• Two custom fixtures included annually, targeting code paths in your loader of your choosing
• 4 hours/month consulting time: async or scheduled, your choice of cadence
• Coordinated disclosure where PAAX findings affect your tooling, on your timeline
• Quarterly written status report covering corpus state, deltas, and consulting summary

The £18,000 figure is the entry point. Pricing scales with organisation size and the number of loaders or engines in scope.

PAAX Bespoke

For: vendors and high-assurance environments with custom requirements that fall outside the Subscription scope.

£1,400/day — 5-day minimum engagement.

• Custom adversarial fixture design for proprietary loaders, packers, or unpackers
• Vendor-specific cross-tool differential studies
• Integration support: CI/CD harness design, regression-suite construction
• Disclosure-quality methodology consulting for your internal research teams
• Expert-witness preparation and written technical opinion
• Workshops and deep-dive sessions on PAAX taxonomy and adversarial PE structures

Bespoke engagements are scoped per project. Subscription customers receive priority booking and a 15% rate reduction.

What's outside the commercial offering

The 99-fixture public PAAX corpus is shipped with iocx under MPL-2.0 and remains free. The PAAX taxonomy is published openly at our About page and is free to cite, apply, and extend.

We don't sell access to the public corpus. We don't sell taxonomy access. We don't sell the methodology. These are the credibility surface; they're freely available. What we sell is the work that turns those artefacts into a working correctness programme for your specific tooling.

The full methodology — four principles, validation examples, and contribution guidance — is documented over at iocx.

How to start a conversation

If you're evaluating PAAX for an AV/EDR engine, an RE platform, or a sandbox, the right first step is a 30-minute call to discuss scope. We'll talk about your loader, your current parser-correctness posture, and whether a Pilot makes sense.

Start a pricing conversation →

VAT is added where applicable. UK invoicing; net 30. Quotes in USD available on request at prevailing rates.

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 five-axis classification framework for adversarial PE behaviour. Each axis represents an orthogonal class of structural anomaly; complex adversarial samples are described by composition of axis classifications.

• 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 axis is independent and can be combined to describe complex adversarial structures:

• A fixture may target a single axis (e.g. an EMD-only structural anomaly)
• A fixture may combine two structural axes with an intentionality marker (e.g. VRD + STI + AIL)
• A synthetic adversarial sample may span all five axes

The Ghidra finding documented in our case study is classified across four axes, illustrating composition in practice.

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.

How engagements work

What does the first conversation look like?

A 30-minute call, scheduled via the contact form. We discuss your loader or detection engine, your current parser-correctness posture, and what success would look like. No NDA is required for this conversation. We do not ask for samples, source, or internal documentation at this stage. The output is a written scoping note (1–2 pages) describing what a Pilot or Subscription would cover for your specific environment, and what it would cost.

What is the typical lead time from first contact to engagement start?

For a Pilot: 4–6 weeks from initial call to start date, assuming a signed Statement of Work and a paid invoice. The bottleneck is usually your procurement, not ours. For a Subscription: 6–10 weeks, the same plus contract negotiation. Bespoke engagements can sometimes start sooner if scope is tight.

How many customers does PAAX work with at once?

PAAX is a small operation. We run one Pilot at a time and a small number of concurrent Subscription customers. Slots are scheduled in advance. If your timing is sensitive, the contact form has a "preferred start" field — use it.

Who does the work?

Peter Weaver, founder of MalX Labs and the maintainer of https://github.com/iocx-dev/iocx. All technical work — fixture construction, classification, cross-tool behavioural testing, custom anomaly design, written reports — is delivered personally. We do not subcontract. This is both a constraint (limited capacity) and a feature (consistent methodology, single point of contact, predictable quality).

What happens if Peter is unavailable (illness, emergency)?

Subscription customers receive written notification within one working day, with an estimate of how the unavailability affects deliverables. Quarterly deltas that slip more than two weeks beyond their scheduled date are credited pro-rata against the following year's subscription. For multi-month unavailability, customers may exit the subscription at the next quarterly boundary with a refund of unused months. This is documented in the Master Services Agreement.

Scope and deliverables

What exactly do you deliver, in concrete terms?

Deliverables are written artefacts: fixture binaries, taxonomy classification documents, cross-tool behavioural maps, generation recipes, quarterly delta reports, custom-fixture construction recipes, and consulting time captured in written form (call summaries, async Q&A logs). Every commercial engagement produces a structured paper trail. We do not deliver dashboards, web portals, or hosted services — PAAX is delivered as artefacts, not infrastructure.

What format are deliverables in?

Binaries are PE files. Documentation is Markdown and PDF. Cross-tool maps are CSV/JSON plus human-readable Markdown. Reports are PDF for sign-off, Markdown for source. Everything is intended to be machine-readable where the buyer wants it to be, and human-readable everywhere else.

How are deliverables transferred?

For Pilots: a private Git repository (GitHub, GitLab, or Azure DevOps — your choice) with signed commits, or an SFTP drop. For Subscriptions: a private Git repository on your preferred platform, with quarterly tagged releases. PGP-signed manifests accompany every release. We do not use third-party file-share services for deliverables.

What if a deliverable doesn't meet our expectations?

Every engagement has a written Statement of Work specifying deliverable acceptance criteria. If a deliverable doesn't meet those criteria, we work it until it does, at no additional cost, within the engagement's timeframe. If a deliverable can't be made to meet the criteria — which has not happened to date — we issue a pro-rata refund. We do not bill against criteria that weren't agreed in writing.

Do you guarantee finding bugs in our tooling?

No. We guarantee the work: rigorous methodology, taxonomy-classified fixtures, defensible cross-tool testing, and clear written reports. Whether the work surfaces actionable findings depends on your tooling. A clean result — "no significant divergences from Windows semantics observed across the corpus" — is itself a valuable deliverable for your engineering and marketing teams. We do not sell findings; we sell the methodology that finds them when they exist.

Intellectual property

Who owns the fixtures delivered to us?

Under a Subscription, you receive a non-exclusive perpetual licence to use the delivered fixtures and accompanying documentation within your organisation, including in internal testing, CI/CD pipelines, and regression harnesses. You do not own the fixtures; we retain copyright. You may not redistribute the fixtures or the generation recipes outside your organisation without written agreement. If you cancel your Subscription, your perpetual licence to fixtures delivered during the subscription period continues; you simply stop receiving new fixtures and deltas.

Who owns custom fixtures built for our specific loader?

This is the most-asked question and the answer is deliberate. Custom fixtures built under a Bespoke engagement or the Subscription's bundled-custom-fixture allowance follow this rule:

• You own the right to use the fixture indefinitely within your organisation, including after the engagement ends. This is an irrevocable, perpetual, non-exclusive licence.
• We retain the right to incorporate the underlying anomaly pattern into the general PAAX corpus, sanitised of any vendor-specific identifiers, code paths, or proprietary information. The general corpus may then be delivered to other Subscription customers.
• Identifying details remain confidential. The fixture's existence is not disclosed; the anomaly class may be incorporated into future corpus work.

This balance is non-negotiable: it protects your investment (the fixture works for you forever) while keeping the methodology compounding (anomaly classes can inform the broader corpus). If a customer needs strict exclusivity on a specific anomaly class — i.e. it will never appear in the general corpus — that is available as a separately-priced exclusivity uplift. Most customers find the standard arrangement sufficient.

Who owns findings produced from our subscription?

Findings in your own tooling, surfaced by PAAX testing, are yours to disclose or remediate as you see fit. We do not publish findings about your tooling without your written consent. Findings in third-party tooling that emerge during your subscription (e.g. while running cross-tool deltas) are PAAX's to disclose under coordinated vulnerability disclosure practice, with your subscription anonymised in any public material unless you elect otherwise.

Will you publish that we are a customer?

Only with your written permission. The default is full confidentiality. Some customers value being publicly named (it signals correctness investment to their customers); some require strict confidentiality. Both are supported. We do not list customers on the website without explicit written agreement.

What about the public PAAX corpus and taxonomy?

The 99-fixture public PAAX corpus shipped with iocx is published under MPL-2.0 and remains public. The PAAX taxonomy (VRD, STI, LPM, EMD, AIL) is published openly at #about. These are the credibility surface and they are not subject to commercial restriction. Becoming a Subscription customer does not restrict your use of the public corpus or the taxonomy in any way.

Legal and confidentiality

Will you sign our NDA?

Yes, for mutual NDAs covering customer-disclosed information. We will not sign:

• One-way NDAs that bind PAAX without reciprocal commitments
• NDAs that restrict our right to disclose findings in third-party tooling surfaced during the engagement
• NDAs that restrict publication of the PAAX methodology, taxonomy, or research independent of the customer's data
• NDAs with non-compete clauses for adjacent security research
• NDAs without a defined duration (most we sign run 3–5 years)

We have a standard mutual NDA template that streamlines this for most customers; it is available on request before the first call.

What is your stance on coordinated vulnerability disclosure?

We follow standard 90-day coordinated disclosure practice for findings in third-party tooling, with extensions on reasonable vendor request. For findings in your own tooling under a Subscription, you control the disclosure timeline. We never publish findings about your tooling without your written consent, and we never use findings about your tooling for marketing purposes without your explicit agreement.

Where is PAAX based legally?

MalX Labs operates from the United Kingdom. Contracts default to England and Wales jurisdiction. For customers in other jurisdictions, alternative governing-law arrangements can be negotiated. VAT is added to UK customer invoices where applicable; non-UK customers receive reverse-charge invoices per HMRC guidance.

Are you GDPR-aligned?

Yes. PAAX engagements typically involve no personal data; the artefacts exchanged are technical (binaries, classifications, behavioural maps). Where customer-contact information is held for engagement management, it is processed under legitimate-interest basis, retained only for the engagement duration plus statutory requirements, and never shared with third parties. A formal Data Processing Agreement can be issued on request.

Do you carry professional indemnity insurance?

Yes. PAAX engagements are covered by professional indemnity insurance appropriate for technical consulting work in the UK. Specific limits and certificate of currency are available to customers under signed engagement.

Payment and commercial terms

What are your payment terms?

Standard terms are net 30 days from invoice date. Pilots are invoiced 50% on engagement start and 50% on delivery of the written report. Subscriptions are invoiced annually in advance. Bespoke engagements are invoiced monthly in arrears against time recorded. Quarterly billing is available for Subscriptions on request.

What currencies do you invoice in?

Default invoicing is GBP. USD invoicing is available at prevailing rates, with FX risk borne by the customer. EUR invoicing is available on request. Cryptocurrency payment is not accepted.

How do you handle VAT?

UK customers receive standard VAT-inclusive invoices. EU customers receive reverse-charge invoices under post-Brexit HMRC guidance. Non-EU customers receive zero-rated invoices. We register VAT identifiers on initial setup; customers should provide their VAT registration number at contracting.

Can we pay via purchase order?

Yes. We accept POs from established procurement systems. PO numbers must appear on engagement contracts; invoices reference the PO. Pilots require either a PO or paid invoice before the engagement start date.

What happens if our procurement takes longer than expected?

We hold a quoted engagement slot for 30 days from the date of the formal proposal. After that, the slot is released and the quote may need to be re-issued. We have not seen this be a problem with established vendor procurement, but it is worth flagging if your cycles run longer than a month.

Do you offer multi-year contracts?

Yes, for Subscriptions. A 2-year commitment receives a 10% discount; a 3-year commitment receives 15%. Multi-year discounts are not stackable with other discounts. Either party can exit a multi-year contract at annual boundaries with 90 days' notice; no exit fee applies.

What if the work doesn't deliver value and we want to cancel?

Pilots are non-refundable once the engagement starts, given the front-loaded nature of the work. Subscriptions can be cancelled at the next quarterly boundary with 30 days' notice; cancellation refunds the unused portion of the annual fee on a pro-rata basis, less any delivered custom-fixture work valued at the Bespoke day rate. Bespoke engagements may be cancelled with 7 days' notice; cancellation is billed against time worked plus any committed external costs.

What we do not do

It is faster to state this directly than to be vague.

• We do not write or sell exploit code. PAAX surfaces parser correctness divergences, not exploitable conditions, and our deliverables stop at the behavioural-observation boundary.
• We do not provide live malware. All PAAX fixtures are synthetically constructed under a controlled fixture pipeline. None are derived from in-the-wild samples.
• We do not provide samples of any third party's malware corpus. Existing public corpora (EMBER, malicia, etc.) are available from their original sources; we do not redistribute.
• We do not provide red-team services, penetration testing, or offensive security consulting. Other firms do this well; PAAX is correctness research, not offensive security.
• We do not provide expert-witness testimony as a primary service. We will prepare written technical opinions as part of Bespoke engagements where appropriate, but PAAX is not a litigation-support practice.
• We do not provide training as a standalone product. Subscription and Bespoke engagements include consulting and workshops where appropriate. We do not run open-enrolment training courses.
• We do not offer free pilots. Paid pilots have proven the right entry point for serious buyers; free pilots attract tyre-kickers and burn capacity. The pilot fee is creditable toward the first year of a Subscription.

Technical questions

What loader modes does PAAX cover?

Both CreateProcess-style executable mapping and LoadLibrary / MapViewOfFile data-mapping modes. Where Windows behaviour diverges between modes (and it does, often), PAAX fixtures specify which mode they target and we test against the relevant mode.

What Windows versions are PAAX fixtures aligned with?

Windows 10 22H2 and Windows 11 (current). Where Windows 7/8/8.1 loader behaviour differs materially from current versions, this is noted in the fixture documentation. PAAX does not certify against Windows Server beyond noting where server-loader semantics differ from workstation.

Does PAAX cover formats other than PE?

Not currently. PAAX is PE-specific. ELF, Mach-O, and embedded firmware formats are out of scope. If there is sustained customer demand for a sibling corpus on another format, this may change; it is not on the 2026–2027 roadmap.

How is PAAX different from a fuzzer?

Fuzzers produce many inputs at low individual semantic value, hoping that breadth surfaces bugs. PAAX produces few inputs at high individual semantic value: each fixture is constructed deliberately to model a real attacker behaviour or a real loader edge case. The two approaches are complementary; PAAX customers typically run their fuzzers and PAAX, and the fixtures we deliver often surface bugs that years of fuzzing did not.

How is PAAX different from existing public corpora?

Public corpora (EMBER, malicia, capa test fixtures, Corkami's PE samples) generally serve either malware-classification research (label-focused) or specific tool-testing (project-focused). PAAX is methodology-focused: every fixture carries a single isolated anomaly, classified under a published taxonomy, with a generation recipe and a behavioural map. This is a different shape of artefact from a malware-classification dataset, and complementary to existing tool-test fixtures.

Before you get in touch

The fastest first conversations come from buyers who already know:

• Which loader, engine, or detection pipeline they want PAAX to test against
• Whether they have internal correctness testing in place today, and what its gaps are
• What "success" looks like for the engagement — findings, methodology adoption, regression coverage, or marketing-grade assurance
• Their procurement constraints (PO required, NDA required, contracting jurisdiction)
• Their preferred start window

If you don't have answers to all of these yet, that is fine — we will work them out on the first call. But the more of them you bring, the more useful the first 30 minutes will be.

#contact

Still have questions?

This page will grow as customers ask. If your question isn't here, raise it on the contact form and it will be answered directly — and added here for the next reader.