Decompiling An Autoit Exe

• Decompile Autoit .exe Au3
• How To Decompile An Exe
• Autoit Exe To Au3

Apr 6, 2015 - Simply drag and drop the executable onto Exe2Aut's main window and the source script will be displayed. Unlike the decompiler that's being.

A friend of mine downloaded some malware from Facebook, and I'm curious to see what it does without infecting myself. I know that you can't really decompile an .exe, but can I at least view it in Assembly or attach a debugger?

Edit to say it is not a .NET executable, no CLI header.

15 Answers

With a debugger you can step through the program assembly interactively.
With a disassembler, you can view the program assembly in more detail.
With a decompiler, you can turn a program back into partial source code, assuming you know what it was written in (which you can find out with free tools such as PEiD - if the program is packed, you'll have to unpack it first OR Detect-it-Easy if you can't find PEiD anywhere. DIE has a strong developer community on github currently).

Debuggers:

• OllyDbg, free, a fine 32-bit debugger, for which you can find numerous user-made plugins and scripts to make it all the more useful.
• WinDbg, free, a quite capable debugger by Microsoft. WinDbg is especially useful for looking at the Windows internals, since it knows more about the data structures than other debuggers.
• SoftICE, SICE to friends. Commercial and development stopped in 2006. SoftICE is kind of a hardcore tool that runs beneath the operating system (and halts the whole system when invoked). SoftICE is still used by many professionals, although might be hard to obtain and might not work on some hardware (or software - namely, it will not work on Vista or NVIDIA gfx cards).

Disassemblers:

• IDA Pro(commercial) - top of the line disassembler/debugger. Used by most professionals, like malware analysts etc. Costs quite a few bucks though (there exists free version, but it is quite quite limited)
• W32Dasm(free) - a bit dated but gets the job done. I believe W32Dasm is abandonware these days, and there are numerous user-created hacks to add some very useful functionality. You'll have to look around to find the best version.

Decompilers:

