BlackHat, one of the world's biggest security conferences, was held in Las Vegas two weeks ago. Among the BlackHat conferences this year, Las Vegas was by far the biggest event  - bringing thousands of security researchers to the heart of the Sin City. Bigger then ever before, BlackHat featured eleven tracks with an impressive number of high quality talks and trainings. We were there, and we were more than proud to present our newest file analysis tool, TitanMist, to the World.

In a fairly full room, for a reversing track that is, we presented the TitanMist project we have been working on for the past couple of months. Best described as  an automated PE32 file format identification and unpacking tool, TitanMist aims to improve collaboration among reverse engineers across the globe. That is an ambitious goal, but we have high hopes for this project and believe that we can grow it into something of great value in the coming months. Our detailed project roadmap will be unveiled on our blog next week.

The TitanMist presentation was accompanied by the Arsenal presentation that featured all of our tools: TitanEngine, NyxEngine and TitanMist. This kind of tool demo was introduced at this year's BlackHat USA and we must admit that we like the idea of tool presentations, during which authors receive direct feedback from the community. This feedback enables us to add new features and improve our tools even further. We got  many great ideas from talking to attendees with an interest in our tools and what we do. Ones attendees with particularly intriguing questions or ideas questions were rewarded with one of our TitanEngine T-Shirts. But t-shirt winner or not, we thank you all for your continuing support of ReversingLabs and the TitanEngine project!

In the picture on the left you can see our Arsenal booth and one of our senior software engineers, Mario Suvajac. Mario is one of the guys behind the TitanMist project, in charge of the byte pattern matching and overall tool design.

That is it for this report, until next week...

We had a great time during this year's REcon Conference last week.  Now it is the time to sort out our impressions. First of all, thanks to all that attended our TitanEngine training and during the course of 3 days learned how to make unpackers with our engine. We covered coding of both static and dynamic unpackers and showed how to deal with the complex protection options that reverse engineers come across on a daily basis. In addition to training attendees, we also want to thank everyone who grabbed one of our TitanEngine T-shirts to show support for the project. You want one too? Click here...

We can, without any false flattering, call REcon our favorite small conference and promise to be back next year too! But that doesn't mean that everything went smoothly, as there were some problems with the air conditioning that flooded the conference twitter feed with AC related rants. The heat was so bad that the conference opening talk dedicated a good amount of time to it. Being slightly older than the average REcon attendee, Richard Thieme, made a parallel between Woodstock and the problems we had. He argued that Woodstock wasn't that great either but that over time it became a myth due to people, rain and mud and that the same can be said about the heat in Montreal which will probably make us say on some later REcon "remember the one when the AC was broken? That one was great!" Because indeed it was, and as the AC problems went away, everyone's will to commune ignited. And the people who  attend the conference on a regular basis are probably the best thing about the conference. Don't get us wrong, the trainings were great, the talks were awesome but it was the people who impressed us the most. And it is these great people that we will meet again in two weeks at BlackHat US. Until then...

When talking about new concepts, its always best to demonstrate them on something everyone is familiar with. In our case that's of-course UPX with which we are fairly familiar. It almost feels like we write one UPX unpacker each week, doesn't it?

Today we are presenting an optimization concept that enables us to unpack everything in a single go. Now, when talking about file unpacking we always unpack everything in one go, but we never unpack both the main executable module and all of its packed dependencies in a single run. Normally, you wold do this by batching through individual files.  But from a speed perspective, the best optimization imaginable comes from unpacking the main module and all of its dependencies at once. Since TitanEngine wasn't really designed to do that out-of-the-box, it needs just a little bit of help to pull it off.

The problem is the existence of multiple relocation tables, and more importantly multiple import tables. Since TitanEngine was designed to unpack files one at the time, we must do some additional coding around these boundaries to achieve our goal. Compared to a traditional TitanEngine dynamic unpacker, the only difference is the need to collect import table data for modules in one place, and use that data for any module that has reached its entry point jump. The UPX is a special case because it always imports packed file dependencies through the import table. This is, of course, a static way of importing libraries but our approach must be flexible enough to cover both dynamic and static importing.

