Custom compiler

[Terenz]

Would to be nice for improve the security of our script ( actually not the best, or better to say that our .exe are opensource to every guys who knows how to click on the first result on google ) if was developed a custom compiler we can use for make unique .exe every time, or it would be good even if each can create a password when compiling
If is not possible, please explain the reasons.
Thanks for all dev's works

[TicketCleanup]

Automatic ticket cleanup.

[guinness]

Can you explain what is wrong with the current compiler?

[Terenz]

An autoit exe can be easily decompiled with automatics tool, obfuscated or not.
There are many ways to "protect" an executable in the forum, like AutoIt3Camo, or custom packer, like Themida, Armadillo etc. but really they are useless, i have make some test but everytime i have the source from my exe

So if there is development of a custom compiler ( like alternative, i don't want to replace tha actually ) which it create an unique exe everytime, or a password protect executable against decompiler, at least our work can be "safe" against automatic tools and can be reversed only in a manual way
I hope i was clear what is my intention with this request.

[anonymous]

Nobody wants to see your work days, months or years lost easily so I also seek ways to prevent or hinder decompiler and support the idea of ​​single executable each time it is compiled.

[anonymous]

Actually, and certainly i'm not happy of that, you can decompiling an autoit script in a snap of fingers. If a custom decompile or any other solution can reverse the course, i'm approve it

[anonymous]

Ops, missspelling. "if a custom compiler or any other..."

[ewieldra]

Search for AutoCamo on the forum

[Terenz]

Replying to ewieldra:

Search for AutoCamo on the forum

Did you read the comment n°3? Also AutoIt3Camo is useless and did not help with that type of tools

[MyEarth]

I'd like to know what devs think about this Feature Request.
Seems an important step for security development and i'm agree in every step in that direction

[James]

AutoIt is a scripting language. When your script is compiled, the EXE is a result of the interpreter and source code being bundled together. Over the years Jon has always tried to defeat the hackers, but they get quicker and quicker each time.

[Terenz]

James don't tell me the only way is surrender...
A custom compiler maybe is not the solution against hacker but at least after automatic tools, if the exe changes everytime you don't need a different approach everytime?

Another way is maybe to obfuscate the Autoit Stub or make it "dynamic" every time it compile a new exe? ( we can't do it but some unofficial tools does it, i don't have try that tools because is breaks the AutoIt EULA ) or adding some random junkcode to some part of the code for deceive the automatic tools?

I'm not an expert of this thing and probably i'm just saying crap words, but I can not believe at the phrase "I tried but there is nothing to do, sorry" for my part i'm trying to help in any way i can.

[Mat]

Well the truth is: "There is nothing to do, sorry". There is no way to compile a script so that the interpreter can run it but it can't be decompiled.

If security is an issue then move the code to a web server and create a web interface for it, that's security by design, rather than "security" by obscurity.

[Terenz]

From your answers guys i think i wasn't clear so i'll repeat again:

If a XYZ hacker want to decompile an ABC autoit exe, there is NOTHING you can do. I know, in every language the situation is always the same, is "normal" and you have to live with it.

But for autoit the situation is:
If a XZY noob, lamer, without any debugging-reverse-assembly knowledge what to decompile a ABC autoit exe, he can do it in a few click with automatic tools ( not one, but three-four ), doesn't matter the Func() you use, if you obfuscate it, packed or other protection i have write in the third post. This isn't a security issue? Pratically is a open door and everyone can go in.

So, for the last situation and only for the last situation, are you totally sure the dev's can do nothing? Would you put your hand on fire?

[Melba23]

Terenz,

The last time Jon changed the compilation method it was only a matter of hours before a new decompiler appeared. There are people out there with the time and determination to break into whatever they wish - as games and OSs get hacked pretty quickly despite huge sums being spent on prevention, what hope do we have with a simple scripting language?

Basically if you want security then do not use AutoIt - or in fact any other language. Do as Mat has suggested and go down a different road. ;)

And you have now flogged this subject to death. I will take a very dim view of any more threads, posts or tickets from you about AutoIt code security - please let it drop.

M23

[Terenz]

Melba,
I don't need and i don't want open another thread ( the last was closed, you know so i'm not do it again ) or make another Feature Request.
I'm not flogged this subject to death, but seems noone cares ( in Dev's group ) if you exe can be decompiled is so easy way by few click, not by "people with the time and determination to break into whatever they wish", but by anyone with at least a finger, a mouse, no knowledge and a internet connection.

The only subject of this Feature request is "try" to found something can be userful for improve our exe, if a custom compiler, a dynamic stub, a password protected .exe or any idea can be helpful for the security or our script.

I'll remember you ( I know you know ;) ) the Autoit EULA can't allow to us to edit the .exe after the compilation, disassemble, edit or modify the stub etc. without breaking the EULA so only from the "high plan" can release something in this way

[Jon]

I'm fairly insulted to be told "noone cares". If it were possible to improve the compilation I would. I just don't have the skills and I've wasted weeks of my life trying. In fact I believe it to be close to, if not actually impossible with the current interpreter+compiled script way that is used. Nothing apart from a full rewrite of autoit will do.

Do you know how the current best decompiler works? It doesn't even read in the script and trying and work out how I encoded and encrypted and obfuscated things. It doesn't even bother. What it does is it lets the script run and then as it executes it always gets to a point where it has to "run" the line of script - at that point the script tokens (not even stored as text) are ripped out of memory and reversed into readable text. No amount of tweaking will stop that. .NET can be one-click decompiled in a similar fashion.

On the plus side with the new beta scripts are stored as part of the resources in an exe rather than hacked-onto the end. This means that it may be possible to use your own packer/exe protector type software to wrap around it. I've not tried myself though.

[Terenz]

Jon my intention is not to offend anyone, I have much respect for people like you and for your hard work, i can only envy your knowledge.
Do you want to know why i have say "noone cares"?
Because on the forum we can't talk about security of our script, closed in a blink of an eye follow the rule DADT, officially because we can't talk about decompiling, but the subject is not the opposite, so prevent decompiling? ;)
I'm totally agree about epidemic 200 threads with the same subject, but maybe can be opened by you or one of the stuff an official thread about "suggestion" or proposal-script for improve the security of our exe? If you "don't have the skills", maybe other has ( not me :D )

Said this, i think you know the new beta is incompatible with the decompiling tools, because you have change the something in the compiling part which makes the executable not recognized, don't know if it is involved the resource part.
Many people say this is only a temporary phase. By this I was inspired by the idea of "custom compiler", if the compile process "change everytime" in some random part then the exe can be decompiled only manually.

A good article i have found about security of executable is this, maybe you are interested:
​http://en.wikipedia.org/wiki/Portable_Executable_Automatic_Protection