Add support for binary and firmware analysis

TAG=agy
CONV=802ab86c-1a4a-43d0-b4a6-10ff3c9bde3b

Change-Id: I3aa6a4c9442a03d16a2ee9830894cdd6cab2cf59

Author: nickg-ca

README.md

@@ -33,6 +33,12 @@ for:
 *   **Data & ML Pipelines**: Auditing training data ingress, model serialization
     formats (e.g., Pickle vulnerabilities), or boundary constraints between data
     science notebooks and production.
+*   **Compiled Binaries & Firmware (Gray-Box Auditing)**: Pointing the suite at
+    compiled release artifacts (using tools like `unblob`, `Ghidra`, `radare2`,
+    `qemu`, or `unicorn`) without providing source code. The intent of this mode
+    is to emulate a third-party security researcher, allowing you to see exactly
+    what vulnerabilities are discoverable by adversaries who only have access to
+    your released binaries.
 *   **Custom Test Environments**: Replacing the default container reproduction
     stage with isolated VMs, physical hardware testbeds (via USB/serial), or
     custom simulators.

SCHEMA.md

@@ -16,7 +16,8 @@ evolves sequentially as different skills process it.
 -   **`description`** (String): Detailed explanation of the flaw and its
     mechanism.
 -   **`code_paths`** (Array of Strings): Exact locations of the flaw (e.g.,
-    `["src/auth.c:145"]`).
+    `["src/auth.c:145"]`, binary memory addresses, function offsets, or specific
+    files within an extracted firmware blob).
 -   **`impact`** (String): The potential consequence of the vulnerability.
 -   **`severity`** (Enum): Initial severity estimate (`"CRITICAL"`, `"HIGH"`,
     `"MEDIUM"`, `"LOW"`, `"INFO"`).
@@ -55,7 +56,9 @@ evolves sequentially as different skills process it.
 -   **`patch_status`** (Enum): The outcome of the patching and re-attack
     attempts.
     -   Values: `"VERIFIED_SECURE"`, `"VERIFICATION_FAILED"`, `"ERROR"`
--   **`patch_diff`** (String): The unified diff of the verified fix.
+-   **`patch_diff`** (String): The unified diff of the verified fix, OR for
+    binary-only targets, a general recommendation on how this could be mitigated
+    in a production environment.
 -   **`reattack_status`** (Enum): The outcome of the variant-hunting re-attack
     attempt against the patch.
     -   Values: `"bypassed_patch"`, `"failed_to_bypass"`

mantis_meta_agent/SKILL.md

@@ -25,6 +25,17 @@ resilience, and monitors long-running security pipelines.
 Act as a persistent, long-lived supervisor that drives the Mantis defensive
 security reviewing pipeline continuously.
 
+> **Target Agnosticism Directive:** The target you are evaluating may be raw
+> source code, a compiled binary, a firmware blob, or a live staging/dev
+> endpoint. Ground your analysis in whatever format the target is currently in.
+> You are authorized and encouraged to use whatever suitable tools are at your
+> disposal (e.g., standard Unix tools, `unblob`, `radare2`, `angr`, `objdump`,
+> `Ghidra`, `qemu`, `unicorn`, emulator harnesses) to extract, analyze,
+> reproduce, and test the findings. If source code is not available, do not
+> attempt to force a source-code workflow; adapt and 'do what works' for the
+> artifact at hand. Ensure your subagents are aware of the tools available to
+> them.
+
 Do not perform the auditing or patching tasks yourself. Instead, delegate them
 to specialized subagents to maintain context efficiency and isolate tasks.
 

mantis_patch/SKILL.md

@@ -33,23 +33,38 @@ Execute the patching and verification stage as follows:
 
 2.  **Generate and Apply Minimal Patches:** For each reproduced security flaw:
 
