• Bug fix: A variable scope error meant that files created in a temporary directory using the "-t" feature would not be deleted in some cases.
• New feature: You may include any number of arbitrary files by using the "-f filename" option. You may repeat the "-f" option as many times as you like, up to a limit of 255 files.
• New feature: Three environment variables are created when the script is decrypted. These are detailed in a later post.

18 December 2002 Version 2.14b releasedActually, it was released a few days ago, but the board has been down It's amazing how much a part of my daily life monitoring the KiXtart BB has become!
Changes

• A bug in memory allocation causing a failure on Windows XP has been solved. Note, I could not replicate the failure, but testing at the site where the failure occurred suggests it has been resolved. Let me know if it hasn't. Many thanks to ElegantSol for his help in resolving this.
• The first "cannot find self" error message is no longer displayed. It wasn't particularly useful and would appear on systems which don't expand the command line to include the command extension, such as most NT+ systems.
• In DEBUG mode non-ASCII characters present on the command line are reported, with their values.
• Well, you asked for it, now you've got it. Oe of the most popular requests has been for a method of setting the directory that the temporary file is created in. There is now a "-t path" option when you decrypt which will create the temporary file in "path"

• Feature: The temporary file now overwrites itself before deleting, to avoid exposing the script with undelete utilities.
• A warning message is issues if the temporary script file does not delete itself, then the file is overwritten and deleted by the controlling program. If the "-k" option has been used the file is overwritten and deleted silently.

• Bug fix: "-s" trojan detection worked ok but didn't exit due to debug code left enabled (Spotter: Roberto M.)

• Bug fix: Fixed the "Cannot find self" bug. Again.
• Added "-v" option to display version and full amendment history.
• Added code to detect and avoid the "Russ Exploit" security issue.
• Release status changed to beta

• Bug fix: Lazy coding using "realloc()" caused garbage in the command line under Windows XP
• New option "-c" added. This inhibits "%COMSPEC% /C" being pre-pended to the command.

• Code now stable enough to optimise Compiled with -O2 means is faster, and smaller (back down to 12KB).
• -p GPF fixed.
• Temporary file name is now entirely random and changes every time crypted.exe is run. Crypted.exe will attempt 1000 different random file names before giving up.
• A directory which matches the temporary file name will no longer cause crypted.exe to exit.

code:

---

kixcrypt.exe myscript.kix

---

code:

---

kixcrypt -p password myscript.kix

---

code:

---

crypted.exe -p password

---

code:

---

crypted.exe password

---

code:

---

kixcrypt.exe -k myscript.kix

---

code:

---

kixcrypt.exe myscript.kix \\MYLOGONSERVER\NETLOGON\kix32.exe %s

---

code:

---

kixcrypt.exe myscript.kix \\MYLOGONSERVER\NETLOGON\kix32.exe %s "$PASSWORD=OpenSesame"

---

code:

---

kixcrypt.exe -k mybatch.bat %s

---

code:

---

kixcrypt.exe -k index.html start %s

---

code:

---

kixcrypt.exe -p installpassword -k myprog.exe copy %s myprog.exe

---

code:

---

kixcrypt.exe -m "$s$n$nThis script encrypted with version $v of KiXcrypt" myscript.kix
kixcrypt.exe -m "" myscript.kix

---

code:

---

kixcrypt.exe -s myscript.kix

---

code:

---

kixcrypt.exe -s myscript.kix \\LOGONSERVER\NETLOGON\kix32.exe %s

---

wow!!

Very nice and well done too. Nicely feature rich !!!

-Shawn

