This is an example of Really Simple Reversing of a piece of malware. It’s written in the AutoIt scripting language and compiled to an EXE.
It’s not intentional, I’m sure about this, but this AutoIt tool offers some interesting features for (inexperienced) malware authors. You can compile your script to a stand-alone executable that is automatically packed with UPX. And even after unpacking it, the strings are still obfuscated.
Decompiling the script is really easy, because the AutoIt authors include a decompilation utility with the AutoIt installation package (Exe2Aut). You can find a video of the decompilation here hosted on YouTube, and you can find a hires version (XviD) here. The icon of the bin.exe file you see in the video is the default AutoIt icon.
See how easy it becomes understanding what this malware does once you have the source code:
- the URLs are defined in variables at the beginning
- you can see from where the malware downloads updates and where they get installed
- how it disables tools that can help you clean the infected machine, like Task Manager
- that it tries to spread via IM applications
- …
And did you notice the folder under F:\Documents and Settings at the beginning of the script? Oops!
When I submitted this malware to VirusTotal, only 4 AV engines detected it (July 18th 2007).
I played with the AutoIt compiler and decompiler and found some interesting things, I’ll probably blog about this later. Here is a hint: when you password-protect a compiled AutoIt script, you have to provide the password to decompile it, but not to execute it. Can you guess what this means? 😉 Post your answer in the comment section!
Didier Stevens 
[…] Really Simple Reversing […]
Pingback by Liquidmatrix Security Digest » Security Briefing: July 24th — Tuesday 24 July 2007 @ 13:05
I guess one could put in a huge random password that even they don’t know and fire away the compiled malware anywhere they can. Good luck bruting that. 🙂
Comment by LonerVamp — Tuesday 24 July 2007 @ 13:49
Obviously, the password to decrypt is obfuscated in the exe somewhere.
Comment by oldami — Tuesday 24 July 2007 @ 13:50
@LonerVamp
That is actually what they do when you select the option to disable decompilation!
Comment by Didier Stevens — Tuesday 24 July 2007 @ 14:39
@oldami
That is one valid explanation. But they are also doing something else. Take a look at the layout of the script (identation & whitespace). See anything peculiar?
Comment by Didier Stevens — Tuesday 24 July 2007 @ 14:41
Well, having looked at the snippet shown above, there is definitely something odd happening with the spacing of left brackets and the occasional comma; the first If block also didn’t indent – all others have done. But there is too little shown to see what this means (if anything). Can we have another clue please?
Comment by James_A — Tuesday 24 July 2007 @ 20:39
Very good observation.
When compilers compile source-code into machine language or intermediate language (like Java bytecode and .NET MSIL), they ignore whitespace. A decompiler will have to add whitespace according to certain rules (like indentation). Because we see anomalies in the whitespace of the decompiled program, it’s very likely that we’re not dealing with a real decompiler. I believe that the source-code is stored inside the “compiled” AutoIt script, and what we see is exactly how the malware author typed it in.
But why can you execute a password-protected script without providing the password, while having to provide the password to “decompile” it?
Comment by Didier Stevens — Tuesday 24 July 2007 @ 20:55
Is it because the script might be stored in an alternate data stream or something?
Comment by Stefan — Tuesday 24 July 2007 @ 21:10
No, it’s not in an ADS.
Comment by Didier Stevens — Tuesday 24 July 2007 @ 21:18
Ah, thank-you for a reply. I did actually wonder if I was looking at the original “as-typed” script, because it is too inconsistent for machine-made pretty printing. I don’t know much about AutoIt files but one possible answer is to have both a bytecode version and a (probably compressed) source version of the script present in the “.EXE” together with the standard runtime module. These three building blocks thus make up the whole file. The EXE header runs the bytecode, but the decompiler looks for the source module.
Comment by James_A — Tuesday 24 July 2007 @ 22:34
@James_A
Excellent! I too believe the compiled script file contains 2 versions: the compiled script and the source-code.
I haven’t looked at the file format in detail, but I saw an MD5 hash of the password somewhere at the beginning.
Comment by Didier Stevens — Wednesday 25 July 2007 @ 7:50
[…] Really Simple Reversing (RSR) – This is quite cool. This is an example of Really Simple Reversing of a piece of malware. It’s written in the AutoIt scripting language and compiled to an EXE. […]
Pingback by www.andrewhay.ca » Suggested Blog Reading - Tuesday/Wednesday July 24th/25th, 2007 — Wednesday 25 July 2007 @ 21:50
Excellent article. I had a few thoughts on this. Would the AutoIT guys really store two versions of the script in the EXE? I know this sounds the most efficient, but we all know programmers are people and they do not always follow the path of least resistance. Just storing the encrypted/compressed script and then running it on the fly would be the path I think some programmers would take.
It would be interesting to run this in a sandbox and see if the code shows up unencrypted in memory. The MD5 could just be a permissions check more than anything to see if the decompiler has the password and thereby also having the “permission” to view the code.
*I am not a programmer by trade so this may all seem like complete gibberish to you pro’s. 🙂
Keep up the great work!
Comment by Rick — Tuesday 31 July 2007 @ 19:34
I really need help decompiling an AutoIt file that is screwing with my computer, but I can’t figure out how to bypass the passphrase! I’ve hex-edited the .exe and cannot find anything in particular, and Google-searching brings up nothing I can really understand.
Thanks for the help!
Comment by Ice — Friday 10 August 2007 @ 14:55
Haven’t researched yet how to decompile without a password, but I discovered that a compiled AutoIt script contains the MD5 hash of the password starting position 24 (an MD5 hash is 16 bytes long). That’s for an .a3x file, if you have an .EXE file, you will have to unpack it with UPX and search the compiled script at the end of the file.
You could extract the MD5 hash from the file and try to find the password, with bruteforcing, dictionary attack or rainbow tables (there are some online rainbowtable crackers, but plaintext.info seems to be out of business).
Success.
Comment by Didier Stevens — Friday 10 August 2007 @ 15:30
FYI… any version after 3.2.5.1 will not decompile.
Comment by AutoIt Member — Wednesday 12 September 2007 @ 8:47
> any version after 3.2.5.1 will not decompile.
Because no official decompiler is available?
Comment by Didier Stevens — Friday 14 September 2007 @ 20:03
[…] Filed under: Malware, Reverse Engineering — Didier Stevens @ 10:17 Since I’ve blogged about malware written with the AutoIt scripting language, I got a couple of mails asking for […]
Pingback by AutoIt Malware Revisited « Didier Stevens — Tuesday 2 October 2007 @ 10:17
It is still possiable to decompile autoIT scripts past version 3.2.5.1 It is done constantly in the autoit forums. However it is kept a secret and is frowned upon. A ban is in place for those who pursue the secret =\
From what I have heard, it isn’t all that hard.
ender998@hotmail.com
Comment by Brian Pepin — Tuesday 6 November 2007 @ 13:26
AutoIt is a interpretated language (script) so it mean that the password is stored somewhere in the interpreter slice of file. I think
ruined
Comment by ruined — Wednesday 14 November 2007 @ 13:51
Take a look at the update:
Comment by Didier Stevens — Sunday 18 November 2007 @ 20:21