decompiler
1.0.0
|
To use SLEIGH as a library within an application, there are basically five classes that you need to be aware of.
The core SLEIGH class is Sleigh, which is derived from the interface, Translate. In order to instantiate it in your code, you need a LoadImage object, and a ContextDatabase object. The load image is responsible for retrieving instruction bytes, based on address, from a binary executable. The context database provides the library extra mode information that may be necessary to do the disassembly or translation. This can be used, for instance, to specify that an x86 binary is running in 32-bit mode, or to specify that an ARM processor is running in THUMB mode. Once these objects are built, the Sleigh object can be immediately instantiated.
Once the Sleigh object is in hand, the only required initialization step left is to inform it of the ".sla" file. The file is in XML format and needs to be read in using SLEIGH's built-in XML parser. The following code accomplishes this.
In order to do disassembly, you need to derive a class from AssemblyEmit, and implement the method dump. The library will call this method exactly once, for each instruction disassembled.
This routine simply needs to decide how (and where) to print the corresponding portion of the disassembly. For instance,
This is a minimal implementation that simply dumps the disassembly straight to standard out. Once this object is instantiated, the Sleigh object can use it to write out assembly via the Translate::printAssembly() method.
In order to generate a pcode translation of a machine instruction, you need to derive a class from PcodeEmit and implement the virtual method dump. This method will be invoked once for each pcode operation in the translation of a machine instruction. There will likely be multiple calls per instruction. Each call passes in a single pcode operation, complete with its possible varnode output, and all of its varnode inputs. Here is an example of a PcodeEmit object that simply prints out the pcode.
Notice that the dump routine uses the built-in function get_opname to find a string version of the opcode. Each varnode is defined in terms of the VarnodeData object, which is defined simply:
Once the PcodeEmit object is instantiated, the Sleigh object can use it to generate pcode, one instruction at a time, using the Translate::oneInstruction() const method.
For an application to properly follow flow, while translating machine instructions into pcode, the emitted pcode must be inspected for the various branch operations.
A LoadImage holds all the binary data from an executable file in the format similar to how it would exist when being executed by a real processor. The interface to this from SLEIGH is actually very simple, although it can hide a complicated structure. One method does most of the work, LoadImage::loadFill(). It takes a byte pointer, a size, and an Address. The method is expected to fill in the ptr array with size bytes taken from the load image, corresponding to the address addr. There are two more virtual methods that are required for a complete implementation of LoadImage, getArchType and adjustVma, but these do not need to be implemented fully.
The ContextDatabase needs to keep track of any possible context variable and its value, over different address ranges. In most cases, you probably don't need to override the class yourself, but can use the built-in class, ContextInternal. This provides the basic functionality required and will work for different architectures. What you may need to do is set values for certain variables, depending on the processor and the environment it is running in. For instance, for the x86 platform, you need to set the addrsize and opsize bits, to indicate the processor would be running in 32-bit mode. The context variables specific to a particular processor are established by the SLEIGH spec. So the variables can only be set after the spec has been loaded.