[i wanted to put ten smilies but the UBB filter wouldn't let me - what the heck is going on around here?]

[ 28 November 2001: Message edited by: Shawn ]

I try: kixcrypt kixtart.kix
and the error returned:

kixcrypt: Cannot open self!
kixcrypt: Trying with extension...
kixcrypt: Still cannot open self!
kixcrypt: Bailing out.

I try: kixcrypt d:\kixcrypt\kixtart.kix
and the error returned:

kixcrypt: Cannot open self!
kixcrypt: Trying with extension...
kixcrypt: Still cannot open self!
kixcrypt: Bailing out.

I try: kixcrypt -p password kixtart.kix
and the error returned:

kixcrypt: Cannot open self!
kixcrypt: Trying with extension...
kixcrypt: Still cannot open self!
kixcrypt: Bailing out.

wow!!!

I don't know why this happens. One of the first things the program does is to open itself to check if it is in encrypt or decrypt mode. My speciality is Unix rather than Windows, so I'm not experienced enough to tell whether the problem is down to file semantics in different versions of the OS.

Can you guys who've downloaded and tried KixCrypt let me know what version of Windows it ran on and whether or not it worked.

I initailially got the same message here. This is what I had to do to get kixcrypt running on my Windows 2000 box:

I created a shortcut called encrypt.lnk with the following specifics:

shortcut->target: c:\kixcrypt.exe c:\test.kix

then I simply started the link from the DOS command prompt. This created an executable called crypted.exe in the root of C:. Hopes this gives you a clue as to waht might be happening !

-Shawn

[ 29 November 2001: Message edited by: Shawn ]

I think the Problem is the call of the Program !!
When you call the program without the extension ".exe"
e.g. "kixcrypt c:\test.kix"
i get an error !!

But when you call the Programm with itīs own extension, like
"kixcrypt.exe c:\test.kix"

it works !!
Hope i could help !!

KST

The program attempts to open itself - if that fails it adds ".exe" and tries again, so you shouldn't need to do it yourself. This works for Win95 which is the system I'm compiling / testing on. Perhaps the value passed in argv[0] is slightly different on Win2K.

Tan Bandradi - please confirm that using the full executable name "kixcrypt.exe" works for you, and I'll try to dig up a W2K box to play with.

Thanks Shawn, KST for helping debug this.

I need to test it further more on my environment, but actually this is very good, awesome utility and I think this is the more practical and efficient KiXtart script encryption utility, ever!

Tan

- KixTart is not installed or copied on all clients and KixTart script extension is not associated to run with Kix32.exe
- All necessary KixTart executable and dll files are copied to netlogon share folder on all DC's, with KXRPC installed.
- I am using Kix 3.63
- All users run KixTart logon script from these DC's, as it is set on User Profile using User Manager. I set my account to run the executable encrypted file for testing.

These are the result according how do I use the kixcrypt command line switchs:

- kixcrypt.exe kixtart.kix
It works fine on WinNT, but I received: 'Bad command or filename' error on Win9x during logon.

- kixcrypt.exe kixtart.kix \\\netlogon\kix32.exe %s
It works fine on Win9x, but I received: 'Script error: failed to find/open script!' on WinNT, it runs kix32.exe but it couldn't find the extracted script.

- kixcrypt.exe kixtart.kix kix32.exe %s
It works on WinNT, but 'Bad command or filename' on Win9x.

Finally, I found out this command line that works on those both Win32's:
kixcrypt.exe kixtart.kix \\\netlogon\kix32.exe kc000000.kix

KC000000.kix is the extracted file of kixtart.kix from the encrypted executable file.

Tan

Tan, thanks for the excellent feedback. Could you try the new version with the debugging flag set and check what command line is being used - perhaps that will help narrow down the problems you are having.

Also, try these things:
1) Use "%%s" rather than just "%s" - this should stop the OS attempting to expand "%s" to an environment variable. You can also now use "^s" instead of "%%s".
2) The temporary file is created in the current working directory. Make sure this is a writeable directory during the login process.
3) Try forcing a local path e.g.

code:

---

kixcrypt kixtart.kix \\\netlogon\kix32.exe .\%s

---

Now it looks pretty good
Iīll stay on testing !!
Have a nice Weekend !!

KST

-Shawn

Thanks!
Tan

I had a similar idea, but I was going to have the new EXE contain the KIX32.exe as well. This would make the encrypted script completely stand alone.

How hard would it be to add that to what you have already done?

cj

Is it possible to use "wkix32.exe -i" and get rid of the dos box where crypted.exe is running. We are using wkix32.exe -i for some simple utils, were we do not need any black dos box.

KiXcrypt is the solution for our network with several students who seem to find my kix scripts where ever i put them thanks!!

GR Peter van der Struis

Shawn I never bothered to convert the date math stuff as the functionality is duplicated in the ScriptLogic SerialDate() UDF.

Peter you should be able to run any command as the interpreter. To ensure that the options are not used by KiXcrypt enclose the command in speech marks. Something like:

code:

---

kixcrypt myscript.kix "wkix32.exe -i .\%%s"

