competition-malware-config

Name: competition-malware-config
Author: zhaoxuya520

8.8kstars1.4kforks

How to install competition-malware-config?

zhaoxuya520/reverse-skill/competition-malware-config

$npx -y skills add zhaoxuya520/reverse-skill --skill competition-malware-config

Installs into the current project.

Summary

Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for malware configuration recovery, staged payload boundaries, beacon parameter extraction, and IOC decoding. Use when the user asks to recover a malware config, decode C2 or beacon fields, unpack staged

Files · 1

View on GitHub

SKILL.md

1	# Competition Malware Config
2
3	Use this skill only as a downstream specialization after `$ctf-sandbox-orchestrator` is already active and has established sandbox assumptions, node ownership, and evidence priorities. If that has not happened yet, return to `$ctf-sandbox-orchestrator` first.
4
5	Use this skill when the decisive value is not just "what the sample does," but which config fields, stages, or network parameters the sample hides and when they become plaintext.
6
7	Reply in Simplified Chinese unless the user explicitly requests English.
8
9	## Quick Start
10
11	1. Preserve the original sample before unpacking or patching.
12	2. Separate loader, payload, config blob, and post-decode behavior.
13	3. Rank candidate config blobs by entropy, field shape, nearby strings, and decode helpers.
14	4. Record the exact transform chain for each recovered field.
15	5. Reproduce the decoded config or beacon parameters from the smallest possible path.
16
17	## Workflow
18
19	### 1. Find The Config Boundary
20
21	- Inspect sections, resources, embedded archives, strings, imports, and decode helpers.
22	- Identify where config is stored: resource, overlay, encrypted blob, registry seed, network bootstrap, or stage2 memory.
23	- Keep one note of when each value becomes plaintext.
24
25	### 2. Reconstruct The Decode Chain
26
27	- Recover the chain in order: container -> compression -> encoding -> xor/substitution -> crypto -> parse.
28	- Group all config fields from the same chain together instead of treating them as unrelated clues.
29	- Preserve hashes, offsets, keys, IVs, masks, and parsed fields in one compact evidence block.
30
31	### 3. Tie Config To Behavior
32
33	- Show which field affects which branch: beacon path, mutex, wallet, bot id, campaign, tasking route, persistence name, or process target.
34	- Correlate decoded config with PCAPs, process trees, or stage2 strings when possible.
35
36	## Read This Reference
37
38	- Load `references/malware-config.md` for the config-hunting checklist, staged-sample checklist, and evidence packaging rules.
39
40	## What To Preserve
41
42	- Original artifact, unpacked layer, dumped stage, and parsed config as separate artifacts
43	- Offsets, hashes, decode helpers, keys, masks, and field names
44	- The branch or protocol step each recovered field actually influences

People who liked this also viewed

6 picks

Type

competition-malware-config

8.8kstars1.4kforks

View on GitHub

How to install competition-malware-config?

zhaoxuya520/reverse-skill/competition-malware-config

$npx -y skills add zhaoxuya520/reverse-skill --skill competition-malware-config

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Competition Malware Config
2
3	Use this skill only as a downstream specialization after `$ctf-sandbox-orchestrator` is already active and has established sandbox assumptions, node ownership, and evidence priorities. If that has not happened yet, return to `$ctf-sandbox-orchestrator` first.
4
5	Use this skill when the decisive value is not just "what the sample does," but which config fields, stages, or network parameters the sample hides and when they become plaintext.
6
7	Reply in Simplified Chinese unless the user explicitly requests English.
8
9	## Quick Start
10
11	1. Preserve the original sample before unpacking or patching.
12	2. Separate loader, payload, config blob, and post-decode behavior.
13	3. Rank candidate config blobs by entropy, field shape, nearby strings, and decode helpers.
14	4. Record the exact transform chain for each recovered field.
15	5. Reproduce the decoded config or beacon parameters from the smallest possible path.
16
17	## Workflow
18
19	### 1. Find The Config Boundary
20
21	- Inspect sections, resources, embedded archives, strings, imports, and decode helpers.
22	- Identify where config is stored: resource, overlay, encrypted blob, registry seed, network bootstrap, or stage2 memory.
23	- Keep one note of when each value becomes plaintext.
24
25	### 2. Reconstruct The Decode Chain
26
27	- Recover the chain in order: container -> compression -> encoding -> xor/substitution -> crypto -> parse.
28	- Group all config fields from the same chain together instead of treating them as unrelated clues.
29	- Preserve hashes, offsets, keys, IVs, masks, and parsed fields in one compact evidence block.
30
31	### 3. Tie Config To Behavior
32
33	- Show which field affects which branch: beacon path, mutex, wallet, bot id, campaign, tasking route, persistence name, or process target.
34	- Correlate decoded config with PCAPs, process trees, or stage2 strings when possible.
35
36	## Read This Reference
37
38	- Load `references/malware-config.md` for the config-hunting checklist, staged-sample checklist, and evidence packaging rules.
39
40	## What To Preserve
41
42	- Original artifact, unpacked layer, dumped stage, and parsed config as separate artifacts
43	- Offsets, hashes, decode helpers, keys, masks, and field names
44	- The branch or protocol step each recovered field actually influences

People who liked this also viewed

6 picks

Type