binary-reversing

name	binary-reversing
description	Aggressive static reverse engineering of authorized binaries and native components with the explicit goal of finding high-severity vulnerabilities. Use when you have ELF, Mach-O, PE, firmware, packed artifacts, native libraries, or large decompiles (especially jadx trees) and need to hunt for bugs fast. Red-team oriented: form attack hypotheses early, chase weak signals, and hand off to dynamic/fuzzing aggressively when static hits a wall.
metadata	{"short-description":"Red-team binary reversing — fast static analysis to find real bugs in native code and decompiles","category":"vulnerability-research","priority":"high"}

Binary Reversing (Red Team Edition)

Your mission is to find bugs, not to produce beautiful reversing notes.

Static analysis is a weapon. Use it to locate trust boundaries, parsers, crypto, auth checks, and dangerous sinks as fast as possible. Then either prove the issue statically or throw it over the wall to dynamic analysis and fuzzing.

Red Team Philosophy

• Form attack hypotheses early. Do not wait until you have a complete understanding of the binary.
• A "weird" function, missing check, or suspicious data flow is a lead — chase it.
• Static is fast. Use it to eliminate impossible paths and highlight the most promising ones.
• When static runs out of steam, hand off aggressively to binary-debugging, fuzz-harness-builder, or code-vulnerability-review (if source exists in the jadx tree).
• De-escalate only after real effort, not because "we couldn't find the bug statically."

Core Workflow

1. Rapid Triage

   • Identify architecture, format, compiler, protections, packing, entropy.
   • Run string_triage.py immediately for quick wins (URLs, paths, crypto terms, error strings, protocol constants, debug strings).

2. Map the Attack Surface

   • Find input parsers, deserializers, protocol handlers, plugin loaders, update mechanisms, license checks, IPC boundaries.
   • Locate dangerous sinks (memory operations, command execution, file writes, crypto operations, privilege transitions).

3. Generate Hypotheses

   • "What if this parser trusts the length field?"
   • "What if we can reach this dangerous function with attacker-controlled data?"
   • "What if the signature check can be bypassed before this point?"
   • Write these down and start proving or disproving them.

4. Deep Static Analysis

   • Use disassembly + decompilation together (never trust one view).
   • Trace data from untrusted sources to dangerous operations.
   • Look for missing bounds checks, integer issues, use-after-free patterns, weak crypto, improper key handling, etc.

5. Decide Fast

   • Can I prove this statically? → Document it and promote in finding-tracker.
   • Looks promising but needs runtime? → Hand off immediately to binary-debugging.
   • Parser or protocol? → Consider fuzz-harness-builder.
   • Dead end after real effort? → De-escalate with notes.

Helper Tools

String triage (use this first):

python3 .grok/skills/binary-reversing/scripts/string_triage.py /path/to/binary
python3 .grok/skills/binary-reversing/scripts/string_triage.py --json --min-len 8 /path/to/binary

Other fast tools:

• file, readelf, objdump, nm, rabin2, rizin, binwalk, strings
• Ghidra / Binary Ninja / IDA for serious work
• capa for capability detection
• yara for known packers/protectors

Special Cases

Large jadx decompile trees (very common in your work):

• Treat the decompiled Java as the primary source of truth when available.
• Use grep aggressively across the entire tree before reading individual files.
• Focus on native method calls (System.loadLibrary, JNI, etc.) and any interaction with native components.

Patch diffing:

• Compare versions quickly. Focus on changed functions around parsers, auth, crypto, and update logic.
• A changed function + a string like "signature verification failed" is often a goldmine.

Packed / obfuscated binaries:

• Identify the packer/protector fast.
• If easy static unpacking is possible, do it.
• If not, hand off to binary-debugging with a clear plan instead of wasting time.

Handoffs (Be Aggressive)

• Promising lead that needs runtime behavior, crashes, or memory inspection → binary-debugging
• Parser / file format / protocol that should be fuzzed → fuzz-harness-builder
• Code that has Java/Kotlin source in the jadx tree → code-vulnerability-review
• Chain potential → exploit-chain-analysis
• Needs clean proof packet → triage-verifier

Output Expectations

When you have a lead, produce something actionable:

• Clear hypothesis
• Specific locations (function, offset, class, offset in jadx)
• Attacker-controlled input path
• Dangerous sink
• Missing or weak control
• Evidence (strings, cross-references, decompiler output, constants)
• Recommended next step (debug, fuzz, source review, etc.)

Do not over-document dead ends. Move fast.

Bottom Line

This skill should feel like a scalpel for finding native and decompiled vulnerabilities, not an academic reversing exercise.

Form hypotheses fast.
Gather evidence.
Prove what you can statically.
Throw the rest to dynamic tools or fuzzing.

The goal is high-severity findings, not perfect reversing reports.