Re: Autoit Decompiler 3.3 Download
Jason Ramgel
If the version of AutoIt is v3.2.5.1 or lower, then the decompiler is located at C:\Program Files\AutoIt3\Extras\Exe2Aut\Exe2Aut.exe by default. The directory may be different if you performed a custom installation. For all other newer versions, the decompiler has been removed.
You are mostly out of luck. Take the opportunity to learn how to properly back up your important files. The developers can decompile scripts but you must be prepared to prove you own the script. This is not done very often and the developers reserve the right to say no for any reason.
Yes. There is software in existence which can decompile all versions of AutoIt. Creation or use of such software may be a violation of the law depending on your local laws. DO NOT USE IT.
This includes decompiling scripts users have posted in binary-only form. Under no circumstances are scripts to be decompiled unless the author grants their explicit permission and the script can be decompiled with the official decompiler.
No. It is theoretically possible to modify compiled scripts in a way that it still works but a decompiler fails to extract the source. However, tools that are capable of doing this violate the reverse engineering clause of the AutoIt license (the very same clause the 3rd-party decompiler violates).
During the analysis of an AutoIT compiled malware sample, a message box popped up indicating the possible execution of the sample when using Exe2Aut decompiler. This triggered my interest in how this decompiler works and how AutoIt scripts are compiled in the first place. In this writeup, I will explain how the two most common AutoIT decompilers (Exe2Aut and myAut2Exe) work and how they can be tricked into decompiling a decoy script instead of the real script.
A compiled AutoIT executable basically consists of two parts: a standalone AutoIT interpreter and the compiled script bytecode present as a resource in the PE file. The creators of AutoIT have taken some measures against easy decompilation and applied a form of compression and encryption on the bytecode. The decompression of the bytecode is performed by the compiled AutoIT binary before it is interpreted and executed.
Unlike Exe2Aut, MyAut2Exe extracts the bytecode resource and unpacks and decodes it without the help of the embedded interpreter -- making it a full static decompiler because of this, there is no risk of accidentally executing anything.
MyAut2Exe is more advanced than Exe2Aut. It supports multiple versions of AutoIT and AutoHotkey compiled scripts. Therefore, it has more settings to adjust the extraction and unpacking of the compiled script code. To take the hassle out of correctly configuring it, it comes with a feature called "automate". This brute forces the decompiler settings until a script is successfully decompiled. When the "automate" functionality is used, MyAut2Exe parses the executable for AutoIT magic bytecode signatures. Once found, it extracts and decompiles the code. As the parsing and decompilation stops on the first occurrence of the magic bytecode sequence, MyAut2Exe can be easily tricked into decompiling a decoy script as long as it's placed at a lower offset than the real compiled script resource.
The decoy script for MyAut2Exe is placed before the real bytecode as explained earlier. For Exe2Aut, the script resource name for the decoy and real script is renamed at runtime to make it decompile the wrong code.
I have compiled three different AutoIt scripts and added those as resources to the .rsrc section. Two of them are decoy scripts, while the third is a real one. Afterward, I set the permissions of the .rsrc section to read / write in the portable executable (PE) header.
What we can learn from this POC is that we shouldn't always blindly trust the output of our tools. Reverse engineers should be aware of how their tools work and how they can possibly be tricked into returning a misleading output. While the tricks presented here might mislead two decompilers, they don't affect the results of a dynamic analysis in a sandbox.
A while ago I posted a short description on how to decompile 64-bit autoit scripts. Someone pinged me asking on how to actually do it, so I thought it will be handy to simply write a script to do the dirty work for us.
After unpacking the UPX (when needed) and filtering the AutoIt executables, I used myAut2Exe, an open-source AutoIt decompiler. One nice thing about myAut2Exe is that you can run it with command-line arguments from a script. I found a number of common AutoIt scripts used to pack or drop different malwares and a couple of full-blown malware written entirely in AutoIt.
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:
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.
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).
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:
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:
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.
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
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
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:
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.
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:
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.
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.
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.
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.
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.
7fc3f7cf58