SnikrFlow

Native binary security triage and reachability platform.
Stop wondering where to start reversing a binary. Let SnikrFlow tell you.

The problem

You've got a large ELF binary or an Android .so library. Thousands of functions. No idea where the interesting stuff is. You could spend two hours blindly following callers, references, and branches in Ghidra... or you could ask:

"Before I spend two hours reversing this binary, tell me where I should spend those two hours."

That's what SnikrFlow answers.

SnikrFlow is not a replacement for Ghidra, IDA, Binary Ninja, or GDB. It's the step before those tools: automated triage, reachability analysis, and symbolic execution that narrows "here are thousands of functions" down to "here are the paths you should investigate first."

Large ELF / Android .so
        │
        ▼
    SnikrFlow
        │
        ├── ELF analysis          ├── Call graph analysis
        ├── Function discovery    ├── Reachability
        ├── JNI discovery         ├── Data-flow analysis
        ├── Security sink detect  └── Symbolic execution
        ├── CFG analysis
        │
        ▼
  Prioritized findings
        │
        ▼
      Ghidra
        │
        ▼
  Deep manual RE

Install

pip install snikrflow

(Or, for development: clone the repo and pip install -e .)

Requires Python 3.11+. Built on angr + Claripy for the underlying static/symbolic analysis engine.

Quick start

# The whole pipeline, orchestrated -- this is the one you actually want
snikrflow audit libfoo.so

# Or drill in stage by stage:
snikrflow info libfoo.so                 # ELF metadata
snikrflow functions libfoo.so            # discovered functions (angr CFGFast + symbols)
snikrflow jni libfoo.so                  # statically-exported JNI entry points
snikrflow sinks libfoo.so                # security-sensitive function calls
snikrflow cfg libfoo.so                  # control-flow graph summary
snikrflow callers libfoo.so 0x400d80     # who calls this address
snikrflow callees libfoo.so 0x400d80     # what this address calls
snikrflow reach libfoo.so --source 0x403a00 --sink 0x400d80     # static reachability
snikrflow solve libfoo.so --source 0x403a00 --target 0x400d80   # symbolic candidate input
snikrflow dataflow libfoo.so --source 0x403a00 --sink 0x400d80  # does tainted data reach the sink?

Every command supports --json for scripting/piping into other tools.

What audit actually does

audit is the flagship command -- it runs the full pipeline automatically:

1. Discovers all functions, JNI entry points, and security-sensitive sinks.
2. Checks static (call-graph) reachability across every JNI-to-sink pair -- cheap, so it covers everything.
3. Ranks the statically-reachable pairs by call-chain directness and picks the most promising few for deep analysis.
4. Runs data-flow (symbolic) analysis on that shortlist -- expensive, so it's spent only where it matters.
5. Scores risk transparently and prints ranked findings.

SnikrFlow Security Audit
═══════════════════════════
Binary
  Architecture: x86_64
  Type:         Shared Object
Functions
  294 discovered
  3 JNI candidates
Security-sensitive operations
  2 identified
Interesting paths
  1 statically reachable
  1 selected for data-flow analysis
Findings
  [MEDIUM] JNI -> memory
    Source: Java_..._MainActivity_init @ 0x403a00
    Sink:   strncpy @ 0x400d80  (memory)
    Status: statically_reachable

Risk levels are a prioritization aid, not a vulnerability verdict. Manual verification is still required -- SnikrFlow narrows the search space, it doesn't replace the researcher.

Architecture

SnikrFlow is built in layers, deliberately kept independent from its analysis backend:

CLI ──┐
      ├──> Core Engine ──> SnikrFlow Models ──> Analysis Interfaces ──> Backends
Future GUI ──┘                                                          (angr today;
                                                                     Unicorn/Pin/Dyninst
                                                                          possible later)

• SnikrFlow owns the concepts (Function, SecuritySink, AnalysisPath, SymbolicResult, AnalysisFinding, ...). The CLI never touches angr objects directly.
• analysis/interfaces/ define what SnikrFlow can do. analysis/backends/angr/ define how angr does it today. Adding a future backend means writing a new backend module, not rewriting the CLI.
• The sink signature database (sinks/signatures.py) is a plain, editable Python dict -- add your own categories/functions freely.

Terminology (read this before trusting a finding)

SnikrFlow is deliberately precise about what different results mean -- these are never used interchangeably:

Responsible use

SnikrFlow is for authorized security research only -- use it against binaries you own or have explicit permission to analyze.

Roadmap

• M1 -- ELF foundation (info, functions)
• M2 -- Security triage (jni, sinks)
• M3 -- Program structure (cfg, callers, callees)
• M4 -- Reachability (reach)
• M5 -- Symbolic execution (solve)
• M6 -- Data flow (dataflow)
• M7 -- Audit engine (audit)
• M8 -- Android APK support (audit app.apk)
• M9 -- Advanced analysis (better taint tracking, caching, SARIF)
• M10 -- GUI (presentation layer over the same engine, no duplicated logic)

Credits

Built on angr and Claripy. CLI powered by Typer and Rich.

License

MIT -- see LICENSE.