---

cj I considered including the kix32 executable earlier on but decided against it. It didn't really add anything so I didn't bother. Having said that it would be very simple to have an option to include the binary (any binary for that matter). For KiXtart specifically there are a couple of issues:
1) Win9x clients will need to have the DLLs present.
2) After all his good works I really don't want to undermine Ruuds "CareWare" policy, and a tool that allows a hidden distribution of KiXtart, however benign, would make me uneasy. Maybe I'm being too sensitive, I dunno. Ruud, if you are following this thread maybe you'd like to comment.

I'm in two minds about it. If there is enough interest and no objections I'll add the functionality and leave it to the user's conscience.

[ 04 December 2001: Message edited by: Richard Howarth ]

A very nice upgrade and an excellent job. The first version which doesn't
need a temporary file to past kixtart code to the kix32 binary. The file
is very hard (possible impossible) to catch.
It works fast and is very flexible.
Also the way of passing the password to the script is very nice. Possible
by this one-way encryption method. Encrypting and decrypting program aren't
the same and it is also possible to use all other kind of files/information
to encrypt.
Also a possible security leak with kix32.exe can be catch with the
checksum security -s switch.

Some points:

• we doesn't get a error message when we want to encrypt a file.
  an example:
  - we have the file "code"
  - 'kixcrypt code' creates the file 'crypted.exe'
  and 'crypted.exe' returns the message 'Script error : failed to find/open script !'
  - 'kixcrypt code.' createsalso the file 'crypted.exe'
  and 'crypted.exe' runs like we expected. no error messages.
  
• by using the -d switch the 'crypted.exe' run will also display
  debug information, which can't be stopped.
  is this the wanted result?
  
• we get an error when we are using following script with a password
  

  code:

  ---

  
  ? "kix @kix @build"
  

  ---

  
  the call are 'kixcrypt -p password script.' and 'crypted password'.
  the output on the screen is:
  

  code:

  ---

  
  CRYPTED caused a divide error in module CRYPTED.EXE at 014f:00402fe1.
  Registers:
  EAX=00000000 CS=014f EIP=00402fe1 EFLGS=00010246
  EBX=00530000 SS=0157 ESP=0073fc10 EBP=0073fd58
  ECX=78037ca8 DS=0157 ESI=816096fc FS=3a97
  EDX=00000000 ES=0157 EDI=00000000 GS=0000
  Bytes at CS:EIP:
  f7 3d a0 50 40 00 89 d6 89 35 a4 50 40 00 a1 00 
  Stack dump:
  00530000 816096fc 815e723c 815bc000 8160de40
  0008160e 000000c0 8160de40 00000010 bff782c8
  815bc000 8160de50 000000c0 00000000 8160de40
  815bc000 
  

  ---

  
  f.e. the same problem we have by encrypted our os.kix of our
  site. without using the -p option we doesn't have any problem.
  we have verify it on a windows95 system for you.
  
• we get another error when f.e. the filename 'kc000000' is a directory.
  the message was:
  

  code:

  ---

  
  Cannot open temp file for writing kc000000.
  Could not open an output script file - aborting
  

  ---

  
  questions:
  - is it possible to use a random filename, which also check for
  already existing (directory)names.
  - what will happen when the user doesn't have write access to the
  directory for creation of 'kc000000' file.
  

A nice issue can be the usage of environment variables which can't
prevent running the crypted.exe file in other environments. Specifi-
cations like:
- kixcrypt -p %domain% script.kix
- kixcrypt script.kix \\mylogonserver\netlogon\kix32.exe %s
will always decrypt the script. In the first situation you can simple
enter the another (= required) domain name to bypass it.

we are waiting for an upgrade.
greetings.

btw:
we like to publish your program on our site. let me know what you
think of that idea.

Changes

• Code now stable enough to optimise Compiled with -O2 means is faster, and smaller (back down to 12KB).
  
• -p GPF fixed.
  
• Temporary file name is now entirely random and changes every time crypted.exe is run. Crypted.exe will attempt 1000 different random file names before giving up.
  
• A directory which matches the temporary file name will no longer cause crypted.exe to exit.

To answer your points:

• KiXtart script with no suffix.
  The "'Script error : failed to find/open script !" error is a feature (bug?) of KiXtart.
  You will find that "kix32.exe code" will also produce this error, and that "kix32.exe code." will work.
  
