I’m using it a lot in AI-driven reverse-engineering (old DOS games), agents love it (usually Python harness)
Unicorn – The Ultimate CPU Emulator
21–30 of 35 posts
Re: Unicorn – The Ultimate CPU Emulator
#22The problem is that it's not sustainable - QEMU improved so much since the moment of fork and updating the QEMU code in Unicorn is always done manually. It is especially important for architectures that evolve quickly - ARM64, RISC-V, x86. Meanwhile, QEMU now has the notion of TCG plugins[1] that can read/write registers and memory, which is enough for most cases. You can see many examples of the plugins in contrib/plugins[2] directory of the mainline QEMU - a good starting point.
[1] https://www.qemu.org/docs/master/devel/tcg-plugins.html
[2] https://gitlab.com/qemu-project/qemu/-/tree/master/contrib/p...
Re: Unicorn – The Ultimate CPU Emulator
#23The problem is that it's not sustainable - QEMU improved so much since the moment of fork and updating the QEMU code in Unicorn is always done manually. It is especially important for architectures that evolve quickly - ARM64, RISC-V, x86. Meanwhile, QEMU now has the notion of TCG plugins[1] that can read/write registers and memory, which is enough for most cases. You can see many examples of the plugins in contrib/p…
This looks useful for a lot of instrumentation use cases, but less so for building custom emulators, if I'm understanding it correctly.
Re: Unicorn – The Ultimate CPU Emulator
#24The problem is that it's not sustainable - QEMU improved so much since the moment of fork and updating the QEMU code in Unicorn is always done manually. It is especially important for architectures that evolve quickly - ARM64, RISC-V, x86. Meanwhile, QEMU now has the notion of TCG plugins[1] that can read/write registers and memory, which is enough for most cases. You can see many examples of the plugins in contrib/p…
This looks useful for a lot of instrumentation use cases, but less so for building custom emulators, if I'm understanding it correctly.
For this, I believe, working with the mainline is more promising path, at least to reduce the amount of changes needed[1].
Re: Unicorn – The Ultimate CPU Emulator
#25uh.. what is a cpu emulator? or what can I do with it? I am kind of having hard time comprehend this.
It can be used for many things. But the main use is reverse engineering.
This. It is far easier to debug something like obfuscated DRM code when you have it running inside an emulator and can wind the code forwards and backwards and see the whole machine, rather than trying to debug it on the actual hardware where your options are more limited.
Re: Unicorn – The Ultimate CPU Emulator
#26uh.. what is a cpu emulator? or what can I do with it? I am kind of having hard time comprehend this.
[deleted]
Re: Unicorn – The Ultimate CPU Emulator
#27uh.. what is a cpu emulator? or what can I do with it? I am kind of having hard time comprehend this.
It can be used for many things. But the main use is reverse engineering.
Main use for consumers / tinkers. In industry, the main use is during pre-silicon development. You emulate the target processor and model the periphs and you have a complete virtual representation of your new SoC/MCU/etc before the hardware is available. Benefit being once you do get the hardware, you already have the entire software stack nearly ready to go and already tested.
Re: Unicorn – The Ultimate CPU Emulator
#28Codex just walked me through my first experience with unicorn the other day, emulating / stubbing out subsystems from a Pioneer CDJ-3000 to help understand its music catalog database format and network protocol.
It felt like science fiction watching Codex write unicorn to host binaries and reverse engineer them.
Re: Unicorn – The Ultimate CPU Emulator
#29The problem is that it's not sustainable - QEMU improved so much since the moment of fork and updating the QEMU code in Unicorn is always done manually. It is especially important for architectures that evolve quickly - ARM64, RISC-V, x86. Meanwhile, QEMU now has the notion of TCG plugins[1] that can read/write registers and memory, which is enough for most cases. You can see many examples of the plugins in contrib/p…
This is actually the whole reason I wrote the patches that allow you to read and write memory and registers. I work on fuzzing, and fuzzing tools are a fragmented ecosystem of QEMU forks and patches that are outdated the moment they are published. Even PANDA from MIT LL which has great support struggled to keep their patches rebased and compatible with QEMU's actually-pretty-fast releases. Upstream or bust, it's really not that hard, it just takes a little persistence (and with LLMs learning git email is easy)!
Re: Unicorn – The Ultimate CPU Emulator
#30The problem is that it's not sustainable - QEMU improved so much since the moment of fork and updating the QEMU code in Unicorn is always done manually. It is especially important for architectures that evolve quickly - ARM64, RISC-V, x86. Meanwhile, QEMU now has the notion of TCG plugins[1] that can read/write registers and memory, which is enough for most cases. You can see many examples of the plugins in contrib/p…
This looks useful for a lot of instrumentation use cases, but less so for building custom emulators, if I'm understanding it correctly.
Plugins would definitely be the wrong tool for the job for actual new emulator development, but if you needed to do something easy like add an NVRAM for a router rehost you could do that with plugins e.g. by skipping an instruction and using a callback to implement the desired behavior (as long as it is something a plugin is allowed to do -- you can't access device memory yet).