How to Configure Network Profiles for Authorization in reverse-skill: A Complete Guide

The reverse-skill framework enforces a hard gate that requires a valid network profile in scope.md before allowing any active analysis (ACT), ensuring tasks only communicate with authorized network environments.

Configuring network profiles for authorization in reverse-skill is essential before initiating any live interaction. The framework uses this configuration as a mandatory safety check alongside authentication status to determine whether a case can proceed to active testing. According to the zhaoxuya520/reverse-skill source code, this mechanism is defined in the scope contract and validated through the routing chain.

Understanding the Scope Contract Gate

The reverse-skill project implements a scope contract located at skills/ops/scope-contract.md that serves as the authorization gate. This contract contains a dedicated network_profile section that dictates network communication boundaries.

Before any ACT (active analysis) can execute, the routing engine performs a strict validation. As implemented in RULES.md at lines 4-5, the framework checks that auth.status=granted and ready_for_act=true, which requires a valid network_profile.mode to be present. This ensures that analysts cannot accidentally interact with unauthorized networks.

The field definition resides in skills/ops/scope-contract.md at lines 65-73, while the quick-reference table mapping modes to allowed actions appears at lines 105-113.

Available Network Profile Modes

The framework supports four distinct network isolation levels. Each mode strictly controls what network interactions are permitted during analysis:

Mode	Allowed Actions	Prohibited Actions
offline	Pure static analysis, local samples, simulated traffic	Any outbound network traffic or public-Internet RPC
lab_only	Lab/CTF VM sub-networks	Production or unauthorized IP ranges
authorized_target_only	Assets explicitly listed in in_scope.assets	Any host outside the defined scope list
unrestricted_lab	Isolated experimental network (requires written-off agreement)	Direct Internet access to production systems

Selecting the correct mode prevents accidental data exfiltration or unauthorized scanning. The authorized_target_only mode is recommended for targeted penetration testing, while offline is mandatory for analyzing untrusted samples without network connectivity.

How to Set a Network Profile

You configure the network profile during case initialization using the provided CLI scripts. Both Bash and PowerShell interfaces support the --network-profile (or -NetworkProfile) parameter.

Using the Bash Script (Linux/macOS/Kali)

Initialize a case with the lab_only profile to restrict activity to virtual machine networks:

bash skills/scripts/case-init.sh \
  --hint "Analyze sample in lab network" \
  --case-name "lab-analysis" \
  --network-profile lab_only

This command generates work/lab-analysis/scope.md containing:

## network_profile

- mode: lab_only
- notes: |
    lab_only = 仅 lab/CTF 虚拟机网段

Using PowerShell (Windows)

For offline binary reverse-engineering scenarios on Windows hosts:

powershell -NoProfile -ExecutionPolicy Bypass -File skills\scripts\case-init.ps1 `
  -Hint "Offline binary reverse-engineering" -CaseName "offline-rev" `
  -NetworkProfile offline

Manual Configuration

You can manually edit the generated work/<case>/scope.md file to change the profile after initialization. Modify the mode line under the network_profile section:

## network_profile

- mode: unrestricted_lab
- notes: |
    Isolated test environment with written-off agreement

Verification and Validation

After creation, verify the profile is correctly registered before attempting ACT:

cat work/lab-analysis/scope.md | grep -A2 "network_profile"

Expected output confirms the mode and notes:

## network_profile

- mode: lab_only
- notes: |

If the network_profile.mode is missing or contains an illegal value, the case-init script aborts and prompts you to correct scope.md. The validation logic in skills/ops/scope-contract.md ensures only the four predefined modes are accepted.

Key Files and Implementation Details

Understanding these source files helps troubleshoot authorization failures:

• skills/ops/scope-contract.md (lines 65-73, 105-113): Defines the network_profile schema and validation rules. This is the authoritative source for allowed modes and their constraints.
• RULES.md (lines 4-5): Implements the routing chain logic that checks auth.status=granted alongside the network profile before setting ready_for_act=true.
• skills/scripts/case-init.sh and skills/scripts/case-init.ps1: Cross-platform initialization scripts that generate the scope.md artifact with the selected network profile.
• work/<case>/scope.md: The runtime case configuration file where the framework reads the current network authorization level.

Summary

• Network profiles are mandatory: The reverse-skill framework blocks all ACT operations unless scope.md contains a valid network_profile mode.
• Four isolation levels exist: Choose between offline, lab_only, authorized_target_only, or unrestricted_lab based on your testing environment.
• Configure via CLI: Use case-init.sh or case-init.ps1 with the --network-profile flag, or manually edit work/<case>/scope.md.
• Validation is strict: The routing engine in RULES.md requires both authentication grant and a valid network profile before allowing live interactions.

Frequently Asked Questions

What happens if I try to run ACT without a network profile?

The framework aborts the operation. According to the routing chain in RULES.md lines 4-5, the engine checks for auth.status=granted and a valid network_profile.mode before setting ready_for_act=true. If either condition fails, the case cannot proceed to active analysis.

Can I change the network profile after creating a case?

Yes. Edit the work/<case>/scope.md file and modify the mode value under the network_profile section. Valid options are offline, lab_only, authorized_target_only, or unrestricted_lab. Save the file before restarting your analysis session.

How do I restrict analysis to specific in-scope assets only?

Use the authorized_target_only mode. This profile allows communication exclusively with IP addresses, domains, or systems listed in the in_scope.assets section of your scope.md. All other network targets are automatically blocked by the framework's authorization gate.

Where is the network profile defined in the source code?

The schema and validation rules are defined in skills/ops/scope-contract.md at lines 65-73, with the quick-reference table at lines 105-113. The routing logic that enforces this profile during ACT is implemented in RULES.md at lines 4-5.

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