06 Feb

Updated Molebox unpacker

During last year, the most common complaint on this blog was “your Molebox unpacker cannot unpack this crazy big EXE of MMORPG game X, Y or Z.”

Sounds like an easy problem to fix, right? Well, that’s not true – but I finally did it!

TL;DR – new version of unpacker is here: https://www.mediafire.com/?t3xw46s554it5fp

In the rest of the post I’ll describe the obstacles I had to overcome while solving this seemingly simple problem.

Delphi TMemoryStream limitation

First, unpacker is written using classic (non-.NET) Delphi and compiled as x86 executable. And standard Delphi streams are retarded. TMemoryStream uses GetMem – which ends up somewhere in Delphi memory manager and VirtualAlloc. That doesn’t work well with 800+MB files.

I ended up with implementing custom stream backed by temporary file (CreateFile with FILE_ATTRIBUTE_TEMPORARY | FILE_FLAG_DELETE_ON_CLOSE).

Pointer magic

Since the original unpacker was using TMemoryStream, the whole file was loaded in memory as a continuous memory block and I could easily read/write each byte of file using pointers. Something like this:

Guess what? Files don’t work that way.. sad I had to do a full and complete rewrite of all those methods.

Zlib conflicts

Original unpacker was compiled with Delphi 3. Delphi 3 didn’t have Zlib library, so you had to supply your own Zlib implementation. But it won’t compile with new versions of Delphi, giving error message

Unit Graphutil was compiled with a different version of zlib.TZDecompressionStream.

The solution was to get rid of my Zlib implementation and rewrite all methods that deal with decompression.

ANSI strings

In Delphi 3 all strings were ANSI. Starting from Delphi 2007, strings are Unicode. Since Molebox internally uses ANSI, it required changing quite a few structure definitions and rewriting several string manipulation routines. It’s a lot of fun (and source of the most obscure bugs), trust me!

Conclusion

I hope you find this unpacker useful. But if it doesn’t work for you, please send me an error report with all the details you can and I’ll try to fix it. Have fun!

Download link: https://www.mediafire.com/?t3xw46s554it5fp

02 Dec

Deobfuscating AutoIt scripts

Every once in a while, someone posts an interesting challenge concerning protected or obfuscated AutoIt scripts. Today I’d like to show some basic approaches to AutoIt deobfuscation. As a target I’ll use a very simple protection called AutoGuardIt and the crackme from Tuts4You thread. If you don’t have access to Tuts4You, here is the alternative download link: https://www.mediafire.com/?qs52emp7tkk472g

In general, there is nothing hard in decompiling AutoIt scripts. The Autoit script interpreter is designed in such a way that it’s really easy to convert P-Code back to the script form. There’s also a tidy.exe utility which takes ugly hand-written script and reformats it to make it really pretty. All of this makes writing deobfuscators much easier because you can start with well-formatted AutoIt script and your deobfuscator can consist of simple regexps and string replaces. It will not be very pretty code but it will work.

While I was preparing this blog post, SmilingWolf came up with a full-featured solution written in Python. It’s a nice solution but it doesn’t explain how or why it works. So, in this article I will explain how the protection works, show the basic techniques and sample source code to defeat each of the protection steps. Making a full-featured deobfuscator is left as an exercise for the reader.

Required tools

  • C# compiler. All my examples were tested under Visual Studio 2010 but any recent version should do
  • MyAutToExe. I’m using my personal modification of myAutToExe. You can download it from Bitbucket: https://bitbucket.org/kao/myauttoexe
  • Tool for testing regexps. I’m using http://regexr.com/
  • Some brains. You can’t become a reverser if you can’t think for yourself.

Decompiling the script

There are 2 public tools for extracting compiled AutoIt script: MyAutToExe and Exe2Aut.

Exe2Aut uses dynamic approach for obtaining script – it runs the file and gets decrypted and decompressed script from process memory. That’s usually the easiest way but you really don’t want to run the malware on your computer.

