Compiled AutoIT files encrypted?

[smooter]

I am compiling all of my AutoIT scripts into .exe files, but have come across a situation where it may be necessary to include usernames and passwords in the script.

Question is:

If I compile my AutoIT scripts to .exe can they be opened/edited in order to get the username/password out?

If so, is there a way to compile that information?

Thanks,

smooter

[SmOke_N]

I am compiling all of my AutoIT scripts into .exe files, but have come across a situation where it may be necessary to include usernames and passwords in the script.

Question is:

If I compile my AutoIT scripts to .exe can they be opened/edited in order to get the username/password out?

If so, is there a way to compile that information?

Thanks,

smooter

You should never include passwords and or sensitive material in an AutoIt executable. Even obfuscation isn't safe for this.

[plastix]

You should never include passwords and or sensitive material in an AutoIt executable. Even obfuscation isn't safe for this.

SmOke_N is right - sensitive material is not safe. You could protect username/password pairs a little better by validating them against a Hash (ie user enters username & password - and script checks that hash of entered details = hash of actual username / password before continuing).

If you want to automated a login - then you will need to have these details encrypted within the application - and decrypt them prior to use - using some of the algorithms already coded, or a 3rd party DLL (or ActiveX library - but this would need to be installed / registered on local machine)

A final option is to use a 3rd party EXE wrapper to encrypt the Autoit executable - but many systems are not compatible (there was a thread regarding this a year ago I think).

I'll try and post some standalone 3rd party DLLs when I find some...

[Bert]

No software is safe from hacking. No matter what you do, someone with enough skills can break in. The best you can do is provide a layered defense against it. Like Plastix said, there are things you can do, but nothing is fail safe.

[SmOke_N]

SmOke_N is right - sensitive material is not safe. You could protect username/password pairs a little better by validating them against a Hash (ie user enters username & password - and script checks that hash of entered details = hash of actual username / password before continuing).

If you want to automated a login - then you will need to have these details encrypted within the application - and decrypt them prior to use - using some of the algorithms already coded, or a 3rd party DLL (or ActiveX library - but this would need to be installed / registered on local machine)

A final option is to use a 3rd party EXE wrapper to encrypt the Autoit executable - but many systems are not compatible (there was a thread regarding this a year ago I think).

I'll try and post some standalone 3rd party DLLs when I find some...

This either totally confused me, or I just don't see where this would make a difference. The path to the DLLs/Exes would be known, and the way that you are calling them would be known, so it would the same as just including the pass/username within the script itself (If I'm reading this right).

As far as another Exe wrapper, packing with another packer, etc... all of this has been explored before, and all of them bypassed the same way.

You can make it more difficult of course, and you will spend probably more time on the securing of your application/script then you did the actual script itself (been there done that). Until Jon finds the time to start/finish his tokenization project, I'd be looking at other languages (though they have their faults as well) to do what you want.

IMO, your only hope is making it a pain in the ass for the reverse engineer to find out the sensitive information you are trying to hide, and if they are really determined, that's no help at all.

If you've actually found a way around all of this "securely" that hasn't been proven faulty already, I'm all ears.

[plastix]

If the script only contains the HASH of username / password, then the program will use the values entered by the user at runtime (validated against hashes) - but the actual username / password will not be known. The attacker can only capture the username / password by sniffing communication of the script with a 3rd party DLL (if an internalised script isn't used to calculate the hash) / use a keylogger / reverse the hash using a lookup table (ie rainbow table for MD5 etc). However, this is only useful for username / passwords that are entered by the end-user.

Encryption,again, is only helpful if the program requires a end-user input - the encryption KEY being stored as a hash again and validated as above. Again, breaking this can only be achieved with the above. MD5 is broken, and RC4 can be broken on most home systems in a few hours/days. However, lookup tables for SHA256 or RipeMD160 etc are not complete.

Themida is a compatible (and essentially 'a pain in the ass' to undo) 3rd party packager,but is gonna sting for a developer license a minimum of 120euro+. It's an option in the interim...

Nothing is failsafe.

[Jos]

If the script only contains the HASH of username / password, then the program will use the values entered by the user at runtime (validated against hashes) - but the actual username / password will not be known.

This does not work when you want to run a Background/Batch type job that requires admin rights on the PC for which you requier a RunAsSet().