# How `case-init.ps1` and `case-init.sh` Enforce the Authorization Gate in Reverse‑Skill

> Discover how case-init.ps1 and case-init.sh enforce the authorization gate in reverse-skill. Learn how these scripts ensure explicit authorization, valid network profiles, and in-scope assets for security.

- Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill)
- Tags: how-to-guide
- Published: 2026-08-29

---

**Both initialization scripts act as a mandatory security checkpoint by computing a `ready_for_act` flag that only evaluates to `true` when explicit authorization is granted, valid network profiles are selected, and in‑scope assets are defined, with all conditions permanently recorded in a generated [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) file.**

The `case-init.ps1` and [`case-init.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/case-init.sh) scripts in the `zhaoxuya520/reverse-skill` repository serve as the **single point of entry** for any forensic or penetration testing work. They enforce a hard authorization gate at case creation time, ensuring downstream tools like `case-guard` or `master-route` never process unauthorized targets.

## The Authorization Gate Architecture

The authorization gate is architecturally embedded in the case initialization flow. Located in [`skills/scripts/case-init.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/case-init.sh) (Bash) and `skills/scripts/case-init.ps1` (PowerShell), these scripts prevent analysis execution by default and require explicit operator sign‑off through command‑line flags. The gate logic follows a strict decision tree that validates inputs, normalizes authentication states, and emits an immutable [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) contract that downstream components trust.

## Step‑by‑Step Enforcement Flow

### Parsing and Normalizing Authentication Flags

The scripts begin by capturing user intent through flags such as `-AuthGranted`, `-AuthStatus`, `-Preset`, `-NetworkProfile`, and `-Sample`. In the Bash implementation (lines 30‑34), these values populate variables like `AUTH_GRANTED`, while the PowerShell version (lines 15‑26) binds them to `$AuthGranted` and related parameters.

Following input capture, the scripts normalize the authentication status. If `-AuthGranted` is supplied or a preset implying authorization is used, the `auth_status_resolved` variable (Bash lines 29‑31) or `$authStatusResolved` (PowerShell lines 14‑16) is forced to **`granted`**. Without these flags, the status defaults to **`pending`**, automatically blocking readiness regardless of other inputs.

### Validating Case Names and Network Profiles

Before creating any directories, the scripts sanitize the `CaseName` to prevent path traversal or malformed entries. The Bash version (lines 104‑112) rejects names containing path separators, trailing dots, control characters, or wildcard symbols. PowerShell performs equivalent validation (lines 93‑96) using pattern matching to ensure the case directory remains confined to `work/<case>/`.

The `NetworkProfile` must belong to a strict whitelist: `offline`, `lab_only`, `authorized_target_only`, or `unrestricted_lab` (plus aliases). Invalid values trigger immediate termination (Bash lines 115‑124; PowerShell lines 98‑101). This prevents operators from accidentally selecting undefined network modes that could bypass isolation controls.

### Asset Resolution and Network Mode Determination

Assets are collected from `-TargetUrl`, `-Sample`, or inferred from the hint string. The scripts then determine the network mode: it defaults to `offline` unless authorization is granted and assets are present, in which case it switches to `authorized_target_only` (Bash lines 47‑55, 119‑129; PowerShell lines 35‑47, 50‑56). This ensures that **no network connectivity is assumed** without explicit authorization.

### The `ready_for_act` Flag Computation

The core enforcement mechanism is the boolean `ready_for_act` flag. According to the source code in [`skills/scripts/case-init.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/case-init.sh) (lines 108‑115, 129‑135) and `skills/scripts/case-init.ps1` (lines 72‑80), this flag evaluates to `true` **only when all three conditions are satisfied**:

- `auth_status_resolved` equals **`granted`**
- At least one in‑scope asset exists in the resolved list
- The network mode is not `offline` (or an explicit offline sample is provided with authorization)

This mirrors the high‑level policy defined in [`RULES.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md): authorization requires granted status plus a valid network profile to transition to ready state.

### [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) Generation and Checklist Markers

The scripts materialize the authorization state in `work/<case>/scope.md`. This file contains a **sign‑off section** with Markdown checkboxes for auth status, assets, and network profile. The scripts mark boxes as `[x]` only when conditions pass, creating an explicit audit trail (Bash lines 172‑185; PowerShell lines 82‑90).

For example, a granted authorization with assets produces:

```markdown
- [x] auth.status = granted
- [x] in_scope.assets
- [x] network_profile = authorized_target_only

```

A pending case shows unchecked boxes, making the gate status immediately visible to operators and automated validators.

### Preventing Bypass via `-ReadyForAct`

