dsh 破甲 plugins: 3 types, permissions and reset

dsh 破甲 plugins are not one category: some rewrite requests, some provide a red-team workbench, some organize pentest flows. Identify the type before installation; the wrong type will never behave as expected no matter how you configure it.

Three types first

At least three implementations are called 破甲 plugins. Their goals, entry points, and risk boundaries differ.

dsh-jailbreak changes the request, not the model. It rewrites at the outbound boundary and pairs that with a fixed evaluation set and scoring loop so reverse engineering, sample analysis, CTF, and authorized pentest questions return actionable steps (source).

dsh-redteam-model changes the workflow. It turns the DSH web UI into a red-team workbench with ten modes, each carrying persona, playbook, skills, and references, plus stage gates, tool interception, and process records (source).

dsh-pentest and dsh-voredteam focus on process and auditability. The former records targets, leads, and vulnerability assets; the latter uses a blackboard and a six-stage method to make testing a traceable state-space search, explicitly banning DDoS and high-frequency brute force (source).

Before installing: three authorization artifacts

A 破甲 plugin does not grant authorization; it only executes. Prepare three things before starting.

1. Scope: written authorization, boundaries, and the list of assets you may touch. Targets without written authorization do not enter the list.
2. Target list: domains, IPs, accounts, and environments, marking production versus isolated.
3. Window and contact: start and end times, an emergency contact, and how to stop if something is damaged.

The artifacts constrain, not decorate. The stronger the plugin, the more external constraints it needs. Isolation comes first; reproduce in a local or staging environment when possible.

Install: Hub or CLI

Installation is simple; installing into the right profile is not. Choose one path and do not mix.

1. Hub path: open Settings, Plugin Market, search the plugin, verify owner and source, click Install, check package name and version in the dialog, then restart.
2. CLI path: run dsh plugin --profile web add <package-or-reference>, then confirm with dsh plugin --profile web list.
3. Verify profile: for the desktop app, replace web with the actual profile name; wrong profile is the most common "no effect."
4. Restart: request-boundary plugins attach during startup, so a full exit and restart is required.

The package name in the dialog is the only identifier. Same-name plugins are common; if owner and package do not match, cancel. Do not install several plugins of the same type at once, or request rewriting and workflow may conflict.

Configure: valves, modes, scope

Configuration should limit capability, not amplify it.

1. Request rewriting: check valve switches, self-test, and evaluation criteria. Run self-test first, then adjust valves; wider valves need stronger external constraints.
2. Workbench: choose a mode, then inspect stage gates. The mode sets process and assets; the gate decides when progress is allowed. Do not skip a gate manually.
3. Flow plugins: define target and scope before recording leads and results. Keep targets, assets, and findings separate for traceability.
4. Shared settings: keep tool interception, permission prompts, and logging on; turning them off makes the process unauditable.

Record configuration changes. Which valve, which mode, and why, in the same test record; otherwise rollback has no baseline. Working is not the same as correctly configured: correctness means it stays inside authorized scope.

Verify: three signals

Verify once after installation and once after configuration.

1. Load signal: dsh plugin --profile web list contains the plugin and system logs show no load failure.
2. Effect signal: request plugins show rewritten requests; workbenches show mode entries and gates; flow plugins show target and lead panels.
3. Boundary signal: out-of-scope requests are blocked or prompted, not silently allowed.

All three signals must pass before real testing. Passing the first two only means capability is enabled, not that constraints are verified, which is the most dangerous state.

Reset: four steps

Failure usually looks like "installed but no effect" or "flow stuck." Reset in four steps instead of reinstalling.

1. Identify the layer: plugin not loaded, configuration not applied, or model refusal. The external behavior differs.
2. Revert configuration: restore the last valve, mode, or interception setting and retest. A single-variable rollback beats reinstalling.
3. Clear cache: workbench modes and assets may be cached locally; export test records before clearing.
4. Reinstall: only after the first three fail. Record version and configuration to avoid restoring the same broken combination.

The goal is a known-good state, not defaults. Defaults may not fit your test scenario; known-good is the baseline.

Uninstall and cleanup

Uninstalling removes the plugin, not three kinds of residue.

1. Plugin directory: run dsh plugin --profile web remove <package>, restart, and confirm the list is clean.
2. Configuration: check the profile for sections the plugin registered; leftovers affect the next install.
3. Test data: clean modes, assets, findings, and reports separately; export before deleting.

Restart once before judging cleanliness. Some registrations are cached at runtime and only disappear after a restart.

Three common problems

No effect, stuck flow, and incomplete uninstall are the three most common issues.

1. No effect: verify profile, then loading, then model refusal. Reverse the order and you reinstall in the wrong direction.
2. Stuck flow: inspect stage gates and tool interception; decide whether requirements are unmet or permission was denied. Do not skip the gate.
3. Incomplete uninstall: check directory, configuration, and test data. Deleting the directory alone leaves configuration and data that affect the next use.

All three share one cause: checking only one signal. Plugin, configuration, and model are three layers; a conclusion from one layer is unreliable.

Next steps

Confirm authorization, confirm type, then install. For layer diagnosis, read Why old DeepSeek jailbreak prompts fail. For install failures, read When a jailbreak plugin installs but fails. For the security-testing plugin landscape, read What pentest plugins exist.

Sources: dsh-jailbreak plugin page, dsh-redteam-model plugin page, dsh-pentest plugin page, dsh-voredteam plugin page