usercorn

st 1:1 then. https://github.com/lunixbochs/usercorn

r runtimes. x86_64 Linux is the best supported loader right now, so the rest could use some love. There's progress being made on OS X / iOS + dyld startup right now. Support for issuing signals to the guest CPU (need a signal handler table on a process's kernel structure, a syscall handler for `signal` and `sigaction`, and code that can jump the guest CPU into a signal handler and do a `sigreturn`) More syscall emulation (~50/350 syscalls are implemented for Linux and OS X), but it's pretty easy to add new ones. Support for guest threading and fork/clone (these will likely need a virtual process/thread table, then each thread/process can run on a Goroutine and take advantage of Go's existing scheduler). Virtual filesystem layer, so syscalls like open/read/write don't go directly to the host OS and can be intercepted/overlaid in a more general sense. - - - lib43 - https://github.com/lunixbochs/lib43 Skills: C, ASM, Syscall ABI Yet another libc, created as a result of this blog post: http://ryanhileman.info/posts/lib43 - mostly just has string, memory, number, and basic IO functions right now. Ways to contribute: Pick a man page for any missing libc function and implement it in a simple/readable manner, or dive into an architecture syscall ABI (like ARM/NetBSD) and write the assembly backend for it. https://github.com/lunixbochs/lib43 - - - glshim - https://github.com/lunixbochs/glshim Skills: C, OpenGL This provides desktop OpenGL ~1.5 sans shaders to any mobile device implementing OpenGL ES 1.0. It has been used to port dozens of open and closed-source games to the Pandora and other mobile platforms. It was also used for the Android real-Minecraft launcher (called Boardwalk I think). Current goals include testing/improving the remote rendering (which allows software like emulators to easily serialize and remotely render OpenGL), increasing compatibility (testing games + filing/fixing issues on GitHub), adding WINE support (will be a trial/error process of running WINE, debugging/fixing the thing that prevents initialization, repeat), and writing more feature tests (which are actually pretty easy. You write a simple program to make OpenGL calls and assert which OpenGL ES calls should be emitted from the other end). - - - patchkit - https://github.com/lunixbochs/patchkit Skills: Python, C, ASM This project allows you to reproducibly patch compiled binaries with one or more short Python scripts. It includes an assembler (Keystone), disassembler (Capstone), basic linker, basic static recompilation/code transformation engine, control flow graph, and C compiler integrations... all in about 700 lines of Python. It was mostly created for use in attack-defense Capture The Flag competitions. These are both working patches: def patch(pt): pt.patch(0x800400a, asm='mov eax, 1') def patch(pt): pt.patch(pt.entry, c='void f() { printf("hi\n"); }') It mainly needs glue code written for more architectures, support for PE/MachO formats, and improvements to the C compiler/linker. The provided symbols are mostly specific to Darpa's DECREE environment, so support should be added for yanking/calling symbols from the binary itself as well as integrating something like lib43 to provide a basic libc and syscall support on many platforms. - - - ActualVim - https://github.com/lunixbochs/actualvim Skills: Python This project is a massive hack to sneakily jam a Vim instance into a Sublime Text buffer. This gives you surprisingly good Vim keybinding support, and even works with your Vim plugins, but it totally breaks Sublime Text plugins and commands (as text changes won't be propagated back to Vim). As a result, the project is mostly a joke right now (just a pretty UI around Vim that breaks most interactive Vim plugins). I do think NeoVim is mature enough to take this the rest of the way into being a serious project, and there's a fair bit of interest. The Sublime Text side of the interface works very well, so the main tasks here would be (1) swapping out Vim for NeoVim (which I seem to remember having a very simple remote control API), and a (2) handler to propagate text changes back from Sublime plugins into the NeoVim buffer.

emu-i386 and qemu-arm. The primary usercorn binary can emulate every single supported OS/arch combination and aims automatically detect the correct arch/kernel when you run a program. Usercorn is being built as a framework around the Unicorn Engine. It's not just a way to run a binary on the command line. It can be loaded as a library (`NewUsercorn("binary").Run(args, env)` will run an arbitrary supported app). It allows hooking many things and I've been building a lot of features around static trace/analysis. I'm extremely excited about some of the features and supporting tools I have planned. This twitter thread shows examples of a tool called imgtrace I built with Usercorn. imgtrace can visualize memory writes done by a program. The Hilbert curve view of MD5 is nice, as it makes the memory containing the internal MD5 state as well as the iterators very obvious at a glance: https://twitter.com/lunixbochs/status/717945725024280578 The underlying code of imgtrace is also extremely simple (basically all of it is to create the image data), which shows off the power of Usercorn's simplicity: https://github.com/lunixbochs/usercorn/tree/master/go/cmd/im... Usercorn is much less mature than qemu-user. It supports around ~50/400 Posix syscalls and is missing many architecture-specific features. Some architectures still need work on memory segmentation and thread-local storage. I've split up functionality internally in a way that makes sense, but I'm still building the base functionality and haven't designed the public API at all yet (even though it's possible to use Usercorn from external code, that's just happenstance due to the functions/types I exposed while building it). ---- Architecture support is tied to Unicorn. Usercorn supports x86_64 best, and has various levels of support for ARM, MIPS, sparc, and m68k. It's still very much WIP, but can run many binaries at this point, even Linux binaries dynamically linked to glibc. Host support is best on OS X and Linux. Guest support is best on Linux.

ed Alternately you can use dynamorio, intel pin, qemu, or a quick instruction scan/patch for SYSCALL to manually break on syscalls. Either way you almost certainly will not be able to do this with python-ptrace alone. I filed an issue to write a `maybe` tool using Usercorn [1] (which supports OS X) with my VFS overlay work, which means writes could still succeed but be non-destructive. [1] https://github.com/lunixbochs/usercorn/issues/151