How secure are compiled AU3 scripts?

[ktuimala]

There is a lot of content in these forums. Sometimes it is downright hard to find things.

How secure are compiled AutoIT scripts? I have been toying with the idea of doing a semi commercial (maybe) project with AutoIT, and I would like to keep some of my code kept under wraps. Also I have been working on converting a lot of my company's vbs and kix scripts to autoit. Some of these scripts are now going to have embedded passwords for some functions.

Is a compiled AutoIT script going to keep this code relatively secure, or is it going to be near impossible to keep code and passwords secure? Is there a way to make compiled AutoIT executables secure? Could I add a ridiculously long and complex pass phrase to a compiled AutoIT script to make it more secure?

I look forward to your responses.

Edited June 28, 2007 by ktuimala

[Uriziel01]

You may use tool Obfuscator to deform the code and rename all variables and funcs to real hard to red but i think that if somebody wanted to read your code real hard he will do it, but this tool will increase lv of security. p.s-Obfuscator is included in the SciTe full package.

[MHz]

Use Scite4AutoIt3 with the protection of Obfuscator. The protection level is reasonable. A person with lot's of time to waste maybe able to crack it. The protection will make it hard for them. That is perhaps the best you can do. And do not tell the end user that it is a AutoIt compiled script.

[ktuimala]

Thanks for the tip. Obfuscating the code is a good start. However, I really have no hacking skills, but is it easy to decompile an exe made with AutoIT? Will a large complex pass phrase offer any hacking protection?

Also, I have already taken the approach of not letting my users know that the executables were made with AutoIT. However, more intuitive users might look at the version tab of the file's properties and notice that the Other Compiled Information contains AutoIT. Is there a way to modify this data or change it at compile time to show something less obvious?

[weasel127]

To change the version Info, you can use the program ResHacker (there is a link in SciTE on the 'Resource Hack' tab of the Compile dialog) and edit the resources. Also, there are some decompilers that can decompile any script no matter what, so the only protection is obfuscation. I tried to protect against this by packing with a different packer, but people can still decompile, so just use a good obfuscation.

[ktuimala]

I have been using AutoIT for a long time now, and I never knew these tools existed outside of the SciTE package that came with the AutoIT installer. I am floored by the options in the full version.

You can't imagine how excited I am right now!!! This is by far the best thing that has happened to my career in IT for Windows platforms.

I am now a very very happy camper.

[Qualitybit]

Thanks for the tip. Obfuscating the code is a good start. However, I really have no hacking skills, but is it easy to decompile an exe made with AutoIT? Will a large complex pass phrase offer any hacking protection?

Also, I have already taken the approach of not letting my users know that the executables were made with AutoIT. However, more intuitive users might look at the version tab of the file's properties and notice that the Other Compiled Information contains AutoIT. Is there a way to modify this data or change it at compile time to show something less obvious?

Consider that any change of variables does not affect constants like your passphrase. So if you do not use something e.g. descrambling at runtime, someone using a simple fileviewer have a good chance to discover this "secure passphrase" ^^

Hiding the hiding routine could be recommended also ^^

regards

Qualitybit *revellingearly80'soldschoolcrackertimes*

Edited June 28, 2007 by Qualitybit

[Uriziel01]

I thank there is a way to secure from decompiling but not from desassembling and i now few people (they are genius in Asembler) who can read code desassembled in this way.

[bhoar]

The obfuscation tool is really *the* best currently available way to protect your script.

I have to admit, I've used google to discover tools to remove the password on password protected autoit scripts. I even found a tool that can partially de-obfuscate obfuscated scripts. But that's not enough to make things easy. Why?

If I understand it correctly, the obfuscator consists of several tasks:

1. A comment stripper.

2. A variable and constant name randomizer.

3. A variable placement reorderer.

4. A function name randomizer and placement reorderer.

5. A variable content scrambler.

Any current or future deobfuscator is only going to be able to undo the work done by item #5. Items #1-4 aren't really computer-reversible because they are essentially one-way functions.

And you'd be surprised how much work reversing 1-4 by hand will be. So much context is lost in those steps. A hacker might be able to deduce something useful out of the variable strings revealed by rolling back #5. They might even, after some serious work, get an idea of how to implement an algorithm you implemented by examining the code.

The best a script kiddy could hope for would be to change strings in your program (e.g. pretend it is theirs). Making significant changes would be headache inducing.

...especially if you link in a whole heck of a lot of additional include files you never call into...

-brendan

[Jos]

The obfuscation tool is really *the* best currently available way to protect your script.

I have to admit, I've used google to discover tools to remove the password on password protected autoit scripts. I even found a tool that can partially de-obfuscate obfuscated scripts. But that's not enough to make things easy. Why?

If I understand it correctly, the obfuscator consists of several tasks:

1. A comment stripper.

2. A variable and constant name randomizer.

3. A variable placement reorderer.

4. A function name randomizer and placement reorderer.

5. A variable content scrambler.

Any current or future deobfuscator is only going to be able to undo the work done by item #5. Items #1-4 aren't really computer-reversible because they are essentially one-way functions.

And you'd be surprised how much work reversing 1-4 by hand will be. So much context is lost in those steps. A hacker might be able to deduce something useful out of the variable strings revealed by rolling back #5. They might even, after some serious work, get an idea of how to implement an algorithm you implemented by examining the code.

The best a script kiddy could hope for would be to change strings in your program (e.g. pretend it is theirs). Making significant changes would be headache inducing.

...especially if you link in a whole heck of a lot of additional include files you never call into...

-brendan

Yeap ... thats pretty close ... unneeded Funcs can be stripped too with Obfuscator...

[McGod]

There are hacked Exe2Aut files out there that can bypass the passphrase. Obfuscator is your best bet, but nothing is 100% secure.

[bhoar]

Yeap ... thats pretty close ... unneeded Funcs can be stripped too with Obfuscator...

Heh. Good work JdeB. You'll be making me feel both secure and frustrated for years to come.

-brendan