competition-reverse-pwn

Name: competition-reverse-pwn
Author: zhaoxuya520

8.8kstars1.4kforks

How to install competition-reverse-pwn?

zhaoxuya520/reverse-skill/competition-reverse-pwn

$npx -y skills add zhaoxuya520/reverse-skill --skill competition-reverse-pwn

Installs into the current project.

Summary

Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for reverse engineering, malware, DFIR, firmware, pwnable, and native exploit challenges. Use when the user asks to reverse a binary, unpack a sample, inspect a memory dump or PCAP, recover malware behav

Files · 1

View on GitHub

SKILL.md

1	# Competition Reverse Pwn
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 for binary-heavy challenges where the decisive path runs through artifacts, decoded layers, process behavior, crash state, or exploit primitives.
6
7	Reply in Simplified Chinese unless the user explicitly requests English.
8
9	## Quick Start
10
11	1. Preserve the original artifact before unpacking, patching, or instrumenting.
12	2. Start with passive triage: type, headers, sections, imports, strings, entropy, resources.
13	3. Decide whether the path is reverse-first, DFIR-first, or exploit-first.
14	4. Tie every claim to an observable boundary: decode edge, persistence edge, crash edge, or leak edge.
15	5. Reproduce the artifact or primitive from a clean baseline.
16
17	## Workflow
18
19	### 1. Reverse Or Forensic Triage
20
21	- Separate loader, payload, config, and post-decode behavior.
22	- Correlate files, memory, logs, registry, services, tasks, IPC, and PCAPs as one graph.
23	- Keep decoded or dumped artifacts separate from the pristine sample.
24
25	### 2. Native And Exploit Path
26
27	- Map mitigations, loader behavior, libc or runtime, syscall and IPC surfaces, and protocol framing.
28	- Record the primitive, controllable bytes, leak source, target object, and final artifact separately.
29	- Compare host, libc, loader, and framing differences before doubting the primitive.
30
31	## Read This Reference
32
33	- Load `references/reverse-pwn.md` for triage order, exploit evidence expectations, and common failure modes.
34	- If the task is specifically about staged payload boundaries, config blobs, beacon parameters, or decoded IOC fields, prefer `$competition-malware-config`.
35	- If the task is specifically about firmware partitions, boot chains, extracted filesystems, or update-package trust boundaries, prefer `$competition-firmware-layout`.
36	- If the task is specifically about upload parsing, previews, archive extraction, converters, or deserialization chains, prefer `$competition-file-parser-chain`.
37	- If the task is specifically about source maps, emitted bundles, chunk registries, or reconstructing hidden runtime structure from served frontend assets, prefer `$competition-bundle-sourcemap-recovery`.
38	- If the task is specifically about container-to-host boundary crossing, kernel exploit preconditions, namespace or cgroup crossover, or escape primitive verification, prefer `$competition-kernel-container-escape`.
39	- If the task is specifically about reconstructing protocols, streams, or transferred artifacts from packet captures, prefer `$competition-pcap-protocol`.
40	- If the task is specifically about a custom binary or text protocol where replay state, message order, or checksum logic is the real blocker, prefer `$competition-custom-protocol-replay`.
41	- If the task is specifically about reconstructing chronology across EVTX, PCAP, registry, mail, or disk artifacts, prefer `$competition-forensic-timeline`.
42
43	## What To Preserve
44
45	- Offsets, hashes, section names, imports, config blobs, mutexes, registry keys
46	- Crash offsets, registers, heap or stack shape, leak addresses, and protocol steps
47	- Original, decoded, dumped, and instrumented artifacts as separate files

People who liked this also viewed

6 picks

Type

competition-reverse-pwn

8.8kstars1.4kforks

View on GitHub

How to install competition-reverse-pwn?

zhaoxuya520/reverse-skill/competition-reverse-pwn

$npx -y skills add zhaoxuya520/reverse-skill --skill competition-reverse-pwn

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Competition Reverse Pwn
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 for binary-heavy challenges where the decisive path runs through artifacts, decoded layers, process behavior, crash state, or exploit primitives.
6
7	Reply in Simplified Chinese unless the user explicitly requests English.
8
9	## Quick Start
10
11	1. Preserve the original artifact before unpacking, patching, or instrumenting.
12	2. Start with passive triage: type, headers, sections, imports, strings, entropy, resources.
13	3. Decide whether the path is reverse-first, DFIR-first, or exploit-first.
14	4. Tie every claim to an observable boundary: decode edge, persistence edge, crash edge, or leak edge.
15	5. Reproduce the artifact or primitive from a clean baseline.
16
17	## Workflow
18
19	### 1. Reverse Or Forensic Triage
20
21	- Separate loader, payload, config, and post-decode behavior.
22	- Correlate files, memory, logs, registry, services, tasks, IPC, and PCAPs as one graph.
23	- Keep decoded or dumped artifacts separate from the pristine sample.
24
25	### 2. Native And Exploit Path
26
27	- Map mitigations, loader behavior, libc or runtime, syscall and IPC surfaces, and protocol framing.
28	- Record the primitive, controllable bytes, leak source, target object, and final artifact separately.
29	- Compare host, libc, loader, and framing differences before doubting the primitive.
30
31	## Read This Reference
32
33	- Load `references/reverse-pwn.md` for triage order, exploit evidence expectations, and common failure modes.
34	- If the task is specifically about staged payload boundaries, config blobs, beacon parameters, or decoded IOC fields, prefer `$competition-malware-config`.
35	- If the task is specifically about firmware partitions, boot chains, extracted filesystems, or update-package trust boundaries, prefer `$competition-firmware-layout`.
36	- If the task is specifically about upload parsing, previews, archive extraction, converters, or deserialization chains, prefer `$competition-file-parser-chain`.
37	- If the task is specifically about source maps, emitted bundles, chunk registries, or reconstructing hidden runtime structure from served frontend assets, prefer `$competition-bundle-sourcemap-recovery`.
38	- If the task is specifically about container-to-host boundary crossing, kernel exploit preconditions, namespace or cgroup crossover, or escape primitive verification, prefer `$competition-kernel-container-escape`.
39	- If the task is specifically about reconstructing protocols, streams, or transferred artifacts from packet captures, prefer `$competition-pcap-protocol`.
40	- If the task is specifically about a custom binary or text protocol where replay state, message order, or checksum logic is the real blocker, prefer `$competition-custom-protocol-replay`.
41	- If the task is specifically about reconstructing chronology across EVTX, PCAP, registry, mail, or disk artifacts, prefer `$competition-forensic-timeline`.
42
43	## What To Preserve
44
45	- Offsets, hashes, section names, imports, config blobs, mutexes, registry keys
46	- Crash offsets, registers, heap or stack shape, leak addresses, and protocol steps
47	- Original, decoded, dumped, and instrumented artifacts as separate files

People who liked this also viewed

6 picks

Type