glshim

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.