I wanted a way to analyze suspicious Linux binaries locally without uploading them to VirusTotal, spinning up a virtual machine, or deploying a heavyweight sandbox.
So I built Lure — a Python-based CLI that isolates ELF binaries using Linux namespaces, traces their behavior with strace, and generates a simple risk verdict in seconds.
As a cybersecurity student, I built it because I wanted something fast, local, and easy to understand.
The Problem
When I need to quickly inspect a suspicious binary, the usual options are:
- Upload it to VirusTotal (not always possible with private or sensitive samples)
- Spin up a virtual machine
- Deploy a sandbox such as CAPE or Cuckoo
- Run
strace ./binaryand manually sift through hundreds of lines of syscall output
All of these approaches work, but they can feel heavy for a quick local analysis workflow.
I wanted something that could answer a simple question:
What did this binary actually do?
Meet Lure
Lure is a command-line tool for analyzing Linux ELF binaries in an isolated environment.
It combines Linux namespaces and syscall tracing to provide a concise, readable summary of a binary's behavior.
lure run ./suspicious_binary
Instead of raw strace output, Lure displays events in real time:
📁 [0.026s] OPEN /etc/ld.so.cache
⚠️ [0.031s] SENSITIVE /etc/passwd
🌐 [0.033s] CONNECT 93.184.216.34:443 (BLOCKED)
When execution finishes, it generates a structured report:
╭─── Execution Summary ───╮
│ Runtime 0.017s │
│ Syscalls 45 captured │
│ Exit Code 0 (success) │
╰─────────────────────────╯
╭─── Files Accessed ──────╮
│ ⚠️ /etc/passwd │
╰─────────────────────────╯
╭─── Network Activity ────╮
│ 93.184.216.34:443 │
│ Status: BLOCKED │
╰─────────────────────────╯
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ ✗ DANGEROUS ┃
┃ Sensitive file access combined ┃
┃ with network activity detected ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
The verdict system is intentionally simple:
- ✓ CLEAN
- ⚠︎ SUSPICIOUS
- ✗ DANGEROUS
The goal is not to replace a full malware analysis platform, but to provide an immediate and understandable assessment.
How It Works
The core of Lure relies on two Linux features.
unshare
unshare creates isolated namespaces for the process being analyzed.
The binary runs with:
- An isolated user namespace
- An isolated mount namespace
- An isolated network namespace
This gives the binary a restricted view of the system and prevents direct network communication.
strace
strace records every syscall made by the target process.
Lure parses those syscalls in real time and categorizes activity such as:
- File access
- Process execution
- Network connections
- Sensitive system interactions
The result is a report that is significantly easier to interpret than raw syscall logs.
Binary Inspection Without Execution
Before running a binary, Lure can perform static inspection.
lure inspect ./binary
This command extracts information directly from the ELF file, including:
- Architecture
- Entry point
- Linked libraries
- Security mitigations
- NX
- PIE
- RELRO
- Stack canaries
- File hashes
- UPX packing detection
All without executing a single instruction.
Why Not Use Existing Tools?
Lure is not intended to replace established malware analysis frameworks.
Tools such as CAPE, Cuckoo, and virtualized analysis environments provide much deeper visibility and more advanced capabilities.
However, they are designed for different workflows.
Lure focuses on:
- Fast local analysis
- No cloud uploads
- Minimal setup
- Readable output
- Lightweight execution
- Linux-first workflows
For many quick investigations, that is enough.
What I Learned Building It
Parsing strace Is Harder Than It Looks
I initially assumed syscall parsing would be straightforward.
It wasn't.
Different syscall formats, interrupted calls, incomplete lines, and numerous edge cases meant that a significant portion of the project became defensive parsing rather than analysis logic.
False Positives Destroy Trust
One early version flagged /etc/ld.so.preload as a sensitive file.
The problem?
Many normal dynamically linked binaries interact with it during startup.
As a result, something as harmless as /bin/ls appeared suspicious.
Reducing false positives turned out to be more important than adding new detections.
Linux Namespaces Are Incredibly Powerful
I expected sandboxing to be the hardest part.
Instead, Linux already provides most of the primitives needed through namespaces and standard tools such as unshare.
Python's subprocess module handled the rest.
Tech Stack
- Python 3
clickrichpyelftoolsstraceunshare
No external APIs.
No cloud services.
No subscriptions.
Just standard Linux tooling and Python.
Roadmap
Some features I'm currently exploring:
- JSON report export
- YARA rule integration
- File-write tracking
- Improved syscall classification
- Additional detection heuristics
- Terminal dashboard (TUI)
Try It Yourself
git clone https://github.com/0xusmanismail/lure.git
cd lure
pip install -e .
Inspect a binary:
lure inspect /bin/ls
Run a binary:
lure run /bin/ls
Lure currently targets Kali Linux and Debian-based distributions with strace and unshare installed.
GitHub: https://github.com/0xusmanismail/lure
Final Thoughts
Lure is the first security tool I've released publicly.
Building it taught me far more about Linux namespaces, ELF internals, and syscall tracing than I expected. There's still plenty of work ahead, but the current version already solves a workflow problem I encounter regularly.
If you work in malware analysis, reverse engineering, incident response, or Linux security, I'd genuinely appreciate your feedback.
As a cybersecurity student, this is the first tool I've shipped publicly—I would genuinely love your feedback!
What would you add to a tool like this?
Top comments (0)