ReversingLabs | Blog

In the last couple of years we have seen a drastic increase in numbers of malicious sample we see a day. These numbers are quickly closing to 40M samples a year mark that we expect to see hit this year. That is why the sheer volume of data we are bombarded with each day raises an important question, where is the relevant data in this sea of information?  And even is all data we have relevant?

Prioritization is the main way of extracting relevant data with the techniques and methods used to highlight interesting information varying from one antivirus company to another. However we can think differently in order to sort this information. We can think in reverse asking ourselves which of this data isn’t interesting. With that question in mind we developed a system to exclude damaged, invalid and broken files from our sample bases. In depth file analysis tell us exactly which files have zero chance of execution on any system flagging them as crapware. But is everything broken to that extent?

If you remember recently we gave you a good idea what to do with broken files and how to implement TitanEngine statical validity analysis to identify and fix broken files. For this purpose we will update the TitanEngine Nexus plugin to automatically identify and fix broken files. This will extend this plugin functionality from creating missing dynamic link library dependencies to fixing every aspect of the broken inputted file. And since the plugin will work automatically it needs to be compatible with all existing unpackers. To achieve this we must recognize the basic dynamic unpacker model which looks like this:

As we can see from this flow chart all dynamic unpackers share a certain logic model. Perfect place for Nexus to handle the inputted file is at the start of unpacking process which is achieved by hooking TitanEngine's function IsPE32FileValidExW. This function is called before the unpacking process starts by all unpackers and if it estimates the file as invalid or broken unpacking is aborted. So what does our hook need to do? List of steps to do would be:

• Perform statical validity analysis by calling IsPE32FileValid
• Determine if file is valid or not and if it isn't do the following
  • Create a backup for inputted file
  • Perform statical file fixing by calling FixBrokenPE32FileEx
  • Validate the file fixing success
  • Return TRUE

But this is just the first step because in order to fix the file the TitanEngine can temporarily disable certain fields by removing them from PE header. To revert these changes we must add another hook to revert these changes. Since we are improving Nexus to automatically correct broken files for dynamic unpackers the function to hook is easily recognized as DumpProcessW. This function is called at the start of the unpacking process finalization, just before the necessary data is exported to file on the disk. That makes this function a perfect place to revert the changes to temporarily disabled PE fields. To do this we just need to call FixBrokenPE32FileEx again with the saved FILE_FIX_INFO structure.

By implementing these changes to TitanEngine's Nexus plugin we convert it to all purpose dynamic unpacker helper module because with its help we can unpack broken files and files that are missing their dependencies. And all this done with no modification to the source code of any unpacker we made in the past. As a demonstration of the plugin capabilities we have attached it and a broken UPX sample file with this blog. Until next week...

TitanEngine ReversingLabs Corporation

Nexus plugin (package contains Nexus plugin, UPX unpacker and a broken sample file)