MyAutToExe uses static approach – it analyzes file and tries to locate, decrypt and decompress the script on its own. That’s more safe approach but it’s easier to defeat using different packers, modified script markers and so on. To extract script from this crackme, I used my own MyAutToExe (see “Required tools” section above).

Analyzing the obfuscation

Once the script is extracted and decompiled, it looks quite strange and unreadable:

Let’s look at each of the obfuscation techniques and see how it works and how it can be defeated.

Integer decomposition

AutoGuardIt takes constants and converts them to series of math operations. Example:

Deobfuscator should be able to take the expression, evaluate it and replace the expression with the correct value.

The biggest problem here is the precedence of operations (multiply and divide should be processed before addition and subtraction), so you can’t start from the beginning of line and do it one step at a time. This would be wrong:

After some thinking and few Google searches, I found a LoreSoft.MathExpressions library that does all the heavy lifting for me. smile

The following C# code snippet will find all math expressions, extract them, evaluate them and replace expression with the actual value:

Pseudo-random integers

This is quite strange protection that relies on a fact that AutoIt’s Random function is actually pseudo-random number generator. If you seed it with the same seed, you get the same results. Example:

In general, it’s a very bad idea because there’s no guarantee that random number generator will not change in the next version of AutoIt. But for now it works..

Since I was already using myAutToExe, I decided to use RanRot_MT.dll from the package.

a = StringLen(“xyz”)

Small integers can be obfuscated by using function StringLen:

To clean them up, a simple regex can be used:

End result:

Chr(x)

Some strings in the executable are split into bytes, and each byte is then encoded as call to Chr function:

Another simple regex will kill all of those:

The result will be valid but still hardly readable string:

And one more simple search-replace will fix that:

End result:

If 1 Then

Once you remove the integer obfuscations, you’ll see a lot of useless statements like this:

This condition is always true, so we can remove both If and EndIf lines and improve readability.

The problem here is that If‘s can be nested and you can’t just remove first EndIf that you encounter. Consider this example:

Taking all that into account, I came up with this ugly but working* code:

* – see below for some scenarios where this code might fail.

If a = a Then

Variation of previous protection. In such cases, using regexp is much more efficient than simple string comparison

Do Until 1

It’s pretty much the same protection as If 1 Then and it can be defeated the exact same way.

While 1 / ExitLoop / WEnd

Another protection of the same kind, just uses 3 lines of code instead of 2. Same approach, just make sure you match the correct lines and remove all 3 of them.

For $random=0 to 123.456 / ExitLoop / Next

Another protection, very similar to previous ones.

Here one must be very careful not to remove the real for cycles from program, so it’s better to use regexps. Apart from that, it’s pretty much the same code again.

Assign/Execute

This type of protection relies on AutoIt’s Assign function. First, an alias to a function is defined:

Later, alias is used to call the function:

Deobfuscation is a simple operation: find all calls to Assign, extract the variable name and the function name, then replace all references to the variable with the function name:

BinaryToString

As you can see in the example above, some strings in the script are replaced with calls to BinaryToString. Here’s a another example of the same protection where part of code is replaced with BinaryToString + call to Execute.

Merging all 3 lines into one and converting hex strings to bytes gives us the following code:

which using the methods described earlier can be deobfuscated as:

Functions returning constants

Some strings are not only encoded using BinaryToString but also moved to a separate function.

Deobfuscated code will look like this:

It’s quite tricky to find the correct return value for each function and replace function calls with correct values. In addition to that, regexes aren’t really suitable for such tasks. smile The code I wrote is really ugly, so I’m not going to show it. Go, figure it out yourself! smile

Switch control-flow obfuscation

This is actually the hardest one of them all. The example code looks like this:

You must find the initial value of the variable. Then you must find the correct start/end of the Switch, all the switch cases and all other assignments to the control variable. Then you’ll be able to reorder all the code. It’s a moderately hard problem for which I don’t have a pretty solution. smile

