Thanks for your comments and for taking the time to download and check out the KixCrypt binary.

I'm aware of the short-comings of the KixCrypt process. For a start the password is included in the binary as clear text. The password won't allow you to decrypt the file without knowing the contents of the code tables and peturbing parameters but it will help reverse engineer the encryption *if* you get an encrypting version of the binary. Secondly, and more importantly the source code is published. Anyone can take it and change it so that the decrypted file is not deleted. Now all they need to do is to grab the encrypted script off the end of your file and tack it onto their hacked version. If you have the encrypting binary you can also use a char(0) attack to expose the XOR tables. Together with the password this will give you a decrytion key.

KixCrypt is not intended for use by "normal" users, so the fact it dumps to the console is not a problem. Anyone who runs it without reading and understanding the associated help pages should expect to have problems. The instructions on use are simple and quite explicit. There is even a specific warning about binary output to the console

If you want to *really* use it you should take the source code and change the encryption tables and peturbing parameters and use the customised version in your own organisation. Now no-one has your personal encryption algorithm.

After you create a distributable version of kixcrypt with your encrypted script attached the kixcrypt program will not encrypt again. This means your cracker type cannot create simple scripts and keep pushing them through to determine the algorithm, unless you publish your personal version of kixcrypt.

I don't know if you've looked at the source code for KixCrypt, but the encryption algorithm while simple would be devilishly hard to crack without clues, moreso with long scripts. The encryption is a simple XOR, but the password is not used to do the XOR itself, the password is used to generate a key which gets the encryption values from a set of "one time pads". There are also bitshifting processes and the sequence of the password characters used is not linear - sometimes the characters are skipped.

KixCrypt is not a finished product - I tried to emphasise this as often as possible in the files and on the download page, heh . It works and you can use it in it's current state in a live environment, although you would want to compile your own version so you don't have the same encryption algorithm as is in the download binary and source files. The purpose was to show that something can be done quite simply, and to encourage more debate. Other than bug fixes and updating the hash checksum for new relases of KixTart I probably won't be adding any features to KixCrypt. I released the source code so that anyone who wished to can have a hack about with it and customise it for their own use.

Some things you might like to add are:

• Encryption or obfuscation of the password
  
• Denial of binary or repeated characters to avoid exposing the code tables, in case someone gets hold of your encrypting version.
  
• Replace the "one time pads" with a pseudo random number generator.
  
• Peturb the data so that it is not 1-to-1 with the original script. Perhaps some sort of block switching.
  
• A more intelligent method of determining that the kix32.exe you are running is not a trojan
  
• Adding a simple compression routine
  
• Create an encrypted script without requiring the redirection and catenation process.
  
• Setting internal values in the binary part of the encrupted script so the values aren't so easily exposed.
  
• Including a kixtart binary as part of the distribution.
  
• An option to set a command line argument so that passwords and even short pieces of script which can be "execute()" can be passed into your script as variables so that they never appear in your script itself.
  
• Compile a "decryption only" version which cannot be hacked back into an encrypting version.
  
• Change the output file name generation so that it is not so predictable.
  
• Include a check that the file *can* be deleted once created. If I was cracking something like this, or any other process which creates a temporary script the first thing I'd try would be to run it in a directory which has add but not delete permissions.
  
• An asynchronous forked process to remove the decrypted script after KixTart has loaded it.