Sem86 swaps x86 CPU rules mid-run to find the instruction that gives an emulator away
The research emulator runs old Windows versions, but its demonstration uses deliberately constructed malware and its current CPU descriptions are still handwritten.
A program can spot an emulator by asking a processor a question with an awkward answer. Sem86 lets researchers change that answer while the program is running, then narrow down which instruction made the difference. The fake PC can catch the software checking its ID, right down to the suspicious instruction.
The research project’s description explains that x86 includes undefined behavior and undocumented instructions. Different implementations can respond differently in those corners. Malware can use those differences to decide that it is inside an analysis environment and change its behavior, leaving the analyst staring at a well-behaved sample.
Sem86 moves instruction semantics into a file loaded at runtime. In plain terms, the rules describing what instructions do become an input to the emulator. Changing a rule no longer requires treating the whole emulator as one fixed account of a CPU. That’s useful when the specific odd behavior is the thing under investigation.
The authors’ paper says they constructed a toy malware example for the demonstration. Swapping semantics mid-execution lets Sem86 bisect the run: narrow the interval where alternate rules make execution diverge until the offending instruction is identified. “Toy” is doing useful work here. This is a demonstrated analysis technique, rather than a claim to catch every real-world evasive sample.
The project reports performance at 1.9 times Bochs and about 42 percent of QEMU. Those are the project’s reported comparisons, and they don’t establish the same relationship for every guest or workload. The ability to ask a different CPU question is the selling point; another benchmark trophy would be a rather roundabout explanation.
Old Windows can boot inside the experiment. The project lists Windows 3.1, 98, XP and 7, along with Debian 8, targeting Pentium-era hardware. It also spells out limits: no GPU for Windows 7’s Aero effects, and no Windows 7 driver for the emulated NE2k network card. The nostalgic desktop arrives with convincing reasons something isn’t working.
The repository calls Sem86 a research project and says it is “not ready for production use.” Its instructions require Linux or Android and a working Rust toolchain, plus your own guest disk image. Copy-on-write disk handling keeps guest writes in memory by default; the README warns that enabling persistent writes changes the image and may risk corruption after an improper shutdown.
The larger ambition is CPU cloning from automatically inferred instruction behavior. That remains a goal: today’s Sem86 rules are handwritten, because the linked libLISA work does not yet provide the required 16-bit and 32-bit observers. Automatically copying a processor’s quirks would expand the research, but a future input file shouldn’t be mistaken for a feature already delivered.
If that inference work arrives, reproducing a CPU could mean preserving its mistakes as carefully as its documented behavior. Malware analysts would gain another way to test an evasive sample’s assumptions, while software historians could study why code behaved differently on supposedly compatible machines. The research could preserve the behavior on which old programs depended even when no manual promised that it would work.
The weird CPU answer stays on record.