Building config extractors
Skill meltedinhex/analyst-ai-pack/skills/building-config-extractors
An open agent-skills library for malware analysis, reverse engineering, and threat hunting - 118 curated, runnable skills mapped to MITRE ATT&CK, D3FEND, and CAR.
npx -y skills add meltedinhex/analyst-ai-pack --skill building-config-extractorsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 19 stars19 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Builds reusable malware configuration extractors by applying a declarative JSON spec (offsets, decode layers, field definitions) to a sample to produce structured, defanged config. Activates for requests to build a config extractor, write a reusable family config parser, or run a spec-driven configuration extraction.
The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
2.7 KB, 465 tokens by cl100k_base, as published. Nobody here has run it
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
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/u32little vs big) producing garbage ports. - Forgetting a decode layer (base64 over XOR) and parsing ciphertext as fields.
References
- See
references/api-reference.mdfor the extractor engine. - ATT&CK T1140 and config-extractor framework concepts (linked in frontmatter).