# Seep Reverse Lab for Agent-Native Reverse Engineering

> Seep Reverse Lab is a Lua-centered workbench that organizes reverse engineering tools, knowledge journals, agent contracts, and client-side authorization audits. It is aimed at security researchers who already understand the boundaries of authorized testing and need a structured workflow across Windows, Android, Linux, and Web targets.

**angusdevgo/Seep-Reverse-Lab** — Agent-Native multi-platform reverse engineering and CWE-602 client-side authorization audit workbench.

- Repository: https://github.com/angusdevgo/Seep-Reverse-Lab
- Stars: 1,797 · Forks: 664
- Language: Lua
- License: GPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/angusdevgo-seep-reverse-lab

## What Seep Reverse Lab Combines For Authorized Research

Seep Reverse Lab addresses a practical coordination problem in reverse engineering work. A single investigation may require binary inspection, APK processing, runtime instrumentation, knowledge retrieval, and a written security record, while the underlying tools expose different interfaces and produce different artifacts. The project presents these activities as one agent-oriented workbench rather than as a collection of unrelated command-line programs.

The documented audience includes users who provide a technical goal in plain language and expect the agent to identify the platform, classify the task, select a route, and produce evidence. The README gives the example of finding a premium check in FooBar.apk and bypassing it. That example is security-sensitive, so it should only be used within an authorized scope. The project is not a general-purpose substitute for permission, target ownership, or a formal authorization process.

The workbench also has a narrower CWE-602 focus. CWE-602 is presented as the basis for client-side authorization audits, with an airplane-mode confirmation step intended to test whether a client-side decision is the only control preventing an operation. The README does not describe a hosted service, a public API, or a general application scanner. It describes a repository-based workflow built around files, agent prompts, tool wrappers, and generated scripts.

## The softseep Orchestration Path

The central mechanism is a disk-backed lab mode state machine. According to the architecture diagram, state is held at `~/.pi/agent/lab-mode.flag`. A plain-language request enters the lab mode component, where terminology mapping, `BLOCK_NONE` injection, and cognitive redirection are applied. Context is then persisted across model switches and context compression.

The `softseep` master orchestrator performs a two-stage classification. The first stage identifies the platform as Windows PE, Android APK, Linux ELF, or Web. The second applies nine task paradigms and a seven-gate decision tree, labeled G0 through G6, before selecting a route such as `apkseep`, `ida-reverse`, `seep` MCP, or knowledge-base search. The README states that this routing is intended to reduce agent decision drift, but it does not publish the full classification rules.

Execution then flows through selected tools and returns toward proof generation, sandbox execution, a self-healing loop, airplane-mode confirmation, and a three-part consulting-grade security report. The repository presents this as a closed-loop process. It does not establish that the self-healing loop can repair every failure, nor does it define the exact sandbox or confirmation environment. Those are important implementation boundaries for an adopter who needs reproducible audit controls.

## Tool Routing, MCP Wrappers, And Context Control

The project advertises 23 integrated MCP tools that wrap or connect Radare2, JADX, Apktool, and Frida. The intended benefit is a unified tool surface, so an agent can move between static analysis, APK processing, and runtime verification without manually switching command-line interfaces. The README also mentions an optional IDA Pro MCP route, which means the base workflow appears to accommodate IDA Pro as an additional integration rather than requiring every investigation to use it.

The tool surface is paired with a knowledge base described as 289 technical field journals and 14 desensitized paradigms. The documented discipline is to search the knowledge base before executing a task. This is more than a library suggestion: the architecture places knowledge-base search beside MCP and IDA routes, so prior research is part of the decision path.

Seep also controls output volume. The documented options for `seep_r2_decompile` include `full`, `fold`, and `summary`, with stated token reductions of about 60 percent and 90 percent. `seep_r2_disasm` offers `full` and `branch` output, while `seep_r2_xrefs` uses pagination, a default limit of 10, and a total-statistics header. These figures are claims in the README, not independent measurements. The design trades detail for context economy. An investigator may need the omitted code or broader cross-reference view before accepting an audit conclusion.

## Installation And First Authorized Use

The repository provides a one-click `install.ps1` script, and the README says the setup supports Pi Agent, Claude Code, DeepSeek Harness, Codex, and OpenCode. The README does not show the command line used to invoke the script, its prerequisites, or its supported operating-system setup details. Therefore, there is no safe install command to reproduce here. Start with the repository's `install.ps1` file and confirm the target agent environment before executing it.

After deployment, the README gives a plain-language request as the first interaction. The following is the documented example, using the target name from the README. It should be run only on an APK and device for which the researcher has authorization:

```text
lab: analyze FooBar.apk - find the premium check and bypass it
```

The documented response sequence begins with `seep_auto_triage`, followed by `seep_apk_decompile` using `output_mode=fold`, `seep_kb_search`, and `seep_apk_gen_hook`. The example says that the generated `hook_verify.js` Frida script is then executed on a connected device. The README does not provide the exact invocation for the generated script, so an adopter must follow the generated file and the connected-device setup rather than assume an undocumented command.