• -d produces output in crypted.exe
  This is by design. The idea is that you can create a debug version for testing. When you are ready to release to your users you don't use the "-d" flag. NB For security reasons you cannot used the "-d" flag with "crypted.exe" - it has to be set on when you run kixcrypt.exe.
  
• -p password causes divide zero error
  Fixed in version 2.04a
  
• Temporary file names.
  As of version 2.04a the numbered file name is not used, so cannot easily be guessed. A file name of 8 random upper case letters is used. 1000 of these are tried before the program gives up. Each time crypted.exe is tun the random file names will be different.
  
• kc000000 directory.
  As of version 2.04a a directory with the same name as the temporary file will not cause crypted.exe to exit.

The crypted.exe has to create a temporary file because KiXtart cannot accept piped input. The current directory is always used and I probably won't be changing that simply because it would mean a lot of work for very little benefit.
If the directory is not writable by the user you will get the "Cannot open temp file for writing" error.

If you need to redirect the temporary file to another direcectory then "CD" to it before running crypted.exe

You (and anyone else) are more than welcome to publish the KixCrypt utility on your site.

I hope that answers all your questions.

We will give it a try.
Soon we will inform you also about the publication of it on our site.
Please inform me when new version will be released.
greetings.

We have verify your latest 2.04 version and it works like a charm.
We put it as a Kixtart tool on our site. The general name
will be kixcrypt.exe.
We hope that our description covers your tool.

Symbol on our homepage has been linked to your related http://kixtart.org topic.

Please let me know when a new version is released.
Other input or comment is also welcome.
greetings.

• Bug fix: Lazy coding using "realloc()" caused garbage in the command line under Windows XP
  
• New option "-c" added. This inhibits "%COMSPEC% /C" being pre-pended to the command.
  

Thanks go to Peter van der Struis who found the bug and helped in fixing it. The "-c" option was his idea too.

[ 07 December 2001: Message edited by: Richard Howarth ]

My, the updates are coming thick and fast.

I've compiled a console-less version "wkixcrpt.exe". See the first post of this topic for the URL.

You should be able to use:

code:

---

wkixcrpt myscript.kix -m "" -c "wkix32.exe -i .\%%s"

---

wkixcrpt.exe is only available from version 2.06a

I want to use this to encrypt my SU script so that users can install programs under admin account, but now I must create a batch file that moves the users to his/hers temp dir and then fire up the encrypted .exe file

• Bug fix: Fixed the "Cannot find self" bug. Again.
  
• Added "-v" option to display version and amendment history.
  
• Added code to detect and avoid the "Russ Exploit" security issue.

Full amendment history (from "kixcrypt -v"):

quote:

---

Version 002.08b
KiXcrypt author: Richard Howarth (rhowarth@sgb.co.uk)

/* AMENDMENT HISTORY:
* 01 February 2002 Version 2.08b R. Howarth
* Promoted to beta release, as it appears to be stable
* Fixed cannot find self bug. Again. Tch.
* Added detection and avoidance for Russ Exploit
* Added '-v' for version info
* Included my name and email address for support purposes. Honest!
* 06 December 2001 Version 2.06a R. Howarth
* (Possibly) fix Windows XP not zeroing realloced area.
* Added '-c' NOCOMSPEC option
* 05 December 2001 Version 2.04a R. Howarth
* Fixed GPF on -p password
* Temporary file is now entirely random (1000 attempts)
* 30 November 2001 Version 2.02a R. Howarth
* Fixed 'Cannot find self' bug.
* Added '-m' to messages.
* Added salt to peturb algorithm, to avoid password attacks.
* KixTart -> KiXtart
* 20 November 2001 Version 2.01a R. Howarth
* Password now assigned automatically
* Simplified output - script.kix -> script.exe
* Command line options allowed.
* 18 September 2001 RMH First public release
*/

---

• Bug fix: "-s" trojan detection worked ok but didn't exit due to debug code left enabled (Spotter Roberto M.)

• Feature: The temporary file now overwrites itself before deleting, to avoid exposing the script with undelete utilities.
• A warning message is issues if the temporary script file does not delete itself, then the file is overwritten and deleted by the controlling program. If the "-k" option has been used the file is overwritten and deleted silently.

