How would that help?

If the user can access the crypted.exe to execute it then they can copy it and execute anywhere, so denying the "-t" option won't make it any more secure.

Hard-coding the directory into the crypted.exe may be possible, but you will have to convince me that it will provide an additional useful deterrent.

You could force the files to be created on a hidden share on a server, but that is so easy to circumvent that it is pointless. All that it does is to give a false sense of security.

The problem is a balance. A malignant user with sufficient know-how to break through the other security devices won't be at all deterred by the files being written to a hard-coded directory path. The sort of user who will be deterred by a hard-coded directory path will already have been put off by the existing features.

You need your additional scripts to remain in place, because at some point you will want to CALL or otherwise execute them. If they are deleted before you call them it is going to seriously hamper the functionality of your script [Wink]

There are two things that you can do to increase security:
  • Put any security sensitive code in the primary script. This script is recreated with a random name to make it hard to catch, and is immediately deleted when it is started. The script is deleted even if you are paused at an input prompt.
  • Create all extra code in your additional scripts as functions. This allows you to CALL your additional script as the very first action of your main script. Once each has been called it you can delete it. The functions are loaded in memory, so you can call the functions later on in your scripts even though the original source files no longer exist.
Remember, with any of the encrypting solutions available for KiXtart that the purpose is to make it hard enough for someone to get access that it is not worth their while. At some point the script has to be available in it's original form because that is the only way that KiXtart can interperet it.