Ok, as regards requests about the internals of KiXcrypt, I'll refer you to the comments in the 3.00 release:
quote:
How good is the encryption?
Hmm. The encryption itself is quite good because it is proprietary. Only I know how it works and I'm not telling. It is good because without knowing how it works it is hard to get started cracking it.
I'd love to be in a position to get peer review of the code and techniques, but even giving hints would lessen the effectiveness of the encryption, so I can't divulge anything. Sorry [Frown]

quote:
--------------------------------------------------------------------------------
For instance, using "CMD", "COMMAND" or "%COMSPEC%" will generate a console.
--------------------------------------------------------------------------------

is not true.
if you haven't created a console beforehand, all these do NOT create a console.
Yes, and no [Wink] The point about this comment is that using "wkixcrpt.exe" will not stop a console being created. It will not create one itself but if by your actions one is created then it will appear. Some ways of doing this:
  • Use "kix32.exe" or another console application.
  • Use "wkix32.exe", but forget the "/i" switch.
  • Use "%COMSPEC%" in the execution (-e) command
The GUI front-end automatically uses "wkix32.exe /i" for console-less encryptions which solves most of these problems.
Note however, if you issue a command like:
code:
wkixcrpt -e "%COMSPEC% /C wkix32.exe /i %KIXCRYPTFILE%" "myscript.exe"
A console will appear.

quote:
the usage switch at least does not work
You are correct, this is because the console-less version does not have anywhere to dump the output from the command. I'll add something to the docs about this, but the solution as you found is to get it working with the console version and then switch to console-less for the final version.

There is no easy solution to this, as adding pop-ups (like wkix32.exe does) would bloat the executable enormously. I'm already unhappy that it is up to 35 KB.

quote:
how do I make reliable soft if kixcrypt crashes on existing file?
Ahem. It doesn't crash - it makes a nice clean exit in an exception.

If you think about it you will see why I chose to do this. The problem is that unless you have defined the directory it will unpack in (using -t at the encrypt stage) you don't know which directory will be used. This means that files in the destination directory could be clobbered.

As an example, suppose you create a package which includes the executable kix32.exe and the user runs it in c:\winnt. The package extracts kix32.exe, runs your script and then deletes all the support files. That's fine, unless there was already a kix32.exe present, in which case you have just deleted it from his system, removing his own version.

This could apply to any of the support files included in the package. For this reason the behaviour it to exit and clean up if there is a file name clash. You will not get this error with the primary file, as a unique filename is always generated.

quote:
C:\Documents and Settings\niemjo.PIKVAL\Työpöytä\checker installer>setup -t %temp%\unique1
FATAL: Cannot find temporary directory "C:\DOCUME~1\NIEMJO~1.PIK\LOCALS~1\Temp\unique1"
At present the temporary directory must already exist. I've thought about creating a temporary subdirectory with a random name. There is a lot of coding overhead in doing this, and some security concerns which is why I've avoided it so far.

The problem is mainly the clean-up code, dealing with extra files and subdirectories which may have been created when the unencryted file is executed.

I may well have another look at creating temporary subdirectories if it is a popular request.

Thanks for the feed-back, and any suggestions on how to safely overwrite existing files would be welcome.