To achieve our goal we have to scan the main module and all loaded libraries and try to find  the appropriate patterns. Once the patterns are found, we set breakpoints and store info about them so we know which module triggered which callback event. Normally we have three callbacks for UPX unpackers (LoadLibrary, GetProcAddress and EP jump) but since we are doing transverse unpacking we need one more: the load library event custom handler, which determines whether the loaded dependencies are packed with UPX by trying to find the neccessary breakpoint patterns. Even though it is impossible to have more than one module loading at a time, we still need to store the import data because the import tables for the main executable and dependencies might overlap if the modules are loaded dynamically. Once stored, the import info for each module is retrieved when it hits its entry point callback. Relocations aren't really a problem since there is just one module loading at a time, so we can use our "snapshot and compare" model, provided that modules load on non-default image bases. This can be done in numerous ways - one of the easiest is to compile the sample files so that they do that by default (which is considered cheating in the unpacking game), alternatively, we can pre-allocate the memory so that the modules have no choice but to pick another base address. For the purpose of this blog we cheated, in a real world application of this approach you mustn't.

In the real world you will hardly ever see this kind of case but if you do, you now know how to get everything in one go. Until next week...

TitanEngine ReversingLabs Corporation

RL!deUPX (package contains the unpacker with source and the samples used)

With the increase in packed and protected malicious payloads, collaboration and quick response among researchers has become critical. As new sample numbers are quickly approaching 40M samples per year, the solution to this problem has to come from reverse-engineers themselves, integrating their prior and current work. Huge databases of format identification data and unpacking scripts can be reused to maximize automation. Yet, where do we find a definite collection of functional tools, identification signatures and unpacking tools? And how do we integrate them in a meaningful and accurate way?

Come to this talk to hear how we plan to raise reversing collaboration to a whole new level with TitanMist. We will address today's and future challenges, source code, packaging and distribution, and define your role in making TitanMist the most powerful community tool for years to come.

This talk will be a BlackHat exclusive; a launch and demonstration of TitanMist, a new open-source project based on TitanEngine. All components will be available for distribution with the conference materials.

See you in Vegas...

We can, with a little help from TitanEngine's hooking library. The idea is to use our unpacker as a library which will be injected into the packed file during its execution. Such a library would place hooks inside the packer code, redirecting the control flow to our unpacker wherever data collection or execution handling is needed. Those places are usually spots where the packer processes the import table or relocations, jumps to the original entry point, or just switches execution from one layer to another.

What are the benefits of such an approach? Even though its slightly harder to create and test such unpackers, the most notable benefit of unpacking by hooking is total immunity to various anti-debugging tricks used to detect the unpacking process. The only detection applicable to this unpacking scenario is anti-hooking and memory checksumming. The first is hardly ever used in modern protections due to the large number of false positives it gives, which are triggered by the operating system itself, security software and various window skinning applications. The second one is rarely present, and when it is it only covers specific memory regions that correspond to a single protection layer. In conclusion this method of implementing the unpacking process should result in fewer things to worry about.

Implementing this kind of hooking requires building custom functions to process the hook events. This is necessary to maintain the packed program work flow, and is exactly why we preserve the register state with PUSHAD, and if there is a jump affected by our hook, even EFLAGS with PUSHFD. These ASM instructions are embedded in our C code and with the help of naked pre-processor instruction they become the prologue and epilogue of the function. To apply the hooks we use the DLL_PROCESS_ATTACH event. For example if we were to hook the UPX code which loads libraries the hook code flow would look like this:

Since our hooks are 5 bytes we need to "borrow" as many instructions as we need to insert the hook. In this case we are "borrowing" three instructions. These instructions will be executed right after our inserted function is called. This is done to preserve the packer work flow. As you can see from this diagram we are using hooks instead of breakpoints. Therefore these hooks will be placed on at least three places: when UPX calls LoadLibraryA, GetProcAddress and finally once it jumps to the entry point. The most basic sample UPX unpacker is limited to working on executables that don't import functions by ordinals and use the old jump to entry point method. It's quite limited, but it's enough for a proof-of-concept of our technique.

Debugging this kind of unpacker can be rather tricky. This video shows a quick and easy way to do it:

Since we are creating a hook library unpacker, we also need a loader which will execute the unpacking target and inject the unpacker library in it. This can be done in number of ways but we decided to do it via the debug - detach method. Once both the unpacker hook library and the loader are made, our unpacker is complete. We hope you got the idea on how to use this technique to build your own hooking unpackers from our short blog. Until next week...

TitanEngine ReversingLabs Corporation

upxHooks (package contains the unpacker with source and the samples used)