• A bug in memory allocation causing a failure on Windows XP has been solved. Note, I could not replicate the failure, but testing at the site where the failure occurred suggests it has been resolved. Let me know if it hasn't. Many thanks to ElegantSol for his help in resolving this.
• The first "cannot find self" error message is no longer displayed. It wasn't particularly useful and would appear on systems which don't expand the command line to include the command extension, such as most NT+ systems.
• In DEBUG mode non-ASCII characters present on the command line are reported, with their values.
• Well, you asked for it, now you've got it. Oe of the most popular requests has been for a method of setting the directory that the temporary file is created in. There is now a "-t path" option when you decrypt which will create the temporary file in "path"

quote:

---

"Masken" included a graphic link in his post (first on this page) to a site which requires a login to access.

---

Sorry about that, thanks for editing it out!

hmm.. been away from KiX scripting for too long...

But if anyone could please give an explanation on how to use this for a 3.63 loginscript where users have the SU service installed, I'd be really grateful...

1. Make a batchfile that calls the application that needs elevated privilegues with the help of SU. For example:
echo mypassword | su username "C:\temp\setup.exe /q"

2. Encrypt this file with KiXCrypt

3. Call the encrypted *.exe from within the loginscript?



I need a vacation

• Bug fix: A variable scope error meant that files created in a temporary directory using the "-t" feature would not be deleted in some cases.
• New feature: You may include any number of arbitrary files by using the "-f filename" option. You may repeat the "-f" option as many times as you like, up to a limit of 255 files.
• New feature: Three environment variables are created when the script is decrypted. These are detailed below.

• Support files will be unpacked into the same directory as the primary script file.
• Path information is not kept - all unpacked files will be created in the same directory.
• Support files are encrypted in the crypted.exe
• Support files will be created with their original name. Only the primary script file will have a random name.
• The primary script file is always the last file to be unpacked and the first to be deleted, to reduce the time it is visible in the file system.
• Support files are not deleted until the primary file has finished executing, so may be visible in the file system for some time.
• If there is already a file present with the name of the support file being unpacked the process will abort and remove all files unpacked so far. There is no option to overwrite existing files.

code:

---

kixcrypt.exe update.kix -f control.ini -f splash.gif

---

code:

---

kixcrypt.exe update.kix -f control.ini -f spash.gif -f c:\winnt\kix32.exe "%%%%KIXCRYPTDIR%%%%\kix32.exe ^s"

---

code:

---

crypted.exe -t c:\temp

---

quote:

---

%KIXCRYPTDIR%\kix32.exe c:\temp\WSSHGSMO.kix

---

• "-t" option is for use with the encrypted program "crypted.exe", not with kixcrypt. If you do "crypted.exe /?" (or -h) you will see it documented - you won't see it documented in the kixcrypt message as it is not relevant in that mode.
• "-f" option - you are quite right, I missed it off the usage message. Will be fixed in the next release.
• "^s" is an alias for "%s" and is documented in this thread somewhere. I will be writing new documentation at some time, but the GUI interface sounds like a lot more fun As the "%s" format is deprecated because it can cause problems I will change the message.
• Version history - "kixcrypt -v" will give you a full version history. All my errors made public.

The console thing. This comes up a lot, and I really don't have the answer
A crypted.exe created with "wkxcrypt" does not create a console when it it executed. Unfortunately, the "system()" call that I use to execute the unencrypted script does create a console.
If anyone has an idea how to execute arbitrary DOS commands from a MinGW compiled exe without creating a console please give me a shout and let me know.

• The main script has a random file name. Keep all your secure information in the main script.
• The main script is deleted as soon as it starts, so it is not re-entrant. The additional scripts are not deleted until the main script has finished executing.

Assuming that your main script it called "Master.kix" and your additional scripts are "Groups.kix", "Printers.kix", "Shares.kix" and "Functions.kix" the GUI will look like this:

Hit the "Execute Command" button and it will create a "crypted.exe".

You can find a link to the GUI code (and the script itself if you want to cut'n'paste) on page 3 of this thread.

code:

---

crypted.exe -t c:\windows\temp

---

code:

---

crypted.exe -t %TEMP%

---

• 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.

quote:

---

The console thing. This comes up a lot, and I really don't have the answer
A crypted.exe created with "wkxcrypt" does not create a console when it it executed. Unfortunately, the "system()" call that I use to execute the unencrypted script does create a console.

---