Module Catalogue

Payload providerIntegratedCross-platform position-independent payload blobs, build tooling, runners, and a Hovel payload-provider shim.

1. 01.01 Overview Cross-platform position-independent payload blobs, build tooling, runners, and a Hovel payload-provider shim. →
2. 01.02 User Guide Link or install the module package from modules/picblobs . Its manifest is modules/picblobs/hovel-module.yaml and declares a payload_provider over JSON-RPC stdio. →
3. 01.03 Building picblobs uses the repository root .bazelrc . The imported modules/picblobs/.bazelrc is retained only as deprecated source context. Invoke every build through Task; the Taskfile owns the required Bazel configurations… →
4. 01.04 Testing The original Bazel, Python, CLI, payload, and generated-file tests are available through root Task targets so they run inside the Hovel build. →
5. 01.05 Reference The server config is 34 bytes: port_u16_le || auth_key[32] . The client config is 38 bytes: port_u16_le || server_ipv4[4] || auth_key[32] . Unconfigured blobs end in exact templates containing port 9999, loopback for… →
6. 01.06 Full Guide Position-independent code blobs for multiple OS/arch targets — how to build, run, extend, and ship them. →
7. 01.07 Introduction Pre-compiled, position-independent code (PIC) blobs for loading and executing arbitrary payloads on multiple operating systems and architectures. Eliminates the need for hand-writing shellcode by providing tested,… →
8. 01.08 How It Works A plain-language tour of what picblobs does under the hood — and why the bytes it spits out can run anywhere. →
9. 01.09 Getting Started Run the commands on this page from the Hovel repository root. Task is the public build interface; it selects the pinned Bazel, Python, Rust, C, and cross-compilation inputs used by both local development and CI. →
10. 01.10 Building Blobs Task is the public build interface. Its Bazel-backed targets use bzlmod and fetch pinned Bootlin cross-compilation toolchains on first use. Run every command below from the repository root. →
11. 01.11 Running Blobs The picblobs-cli CLI operates on blobs staged in the package. It has no knowledge of the build system. →
12. 01.12 picblobs CLI picblobs-cli is a companion package that bundles the non-Linux cross-compiled test runners and verifier-only test binaries alongside a click -based command-line interface. Linux payloads run as temporary ELF… →
13. 01.13 Writing a Blob A blob is a freestanding C program that runs at any address. Include the target OS header first, then the syscall wrappers you need. →
14. 01.14 Code Generation Most boilerplate is generated from tools/registry.py : →
15. 01.15 Adding an Architecture Adding a New Architecture Add an Architecture entry to tools/registry.py Add the architecture to each supported OperatingSystem.architectures list Add syscall numbers to the relevant SYSCALL_NUMBERS tables Create… →
16. 01.16 Adding a Syscall The generated sys/{name}.h will contain the numbers, OS guards, and wrapper. →
17. 01.17 Formatting Run quality workflows through Task from the repository root. The underlying formatters, linters, Python runtime, and C toolchain are pinned Bazel inputs; no Picblobs virtual environment or host linter installation is… →
18. 01.18 Platform Support Boolean flags controlling per-architecture decisions: →
19. 01.19 Test Runners Testing runs from a Linux host. The runner executes directly when the host can run the binary -- the runner architecture matches the host ( x86_64 on the usual dev/CI path), or a binfmt_misc handler (… →
20. 01.20 Testing Runs all unit tests, sync tests, CLI tests, and payload execution tests. Some platform-specific execution cases still skip when required runners, QEMU binaries, ptrace support, or network primitives are unavailable. →
21. 01.21 Project Structure Project Structure tools/ registry.py # canonical platform/syscall registry (single source of truth) generate.py # generates all derived files from registry stage_blobs.py # copies bazel outputs into Python package… →
22. 01.22 Kernel Toolkit The kernel/ directory contains kernel-mode tools for the red team lab. See kernel/lab.md for the full lab guide. →
23. 01.23 Specification The spec/ directory contains the full project specification: →

Payload providerIntegratedWindows payload generation, durable inventory, reconnectable sessions, and typed post-exploitation actions.

1. 02.01 Overview Windows payload generation, durable inventory, reconnectable sessions, and typed post-exploitation actions. →
2. 02.02 User Guide Squatter is a trusted module package. Install it only in authorized Hovel workspaces and treat it as arbitrary code execution on both the operator host and the target lab host. →
3. 02.03 Building Build Squatter from the repository root integration workspace. The aggregate module build covers the Go provider, the selected Windows PE payload, and the source module targets that do not require a dedicated Wine… →
4. 02.04 Testing The standard module gate runs host-side Go tests, provider contract tests, package/install checks, PE inspection, and source-contract tests. Wine-backed runtime tests are separated because they need a Windows… →
5. 02.05 Reference The provider validates the complete hovel.pki.bundle/v1 and writes a versioned, integrity-bound SQPKI001 manifest into the generated PE. The payload loads the certificate chain and PKCS#8 key into statically linked… →