We have already talked about fixing the damaged, broken or missing files in several occasions. Based on what we know we created the Nexus TitanEngine plugin to deal with cases of missing dependencies and damaged files. Implementing the basic TitanEngine features to correct file abnormalities does however change the file checksum since modifications  needed to correct detected problems modify file and memory content. And that doesn't go well with software protections that check the file integrity during execution. One of those software protectors is tELock, and that is the starting point for today's blog. That and a question "How can we work around checksums when file repairing is necessary?".

Luckily for us most software protections only check the file integrity on disk while the memory integrity checks are only limited to protected data and the protection itself. Therefore we only need to worry about the integrity of the file on disk. To be able to fool any software protection integrity check in a generic way we need to know how these checks are performed. Usually is as simple as opening a file, reading its content in a buffer, hashing it with a custom hashing algorithm and checking if the hash is different then the one stored during file protection. So the logical place to catch the integrity checks is by hooking functions used open the file. Most commonly that involves hooking CreateFile API since all protections use it to gain access to protected file.

Hooking an API in a remote process is easy but not very practical since it involves injecting a DLL into the unpacking process and that isn't something we want to do. Other option is to set a breakpoint at the selected API and filter the information returned to the protection. In order to fool the checksum checks we do the following:

• Detect if the file is broken (Nexus already did this)
• Correct the damaged file and produce a backup file (Nexus already did this)
• Catch all calls to CreateFileW API to determine when the integrity check is performed
• Open a handle to backup file (which is valid for execution since its checksum is unaltered)
• Pass the open handle back to protector so that backup file is hashed and its checksum is confirmed

Since we only place a breakpoint on CreateFileW API we need to filter the information somehow to make the program open the backup file which is unaltered and therefore has the correct checksum. We can alter the parameter string and possibly corrupt the memory or we can pass the correct handle back to the protection. To do that we open a handle to backup file inside the context of the debugger and duplicate it inside the context of the unpacking process. That new handle is then used by the software protection to read the data from the backup file which successfully fools any integrity check regardless of the checksum algorithm used. We do this handle switch only if the file which the protected file is trying to open is the file we are currently unpacking. Since this method is generic we can use it for any software protection, not just tELock.

To test out theory we intentionally damage the sample file by modifying a single non relevant byte. This damaged file is now named damaged.exe and the backup file which is the original one is named damaged.exe.bak. If we try to unpack damaged.exe file the unpacker will unpack the file correctly regardless of the damage done to the file. This process effectively simulates the scenario in which the Nexus plugin automatically corrects the damaged file. Until next week...

TitanEngine ReversingLabs Corporation

NexusCheckSum (package contains the plugin with source and the samples used)

There are a lot of optimizations one can do with the TitanEngine to make it work even faster then lightning. During the related unpacker execution timing research for our upcoming CARO Workshop talk we measured the impact that certain operations inside the engine itself have on the total unpacking time. We realized that there is significant space for performance improvement in certain unpacking areas which is especially important when we are processing large file volumes. Now, when unpacking files with unpackers built around the TitanEngine you get unpacker execution times quite similar to the sample execution time, except for cases where dynamic link library unpacking requires snapshots to correct the relocation table. in those cases we see a significant unpacking execution time increase. To counter this we can either do memory snapshots to memory or optimize relocation processing and avoid using snapshots at all.

Generally when talking about fixing relocation table we refer to the easy snap-and-compare method. However there is another way of making the unpacked dynamic link library valid for loading on non default base. We can use RelocaterGrabRelocationTableEx function for cases when the packer uses non modified relocation table, defined as it is in the PECOFF document. Relocation data is still compressed and can only be accessed just before the file is relocated, which is why we need a function to inspect the memory and determine the relocation table size. And that is exactly what RelocaterGrabRelocationTableEx does. It determines the size of the relocation table at the provided address and copies it to the engine for later exporting. If we look at the following PackMan code snippet which does the image relocation:

  OR ECX,ECX
  JE L018
  MOV EDI,DWORD PTR DS:[EBX+24]
  JMP L013
L004:
  XOR EAX,EAX
  LODS WORD PTR DS:[ESI]
  OR EAX,EAX
  JE L011
  AND AH,0F
  ADD EAX,DWORD PTR DS:[EBX]
  ADD DWORD PTR DS:[EDX+EAX],ECX
L011:
  CMP ESI,EDI
  JNZ L004
L013:
  MOV EDX,DWORD PTR DS:[EDI]
  LEA ESI,DWORD PTR DS:[EDI+8]
  ADD EDI,DWORD PTR DS:[EDI+4]
  TEST EDX,EDX
  JNZ L011
L018:
  POPAD
 

