Regarding performance: An important question would be how is the target machine code being emulated. From the scarce information we have so far, I think they ar

Regarding performance: An important question would be how is the target machine code being emulated. From the scarce information we have so far, I think they are using an interpreter, which would be too slow for most applications. With a JIT (or even AOT) compiler this scenario would be more realistic. Then, there is the question of what does Unicorn Engine do at user-level with instructions like syscall on x86_64 or sc in ppc64. I see no references to any of this in the site. If your target is "high-level emulating" the underlying operating system (like WINE does), being able to specify native handlers for such instructions is a must. If both conditions are satisfied then it should be doable for most applications: Load the binary, replace calls to dynamically linked system libraries with native implementations that match the specifications (on undocumented systems this means lots of reverse engineering) and ensure that any syscall/sc/etc. instruction results in a behaviour the application expects. From here you could take care of the rest yourself: Multiple threads could be handled by multiple host threads running each a Unicorn Engine instance with separate CPU register states, but sharing the entire virtual address space. The target application's stdin/stdout could be redirected from the host's emulator stdin/stdout. And so on... :-) Disclaimer: I'm just guessing what could be done if they provide a decent binary translator and the API cares about high-level-emulation. But I'm not sure if that's even a goal for them by looking at their site.