Encrypted execution engine
This article describes an implementation of user-mode (therefore,
OS independent) code decryption engine for 32-bit x86 architecture.
Apart from encryption, the engine may be also used for user-mode
tracing, thus avoiding ptrace() or similar APIs. The code has been
developed in x86 assembler and tested under Linux and FreeBSD, but it
should also work on Win32.
I have taken the concept of encrypted execution one step further by
the CSPIM simulator. The results of this research have been published
in this paper.
CSPIM is a MIPS I processor simulator. There are already a number
of different MIPS simulators available on the internet, for
- Simulator in the Nachos
- gxemul; his page has links to many other MIPS
- qemu dynamic translator.
but all are parts of larger projects (mostly whole-system
emulation), and none of them is designed to meet the two basic
requirements of mine (though Nachos seems to come close):
- Library interface, so that all aspects can be easily controlled from the
- Ability to run in freestanding environment (i.e. an environment without
the standard C library).
Given that MIPS I is an extremely simple architecture, it was
easier to write a simulator with clean interface from scratch, rather
than adapting an existing code (some of which I don't want to mess
with because it's GPL'd). The name CSPIM is purposefully chosen to
resemble SPIM, which is actually only an interpreter of MIPS assembly
source code (i.e. it is not able to execute any kind of
Development has been moved to GitHub .
- Simulates the basic MIPS I instruction set in little-endian mode. This
also means that the host application must be running on a little-endian
- Able to load and execute ELF binaries produced by mipsel-elf-gcc
cross-compiler (see demo applications for correct compile/link flags).
- Clean library interface which makes it usable in a wide variety of
- 64-bit clean code which has been tested with 32-bit gcc and both 32-bit
and 64-bit SunCC.
- Safe code which does not let the simulated program "escape" the simulated
CPU and mess up the host application.
- Delivered with a CPU "torture test" that tests every single instruction for
- Implements most of SPIM system calls and is binary-compatible with SPIM's
- It is able to interpret itself.
Floating-point arithmetic and big-endian mode
Both features may be implemented in the future. Neither is high priority.
Not planned at all
The following features/deviations from the real CPU's behavior are not planned
to be implemented at all because they are not needed to correctly run
executables generated by gcc.
- System control processor (paging, caching, exception status register).
- Accurate branch delay slot exceptions (the real CPU/OS resumes the branch
instruction; CSPIM resumes the delay slot).
- If a branch instruction tries to transfer control to invalid memory area,
the exception is reported immediately for the branch instruction itself,
and not for the target PC.
- Delayed loads are not simulated; i.e. a load instruction behaves as if
there were no delay. This is no problem, because it is assumed that gcc
generates correct code. It is also in accordance with MIPS I spec which
says that disobeying delayed load restriction has undefined behavior.