Sign in to follow this  
Followers 0
smooter

Compiled AutoIT files encrypted?

7 posts in this topic

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

Share this post


Link to post
Share on other sites



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.

[center]Common sense plays a role in the basics of understanding AutoIt... If you're lacking in that, do us all a favor, and step away from the computer.[/center]

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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.


[center]Common sense plays a role in the basics of understanding AutoIt... If you're lacking in that, do us all a favor, and step away from the computer.[/center]

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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().


Visit the SciTE4AutoIt3 Download page for the latest versions        Beta files                                                          Forum Rules
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0