02 Dec 2016

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!

23 thoughts on “Deobfuscating AutoIt scripts

  1. kao Hello! I tried to download the myAutToExe modified by you, but from the link you'd posted in the article I just downloaded zip-archive without the exe-file inside. Could you, please, re-upload it somewhere else?
    Best regards.

    • That's normal and expected - Bitbucket repository contains only source code. If you want EXE file, you'll have to compile it yourself.. :)

  2. I wish I were a skilled programmer...It took me a whole day searching for some free VBA compiler but as the result nothing except a lot of errors. Could you,please, share the compiled executable?

    • I'm on a vacation right now. ;) I could post a compiled EXE after I get back.

      However, I can assure that it's very easy to find a copy of Microsoft Visual Basic 6 on the net. "Portable" is one keyword that comes to mind..

      • Another good keyword could be "kitfrends". The usual warning about files downloaded from 3rd party sources applies..

  3. Can't compile your mod, original MyAutToExe compiles fine, but while loading modified version portable vb6 (11 mb in size) failes to load some forms, eaven FrmAbout :) Useless error logs have no info at all. I've never used vb before, so it's hard for me to determine the reason, please help.

    • Thanks for letting me know! :)

      The issue is caused by git messing up CR/LF symbols in FRX files. Please fetch the latest source and try compiling again. I just checked in my VMWare and it compiled just fine. If it still fails for you, please email me with you git config and the exact steps you took to obtain my modified files.

      • Thanks for quick fix, all is working good now! No git config, just downloaded sources via browser :D

  4. pawel97
    Could you, please, share, the compilled MyAutToExe.exe?
    Sorry, but I didn't manage to compile ot from source code by myself...(((

  5. I may be late to the party here, but I can't get past the first step of getting your version of MyAutToExe to even give me a token file. I turned on verbose output, so I believe it tries to detect which version of AutoIt ObfuscatedFile.exe is using, fails all of those, doesn't extract a token file, then tries to deobfuscate on a 0 length file, and quits.

    • Does the original MyAutToExe work? Are you trying to unpack that crackme I mentioned or some other exe?

      There are plenty of things that could go wrong and MyAutToExe doesn't handle (user) errors very well. If you still can't make it work, could you please send me as much information as you can, so that I can reproduce the issue and try to fix it?

      • Yes, I'm trying the AutoIt crackme from Tuts4You thread. I tried both your modified MyAutToExe, and the one from SmilingWolf's "solution" zip, and both have the same problem. I thought it may be my VB6 package, but I tried a few different ones, and got the same problem.

        I did get a bit further using another pre-compiled (and probably modified) myAutToExe 2.09. When I run ObfuscatedFile.exe through it, it actually recognizes it as a Modified Script Type 3.2.5+, but when I click Yes for AutoIt Script, it starts looking at the pData, seems to find the beginning of it, tries, "Decrypting script data...", then just gives me an, "Out of memory" error, stops, and spits out the log.

        Let me know if there's more I can give you to help reproduce the issue. I'm perfectly happy using these tools (if they worked ...) but I'd also be interested in learning how to extract the obfuscated script blob from memory using a debugger like x64dbg or something, if that's easier (then I wouldn't have to rely on these tools, or, perhaps, write my own tool instead of relying on a modified version of an ancient VB6 tool =).

      • Another thing I should mention is that I'm running myAutToExe from within VB6. I haven't been able to create a standalone myAutToExe.exe without VB6 crashing.

        • Well, learning how to build proper EXE file would certainly help. MyAutToExe relies on external DLLs, so quite likely it will not work from within VB6.

          One thing I didn't mention is that crackme is packed with UPX. You do know that you should unpack UPX first, right?

          If you wish to extract tokens from running process memory (myAutToExe calls it .tok file), try this:
          1) load file in Olly;
          2) unpack UPX;
          3) find the sequence of bytes "81 E2 FF FF 01 00 88 04 0A". There should be just one occurrence in main module. That's function "JB01_Decompress::DecompressLoop_EA05". Find the end of the function (around 0xA0 bytes further):

          Put breakpoint on that "xor eax, eax". When breakpoint hits, examine values [EDI] = pointer to buffer with tokens and [EDI+8] = size of that buffer. Dump it, detokenize it and then deobfuscate it.

  6. Tried the source from your bitbucket.
    But found malware/virus.
    Could you upload source code with no virus to your bitbucket?

    • There is no virus. Get an antivirus that actually works.

      Furthermore, there is no pre-built myAutToExe binary on my Bitbucket. You have to compile it from the source - so you can always be sure you have a clean version.

  7. Hi, what do you think about my obfuscator Kao?

    Here is a free code to play with it

    343E-162B-1484-663D

    link:

    {hidden link}

    I'm thinking about adding anti-regex obfuscations after I read your article, this looks like a weak spot of all autoit deobfuscators I've seen. Currently I'm upgrading the parser to handle object method calls (like COM/WMI etc.) and access to object properties (a few days).

    Hit me up with some good obfuscation ideas, I like to play with this toy project of mine.

    The biggest issue I have is the server side processing, while it's great to keep those nasty crackers away it prevents me from incorporating more computing intensive obfuscations like complex math transformations, especially those using floating point numbers (it's just too damn slow while processing complex AST structures).

    What do you think is the future of AutoIt obfuscation? Opcodes virtualization? Finite state machines?

    • You want an honest opinion?

      In 10+ years I've seen hundreds of malwares and gamehacks written in AutoIt. 95% of them were protected with some sort of obfuscator. But I haven't seen a single useful, legitimate, commercial software written in AutoIt that would require obfuscator to protect an actual intellectual property.

      So yeah, you might have a very cool toy project. It's fun and games to push the limits of what can be achieved in the niche largely overlooked by everyone else.

      But who does benefit most from your work?

      • I have plenty of legitimate customers, from system administrators to TV station developers (seriously!). I could argue C++ was used plenty times to create malware too, would you blame Visual Studio team for this? Of course not.

        • Oh, the good old "don't blame compiler/packer/protector for malware" argument. Classy move! :) There were some legitimate users of RLPack and MEW as well. Or EPL/FlyStudio. But the vast majority of protected software was malware, so the protection itself got blacklisted swiftly. Hell, some antiviruses even detect Confuser(Ex) by default.

          So, you're right, there might be some legitimate use cases for Autoit obfuscation, but I've just never seen one.

          As for your product - I googled for the first available AutoIt example code, namely a a snake game. It compiles and runs fine using standalone AutoIt 3.3.14.2 (no particular reason for that version, I just happened to have it installed). Your code, however stops with utterly unhelpful message

          An error occurred while applying obfuscation to the parsed code.

          Tried another example code, this time - calculator:

          An error occurred while parsing the input source code.

          That's equally unhelpful.

          So, if you want my suggestion - work on the user-friendliness of the interface. :)

  8. You can create malware in anything you want, so it's not a valid argument to blame one specific technology while you can find bad guys using almost everything. AutoIt forums has millions of posts and you would have to be ignorant to think most of it is about writing malware.

    Damn boy, you found a bug in my code!

    Remove the #cs comment section at the start in the calculator, I thought I got it covered. Will upgrade it for sure, thanks for the report :)

    I'm adding anti-regex patterns to the obfuscation strategies right now, looks promising.

    I'm thinking about adding small, internal VM engines.

    What do you think would be good to prevent deobfuscation?

Leave a Reply to shaw Cancel reply

  • Be nice to me and everyone else.
  • If you are reporting a problem in my tool, please upload the file which causes the problem.
    I can`t help you without seeing the file.
  • Links in comments are visible only to me. Other visitors cannot see them.

Your email address will not be published.

 ×  1  =  one