- Latest master build of Unicorn. Both Usercorn and Unicorn are rapidly changing, so make sure both are completely up-to-date before submitting a bug report.
- Stable version of Capstone
- Go 1.5 or newer
- Make sure you have the GOPATH environment variable pointed at a directory like
$HOME/go
, and$GOPATH/bin
is in your PATH
Simply go get -u github.com/lunixbochs/usercorn/go/usercorn
.
To do a source tree build, you can also run make
or go build -i -o usercorn ./go/usercorn
usercorn bins/x86.linux.elf
usercorn bins/x86_64.linux.elf
usercorn bins/x86.darwin.macho
usercorn bins/x86_64.darwin.macho
usercorn bins/x86.linux.cgc
usercorn bins/mipsel.linux.elf
- User-space system emulator.
- Backed by Unicorn.
- Similar to qemu-user.
- Unlike qemu-user, does not require the same OS for which the binary was built.
- Wait, what? What does that mean?
- Syscalls are coerced into the Go language APIs using persuasive fit techniques. Syscalls s/should/might/ work almost anywhere the language does.
- This means Usercorn will eventually work anywhere Unicorn and Go work (but currently means Linux, BSD, and OS X)
- Debug stubborn binaries. I had a binary gdb refused to debug ("Program exited during startup."). No problem. Usercorn can single-step into the program for you.
- Debug foreign architecture and OS binaries. You don't need a MIPS box. You don't need qemu-user. You don't even need Linux.
- Write tools, like fuzzers, static analyzers, recompilers, memory and register tracing...
- Selectively call functions from within a binary.
- Whatever you want. Open an issue if you have a cool debugging / reverse engineering idea I didn't think about - I may just implement it.
- Your userspace might be incredibly confusing to the target binary.
- No API for memory mapped files yet (kinda, if mmap() currently gets a file descriptor argument it will manually copy the file into memory).