Here’s my code which seems to work:

After cleanup, the deobfuscated code looks like this:

Unused variable assignments

There are random variable assignments sprinkled all over the code.

They are only assigned once and never used. To clean them up, one can locate the assignments using regex, count how many times this variable appears in the code and remove it, if it’s only assigned once. Something like this:

You can remove string and integer assignments using very similar regex.

Lather, rinse, repeat

If you run each of the mentioned deobfuscations only once, you’ll end up with half-deobfuscated code. Also, there isn’t one specific order in which the deobfuscations should be applied. Of course, you could just run the entire loop 100 times, but it’s just ugly.

Therefore, I prefer to run the code in the loop like this:

It will run all the deobfuscations until there’s nothing left to clean up. Then run tidy.exe on the output and you’ll get a nicely readable script.. smile

Possible problems and gotchas

Deobfuscators based on string matching are very easy to implement. However, one must be very careful to write correct regular expressions and string comparisons. My example code works very well on this specific crackme. However, it will mess up with code like this:

You can work around such issues by using more specific regexes with anchors. During my research, I used http://regexr.com/ a lot, and I find it really helpful. Give it a try!

Conclusion

In this article I showed basic approaches that can be used to deobfuscate (not only) AutoIt scripts. They are extremely simple and work well for one-time tasks. For more complex tasks, deobfuscators based on abstract syntax trees or disassembled P-Code are much more efficient but more time-consuming to create.

Have fun!

27 Sep

Why I’m not using x64dbg

x64dbg is (probably) the most user-friendly x64 debugger right now. It’s pretty, it’s open-source and it usually works. But I find it very hard to switch from WinDbg to x64dbg for several reasons. Some of them are purely emotional (don’t worry, I’m not going to bore you to death explaining those) but most of them are technical and related to the way x64dbg is being developed.

So, here goes slightly exaggerated but still serious list of my grievances. smile

Insane system requirements

Both DNSpy and x64dbg suffer from this disease. They love to use the “latest and greatest” of technologies, meaning Visual Studio 2017, .NET 4.6 and what not. That’s perfectly fine when you’re writing normal software. But debugger is not a normal software.

If I have a customer with a software crashing on his production servers, I can’t tell him “You need to install Windows 7 SP2 and 3 different VS redistributables and reboot your machine twice just for me to run my debugger”. No, I really can’t.

Debugger must run on any and all systems out-of-the box. Olly does that. WinDbg does that. And it wouldn’t be hard to link x64bdg with static VS runtime libs and target WinXP while using all the modern goodies. But for some reason it’s not done that way.

Updated 30-Sep-2016: Mr. eXoDia let me know that now x64dbg is distributed together with the necessary runtime DLLs. We can remove this grievance off of my list. Hooray! smile

Uncertain direction and feature bloat

Antoine de Saint Exupery said:

Perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away

These are really wise words and Olly is designed that way. It does all the basic stuff and has stable SDK that enables plugin authors to implement all the extras.

On the contrary, Mr. eXoDia is adding features left and right and the direction of x64dbg development looks more like this:
BrownianMovement

For example, why does a debugger need 3 (yes, three!) different assembler engines?
assemble

Want another example? Let’s just look at the latest weekly digest.. How about this:

… change to the info box. Basically the pointer values in the instruction were not resolved (so if the instruction contained qword ptr ds:[rsp+30] it would not show the value of rsp+30). Personally this is quite useless

Yes, Mr. eXoDia, you’re right. It is useless for everyone but few people.

And how about:

The commands plugload and plugunload have been added. This is useful for plugin developers who want to test plugins without having to restart x64dbg all the time.

How many people in the entire world will actually benefit from that? 5? 10?

So, why add such bloat? Once you add something, that something must be maintained. And it’s very hard to remove stuff later, as it might break something else. So, please don’t..

Broken features

When I am on a job and need to debug something, last thing I want to spend my time on, is fighting with debugger bugs. And my customers certainly don’t want to pay me for doing that.

