• 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