#99020 - 2003-03-03 02:40 PM
KiXcrypt version 3.03x - call for testers.
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
I need some help testing a new version of KiXcrypt.
This version uses a new method of hiding the primary script, but at this stage it is experimental.
VERY IMPORTANT 1 This updated requires a version of KiXtart which supports IsDeclared()
Activate the experimental routine by using the "-x" command line switch.
The new features are:
- New environment variable %KIXCRYPTDEBUG% set to "1" if the package was made with the "-d" debug flag.
- New environment variable %KIXCRYPTEXE% which is the full path to the package name when started. This is also quite experimental, so let me know your findings.
- %COMSPEC% is no longer included in the default execution command.
- "-x" experimental script protection
VERY IMPORTANT 2 There is a problem with environment variables being expanded when starting the unencrypted script under the control of a command interpreter. To avoid this issue, either: 1) Don't use environment variables in your script or disguise them so that they don't appear as %ENVVAR%. 2) Don't use %COMSPEC% (command.com or cmd.exe) in your execution (-e) string. The default command no longer includes %COMSPEC%. If you don't use the "-x" switch KiXcrypt works as it always has (or at least it should let me know about any regressions)
For those of you interested in how it works, the "-x" option writes a boot script rather than the encrypted script. The encrypted script is passed as command line variables, which are then catenated in memory to form the original script. This is then Executed().
If you create the package with the debug option the recreated script is saved as "bsdebug.kix" so you can compare it with the original script if there are problems.
Note, if you have a very large script you may get problems with environment space.
To save you hacking it, here is the boot script:
code:
Break OFF $KIXCRYPTCOUNT=0 $KIXCRYPTLINES='Exit 1' While Execute('Exit IsDeclared($$sKIXCRYPT$KIXCRYPTCOUNT)') Redim Preserve $KIXCRYPTLINES[$KIXCRYPTCOUNT] $KIXCRYPTNULL=Execute('$$KIXCRYPTLINES[$KIXCRYPTCOUNT]=$$sKIXCRYPT$KIXCRYPTCOUNT') If $KIXCRYPTLINES[$KIXCRYPTCOUNT]='0' $KIXCRYPTLINES[$KIXCRYPTCOUNT]='' EndIf $KIXCRYPTCOUNT=$KIXCRYPTCOUNT+1 Loop If %KIXCRYPTDEBUG% $KIXCRYPTNULL=RedirectOutput('bsdebug.kix',1) Join($KIXCRYPTLINES,@CRLF) $KIXCRYPTNULL=RedirectOutput('') EndIf Exit Execute(Join($KIXCRYPTLINES,@CRLF))
VERY IMPORTANT 3 There is a small problem passing in a blank variable. If you start KiXtart with a variable specified as '$sVar=""' it gets converted to a numeric zero. This would mean that a blank line in your script would be converted to a zero, and the zero would be dumped to the console when you ran the script. To avoid this, the boot script changes any line which is "0" to "". In the unlikely event that you need a line in your script which is just "0" you will need to code around it.
This may apply to any line which can be converted to a numeric, so beware.
Right, if you've got this far and are still interested, the files are here
|
Top
|
|
|
|
#99037 - 2003-09-02 12:15 AM
Re: KiXcrypt version 3.03x - call for testers.
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
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
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 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.
|
Top
|
|
|
|
Moderator: Arend_, Allen, Jochen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Mart
|
0 registered
and 369 anonymous users online.
|
|
|