As an addition to the method of finding the presence of Debuggers and Virtual environment, exploiting the debugging tools have started. Recently we came across a new variant of BKDR.IRCBot was found to perform such a trick of exploiting this unexplored vulnerability existing in the LoadExportSymbols() function of dbghelp.dll. This vulnerability causes Olly Debugger (or any other debugger) using this unfixed version of DLL to crash or execute remote code while they load such crafted executables or DLL’s.
When any debugger tries to load the executable, it crashes without any error or crash report. This being a suspicious behavior of anti-debugging, took made me to analyze the file further. Prior to loading in debugger, I noted the file to contain TLS table entry with a TLS Callback function registered with it. I started looking for other simple documented anti-debugging tricks, but could not find any. This is where we sensed that malware is challenging with some out-of-ordinary anti-debugging tricks.
On further analysis of the file’s structure values like Data Directory entries, Import Table entries and its corresponding API’s imported, Export Table, etc. For an executable, existence an export table made me suspicious. It had one export function with very long random bytes. Upon parsing the file in Hex Editor I could conclude the export table function name is 0xC1C bytes long. Now, what does this long name had to do with the crash of a debugger?
Further analysis of the crash narrowed me down to the crash at dbghelp.dll one of the libraries imported by any debugger. The function LoadExportSymbols() was the place where the execution crashes. Further analysis at this module helped me sense that this function will not check the length of the export name string being copied from the buffer to the stack and hence causing buffer overflow in the module. This can better be understood from the illustration below.
In the fig, we could see that at the memory location 0x6D529AFF, the export table name data is being copied from buffer to the stack. The buffer can be seen in the dump screen at offset 0x01E72613, and the corresponding data being moved to the stack at 0x0012A491. A normal scenario which can be found in any buffer overflow vulnerability.
If someone has not updated their toolset or dbghelp.dll in the Olly directory in this case or in any applications where one uses this DLL, this method can be used as a simple anti-debugging technique.
