Back to the automagical method - the idea was, as always, pretty simple - I wanted to use the "print it" debugging method (basically you print out everything you can on the screen / to some file, and analyze it later to check if something has an unforeseen/invalid value), but, it is not as easy to do it in assembly as it is in C/PHP/Python/etc, since you have to know the address of a printf/puts function, and be able to add several lines of code to print each interesting thing (this can be a problem if you have limited space), and also, you have to remember about storing the environment before the printf call (since the debug messages should not mess up the execution flow). However, as one knows, it is fairly simple to check the value of anything from a debugger - let's say from GDB (the favorite *nix debugger!). But... (there is always a but...) it takes a while to setup the GDB to print the right stuff at the right time - basically you have to create some scripts that do that. And, you'll have to update these screens after each address change - jumping from the disassembler (to check the address) to the script editor (to replace the old address with the new one) can be a real pain sometimes.
So, why not to make a tool that will create a proper gdb script for us? Let's just tell the tool in the source code how what actions do we want it to perform, and let it handle the rest!
The internals of such a tool are really really simple (the approach has some glitches, but it works perfectly in most cases...) and are divided into a few parts.
The first part is embedded in the assembly source code, and it contains GDB scripts with actions that should be taken by the debugger in that place. An example embedded-gdb-script looks like this:
; echo Section name under ESI:
; print (char*)$esi
GDB_BP is a macro thats defined as 4x nop, and it serves a double-purpose: 1st - the string "GDB_BP" itself is a signature detected by another piece of the mechanism; 2nd - the 4 nops are also a signature, detected by yet another piece of the same mechanism. This two pieces work this way:
1. The first signature is detected in the provided source (the GDB_BP string in a line with %macro is omitted), and it reads the gdb script starting from line after the GDB_BP, until it reached the ---GDB_BP string. This script is stored (as a whole) on The Script List - it's added at the end of that list.
2. The 4 nops signature is detected in the provided compiled assembly file, and it's address is calculated (the start address of the place in memory where these opcodes will be loaded also has to be provided) - then, the address is stored in The Script List in the Nth element (there N is the number of detected signature), and in the file the first nop is changed to int3 (CC byte).
After these two steps, the final gdb script is generated - it looks like this:
set disassembly-flavor intel
set logging file gdbhelplog.txt
set logging overwrite
set logging on
if ($eip)==(THE CALCULATED ADDRESS+1)
SCRIPT FROM THE SCRIPT LIST (without the semicolons etc)
...OTHER SIMILAR IFS...
set logging off
And now, after we have the script ready, we launch the gdb, break on some main or sth, load the script (source script_name.gdb), and launch the function (gdbhelpfunc) and the rest is automagical - everything is logged into gdbhelplog.txt.
So, as you can see, it's simple - just find some signatures, and generate some script - nothing more then a few printfs and freads - but it really makes life simpler! The source code is at the bottom of this post (C++, not really safe, but it works). Oh, the GDB_BP macro looks like this:
%macro GDB_BP 0
Download: gdbhelper.cpp (7kb)
P.S. The unicorn has been found by:
Good luck to people who still look for it ;>