How to Initialize a Case and Authorize a Target With reverse-skill Scripts

Use case-init.sh to create a case directory with authorization metadata, then run case-guard.sh to validate that auth.status is granted before executing any active-response steps.

The reverse-skill framework provides a two-phase workflow for preparing authorized reverse-engineering engagements. This article walks through the initialization and authorization process using the official Bash scripts from the zhaoxuya520/reverse-skill repository.

---

Understanding the Workflow

Every case in reverse-skill requires explicit authorization before any active-response (ACT) operations can run. The framework splits this responsibility across two scripts in skills/scripts/:

1. case-init.sh — Creates the case structure, applies authorization presets, and generates scope.md
2. case-guard.sh — Enforces the authorization gate by validating scope.md before ACT execution

Only when case-guard.sh exits successfully (status 0) may subsequent skill scripts operate on the target.

---

Step 1: Initialize a Case With case-init.sh

The case-init.sh script (located at skills/scripts/case-init.sh) generates a complete case directory under work/ and records all authorization parameters in a machine-readable scope.md file.

Argument Parsing and Presets

The script accepts detailed configuration through command-line flags (lines 24-45):

• --hint — Natural language description of the task
• --case-name — Optional identifier (auto-generated from hint + timestamp if omitted)
• --preset — Authorization template: offline-sample, ctf-public, or own-system
• --target-url — Live target for authorized remote engagement
• --sample — Local file path for offline analysis
• --in-scope-asset — Additional assets to include

Preset handling (lines 70-94) automatically configures authorization parameters:

Preset	AUTH_GRANTED	AUTH_STATUS	NETWORK_PROFILE
offline-sample	1	granted	offline
ctf-public	1	granted	lab_only
own-system	1	granted	authorized_target_only

Directory Structure Creation

On execution, case-init.sh creates the following layout (lines 26-27):

work/<case-name>/
├── evidence/      # Collected artifacts

├── notes/         # Analyst documentation

├── report/        # Output deliverables

└── scope.md       # Authorization metadata

Skill Routing

After initialization, the script calls master-route.sh (lines 81-99) to select the appropriate primary skill based on the hint, using the routing table at skills/config/routing.json.

---

Step 2: Verify Authorization With case-guard.sh

Before any ACT step executes, case-guard.sh (skills/scripts/case-guard.sh) performs mandatory validation of the scope.md file generated during initialization.

Validation Checks

The guard implements four critical assertions (lines 66-112):

Check	Requirement	Failure Action
Authorization status	auth.status: granted must be present	Issue added, exit 2
Network profile	Valid mode with constraints met (offline mode requires sample)	Issue added, exit 2
Asset presence	Non-empty in_scope.assets when network mode ≠ offline	Issue added, exit 2
ACT readiness	signoff ready_for_act: true must be set	Issue added, exit 2

Exit Behavior

• Exit 0 — All checks passed; case is authorized and ready
• Exit 2 — One or more requirements missing; issues printed to stderr

---

Complete Usage Examples

Offline Sample Analysis (No Network Authorization Required)

# Initialize case for APK reverse engineering

bash skills/scripts/case-init.sh \
  --hint "apk reverse" \
  --case-name demo-apk \
  --preset offline-sample \
  --sample ./myapp.apk

This creates work/<timestamp>-demo-apk/ with auth.status: granted and network_profile: offline.

# Verify authorization before ACT steps

bash skills/scripts/case-guard.sh --case-root work/<timestamp>-demo-apk

Expected output: CASE-GUARD OK: <case-name> authorized for ACT

Live CTF Target (Authorized Network Engagement)

# Initialize case for public CTF challenge

bash skills/scripts/case-init.sh \
  --hint "ctf web" \
  --preset ctf-public \
  --target-url https://challenge.example

# Validate before exploitation

bash skills/scripts/case-guard.sh --case-root work/<generated-case>

---

Key Files and Their Roles

File Path	Purpose
skills/scripts/case-init.sh	Case generation, preset application, skill routing
skills/scripts/case-guard.sh	Authorization gate enforcement
skills/scripts/master-route.sh	Skill selection based on hint
skills/config/routing.json	Central routing configuration
work/<case>/scope.md	Structured authorization metadata consumed by both scripts

---

Summary

• case-init.sh creates the case directory and establishes authorization via presets that set AUTH_GRANTED=1 and auth.status: granted
• Presets (offline-sample, ctf-public, own-system) automatically configure safe network_profile values
• case-guard.sh is the mandatory gate: it validates scope.md and exits non-zero if authorization is incomplete
• Both scripts must succeed before any ACT steps in the reverse-skill framework can execute

---

Frequently Asked Questions

What preset should I use for analyzing malware samples?

Use --preset offline-sample. According to the reverse-skill source code, this preset sets network_profile: offline and requires a local sample file, ensuring no unintended network activity occurs during analysis.

Can I create a case without a preset?

Yes, but you must then manually ensure all authorization fields are correctly set in scope.md. The presets exist to prevent accidental misconfiguration; without one, case-guard.sh will likely reject the case unless you explicitly craft valid authorization metadata.

What happens if I skip the guard check?

The framework assumes ACT scripts will invoke case-guard.sh or equivalent validation. Running ACT steps against an unauthorized case violates the safety model implemented in reverse-skill and may result in operations against unintended targets.

How do I add multiple assets to a case?

Use multiple --in-scope-asset flags during initialization:

bash skills/scripts/case-init.sh \
  --hint "firmware analysis" \
  --preset offline-sample \
  --sample ./firmware.bin \
  --in-scope-asset ./datasheet.pdf \
  --in-scope-asset ./pinout.svg

These are collected into in_scope.assets (lines 47-58) and validated by case-guard.sh (lines 88-106).

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}