Autoit Decompiler 33 Download
Toni Jarels
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.
You need to make a security group for those users, then make the GPO the tie in the two so the GPO apply only to the user in your group. So no matter where they log on to they will not be able to install software.
This way, although is a computer policy, it is limited to the user and when another user who does not have the policy in question logs on to the computer he will be able to install uninstall stuff because the policy is tied to the user rather than the pc.
But you have other problems with your idea, because windows installer is only 1 way of installing software on a pc. And as far as I know, other than killing their admin rights, you cannot cover them all with GPO.
@enricoc How many of your users have access to/are allowed to install .exe decompilers? The autoIt program is not necessary to be installed on end users computers as the executables it created are standalone.
@enricoc: When I have to use these types of methods, I create a new local administrator account used only for the launcher. If my users somehow became aware of the fact a launcher was being used, somehow figured out it was written in AutoIt, had the technical know-how to decompile it and understand the source, they would STILL only have access to their local computer.
If you are concerned at all about that very remote possibility, then set a start-up script for that particular local admin account that sends you an email if someone logged on interactively using those credentials. I can tell you without a doubt that none of my users have this type of know-how though. If they did, they would be working in my department.
Since our first blog post in February of 2020 on the remote access tool (RAT) known as LodaRAT (or Loda), Cisco Talos has monitored its activity and covered our findings in subsequent blog posts, listed below:
As a continuation of this series, this blog post details new variants and new behavior we have observed while monitoring LodaRAT over the course of 2022. In this post, we will take an in-depth look at some of the changes in these variants. As detailed below, some changes are rather small; however, some variants have made significant alterations, including both removal of code and implementing additional functionality.
LodaRAT is written in AutoIt, a well known scripting language typically used to automate administrative tasks in Windows. AutoIt scripts can be compiled into standalone binaries, allowing them to be executed on a Windows machine whether or not AutoIt is installed on the host. The original source code can be easily retrieved from these compiled binaries by using an AutoIt decompiler.
As discussed in our previous blog posts, LodaRAT will typically utilize function obfuscation, as well as string encoding to impede analysis. However, there are many examples which are non-obfuscated that contain the original function names and strings. If a threat actor does not have access to its source code through other means, all that is required to create their own variant of Loda is decompile the script, make the desired changes, and then recompile it. In addition, LodaRATs C2 communications are not encrypted, making it trivial to implement a custom C2 infrastructure. This ease of source code retrieval and customization has likely contributed to the proliferation of numerous variants and customized versions of LodaRAT.
As such, due to the variations between the samples we observed, the changes discussed in this blog post are from multiple variants and altered versions of LodaRAT, therefore each change does not apply to every variant. It is quite common to find altered versions of LodaRAT, and it should be expected that most samples will likely have some sort of alteration to the source code.
In one heavily altered version of Loda (c73771b3b8c6e548724dd02e5f12380a9160323d88dbdbe12d388ade0f7bc1e2), the function that detects anti-malware processes has been rewritten. This new function searches for thirty different process names, whereas the original and most variants perform a WMI query to enumerate all AV processes. It is worth noting that this new implementation is far less effective than the previous one, as the function will not detect a product that is not included in the list of processes to search for.
The addition of these older products to the search may be an attempt to detect analysis machines or VMs running older versions of Windows, such as Windows XP or 7. It is also worth noting that some of the software included in the list originate from different regions throughout the world, indicating that this attacker is likely not targeting victims in a specific region or country.
During our analysis, one instance of LodaRAT utilized a string encoding algorithm that differed from previous versions we have observed. This new implementation was likely employed to improve the speed of execution.
Historically, most LodaRAT samples utilize string obfuscation by encoding strings with a simple custom encoding scheme. As each string is referenced in a function, a routine at the end of the script decodes it. Generally, the algorithm in the decoding routine was the same through all obfuscated LodaRAT samples, aside from the randomization of the static numerical values stored in the variables.
However, during analysis, we observed a variant using a different string encoding/decoding method. While it is no more complex than the older algorithm, this new method was likely implemented to improve the speed of decoding strings. Rather than XORing the string with three separate numerical values, it simply subtracts from it with a single value.