Is it possible/how do I encrypt a compiled exe?

[cosmicthoughts]

I hate those people who join forums and ask really dumb and obvious questions, and sadly it looks like I might be one of those people today. Sorry if this is the case.

Occasional lurker, but this is the first time I've actually needed to post.

I'm working on trying to run Sage as local admin (Sage is an awful app that tends to require admin rights to run - and giving the user admin rights is not really an option) - and I've this script which does what it says on the tin:

LOCAL $SUSERNAME="administrator"
LOCAL $SPASSWORD="XXXXXXXXXXXXXXXXXX"
RUNAS($SUSERNAME,@COMPUTERNAME,$SPASSWORD,1,"C:\Program Files\Etats comptables et fiscaux\EtatFi.exe")
EXIT

(Obviously that's not the local admin password)

And it works fine. However, we are looking at using something similar to allow users to install certain applications, but my boss is seeking assurances that users cannot get hold of the local admin password. Having taken a look, it appears it is possible to decompile the exe and get the admin password.

I've been looking at encryption methods, and I'm not afraid to admit I am out of my depth. Is there a step by step guide out there on how I can use blowfish (for example) to encrypt my script?

I could use Obfuscator, but mcafee 8.7 is falsely reporting any script I compile via Obfuscator as infected with W32/Autorun.worm.zf.gen - and I understand that it isn't the silver bullet I am looking for.

[Melba23]

cosmicthoughts,

Searching the forums will provide you with a lot more information in greater detail, but in brief:

- Your plain language script is within the compiled .exe, but in compressed form. It is not immediately viewable with a hex editor, but is by no means secure as it is expanded in memory when the .exe is run.

- Obfuscator (part of the full SciTE4AutoIt3 package) will obscure your script by changing variable and constant names (and a lot more!), which makes it harder to decompile but again does not render the .exe secure.

So, Obfuscating/compiling an Autoit script will prevent quick snooping, but a determined, experienced hacker can relatively easily get your source - including passwords, specific filenames, etc. The general consensus is that AutoIt is not the way to do this - although the same is true for many, if not most, other languages out there - a stand-alone app with the password within it has to decrypt it at some point.....

Sorry if that was not what you wanted to hear.

M23

P.S. I doubt it is using Obfuscator that is giving you the virus warning - all it does is alter the script textually. It is much more likely to be the Autoit stub or upx. Try compiling using the #AutoIt3Wrapper_UseUpx=n directive to prevent compression and see if it is still flagged.

[cosmicthoughts]

Thanks Melba23 - you are quite right it's not what I want to hear

And I agree with you that I can't see how Obfuscator is causing the virus alert, but regardless of if I enable or disable UPX, if I compile it comes up with the same virus if I choose to run obfuscator before compilation in SciTE.

Here is the full au3 file.

#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_Version=beta
#AutoIt3Wrapper_UseUpx=n
#AutoIt3Wrapper_Res_Fileversion=0.0.0.6
#AutoIt3Wrapper_Res_FileVersion_AutoIncrement=y
#AutoIt3Wrapper_Run_Au3check=n
#AutoIt3Wrapper_Run_Tidy=y
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****
#Region
#EndRegion
Local $SUSERNAME = "administrator"
Local $SPASSWORD = "Xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
RunAsWait($SUSERNAME, @ComputerName, $SPASSWORD, 1, "C:\Program Files\Etats comptables et fiscaux\EtatFi.exe")
Exit

Edit: If I use the /striponly switch within Obfuscator it works fine. I think it best I work on this and come back if necessary. Thanks very much for your time.

Edited December 2, 2009 by cosmicthoughts
We don't need to know about decompilers

[ajag]

Local $SUSERNAME = "administrator"

Local $SPASSWORD = "Xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

Hi cosmicthoughts,

a way to make your password invisible is to "calculate" it:

instead of

$SPASSWORD = "Xxxxxxxxxxxx"

try

$PASSWORD = Foo('DummyTextToConfuse')


Func Foo()
   $help = Chr(88)
   $help = $help & Chr(120)
   $help = $help & Chr(120)
   $help = $help & Chr(120)
   $help = $help & Chr(120)
   $help = $help & Chr(120)
   :
  Return $help
EndFunc

Maybe this is a solution for you

A-Jay

[anzacfalcon]

Hi cosmicthoughts,

a way to make your password invisible is to "calculate" it:

instead of

$SPASSWORD = "Xxxxxxxxxxxx"

try

$PASSWORD = Foo('DummyTextToConfuse')


Func Foo()
   $help = Chr(88)
   $help = $help & Chr(120)
   $help = $help & Chr(120)
   $help = $help & Chr(120)
   $help = $help & Chr(120)
   $help = $help & Chr(120)
   :
  Return $help
EndFunc

Maybe this is a solution for you

A-Jay

Im not sure if this is appropiate but to further protect your compiled exe , you can code a "Crypter/Packer" with Anti's such as Anti Ollydbg. That is one of the most popular tools used by crackers. The best language for this would be VB6 or Delphi. If an MVP/Dev can approve me helping you with this then i wouldnt mind. Normally people abuse these tool's for what as we call "Making files FUD (Fully Undetectable)". The secondary purpose is to protect your exe. I hope this helped.

[Mobius]

Im not sure if this is appropiate but to further protect your compiled exe , you can code a "Crypter/Packer" with Anti's such as Anti Ollydbg. That is one of the most popular tools used by crackers. The best language for this would be VB6 or Delphi. If an MVP/Dev can approve me helping you with this then i wouldnt mind. Normally people abuse these tool's for what as we call "Making files FUD (Fully Undetectable)". The secondary purpose is to protect your exe. I hope this helped.

OllyDbg has an entire army of plugins to counter this sort of thing, and if all else fails there is always IDA pro, which has a really nice free version available. Granted it is slightly harder to detect and terminate Olly compared to IDA but still, most crackers will use both or more interchangeably depending on the target.

Also Debugger focused Ice often fails when the attacker uses separate dumpers / unpackers.

Which does make the whole procedure futile for protecting AutoIt3 binaries (specifically), and possibly more open to detection by ever Itchy antivirus tools.

Btw

"Making files FUD (Fully Undetectable)" are you sure about this translation?

No disrespect dude, just giving my pov that's all.

Vlad

Edited December 2, 2009 by Mobius

[anzacfalcon]

OllyDbg has an entire army of plugins to counter this sort of thing, and if all else fails there is always IDA pro, which has a really nice free version available. Granted it is slightly harder to detect and terminate Olly compared to IDA but still, most crackers will use both or more interchangeably depending on the target.

Also Debugger focused Ice is often fails when the attacker uses separate dumpers / unpackers.

Which does make the whole procedure futile for protecting AutoIt3 binaries (specifically), and possibly more open to detection by ever Itchy antivirus tools.

Btw

"Making files FUD (Fully Undetectable)" are you sure about this translation?

No disrespect dude, just giving my pov that's all.

Vlad

Yes well there are many other methods of protecting exe's like Anti-Debuggers etc, maybe throw all the top snippets in and see what happens hehe. Well i think it's actually "Fully Undetected", not "Fully Undetectable".

[bo8ster]

There is also the option to read in passwords. _StringEncrypt() can be used (see the example in the help file) but it is not 100% secure as pointed out nothing is. It is all a trade off and you have to decide the risks vs payoffs.

[Mobius]

Yes well there are many other methods of protecting exe's like Anti-Debuggers etc, maybe throw all the top snippets in and see what happens hehe. Well i think it's actually "Fully Undetected", not "Fully Undetectable".

Anti Debug Ice is a fine line, Too sensitive and it can cause problems with antivirus tools doing what they do, Who here has ever downloaded a crack or a loader of somekind (be honest) that has failed or spat out a message reporting it is being debugged when it is not?. (but you have AV installed, or even some crash recovery and analysis programs)

Also adi will give you problems down the line when you come to release your app and someone legitimately wishes to debug it to make sure it is not malicious. (were they not to realize it was Au3)

Don't get me wrong anzacfalcon, what you are suggesting should be viable, but for AutoIt3 binaries this process really is pointless ott for nothing given the procedure that a decompiler might use to detect and extract the source.

Vlad

Edited December 8, 2009 by Mobius

[anzacfalcon]

Anti Debug Ice is a fine line, Too sensitive and it can cause problems with Antivirus tools doing what they do, Who here has ever downloaded a crack or a loader of somekind (be honest) that has failed or spat out a message reporting it is being debugged when it is not?. (but you have AV installed)

Also adi will give you problems down the line when you come to release your app and someone legitimately wishes to debug it to make sure it is not malicious.

Don't get me wrong anzacfalcon, what you are suggesting is right up my alley, I am just saying that for AutoIt3 binaries this process really is ott for nothing given the procedure that the decompiler actually uses to detect and extract the source.

Respect

Vlad

Agreed but i did not quite understand the last bit

Yes i understand now. This process isnt really suited for AutoIt binaries because of the problems it may cause but it may be needed at times.

Edited December 2, 2009 by anzacfalcon

[MyDream]

I hate those people who join forums and ask really dumb and obvious questions, and sadly it looks like I might be one of those people today. Sorry if this is the case.

Occasional lurker, but this is the first time I've actually needed to post.

I'm working on trying to run Sage as local admin (Sage is an awful app that tends to require admin rights to run - and giving the user admin rights is not really an option) - and I've this script which does what it says on the tin:

LOCAL $SUSERNAME="administrator"
LOCAL $SPASSWORD="XXXXXXXXXXXXXXXXXX"
RUNAS($SUSERNAME,@COMPUTERNAME,$SPASSWORD,1,"C:\Program Files\Etats comptables et fiscaux\EtatFi.exe")
EXIT

(Obviously that's not the local admin password)

And it works fine. However, we are looking at using something similar to allow users to install certain applications, but my boss is seeking assurances that users cannot get hold of the local admin password. Having taken a look, it appears it is possible to decompile the exe and get the admin password.

I've been looking at encryption methods, and I'm not afraid to admit I am out of my depth. Is there a step by step guide out there on how I can use blowfish (for example) to encrypt my script?

I could use Obfuscator, but mcafee 8.7 is falsely reporting any script I compile via Obfuscator as infected with W32/Autorun.worm.zf.gen - and I understand that it isn't the silver bullet I am looking for.

You can try running as running as one commandline parameter passed to AutoIt3.exe.

This is from the help file.

AutoIt3.exe [/ErrorStdOut] /AutoIt3ExecuteLine "command line"

Execute one line of code.

That one line parameter can be compiled into exe using

this tool below. Its called Launch Builder.

http://www.softpedia.com/get/System/Launchers-Shutdown-Tools/LaunchBuilder.shtml

Then you only need AutoIt3.exe and the compiled parameter exe file. So the user just need to run compiled parameter exe file.

Heck, even a one line batch commmadline can be compiled into exe file using this tool. I use it before to launch my favourite online game with my username and password in it.

But thats before the game change the launching procedure.

[Juvigy]

Just encrypt with _Base64 or other implemented encryption UDF's that is the minimal security action you can take.

Dont use Obfuscator , dont use stringencrypt() - there is really little use for them - they can be easily overcome.