• Visual Basic: VB Decompiler, commercial, produces somewhat identifiable bytecode.
• Delphi: DeDe, free, produces good quality source code.
• C: HexRays, commercial, a plugin for IDA Pro by the same company. Produces great results but costs a big buck, and won't be sold to just anyone (or so I hear).
• .NET(C#): dotPeek, free, decompiles .NET 1.0-4.5 assemblies to C#. Support for .dll, .exe, .zip, .vsix, .nupkg, and .winmd files.

Some related tools that might come handy in whatever it is you're doing are resource editors such as ResourceHacker (free) and a good hex editor such as Hex Workshop (commercial).

Additionally, if you are doing malware analysis (or use SICE), I wholeheartedly suggest running everything inside a virtual machine, namely VMware Workstation. In the case of SICE, it will protect your actual system from BSODs, and in the case of malware, it will protect your actual system from the target program. You can read about malware analysis with VMware here.

Personally, I roll with Olly, WinDbg & W32Dasm, and some smaller utility tools.

Also, remember that disassembling or even debugging other people's software is usually against the EULA in the very least :)

psoul's excellent post answers to your question so I won't replicate his good work, but I feel it'd help to explain why this is at once a perfectly valid but also terribly silly question. After all, this is a place to learn, right?

Modern computer programs are produced through a series of conversions, starting with the input of a human-readable body of text instructions (called 'source code') and ending with a computer-readable body of instructions (called alternatively 'binary' or 'machine code').

The way that a computer runs a set of machine code instructions is ultimately very simple. Each action a processor can take (e.g., read from memory, add two values) is represented by a numeric code. If I told you that the number 1 meant scream and the number 2 meant giggle, and then held up cards with either 1 or 2 on them expecting you to scream or giggle accordingly, I would be using what is essentially the same system a computer uses to operate.

A binary file is just a set of those codes (usually call 'op codes') and the information ('arguments') that the op codes act on.

Now, assembly language is a computer language where each command word in the language represents exactly one op-code on the processor. There is a direct 1:1 translation between an assembly language command and a processor op-code. This is why coding assembly for an x386 processor is different than coding assembly for an ARM processor.

Disassembly is simply this: a program reads through the binary (the machine code), replacing the op-codes with their equivalent assembly language commands, and outputs the result as a text file. It's important to understand this; if your computer can read the binary, then you can read the binary too, either manually with an op-code table in your hand (ick) or through a disassembler.

Disassemblers have some new tricks and all, but it's important to understand that a disassembler is ultimately a search and replace mechanism. Which is why any EULA which forbids it is ultimately blowing hot air. You can't at once permit the computer reading the program data and also forbid the computer reading the program data.

(Don't get me wrong, there have been attempts to do so. They work as well as DRM on song files.)

However, there are caveats to the disassembly approach. Variable names are non-existent; such a thing doesn't exist to your CPU. Library calls are confusing as hell and often require disassembling further binaries. And assembly is hard as hell to read in the best of conditions.

Most professional programmers can't sit and read assembly language without getting a headache. For an amateur it's just not going to happen.

Anyway, this is a somewhat glossed-over explanation, but I hope it helps. Everyone can feel free to correct any misstatements on my part; it's been a while. ;)

Good news. IDA Pro is actually free for its older versions now:http://www.hex-rays.com/idapro/idadownfreeware.htm

Any decent debugger can do this. Try OllyDbg. (edit: which has a great disassembler that even decodes the parameters to WinAPI calls!)

x64dbg is a good and open source debugger that is actively maintained.

Sure, have a look at IDA Pro. They offer an eval version so you can try it out.

If you are just trying to figure out what a malware does, it might be much easier to run it under something like the free tool Process Monitor which will report whenever it tries to access the filesystem, registry, ports, etc..

Also, using a virtual machine like the free VMWare server is very helpful for this kind of work. You can make a 'clean' image, and then just go back to that every time you run the malware.

What you want is a type of software called a 'Disassembler'.

Quick google yields this: http://www.geocities.com/~sangcho/disasm.html

You may get some information viewing it in assembly, but I think the easiest thing to do is fire up a virtual machine and see what it does. Make sure you have no open shares or anything like that that it can jump through though ;)

I can't believe nobody said nothing about Immunity Debugger, yet.

Immunity Debugger is a powerful tool to write exploits, analyze malware, and reverse engineer binary files. It was initially based on Ollydbg 1.0 source code, but with names resoution bug fixed. It has a well supported Python API for easy extensibility, so you can write your python scripts to help you out on the analysis.

Also, there's a good one Peter from Corelan team wrote called mona.py, excelent tool btw.

If you want to run the program to see what it does without infecting your computer, use with a virtual machine like VMWare or Microsoft VPC, or a program that can sandbox the program like SandboxIE

If you have no time, submit the malware to cwsandbox:

HTH

You can use dotPeek, very good for decompile exe file. It is free.

Not the answer you're looking for? Browse other questions tagged debuggingwinapiassemblydecompiling or ask your own question.

Malware comes in all shapes, sizes, and languages to make defending against attacks more difficult. One of the nefarious ways malware attempts to hide is by masquerading as a legitimate installer or application.

A recent sample encountered by the Carbon Black Threat Research Team used a compiled AutoIT script that pretends to be an installer for Photoshop CS6 portable. The application installs itself and runs as intended on the target system, while stealthily injecting a Remote Desktop tool known as LuminosityLink into a .NET process behind the scenes. The process for reversing AutoIT scripts can be more difficult since there are far fewer and less developed tools for performing the analysis. Since recovery of source code is trivial for script-to-exe programs, the authors rely heavily on string and execution flow obfuscation.

In this blog we will walk through the techniques used by this malware to increase the difficulty of discovering the final payload and the methods used to maintain persistence on the system. We will also look at the tools, tactics, and techniques for reverse engineering this type of AutoIT script.

Executive Summary

The sample AutoIT script is compiled into a Windows portable executable using a tool provided by the AutoIT creators. This tool, Aut2exe, converts an AutoIT script to a more ubiquitous Windows executable by packaging the runtime environment with the script. This conversion allows the attackers to target any Windows system by removing the dependency of having the AutoIT runtime installed.

In the case of this malware, any additional resources referenced in the script are also packaged into the malware, causing the sample to weigh in at over 115MB. The author of this script compiled a legitimate Photoshop portable installer as well as several malicious scripts necessary for infecting the target system with a powerful remote access tool.

The malicious scripts are heavily obfuscated to make it more difficult to analyze the contents and the malware attempts to hide by setting the attributes of the file to system and hidden. This prevents a typical user from seeing the file unless uncommon options are used in the explorer window.

The malware also remains persistent on the system by installing itself to the registry so the malware executes each time the system starts up. When the malware starts, the payload is injected into the .NET command line compiler application (vbc.exe) to appear legitimate on the system. However, the actual code running in the process is the backdoor allowing the attacker full access to the target system.

Stage1

The packaged malware starts its life by pretending to be a legitimate Photoshop Portable CS6 application. In this case, it actually does contain the legitimate multi installer for both 32-bit and 64-bit systems. Unfortunately for the victim, it also contains a malicious AutoIT script that infects the system.

AutoIT is a BASIC-like language that is often used to automate tasks with a focus on GUI driven apps embedded with their runtime. Because it’s based on BASIC, the scripts are often easy to read and very descriptive. However, because of this, malware authors typically go to great lengths to obfuscate their code against reverse engineering. In order to get the code out of the compiled binary we can use a tool called Exe2Aut, which retrieves the source code and writes it to disk.

Disclaimer: The malicious binary is launched in memory in a neutered format, however if the malware uses any kind of pre-execution tricks such as TLS, they could potentially execute. Therefore, you should always run this tool inside an isolated or sandboxed system. Dragging and dropping the binary will decompile the binary into source code. It is also important to note that this only works on 32-bit AutoIT compiled binaries:

Decompile Autoit .exe Au3

This provides readable source code and is often enough to determine the purpose of the malware. In this case, the obfuscation makes this static analysis daunting. The way I attack this type of obfuscation is a combination of static analysis and debugging the script. The AutoIT creators provide a script debugger that works similar to other debuggers, although it can be quite buggy and certain functions can crash the application. It is enough to be able to step through the code and set input arguments in order to test out various inputs to the script.

By stepping through the code with the debugger, some functions can be named, modified, and sometimes eliminated altogether to clean up the source code. I also write Python parsing scripts to be able to quickly see what a line of code is going to be. Several of these types of samples use a random function name, pass it a number, and return the corresponding character. By parsing a long line of these integer to ASCII conversions, I can quickly see what string that line of code is trying to build. Using this quick Python script, I pass it the line of code and the function name that I’d like to parse for characters:

This can be fleshed out more, but there were only a few uses in this script. It did help on a few occasions, though, turning obfuscated lines of code into something more readable:

How To Decompile An Exe

We now have a way to do both some static and dynamic analysis of the malicious script and we will be referring to this script as the Stage1 script for the remainder of the writeup. The first line of Stage1 causes the the Photoshop executable to be dropped on disk. It appears the intended destination is in the %TEMP% directory of the target system, but a forgotten ‘’ in the code caused the temp directory to be concatenated to the Photoshop name.

This didn’t affect the execution of the malware. After being dropped, Stage1 checks to see if a file exists in the %TEMP% directory: TGgtjCDKADvaH8BUQkZKWfKWj. This file acts as a semaphore, causing the dropped Photoshop installer to execute if it does not exist. On the first run, the Photoshop installer is executed and the flag file is created in the %TEMP% directory.

This file works and after install, Photoshop can be used on the system. Next, a six-digit number is randomly generated for use later in the script. At this point Stage1 begins using string reversal, replacement, and obfuscation to drop three additional files in the %TEMP% folder:

Autoit Exe To Au3

1. SBIXinQrad -> renamed to the random six-digit number above
   1. This file is a obfuscated script that looks like a large amount of gibberish. Once it is decoded, it will be the second stage of the malware
2. TVsusCoFv2 -> renamed incl1
   1. This file is a series of obfuscated strings that will be used in conjunction with the second stage of malware
3. Incl2
   1. This file is a base64 encoded and RC4 encrypted payload. It will be the final payload for the malware

Incl2 is contained in the Stage1 script as a base64 encoded string. It is decoded and written to disk as an encrypted blob. The SBIXinQrad file is read in and decoded using a custom string deobfuscation routine that builds upon itself and then inverts the result. The following Python code will decode the file:

The above code turns this junk:

Into Stage2 of the malware:

At this point the malware has dropped the final payload, an obfuscated string file, and the second stage of the malware. It is ready to move onto Stage2 and accomplishes this by calling the API ShellExecuteW with the arguments:

• /AutoIt3ExecuteScript
• %TEMP%<random 6 digit number>
• pathto<original binary>.exe

Ms office 2011 mac keygen download. This causes the runtime environment built into the original executable to execute Stage2 instead of the original Stage1 script.

The job of Stage2 is to set up the environment for the malware. First, the malware would like to be running as %APPDATA%svchost.exe and a check is performed to see if this was the argument that was passed from the previous script. Since this is the first run, it will not be running as this target process name, which causes the original binary to be copied into the %APPDATA% as svchost.exe and the attributes of the file set to System and Hidden. The new svchost.exe is executed with similar arguments to the first run except now the paths match the target location:

• /AutoIt3ExecuteScript
• %TEMP%<random 6 digit number>
• %APPDATA%svchost.exe

A batch script that is responsible for deleting the original dropped binary and itself is created as %TEMP%67.bat and executed:

The ping command is actually invalid and improperly concatenated when the script is created. However, since it is piped to nul, the error is suppressed. The author is just looking for a delay in execution using a dummy command until the original binary stops executing. It will then delete the original binary as well as itself. Stage2 also looks for Zone.Identifier files associated with the original dropped binary and deletes that file as well. This file is an Alternate Data Stream that contains information about where the file was downloaded from.

Now that the Stage2 is running in its preferred location, it is ready to install persistence in the ever so common CurrentVersionRun key:

Stage2 is now ready to decrypt the final payload and inject it into the target process on the system. The decryption of the binary is accomplished in an interesting manner. The API CallWindowProc is called with the decryption routine, a pointer to the encrypted blob, and the decryption key. The decryption routine is pulled from the encoded string library (File: incl1) that was discussed above in the Stage1 writeup. An encoded string is accessed by calling a function with the number of the string requested. The entire file is decoded and the string is returned via the number passed. The string encoding uses several replacements in the file to build a hex encoding of the ASCII representations of the characters. The result is converted into ASCII characters and then inverted. Here is Python code for decoding these files:

This code turns the encoded gibberish:

Into a string lookup table for the malware:

In order to retrieve the RC4 decoding routine, the number 26 is passed to the string decoding function: U335BXtWJ(26):

Here is the decoding function:

As you can see, these functions can be difficult to read with all the concatenation, string replacement, function calls, and obfuscated strings. There are also several calls to that function requesting strings:

This function is building the decryption routine as a byte array so that it can be passed to the CallWindowProc API. The encrypted blob is decrypted in place and Stage2 is now ready to inject it into the target process.

This malware chose to look for vbc.exe, which is the command line compiler for the .NET framework. The target process does not matter much, but the final payload is a .NET binary, so perhaps they thought it would be a good place to hide. If it fails to find that particular file, the fallback is to inject into itself. The process is started suspended, space is allocated in the target process, the malicious code is mapped into its memory, and the suspended thread is resumed.

The code continues on and does some very basic sandbox detection, checking to see if either of these two processes are running:

1. SandboxieRpcSs.exe
2. SandboxieDcomLaunch.exe

The script will exit if either process exists, except the injection has already occurred and Stage2 will exit soon anyways. It also retrieves a process list and does nothing with it. There is a decent amount of dead code and my guess is that this was a part of some other malware or planned for future versions of the malware. At this point, Stage2 finishes execution.

The final payload is a Remote Desktop Tool known as LuminosityLink that is sold legitimately. It is often found in conjunction with heavily obfuscated AutoIT scripts. I previously wrote a blog detailing a similar sample. The current sample is capable of doing all the things a typical Remote Access Trojan can do for the price of about $40.

LuminosityLink can be built on the fly with the options that control the behavior of the RAT. Palo Alto published an in-depth analysis of the LumnosityLink family and configuration.

The configuration for this particular sample had all the bells and whistles turned on:

Malware authors go to great lengths to hide their malware and increase the length of time it is present on the infected system. String obfuscation, esoteric language choice, and masquerading as a legitimate installer are all ways this malware attempted to remain on the infected system.

Performing in-depth reverse engineering and sharing accumulated knowledge on the inner workings of the malware, tactics for reversing, and scripts for future samples adds to the body of knowledge in the security community.

By providing this information, we become stronger as a community and able to respond to threats quickly.