The first review should inspect the triage result, the decompiled control-flow artifact, the matching knowledge-base journal, and the generated hook before any execution. A successful tool response is not by itself proof that the client-side authorization control is the only enforcement point.

## Where The Evidence Chain Can Fail

The most important limitation is the gap between an agent-generated conclusion and an independently reproducible authorization finding. The README describes PoC generation, sandbox execution, self-healing, and airplane-mode confirmation, but it does not specify the sandbox image, device configuration, Frida version, target application version, or the exact evidence format. Without those details, another reviewer may be unable to reproduce the same result.

The context-reduction controls create another trade-off. A `fold` or `summary` decompilation view can reduce token consumption while omitting code that changes the interpretation of a check. A branch-only disassembly view and a paginated cross-reference result are useful for navigation, but they can also hide the surrounding behavior needed to distinguish a UI check from a server-side policy. The workflow should therefore treat reduced views as screening artifacts, not complete findings.

There is also a platform boundary. The repository advertises Windows, Android, and Linux support, but the README does not explain how each external binary tool is installed, version-matched, or permissioned. A failed analysis can therefore result from missing dependencies or an unsupported target format rather than from the target lacking the suspected vulnerability. The documentation also does not promise rollback for changes made by an agent, so backup and change-control procedures remain outside the documented feature set.

## Seep Reverse Lab Versus A Direct Toolchain

The practical alternative is to use Radare2, JADX, Apktool, Frida, and IDA Pro directly, with the researcher maintaining the workflow manually. That approach provides more direct control over command selection and evidence capture. It avoids adding an orchestration layer, but it also leaves platform identification, knowledge retrieval, output sizing, and report assembly to the analyst.

Seep's difference is coordination. It puts multiple tools behind an agent-facing MCP surface, adds a `softseep` router, persists lab-mode context, and connects analysis to knowledge-base search and a CWE-602 evidence sequence. Direct tool use is simpler when an investigation is small, familiar, and already covered by an existing playbook. Seep is more relevant when repeated work benefits from consistent routing, reduced decompilation output, and an agent contract that records the intended sequence.

This comparison concerns workflow structure, not output accuracy. The README does not establish that an orchestrated route produces better reverse engineering than direct expert use. It only establishes that Seep is designed to coordinate the named tools and research records.

## License, Maintenance, And Adoption Cost

The repository is licensed under GPL-3.0. The README also attributes related methodologies and frameworks to other projects with MIT or GPL-3.0 licensing. An organization adopting Seep should review the license text and attribution requirements for the full set of code, scripts, documentation, generated artifacts, and external tool integrations that it distributes. This is a compliance and distribution check, not legal advice.

The repository is not archived, and its last push was on 2026-10-14. It has no GitHub releases, so the repository does not provide a release stream through that mechanism. The README displays `v1.6.0`, but the absence of GitHub releases means adopters should not assume that this label has an associated release package, migration notes, or signed artifact.

The largest upgrade cost is likely dependency coordination. Seep is designed to connect several external tools, so changes in Radare2, JADX, Apktool, Frida, agent hosts, or target device environments may affect a workflow even when the Lua workbench itself is unchanged. The README does not document a compatibility matrix, automated upgrade command, or rollback procedure.

## Conclusion

Adopt Seep Reverse Lab when an authorized research team wants an agent-oriented workflow that connects existing reverse engineering tools with structured audit records. Do not treat it as a general-purpose exploit framework, a replacement for human authorization review, or evidence that an agent's conclusion is correct without checking the generated artifacts. Before adoption, inspect `install.ps1`, supported tool dependencies, audit scope, and GPL-3.0 license requirements. The repository's last push was on 2026-10-14, and it has no GitHub releases.

## FAQ

### What is Seep Reverse Lab used for?

It is an agent-oriented reverse engineering and CWE-602 client-side authorization audit workbench. It coordinates tools such as Radare2, JADX, Apktool, and Frida through documented MCP integrations.

### How do I install Seep Reverse Lab?

The repository provides a one-click `install.ps1` script and says it supports Pi Agent, Claude Code, DeepSeek Harness, Codex, and OpenCode. The README does not provide the exact invocation or prerequisites.

### Does Seep Reverse Lab have GitHub releases?

No. The repository has no GitHub releases, although the README displays a `v1.6.0` badge.

## Sources

- [angusdevgo/Seep-Reverse-Lab on GitHub](https://github.com/angusdevgo/Seep-Reverse-Lab)
- [Issues](https://github.com/angusdevgo/Seep-Reverse-Lab/issues)
- [License: GPL-3.0](https://github.com/angusdevgo/Seep-Reverse-Lab/blob/main/LICENSE)
- [README](https://github.com/angusdevgo/Seep-Reverse-Lab/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/angusdevgo-seep-reverse-lab