The scripts explicitly handle the `-ReadyForAct` switch to prevent forced overrides. If an operator attempts to use `-ReadyForAct` without meeting the three core conditions, the scripts emit a warning and ignore the flag (Bash lines 139‑147; PowerShell lines 75‑80). This ensures **the gate cannot be bypassed** by command‑line manipulation alone.

## Practical Code Examples

### Creating a Pending Case (Unauthorized)

To initialize a case that remains locked pending authorization:

```bash
bash skills/scripts/case-init.sh \
  --hint "web pentest" \
  --case-name demo

```

**Output excerpt:**

```text
auth.status=pending
network_profile=offline
ready_for_act=false

# Checklist shows [ ] auth.status = granted

```

### Creating an Authorized Target Case

To create a fully authorized case with explicit network targets:

```bash
bash skills/scripts/case-init.sh \
  --hint "targeted scan" \
  --case-name demo \
  --auth-granted \
  --target-url https://target.example \
  --network-profile authorized_target_only

```

**Output excerpt:**

```text
auth.status=granted
network_profile=authorized_target_only
ready_for_act=true

# Checklist shows [x] auth.status = granted, [x] in_scope.assets

```

### Using Offline Presets

For offline sample analysis where authorization is auto‑granted for local files:

```powershell
powershell -File skills/scripts/case-init.ps1 `
  -Hint "offline apk" `
  -CaseName my-sample `
  -Preset offline-sample `
  -Sample ".\app.apk"

```

**Output excerpt:**

```text
auth.status=granted
network_profile=offline
ready_for_act=true

# Checklist shows [x] auth.status = granted, [x] in_scope.assets

```

### Attempting to Force Readiness (Failure Case)

Demonstrating that `-ReadyForAct` is ignored without proper authorization:

```powershell
powershell -File skills/scripts/case-init.ps1 `
  -Hint "unauthorised test" `
  -CaseName demo `
  -ReadyForAct

```

**Output:**

```text
Warning: -ReadyForAct ignored because auth.status is not granted
auth.status=pending
ready_for_act=false

```

## Key Implementation Files

| File | Role |
|------|------|
| [`skills/scripts/case-init.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/case-init.sh) | Bash implementation of case initialization and gate logic |
| `skills/scripts/case-init.ps1` | PowerShell implementation mirroring Bash enforcement |
| [`RULES.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md) | Defines the "auth = granted + network profile → ready" policy |
| [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md) | Documents the [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) schema used by initializers |

## Summary

- **`case-init.ps1`** and **[`case-init.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/case-init.sh)** enforce authorization at the earliest possible stage—case creation.
- The **`ready_for_act`** flag acts as a computed boolean gate that requires three simultaneous conditions: granted auth status, defined assets, and an approved network profile.
- **Input validation** on `CaseName` and `NetworkProfile` prevents directory traversal and undefined network modes.
- The **`-ReadyForAct` switch cannot bypass** the gate; it is only honored when authorization prerequisites are met.
- **Immutable [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) files** provide a signed contract that downstream tools can trust without re‑evaluating gate conditions.

## Frequently Asked Questions

### What happens if I specify `-NetworkProfile unrestricted_lab` without `-AuthGranted`?

The script will create the case with `auth.status=pending` and `ready_for_act=false`, regardless of the network profile. While `unrestricted_lab` is a valid profile, the authorization gate requires the authentication status to be `granted` before setting `ready_for_act` to `true`. The [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) will show the network profile but with unchecked authorization boxes.

### Can the `ready_for_act` flag be manually edited in [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) to bypass the gate?

While the [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) file is technically editable, downstream tools in the reverse‑skill ecosystem are designed to trust the initial [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) generated by the official initialization scripts. Manual modification would constitute tampering with the audit trail. Furthermore, the scripts compute `ready_for_act` dynamically based on validated inputs, making the file a reflection of the enforced gate state rather than the source of truth.

### Why does the Bash version check for wildcard symbols in case names?

The validation at lines 104‑112 in [`case-init.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/case-init.sh) rejects wildcards (`*`, `?`) and control characters to prevent **glob expansion attacks** and directory traversal. This ensures that the `work/<case>/` directory is created exactly where intended without the shell interpreting special characters that could place case files outside the designated workspace or cause unpredictable behavior during subsequent file operations.

### How do presets like `offline-sample` automatically grant authorization?

Presets bundle common configurations. When you specify `-Preset offline-sample`, the script interprets this as an explicit intent to analyze a local, offline artifact. The PowerShell implementation (lines 56‑78) and Bash equivalent resolve this preset to set `auth_status_resolved` to `granted` while simultaneously forcing the network profile to `offline`. This satisfies the gate conditions for `ready_for_act` because the assets are confirmed to be local files with no network exposure.