We can see that the relocation table is stored at EBX+0x24 address. Therefore by reading that memory pointer before the actual relocation occurs we have all the parameters we need to fix the relocation table. Passing that parameter to the RelocaterGrabRelocationTableEx will result in the engine reading the relocation table and estimating its size. Therefore we can just use the pointer we read at the EBX+0x24 address and the return from RelocaterEstimatedSize to correct the PE header for the unpacked file. However RelocaterEstimatedSize doesn't return the accurate size due to the system design. It must be reduced by 8 to be correct for all cases.

Since we are only updating the PE header data we can free the relocation table stored inside the engine with RelocaterCleanup. Once we dump the process relocation table fixing is as easy as updating the PE header fields. By doing the relocation table fixing this way we optimize the speed of execution by a significant percent. No actual data needs to be written to the file on the disk since it is already there and in the correct format. Furthermore you can start the debugging without the previously necessary DLL loading on the address other then default. If you choose to use that optimization as well packer execution time will be shorter since the file might not be relocated at all thus saving CPU cycles. Until next week...

TitanEngine ReversingLabs Corporation

RL!dePackMan (package contains the unpacker with source and the samples used)

After few months of intense work and code polishing we are proud to present the next major update for the TitanEngine project. Latest update we labeled as TitanEngine 2.0.3. Even though the version incrementation is small the number of changes and the pure size of the code is vast. That is why we dedicate today's blog for listing all additions and changes done to the engine. So, what is new?

This update can be declared as a script update as we were driven by the idea that the TitanEngine should be as easy to use as and as widespread as possible. That is why we have extended the programming language support to LUA and Python, two very popular script languages. Traditionally these script languages execute in a console window with little to no graphical user interface which is why for this update we have integrated easy to use unpacker interface. This interface can be customized to fit your unpacker project and still enables you to use the TitanEngine with any supported script language without the need to make your unpacker a console project. But we didn't stop there, we realized that with more than 400 functions TitanEngine can be overwhelming at first glance. That is why we tried to simplify writing the most basic dynamic unpackers, lowering the knowledge barrier to learning only 5 engine's functions.

In addition to this we introduced a way to set any breakpoint type, be it INT3 single or double byte or UD2 breakpoints. This option was present as a global setting in the engine making it possible to set only one breakpoint type at the time. Now you can set different breakpoints for any byte pattern you choose within the same existing breakpoint manipulation functions.

Release without bug fixes is unimaginable. In this release we fixed all bugs that we are aware of. Thank you for all your reports, you keep TitanEngine with as bugs free as possible.

*Note: If you downloaded the old TitanEngine 2.0.2 instead of the new one please re-download the package as there was a small mix-up with the files while moving hosting servers. We apologize for the inconvenience.

TitanEngine 2.0.3 in numbers

• 405 functions
• 28,000+ lines of code
• 44 usage samples
• 6 supported programming languages
• 390 pages of documentation
• 1 download waiting to happen...

Format we have selected is a simple a Debian archive file format called Deb. Debian packages (DEB files) are standard Unix ar archives that include two gzipped, bzipped or lzmaed tar archives: one that holds the control information and another that contains the data. These two files present in the archive are not compressed but instead they are just stored inside the binary package. Each stored item has its own header, which is defined like this:

typedef struct DEB_HEADER{
    char FileName[16];
    char FileTime[12];
    char Reserved0[6];
    char Reserved1[6];
    char Mode[8];
    char ItemSize[10];
    char TerminateQuote;
    char TerminateNewLine;
}DEB_HEADER, *PDEB_HEADER;

Preceding the first header which is used to describe the archive is the magic string "!<arch>\n" which is used to identify the binary package type. Therefore unpacking the DEB archive format is essentially reading the archive header and copying the binary content that follows it to the selected folder. Header for each binary content contains the file name and time information which can be used during the unpacking process to restore the packed item to its pre-packing state. Because this file format doesn't employ any compression by itself unpacking the DEB format only refers to extraction of the stored binary content. That content is additionally packed but with a different file format which commonly uses compression to reduce the size of the packed file on disk.

This is just one of the many uses for TitanEngine outside the area of unpacking and processing portable executable file format. As we have seen unpacking archives with TitanEngine is quite possible as long as there is no compression or content decompression is supported by the engine. Keep an eye out for our blog next week when we unveil our super secret project. Until then...

TitanEngine ReversingLabs Corporation

DEB unpacker (package contains source code, binary unpacker and a sample archive)

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)