ReversingLabs | Blog

Security is notoriously disunited. Every year multiple tools and projects are released and never maintained. TitanMist is its inverse opposite. Built on top of TitanEngine, it provides automation and manages all known and good PEID signatures, unpacking scripts and other tools in one unified tool. TitanMist is the nicely packaged and open source catch all tool that will become your first line of defense. The project also goes beyond pure tool development. It builds a forum to share information and reverse engineering experience built around the biggest online and collaborative knowledge base about software packers.

With the increase in packed and protected malicious payloads, collaboration and quick response between researchers has become critical. As new sample numbers are quickly closing to 40M samples per year, solution to this problem has to come from reverse engineers themselves, integrating the work that they have done in the past and they continue to do. Huge databases of format identification data and unpacking scripts can be reused in a way 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?

TitanMist approaches these problems in a manner recognizable to every reverse engineer. It aims to mimic, but automate, the reversing process enabling everyone to easily create unpackers and integrate them in an extensible system. This builds a powerful and fast growing community analysis tool. Overcoming the most basic problems of reverse engineering problems was the top priority for the TitanMist project. Hoping to bridge the programming knowledge barrier which troubles many reverse engineers TitanMist introduces a variety of programming languages in which unpackers can be written in.

TitanMist goes beyond languages that compile to native code relying heavily on popular and easy to learn script languages. Backed up by LUA and Python this project makes coding unpackers a much simpler task. However the challenge of making TitanMist as easy to adopt and extend as possible meant that the project has to go further than extending support for more programming languages. Knowing that most of reverse engineers are familiar with debugger level script language OllyScript we added the support for it as well. Combined with the full TitanEngine functionality these scripts become powerful automated unpackers which combined with the layer of file format identification create a unique database of file analysis tools.

Download

• TitanMist / TitanMist Source
• BlackHat Vegas 2010 whitepaper
• BlackHat Vegas 2010 presentation

TitanMist ReversingLabs Corporation

TitanMist 1.0 released!

Looks cool? Want one? All you have to do is solve this challenge and tell us what is the password we seek. Sounds easy? Its not... Mail us with your solution at: blog(at)reversinglabs(dot)com; Challenge is now closed! Thanks to everyone who participated. Click read more for the solution...

Read More >>

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)