MicroPython VS Unicorn Engine

it's not an embeddable runtime like Lua

While it's true you can't have multiple MicroPython interpreters running concurrently (or at least not easily; it's not that the design makes this impossible, it's just that all in all MicroPython is fairly young and development focus has been put elsewhere), it is possible to embed MicroPython. Not completely out of the box, needs some glue code etc. See for example https://github.com/micropython/micropython/tree/master/ports....

It's obviously not directly comparable - each port will be different - but startup time is <50ms on an RP2040 (Cortex M0 @133MHz):

https://github.com/micropython/micropython/issues/8420

Yes, although MicroPython is focused on running on microcontrollers it can be useful if you want to reduce memory consumption, flash space and even startup time on servers.

The challenge is that MicroPython has many fewer standard libraries:

https://github.com/micropython/micropython/wiki/Standard-Lib...

And so many Python libraries targeting CPython won't work out-of-the box and you'll need to modify them or use alternatives that do work on the MicroPython subset.

I'll link to it because many people don't know a version of Python runs on microcontrollers:

https://micropython.org/

I'm personally working on something like this for the ESP32, but written on top of micropython [1]. A few things are written in C such as the display driver, but otherwise most things are in micropython. We chose the T-Watch 2020 V3 microphone variant as the platform [2].

Our objective is to build a modern PDA device via a mostly stand-alone watch that can be synced across devices (initially the Linux desktop). We want to achieve tasks that you might typically do on your desktop, focussed towards productivity.

We did consider a custom OS, but decided against it for a few reasons:

1. Allowing somebody else to handle basic OS stuff allows us to concentrate on what really matters, the higher level stuff on top.

2. Having multiple threads in micropython is super simple and we are able to run many active apps at the same time, rather than having to kill them off [3]. Our background apps can continuously interact with the network in the background.

3. Code written for micropython can be easily run on other Python-capable devices.

[1] https://micropython.org/

[2] https://lilygo.cc/products/t-watch-2020-v3

[3] https://tactility.one/#/application-lifecycle

tools/mpy_ld.py: https://github.com/micropython/micropython/blob/master/tools...

tools/mpy-tool.py lists opcodes: https://github.com/micropython/micropython/blob/master/tools...

Can the same be done with .pyc files; what are the advantages of MicroPython native modules?

Why does it need wasm2c?

And us machine emulators too, like Fabrice Bellard (QEMu) and me (and my OP post detailed the failing of emulated TLB in QEMU as discovered in Unicorn emulator).

Unicorn emulator - https://github.com/unicorn-engine/unicorn

If you find Capstone interesting, check out the Unicorn Engine.

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

Also, if anyone is interested in an example of using capstone for basic disassembly and analysis, here is a link to my capstool project.

https://github.com/alexander-hanel/capstool

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