If you remember not so long ago we wrote about minor inconveniences we encountered while working with OllyDBG. Today we return to that subject with challenges we face when reversing modern software protectors. One such protection is SafeEngine or NoobyProtect, which uses a simple portable executable malformation in order to crash OllyDBG. Even though this crash is limited to old OllyDBG versions, it is interesting for us nevertheless. The crash itself wouldn't be interesting if, in fact, the application didn't then operate normally. But it does, which makes it even more sinister. This leads us to conclude that this portable executable malformation is either ignored by the system or irrelevant to the system loader ... but not to our debugger. So, where's the trick? What does it apply to?

If you look at the import table you will see that the first entry is rather unusual. Its name in LordPE is "kernel32...". Which could be fine since the trailing ".dll" is optional. If only it wasn't for those three little dots. Those dots represent multiple new lines after the name. In fact if we open the file with a hex editor we see that there are exactly 0x100 bytes following the first import library name. And in addition, there are 0x3000 bytes that follow the name of the first imported function in the first library trunk. These extra bytes seem to be too large for Olly to handle, overwriting some memory and ultimately making it crash. Since EIP is rewritten to 0x0d0a0d0a this could be an exploitable attack vector. Now we knew about this kind of attack for a while, having first seen it as an attack via too long names in the export table. But this is a bigger issue, since the import table is affected.

If we investigate further we find an even more interesting issue that arises because of the way Windows processes the import table. If the import address table pointer inside the image import descriptor isn't nil and if it points to a sequence of eight zero bytes, the import entry will be ignored completely. Also, if the import lookup table pointer is valid and it points to at least one valid import address pointer, tools such as LordPE will read that data and display a list of functions that never get imported. This means that Windows will ignore the image import descriptor entry completely, which makes the dynamic link library name irrelevant as it will never reach the loading stage. This enables anyone to craft a file that only looks like its importing a specified library which may or may not be present on the system. And that can create confusion about which library is actually needed and which isn't.

This isn't something that NoobyProtect does - but it could if it wanted to. Working around our crash problem is as easy as updating to OllyDBG 2.0 or patching the broken import table. Until next week...

sampleFile
(package contains a harmless sample file that imports a non existent DLL)

During our every day work as reverse engineers we encounter problems that affect the tools we use. Most commonly to try to detect their presence and/or crash them. Whatever is their purpose we must work our way around them. One of such problems we encountered recently is a theoretical scenario in which OllyDBG can't resolve data about the loaded modules. This scenario is possible do the fact that OllyDBG doesn't use unicode APIs to access files on the disk. However question remains, how can you load a DLL file with non English characters? That isn't possible via import table since all DLL names in that table are ASCII. In fact only way to do this is to use the unicode version of LoadLibrary API, which seems odd because it isn't really clear why this is even possible. Simply put there is no need for such a feature because files with names that consist of non English characters can't be statically loaded because PECOFF documentation specifies that those strings are ASCII. But this is just a minor inconvenience we can work around since that memory can still be accessed. One of the available solutions is to rename the file and correct the LoadLibrary calls to load the new file. Until next week...

Functionality of the plugin is almost equal to the OllyDBG's handle window but with a slight difference. TitaniumHandles gives you an option to view only open mutex handles and has an ability to close remote handles which can come in handy when analyzing software protections. This plugin is just another sample of multiple ways one can use the functions inside the TitanEngine to ease file analysis.

TitanEngine ReversingLabs Corporation

TitaniumHandles 1.0 (package contains plugin binary and source code)