SymbexRequest access
dynamic binary analysis

Static tools guess.
Sandboxes lie. Watch it run.

Symbex executes Android, iOS, Windows, Linux and macOS binaries inside an isolated virtual machine, then hands you a trace you can replay and a verdict you can defend. No source. No host to burn.

Request access See what it does
symbex analyze — liveisolated
$ symbex analyze sample.apk --unpack --symexintake    sample.apk · 24.8 MB · arm64-v8aruntime   android-14 userland · isolatedsymex     18,441 reachable pathsunpack    reflective loader · 3 stagestaint     imei → crypto_key → payloadnetwork   POST hxxps://api-…/v1/ingestbrief     written · findings tied to trace evidenceverdict   MALICIOUS · score 0.94 · Android.Banker

// what it is

One runtime, from raw bytes to a decision.

Most tools do one slice of this and hand you the rest. Symbex does the whole thing:

  1. 01

    the runtime

    It runs the sample

    Instruction-level virtualization for mobile and desktop binaries. The sample runs somewhere it cannot see you, and cannot touch your host.

  2. 02

    the trace

    It records everything

    Every syscall, allocation and packet, captured and replayable — same input, same trace, every time.

  3. 03

    the briefing

    It explains it

    The trace, written in language your whole team understands: what it does, how it persists, where it calls home.

The runtime is where the sample runs. The briefing is where you decide.

Same pipeline. No glue code, no clean-room lab to assemble, no terminal screenshot you have to interpret yourself.

// what teams run through it

Built for samples that fight back.

Everything here is a real thing our beta teams are doing — not a brochure.

  • Malware triage. Take the sample rotting in the queue. Get behavior, IOCs, and a severity you can defend to someone who isn't a reverser.

  • Mobile malware. SMS interception, overlay attacks, droppers, C2 — traced even when the app is packed and the "device" is emulated.

  • Protected samples. Commercial protectors turn native code into bytecode run by an embedded VM. We lift it, follow the handlers, and reconstruct what it actually does.

  • Supply chain. See what that third-party SDK actually does before you ship it.

  • Untrusted binaries. Run a stranger's executable without losing your laptop. Policy bounds what it can even attempt.

  • Detection engineering. Turn real behavior into signatures, YARA and rules — not guesses from a disassembly listing.

// the trace is the product

Analysis you can replay.

A run gives you a deterministic record of everything the sample did. Replay it, diff two samples, or hand it to a teammate — the finding doesn't evaporate when the session ends.

No more 'trust me, it looked malicious.' Point at the instruction, the syscall, the packet.

symbex trace — replayablerun_4f2c
t+0.004s  mmap PROTO_EXEC rx 0x7f31…t+0.011s  read /data/…/payload.bin  (encrypted)t+0.019s  mprotect rwx → self-modifyingt+0.026s  taint imei → key → POST bodyt+0.031s  connect tcp hxxps://api-…/v1/ingest── replay ──$ symbex replay run_4f2c --from 0.026   ok

// nothing to babysit

You shouldn't need a lab to look at one sample.

  • No source. Compiled artifact in, meaning out. APK, IPA, PE, ELF, Mach-O.

  • No native execution. The sample never runs on your machine. Ever.

  • No anti-analysis escape. If a sample checks for a sandbox: we're not one.

  • No lab to build. One service you control, not a weekend of VM wrangling.

// the specifics

What you get, without the fine print.

Symbex technical specifications
PlatformsAndroid · iOS · Windows · Linux · macOS
ArtifactsAPK · IPA · PE · ELF · Mach-O
Architecturesx86-64 · ARM64
Isolationinstruction-level virtualization
Replaydeterministic, byte-for-byte
Executionno native code on the host

// it fights back. that's fine.

Protection is not analysis.

Packing a binary doesn't make it safe. It makes it annoying. That's our problem, not yours.

  • Packers & crypters

    We let the stub do the unpacking, then dump every stage the moment it hits executable memory.

  • Code virtualizers

    Custom bytecode and embedded interpreters get lifted handler by handler until the original logic falls out.

  • Anti-debug & anti-VM

    There's no debugger to detect and no hypervisor artifact to find. The checks pass because there's nothing to catch.

  • Control-flow obfuscation

    Flattened switches and opaque predicates get resolved by symbolic execution, not by staring at a CFG.

  • .NET & Android hardening

    String encryption, reflection, dynamic DEX and IL loading — traced at runtime, where the real code finally shows up.

  • Anti-tamper

    Integrity checks see an untouched binary, because we never patch it. We watch; we don't edit.

// who it's for

We're a private beta. No customer wall yet.

Just the teams we're building this for:

  • malware analysts
  • mobile security teams
  • threat intelligence
  • incident response
  • detection engineering
  • security researchers
  • CTF & reverse-engineering
“We got tired of tools that fall over the second a sample is packed — or lie to you because they can’t see past the anti-debug check. So we built the runtime we actually wanted.”
— the Symbex team · four engineers, building full-time

// get access

Bring us your hardest sample.

Tell us what you're trying to reverse and we'll stand up a runtime. Private beta, onboarding a small number of teams.

Request access
symbex — get startedprivate beta
$ symbex analyze untrusted.bin --unpack --symex$ symbex replay <run-id>

request access → founders@symbex.dev