Oleh Yuschuk got it exactly right with the OllyDbg. There were few releases – but they were properly tested and rock solid. From what I can see, x64dbg is going the other way:
compiles_ship_it

Frequent commits like “Fixed search for constant references”, “Fixed intermodular calls in module”, “Fixed FS/GS memory branch destinations” is not something you want to see in any software, let alone a debugger.

Well, it wouldn’t matter much, if there was some known-stable version I could put in my tool collection and use it anytime anywhere. But no, Mr. eXoDia thinks that “No more excuses to not update every day!” is a way to go. Instead of using tried-and-tested version, I should use a probably buggy and unstable one? Dafuq?

Conclusion

So, those are my 3 biggest complaints about x64dbg. I’d love to love x64dbg. I’d love to use x64dbg for everything. But right now I just can’t.

How about you?

21 Sep

IDA bug in PE export processing

Hi, I’m back from vacation. And now I’m catching up on all the things that have happened during that time. So, here’s a short writeup regarding publicly-known IDA bug and how it will (not) affect reversers.

It was supposed to be a long post showing how to use PatchDiff to locate patched code and then backport it. But, as you’ll see later, that’s not necessary at all. Maybe another time..

Initial research by Palo Alto

When checking my RSS feed, I stumbled upon the article by Palo Alto researchers called “The Dukes R&D Finds a New Anti-Analysis Technique“. It stated:

Using the exported functions by ordinal meant the exported function name was unnecessary, which allowed the developer of this DLL to leave the names for the exported functions blank … The less obvious reason is that it takes advantage of a bug in the popular IDA disassembler that was recently fixed in the latest version of IDA.

Bug in IDA?! How nice, I want to test this!

Testing the bug

Palo Alto report contained most of the information to reproduce the issue. But IDA 6.95 changelog was even more detailed about what was fixed:

BUGFIX: PE: IDA would not detect DLL exports with empty names
BUGFIX: PE: IDA would show no exports if the export directory’s DLL name was an empty string

Armed with the detailed description, I used MASM32 package and their Examples to build a DLL file.

Empty DLL name

First, I took hex editor and changed DLL name in export directory.
export_dll_name_1
export_dll_name_2
Now the exported DLL name is 0-length string. Let’s see what IDA does..

I started with IDA 6.95 Demo you can download from official site. No surprises here, the bug is fixed:
export_dll_name_IDA695

Then I took legit copy of IDA 6.90. As already demonstrated by Palo Alto, it’s buggy:
export_dll_name_IDA690

Naturally, I wanted to see how old this bug is. So, I took a copy of IDA 6.80. Surprise, surprise, it’s not buggy!
export_dll_name_IDA680
So, it looks like this bug was introduced in IDA 6.90.

Empty export name

For completeness sake, I repeated the experiment with empty exported API name.
export_api_name_1
export_api_name_2
The results were identical, the bug is only present in IDA 6.90.

How it affects you?

If you’re using IDA Free, latest version is 6.95. You’re good.
If you’re using legit IDA, you have received the updated version 6.95. You’re good.
If you’re using the latest publicly leaked version of IDA (6.80), it didn’t have the bug. So, you’re good, too.

To sum it up – it’s a fun bit of information but no one is really affected. Good news, I guess. smile

Example DLL files if you want to verify your tools: https://www.mediafire.com/?c9t6hm4icd3kk46

28 Jun

Bugs in Enigma Virtual Box

While working on a new version of my static EnigmaVB unpacker, I tried to generate test files to cover most of the Enigma Virtual Box features. In the process, I ran into quite a few bugs in Enigma Virtual Box v7.40.

So, here’s a short list:

Registry virtualization

1. Importing REG file with wrapped lines:

Data get truncated at the end of first line.

2. Importing REG file with entry type REG_NONE:

It gets virtualized as a string value “hex(0):”

File virtualization

