Unicorn Engine VS box64

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.

macOS runs x64 executables just fine through Rosetta so I don't see why Wine couldn't make use of that hardware acceleration.

It's also possible to only simulate the entrypoints through Rosetta and then execute native aarch64 code from there. On Linux https://github.com/ptitSeb/box64 does exactly that, for example. However, with the performance Apple has been able to squeeze out of Rosetta, I'm not sure of that workaround is even necessary.

Recently, I got a server from Oracle Cloud, having 4 cores and 24GB of RAM. Then, using a software called Box86 and its 64 bit version called Box64, I succeeded in running Factorio! Unfortunately, 1.1.80 ran at 3 UPS! I went through each major version, testing each individual one down to 0.12. Here are my results!

You could try https://github.com/ptitSeb/box86 and https://github.com/ptitSeb/box64/ , I believe they allow you to emulate x86_64 on aarch64, though I have no experience with them, so cannot say for sure.

git clone https://github.com/ptitSeb/box64.git

If you have time and patience take a look at box86 and box64. These are basically like translation layers that allow x86/x86_64 applications to run on ARM. I personally haven't use them yet, so I can't provide a guide or vouch for game compatibilities. But by the look of the progress made by them so far it looks promising.

You can follow progress of this on https://github.com/ptitSeb/box64/issues/635

This analogy falls apart quickly and really isn't great like trimming sandwiches might be like using box64 and box86 and you would be using a bread machine (compiler) to make another bread machine (another/newer compiler). You need to read up on what a compiler to a specific CPU instruction set does to see why a binary made for one can't just run on another without translation or taking the source code and making a binary (what your sample script does) that runs on that CPU arch.

Actual impact is not sure, but I can speculate. Short term customers pay more for ARM. Long term RISC-V products just got relatively cheaper for high end and might see a BoARM to go along with Box86 and Box64 so compiled programs on android (Dalvik byte code programs wont need it) will 'just work'. I wonder if this had anything to do with Google making RISC-V Android version a thing. As long as a big percentage of the device cost is the CPU it should still be competitive.

You could have a look at box86 and box64:

https://box86.org/ | https://github.com/ptitSeb/box64

I haven't tried them myself, but I've read consistent testimony that the performance (and compatibility) is great.