Ok, first the good news [Smile]

The contents are not encrypted but they are compressed (zipped). This means that the command line and script contents are protected from casual browsing of the executable.

However, just so that we don't get too complacent, your password is (please supply your own fanfare...):
code:
gltm844hy@#4t
I'm not going to give away how I cracked the password as there may be quite a few people using the packager as a way of securing tasks. Suffice it to say that it took about 15 minutes and the tool I used to crack it was...KiXtart.

Now that I have the method of course it would take seconds to crack new versions.

I should stress that this is not in any way a failure of the Kix editor product. The problem is that there is not yet any secure way to execute a KiXtart script.

Off the top of my head, the only secure way or running a script with elevated privileges is:
  • Keep the password encrypted and internal to the executable (package). Don't pass it on in any form.
  • Gain higher levels of access within the executable only.
  • Don't call any external files or scripts unless they are on a locked down server share and you check the validity of the file before calling it.
  • Always use fully qualified paths
Remember, creating temporary local files is a gift to a cracker.
Administrative security is always going to be a balance of risk against practicality and cost.

If packaging the files and obfuscating the password is sufficient in your environment, and the cost of the security being breached is less than the cost of implementing a more secure solution then you should implement it. You should however ensure that the powers-that-be buy into it.