A short reaction on this soapbox.

• RE-LLigetfa: decrypt in batch that a memory dump would defeat it.
  - people who analyze memory dumps aren't normal users. kacking of any
  program is always possible. TIP: only not existing programs are secure.
  Richard Howarth calls it: a sophisticated user.
  Popovk tals about: You have users, not hackers.
  - it is true to create a high encruption to reduce possible
  attacks, but it is also important that a decryption doesn't cost
  too much time.
  
• RE-GCrumply: passing passwords to scripts as command line arguments
  This isn't necessary. We have think about some modifications to our
  tool codec.exe, which will personalize your CODEC version.
  Suggestion 1:
  By such a personalizing we think about f.e. domain-name or other
  unique element of your environment.
  During the encryption with this personalized version and YOUR password
  a file will be created, which can only decrypt with CODEC when the
  environment is correct. Reason: environment characteristics and password
  will be inserted as scramble information on random locations in your
  encrypted file and the general version of CODEC recognized this additio-
  nal information. So you can keep your personalized version secure.
  Benefit
  

  code:

  ---

  
  copy such encrypted file isn't interesting because such script can't never
  be decrypted in another environment.
  

  ---

  
  Possible problem is by using of kixtart call command (see later
  for a suggestion about the possibility of reading plain text scripts or
  one-way encrypted scripts by kix32.exe).
  
• RE-CJ: used passwords that do not look like passwords
  Such way of thinking we like, but by the usage of username + passwords in
  f.e. BAT file we encrypt it with BAT2EXEC + SECURE21 andin f.e. kix-scripts
  we do it with CODEC + Compress.
  
• RE-Richard Howarth: generates a self decrypting executable
  - you can use any location for your temporary decrypt scripts. It isn't
  necessary to use the %temp% location.
  Suggestion 2:
  create a BAT file which decrypts your script and runs script by
  kix32.exe. the location of source and destination are possible
  unexpected location on your server and clients.
  with BAT2EXEC + SECURE21 we make those information secure.
  See topic:
  http://kixtart.org/cgi-bin/ultimatebb.cgi?ubb=get_topic&f=1&t=002750 how to make your script secure
  - In another topic we mention a possible SECURITY LEAK for kix32.exe
  Problem: how can an user steel your script.
  Simple: when an user can replace the kix32.exe file. it is easily to
  read the script file and write it to a floppy-disk. the input for kix32.exe
  will never be an encrypted file. it is plain text.
  Most user can have problems with a script file with very very long lines.
  Special tricks must be done to read in such cases all lines.
  Also it is easily to catch parameters which were added by the kix32.exe
  call.
  Suggestion 3:
  A self decrypting executable with kix32.exe and script included
  can be a good solution.
  Popovk talks about: it would be completly independant (an EXE file
  created by a builder which combine kix32.exe and specified script file[/i]
  See topic
  http://kixtart.org/cgi-bin/ultimatebb.cgi?ubb=get_topic&f=1&t=002053 security leak
  
• RE-Shawn: MCA mentioned that VBScript (WSH) has an encryption feature.
  Indeed it was a topic, but we discover that it doesn't its work very well and
  also the way of encryption is very poor.
  Also in a topic we warn that such encrypted file can be hacked easily.
  For us is the way of encryption/decryption by VBScript not an acceptable
  result.
  
• RE-Richard Howarth: a trojan KIX32.EXE which simpy prints the script rather than running it.
  Suggestion 4:
  

  code:

  ---

  
  encrypt your scripts with an additional program (one-way)
  and
  make it possible that kix32.exe can handle plain text scripts or an encrypted scripts.
  possible kixtart CALL commands can also handle both script files.
  temporary files are not necessary by such method.
  

  ---

  
  Benefit: for a torjan KIX32.EXE is an one-way encryption not interesting.
  Only the released KIX32.EXE program can decrypt your encrypted file and he
  isn't using any temporary file at all.
  

We hope that above suggestions and reactions give Ruud more ideas.
Greetings.

See also topic
http://kixtart.org/cgi-bin/ultimatebb.cgi?ubb=get_topic&f=4&t=000093 one-way encryption