+    -   **Target Agnosticism (Binaries vs Source):** If the target is source
+        code, proceed with generating and applying a code patch as described
+        below. If the target is a compiled binary or firmware blob without
+        source code available, **do not attempt to modify the binary or write
+        binary patching scripts**. Instead, skip the file
+        backup/modification/diff steps and generate a general, high-level
+        recommendation for how this issue could be mitigated in a production
+        environment without requiring deep technical depth. Output this
+        mitigation string in place of the `patch_diff` field.
+
     -   *Optional Parallel Trajectory Search:* If your framework supports
         subagents, you may spawn multiple concurrent subagents to design diverse
         patch implementations. Test all generated patches that successfully
         secure the code without breaking standard functionality, and select the
         *best* patch (e.g., the most minimal, readable, and idiomatic fix)
         rather than just the first one that works.
+
     -   Read the original flawed file to grasp function dependencies and
         structures.
+
     -   Design a minimal, correct patch to mitigate the security flaw (e.g.
         adding bound checks, validating sizes, inserting NUL-terminators)
         without breaking other features.
+
     -   **Backup First:** Create a copy of the target file appending `.bak` to
         its filename to allow robust recovery in case the patch breaks
         compilation or functionality.
+
     -   Replace the file content with your generated patched code.
 
-3.  **Post-Patch Verification Run:** To confirm the patch works, re-run the
+3.  **Post-Patch Verification Run:** *(Skip this step for binary-only targets
+    where no code patch was applied)*. To confirm the patch works, re-run the
     reproducer script inside your isolated execution environment. Use the exact
     `"repro_file_path"` and `"run_command"` from the reproduction entry to
     verify the patch.
@@ -69,9 +84,10 @@ Execute the patching and verification stage as follows:
         bug, or if your re-attack successfully bypasses your patch, the patch is
         insufficient. Re-evaluate and adapt your fix.
 
-4.  **Extract Patch and Restore Codebase:** Do not leave the codebase in an
-    altered state. Once you have a final outcome (either `VERIFIED_SECURE` or
-    you have exhausted your retries), you must:
+4.  **Extract Patch and Restore Codebase:** *(Skip this step for binary-only
+    targets)*. Do not leave the codebase in an altered state. Once you have a
+    final outcome (either `VERIFIED_SECURE` or you have exhausted your retries),
+    you must:
 
     -   If successful, generate a unified diff (e.g., `diff -u file.bak file`)
         representing your exact changes.

mantis_plan/SKILL.md

@@ -25,6 +25,16 @@ Analyze the repository structure and create a detailed defensive security review
 plan that avoids duplication of prior efforts while digging deep into complex
 inter-procedural paths and un-scanned code boundaries.
 
+> **Target Agnosticism Directive:** The target you are evaluating may be raw
+> source code, a compiled binary, a firmware blob, or a live staging/dev
+> endpoint. Ground your planning in whatever format the target is currently in.
+> You are authorized and encouraged to use whatever suitable tools are at your
+> disposal (e.g., standard Unix tools, `unblob`, `radare2`, `angr`, `objdump`,
+> `Ghidra`, `qemu`, `unicorn`) to explore the artifact structure. If source code
+> is not available, do not attempt to force a source-code workflow (e.g.
+> searching for `.c` or `.py` files); adapt and 'do what works' for the artifact
+> at hand.
+
 Execute the planning stage as follows:
 
 1.  **Check for Threat Model Context:** Check the knowledge base directory for a

mantis_reproduce/SKILL.md

@@ -48,7 +48,11 @@ Execute the reproduction stage under these constraints:
     payload (e.g., `crash.payload`) that triggers the target bug. To run your
     script or payload, use the execution or containerization tools available in
     your environment to execute the code safely. Select the most appropriate
-    runtime image and flags for the target language.
+    runtime image and flags for the target. **Execute your reproduction using
+    the appropriate environment:** If the target is firmware, you may write a
+    script to boot it via `qemu`, `unicorn`, or Firmadyne. If it's a binary, you
+    may use dynamic instrumentation or standard execution. Use your best
+    judgment to construct a working harness for the artifact.
 
     -   *Optional Parallel Trajectory Search:* If your environment or agent
         framework supports spawning subagents, you can deploy multiple