building-config-extractors

The full skill.

Original instructions from the publisher’s SKILL.md

# Building Config Extractors

## When to Use

- You have reversed a family's config format and want a reusable, declarative extractor instead of
  one-off scripts.
- You need to apply a spec (offset, XOR/base64 layers, field map) to many samples and emit
  structured, defanged config.

**Do not use** a spec built for one variant blindly on another — re-verify offsets/keys per
variant. This skill reads samples statically and executes nothing.

## Prerequisites

- A reversed understanding of the config (location, decode layers, fields) expressed as a JSON
  spec.

## Safety & Handling

- Read bytes statically; defang recovered endpoints in output.

## Workflow

### Step 1: Write the extraction spec

Define a JSON spec: blob `offset`/`length` (or a `marker` to search), ordered `decode` layers
(`xor` with key, `base64`), and `fields` (name, offset, length, type: `str`/`u16`/`u32`/`ipv4`).

### Step 2: Run the extractor

```bash
python scripts/analyst.py extract sample.bin --spec family.json
```

Locates the blob, applies decode layers, parses fields, and defangs URL/IP fields.

### Step 3: Validate output

Confirm fields are plausible (valid hosts, ports, IDs); adjust the spec as needed.

### Step 4: Reuse

Store the spec per family and apply across the corpus.

## Validation

- The spec round-trips on a known sample to the expected config.
- Decode layers are applied in order and produce readable output.
- URL/IP fields are defanged in the emitted config.

## Pitfalls

- Hardcoding a variant-specific offset that shifts in other builds — prefer markers.
- Wrong field endianness (`u16`/`u32` little vs big) producing garbage ports.
- Forgetting a decode layer (base64 over XOR) and parsing ciphertext as fields.

## References

- See [`references/api-reference.md`](references/api-reference.md) for the extractor engine.
- ATT&CK T1140 and config-extractor framework concepts (linked in frontmatter).