1. If size of any embedded file > 4GB: creates invalid x86 executable;
2. If total size of all embedded files > 4GB: creates invalid x86 executable;
3. If size of main EXE > 2 GB: creates executable that seems to be valid but won’t run;
..and that’s only for x86 executables. I wonder how many more issue will surface when I start testing x64 executables. wink

TLS callbacks

Since Enigma Virtual Box uses TLS callbacks to initialize its hooks and handlers, it will (accidentally?) break any executable that also uses TLS callbacks. However, it preserves TLS StartAddressOfRawData, EndAddressOfRawData and AddressofIndex fields. Very weird.. smile

Have fun (and remember to test your software properly)!

06 Jun

CFF bug in RVA2Offset

Yes, this is yet another post about bugs in CFF Explorer. So far I’ve described:

Today, I’ll describe an issue with CFF Explorer’s RVA2Offset function and provide a solution to the problem (patched executable).

And no, I really don’t hate CFF Explorer. In fact, it’s one of my favorite tools and I use it every day – that’s why I keep noticing more and more issues with it. wink

Introduction

Here is an executable that demonstrates the bug: https://www.mediafire.com/?9ju0cfm36b32ys9

If you open it in CFF Explorer and try to check Import Directory. In this case, CFF will show that it’s empty.

cff_bug_empty_imports

That’s incorrect, import directory of this executable is present and valid. It contains 2 DLLs and 3 APIs:

actual_imports

In other executables, it can get stuck into eternal loop or – even worse – show incorrect data.

Also, CFF’s Address Converter feature is affected. In my demo executable, try convert RVA 0x2000 to file offset. It will return 0:

CFF_address_converter_bug

So, what’s happening here?

Background of the bug

To put it simply, bug is triggered when one section in executable has SizeOfRawData much larger than VirtualSize. In my crafted executable it looks like this:

CFF_cause_of_bug

Nitpickers corner: it’s actually more complicated. The exact condition is ALIGN_UP(sec.SizeOfRawData, pe.FileAlignment) > ALIGN_UP(sec.VirtualSize, pe.SectionAlignment). But who cares about those small details, anyway?

And the offending pseudo-code in CFF Explorer looks something like this:

Fixing the bug

Since I’m doing binary patches to CFF Explorer, I’m quite limited to what I can do and how. In the end, I chose the following pseudocode:

While it doesn’t look like much (and it doesn’t cover edge cases, for example, when PE file is truncated), in general it should work just fine.

Download link for fixed CFF Explorer: https://www.mediafire.com/?5eg1bs9a9bv39ge
It also includes all my previous fixes.

Conclusion

While writing this post, I noticed that PE viewer in ExeinfoPE v0.0.4.1 has very similar bug. And ProtectionID v6.6.6. And PETools 1.5 Xmas edition. And Stud_PE 2.1. And LordPE. And then I ran out of tools to test. bigsmile

Obviously, I can’t fix them all. All I can say – use PE editing/viewing tools that actually work, for example, HIEW or IDA. And when you’re writing your own PE parser library, make sure you test it on weird executables.

Have fun and stay safe!

Further reading

31 May

BTVStack.exe requesting access to Skype on every startup

Background

At home I’m using a desktop computer. It has ASUS motherboard with Atheros Bluetooth chip. I have all the drivers installed but I’m not using Bluetooth at all.

Problem

Some time ago I started getting these notifications every single time I started Windows:
btvstack_skype

btvstack.exe is requesting access to Skype. Only allow access to programs downloaded from a trusted source as they will be able to use information such as your Skype contacts and messages.

No matter what option I selected, it would ask me again on next reboot. Bloody hell!

If you google for the solution, you’ll notice that:

  1. It’s a quite common problem;
  2. Most common solution is to deny/allow access either using the dialog above, or Tools->Options->Advanced->Advanced Settings->Manage other programs’ access to Skype;
  3. Another solution for Windows 8+ is to deselect “Allow Bluetooth devices to send you PIM items such as business cards, calendar items, e-mail messages, and notes. ” in Bluetooth Control Panel applet;

