
Rev Unicorn Debug
- 1.3k installs
- 1.8k repo stars
- Updated May 6, 2026
- p4nda0s/reverse-skills
rev-unicorn-debug is a reverse-engineering skill that helps developers emulate and debug isolated code fragments or functions inside the Unicorn engine without executing the full binary.
About
rev-unicorn-debug is a Claude Code skill from p4nda0s/reverse-skills for debugging and emulating specific functions with the Unicorn CPU emulation engine. The workflow loads raw binary segments, identifies context dependencies such as JNI calls, syscalls, and libc functions, then simulates them through hook mechanisms so a single function can run in isolation. Developers reach for rev-unicorn-debug when they need to trace algorithm behavior, decrypt data by emulating a routine, or bypass environment dependencies without launching the complete program. The skill emphasizes loading files raw first and incrementally stubbing external interactions until the target fragment produces observable output.
- Loads files as raw bytes first before any ELF/PE/Mach-O parsing
- Identifies JNI, syscalls, libc and other context dependencies then hooks them
- Uses Unicorn callback system for tracing, debugging, error recovery and environment simulation
- Iterative fix workflow: diagnose crashes via hooks then map memory or adjust registers
- Minimal block-level trace output focused on the target function only
Rev Unicorn Debug by the numbers
- 1,281 all-time installs (skills.sh)
- +62 installs in the week ending Aug 5, 2026 (Skillselion tracking)
- Ranked #41 of 596 Debugging skills by installs in the Skillselion catalog
- Security screen: HIGH risk (skills.sh audit)
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/p4nda0s/reverse-skills --skill rev-unicorn-debugAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1.3k |
|---|---|
| repo stars | ★ 1.8k |
| Security audit | 1 / 3 scanners passed |
| Last updated | May 6, 2026 |
| Repository | p4nda0s/reverse-skills ↗ |
How do you debug one binary function with Unicorn?
Emulate and debug isolated code fragments or functions inside the Unicorn engine without executing the full binary.
Who is it for?
Reverse engineers and security researchers analyzing ARM or x86 binaries who need fragment-level Unicorn emulation with dependency hooks.
Skip if: Developers who only need static disassembly, full-process dynamic debugging, or non-binary application troubleshooting.
When should I use this skill?
User wants to emulate a function with Unicorn, trace binary execution without the full program, or decrypt data by emulating an algorithm.
What you get
Emulated function traces, hooked dependency stubs, and decoded algorithm output from isolated binary fragments
- Unicorn emulation scripts with hooks
- Function execution traces
- Decoded or decrypted algorithm output
Files
rev-unicorn-debug - Unicorn Emulation Debugger
Debug and emulate specific code fragments or functions using the Unicorn engine. Analyze context dependencies (JNI, syscalls, library functions) and simulate them through hook mechanisms to complete the user's debugging goal.
---
Core Principles
1. Load file raw first — do NOT parse ELF/PE/Mach-O headers. Read the file as raw bytes and map directly into Unicorn memory. We only need to emulate specific functions, not the entire binary. If raw loading fails (code references segments at specific addresses), then parse minimally — only map the segments needed. 2. Identify context dependencies — analyze the target code for external calls (JNI, syscalls, libc, imports) and hook them to provide simulated responses. 3. Use callbacks extensively — leverage Unicorn's hook system for debugging, tracing, error recovery, and environment simulation. 4. Iterative fix — when emulation crashes, use the callback info to diagnose and fix (map missing memory, hook unhandled calls, fix register state). 5. Minimal trace output — prefer block-level tracing over instruction-level. Only enable instruction trace on small targeted ranges. Use counters and summaries instead of per-step logging.
---
Environment Simulation Strategy
Before emulating, read the target function and identify what it calls. Hook external dependencies by address and simulate in Python:
| Category | Examples | Simulation Strategy |
|---|---|---|
| libc | malloc, free, memcpy, strlen, printf | Hook address, implement logic in Python (bump allocator for malloc) |
| JNI | GetStringUTFChars, FindClass, GetMethodID | Build fake JNIEnv function table in UC memory, write RET stubs at each entry, hook stub addresses |
| Syscalls | read, write, mmap, ioctl | Hook UC_HOOK_INTR, dispatch by syscall number |
| C++ runtime | operator new, __cxa_throw | Hook and simulate |
| Library calls | pthread_mutex_lock, dlopen | Hook and return success/stub |
Hook pattern: Register a UC_HOOK_CODE callback. When PC hits a known import address, execute the Python simulation, then set PC = LR to skip the original function.
---
Callback Types to Use
| Callback | Purpose |
|---|---|
UC_HOOK_CODE | Intercept import calls by address; instruction-level trace (use sparingly, narrow range only) |
UC_HOOK_BLOCK | Block-level trace (preferred over instruction trace) |
UC_HOOK_MEM_UNMAPPED | Auto-map missing pages to recover from unmapped access errors |
| `UC_HOOK_MEM_READ \ | UC_HOOK_MEM_WRITE` |
UC_HOOK_INTR | Intercept SVC/INT for syscall simulation |
---
Iterative Debugging Workflow
When emulation fails, follow this loop:
1. Run — start emulation, let it crash 2. Read callback output — which address faulted? What type (read/write/fetch)? 3. Diagnose:
- Unmapped memory fetch → missing code page, map it
- Unmapped memory read/write → missing data section or uninitialized pointer, map or hook
- Hitting an import stub → identify the function, add a simulation hook
- Infinite loop → add a code hook with execution counter, stop after threshold
4. Fix — add the hook / map the memory / adjust registers 5. Re-run — repeat until the target function completes
---
Architecture Quick Reference
| Arch | Uc Const | Mode | SP | LR | Args | Return | Syscall |
|---|---|---|---|---|---|---|---|
| ARM64 | UC_ARCH_ARM64 | UC_MODE_LITTLE_ENDIAN | SP | X30 | X0-X7 | X0 | X8 + SVC #0 |
| ARM32 | UC_ARCH_ARM | UC_MODE_THUMB / UC_MODE_ARM | SP | LR | R0-R3 | R0 | R7 + SVC #0 |
| x86-64 | UC_ARCH_X86 | UC_MODE_64 | RSP | (stack) | RDI,RSI,RDX,RCX,R8,R9 | RAX | RAX + syscall |
| x86-32 | UC_ARCH_X86 | UC_MODE_32 | ESP | (stack) | (stack) | EAX | EAX + int 0x80 |
| MIPS32 | UC_ARCH_MIPS | UC_MODE_MIPS32 + UC_MODE_BIG_ENDIAN | $sp | $ra | $a0-$a3 | $v0 | $v0 + syscall |
Related skills
How it compares
Pick this over full-process debuggers when the goal is isolated function emulation with custom hooks for external dependencies.
FAQ
What does rev-unicorn-debug use for emulation?
rev-unicorn-debug uses the Unicorn engine to emulate specific code fragments or functions from a binary. Developers load raw file segments, then hook JNI, syscalls, and libc calls so isolated routines run without launching the full program.
When should developers use Unicorn instead of full binary execution?
rev-unicorn-debug fits when only one function or algorithm must be traced—decryption routines, checksum logic, or JNI-dependent code—where running the entire binary is slow, unsafe, or blocked by missing environment dependencies.
Is Rev Unicorn Debug safe to install?
skills.sh reports 1 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.