Unicorn Engine VS QEMU

OFRAK Tetris is a project I started at work about two weeks ago. It's a web-based game that works on desktop and mobile. I made it for my company to bring to events like DEF CON, and to promote our binary analysis and patching framework called OFRAK.

In the game, 32-bit, little-endian ARM assembly instructions fall, and you can modify the operands before executing them on a CPU emulator. There are two segments mapped – one for instructions, and one for data (though both have read, write, and execute permissions). Your score is a four byte signed integer stored at the virtual address pointed to by the R12 register, and the goal is to use the instructions that fall to make the score value in memory as high as possible. When it's game over, you can download your game as an ELF to relive the glory in GDB on your favorite ARM device.

The CPU emulator is a version of Unicorn (https://www.unicorn-engine.org/) that has been cross-compiled to WebAssembly (https://alexaltea.github.io/unicorn.js/), so everything on the page runs in the browser without the need for any complicated infrastructure on the back end.

Since I've only been working on this for a short period of time leading up to its debut at DEF CON, there are still many more features I'd eventually like to implement. These include adding support for other ISAs besides ARM, adding an instruction reference manual, and lots of little cleanups, bug fixes, and adjustments.

My highest score is 509,644,979, but my average is about 131,378.

I look forward to feedback, bug reports, feature requests, and strategy discussions!

Entails hundreds of hours of single-stepping through that opcode in Linux kernel using an indirect operand pointing toward its own opcode (self-modifying code).

Even the extraordinaire Fabrice Bellard (author of QEMU) admitted that it is broke and did a total rewrite, which fixed tons of other issues.

https://github.com/unicorn-engine/unicorn/issues/364

This is how I found out a snippet of assembly code that can actually distinguished between a KVM hypervisor and most of today’s emulator.

https://github.com/unicorn-engine/unicorn/issues/364

Actually, that gives me an idea. Unicorn Engine (https://github.com/unicorn-engine/unicorn) is FOSS and claims to be able to emulate many CPU architectures like x86. Do you think it could be possible to just run a regular Hackintosh setup through Unicorn Engine‘s x86 emulator? Definitely it would be very slow, and there is chance that it will just not work, but that would make the process fairly easy as Hackintosh setup is pretty well documented. Though I have to admit that I only just found Unicorn Engine and I can find almost no documentation for it other than on their github. I would be a bit skeptical of unicorn engine, but do you think that this could be possible?

https://www.unicorn-engine.org/ for example.

For C/C++ projects that use meson as the build system, there is an excellent way to manage dependencies:

https://mesonbuild.com/Wrapdb-projects.html

https://mesonbuild.com/Wrap-dependency-system-manual.html

meson will download and build the libraries automatically and give you a variable which you pass as a regular dependency into the built target:

https://github.com/qemu/qemu/tree/005ad32358f12fe9313a4a0191...

https://github.com/harfbuzz/harfbuzz/tree/main/subprojects

https://github.com/harfbuzz/harfbuzz/blob/37457412b3212463c5...

Or, if you're using proper operating systems, they're managed by the usual package manager, just like everything else.

In this tutorial, we set up macOS and Windows virtual machines on UTM, a macOS application that provides a GUI wrapper for QEMU, a powerful open-source emulator and virtualizer. UTM allows you to easily manage and run virtual machines without memorizing complex commands. It also has special handling for macOS, making it simpler to install compared to other virtual machine software.

On Mac, each Podman machine is backed by a QEMU based virtual machine. Once installed, the podman command can be run directly from the Unix shell in Terminal, where it remotely communicates with the podman service running in the Machine VM.

QEMU's "VGA" device is a typical PCI VGA adapter with Bochs SVGA extensions. First enumerate PCI so you can figure out how to talk to the device's I/O, then follow the Bochs SVGA specifications to write a driver. There's also some information on the wiki, although it seems to make a few x86-specific assumptions.

The links I gave you explain how to interact with it. This page explains how the Bochs SVGA registers are mapped in PCI devices. This page explains what the Bochs SVGA registers do. This page gives examples for how to use a Bochs SVGA device.

I've had lately a look at QEMUs internals and saw their thread safe implementation of a hash table, capable of concurrent reads: qht [0].

If the author sees this, you might want to take a look at it.

[0] https://github.com/qemu/qemu/blob/master/util/qht.c

TLDR; if you just want a simple VM, use gnome-boxes or qemu which is what gnome-boxes uses under the hood.

QEMU [0] emulates many systems, including the 32-bit Intel architecture. For retro gaming specifically I can recommend PCem [1], which also emulates a wide range of sound and graphics cards, from IBM MDA to 3dfx Voodoo 2.

[0] https://www.qemu.org/

[1] https://pcem-emulator.co.uk/

https://github.com/qemu/qemu/blob/ac5f7bf8e208cd7893dbb1a952...

But not the client side (vfio-user-pci). So, the feature is half-baked in the mainline project.

I don't know if any of the qemu devs browse HN but it would be nice to hear more about the plans for vfio-user.