Unfortunately, first solution was not working for me. And second solution is not feasible because there is no such option in Windows 7 Control Panel.

Solution

Since I don’t need Bluetooth but I don’t like to have broken drivers, I decided to disable just the offending DLL. From the elevated command-prompt I ran

and the problem has disappeared. Great success! smile

Hope this helps someone else too.

03 May

CFF bugs in processing managed resources

Users on tuts4you quite often ask questions like “Can you identify which obfuscator was used”. When I was analyzing one such assembly, my CFF Explorer started to act erratically. New tabs would not open and on exit CFF Explorer crashed with access violation.
CFF acting up
That’s weird, I said to myself and decided to figure out what’s causing it.

Uninitialized buffers and unchecked return values

First bug is a classic. In pseudo-code it looks like this:

First issue is that nobody initialized ResourcesInfo structure, so all fields will initially contain random garbage. As soon as ReadResourceHeader fails to read or validate something, it returns, and lots of fields will still contain random garbage.

It wouldn’t be a big problem, if Daniel checked the return value of the function. But his code just continues processing even if the data initialization failed. And, to make matters worse, it just hides all exceptions by putting try-except handlers around most of the code. No wonder CFF is occasionally acting weird! smile

This bug is quite hard to demonstrate, as it needs to have few lucky coincidences in the uninitialized data. But I’m sure that a skilled person would convert it into arbitrary code execution in no time. Not me, though… smile

Buffer overflow

Second bug is also a classic. In pseudo-code it looks like this:

So, what’s wrong here? Daniel takes a fixed-size buffer and initializes it with all zeros (unlike previous case). Then he reads size of data (NameSize). And then he copies NameSize bytes into a fixed-size buffer – without checking if that’s gonna overflow or not.. Yikes!

Example file demonstrating this bug: https://www.mediafire.com/?x4idsa21toh0t36 (you need to click on Resource Editor -> .NET Resources to trigger the buggy code. Afterwards, CFF Explorer will start acting weird).

Solution

Just like in a previous case where I added support for ConfuserEx and undocumented fields, I had to make few binary patches to CFF Explorer.

Fixed exe file is here: Please get latest version from this post

Have fun and stay safe!

24 Mar

MoleBox goes out of business

Molebox as it used to be

A bit of history

MoleBox 2 was released in year 2003 and it was one of the first file virtualization solutions in the market. It bundled executable with the DLL and data files into a single EXE file. At that time that was something new and innovative.

They had quite a success and released another product (MoleBox Ultra, later renamed to MoleBox Virtualization Solution) in year 2009. Apparently it was very hard to fight in the increasingly more competitive market of application virtualization solutions and the last version of MoleBox Virtualization Solution was released in 2013.

Game over

In February 2016 domain molebox.com was sold for $1526. Yesterday their web server started serving generic WordPress page with dating-related spam. And that is just sad. sad
MoleBox dating advice

Release of static unpacker

However, both editions of MoleBox are still very popular with private game server owners, as they allow to bundle patched EXE files together with their custom data files. It’s not a bullet-proof security but stops newbies from stealing their valuable data.

Since the MoleBox company is officially out of business now, I have no more reasons to keep my static Molebox unpacker private. It supports most versions of MoleBox 2.x including the external box files.

Have fun guys! Download link: REMOVED, see https://lifeinhex.com/updated-molebox-unpacker/ for an updated version.

P.S. This post was made just because I noticed changes in MoleBox web, I wasn’t planning to release the unpacker today. So, please keep in mind this code was written in year 2009 and has had only one small fix applied in 2015. It’s likely that you’ll encounter some bugs and quirks – please send me the problematic file and I’ll fix the bug. smile

P.P.S. I have static unpacker for MoleBox Virtualization Solution as well. But it doesn’t have a nice UI yet, so it will be released on a later day.