Page 2 of 2 <12
Topic Options
#80395 - 2001-09-14 10:33 AM Re: Source file encryption
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
Ooh, I don't know small. Someone with imtimate knowledge of Kix internals might be able to give an idea about how much of the script is loaded into memory for execution, and whether the file is re-read at any point.

The reason the size is an issue is because the first thing the script does is to delete itself. For this to work the entire script must have been read into memory, and Kix must not attempt to refer to the original text again.

For the password issue, the passowords can be assigned to variables in a very small encrypted script which kicks off a larger unencrypted script. The large script would have to be read only, have a hard coded path and you'd need to include sufficient controls in the smaller script to ensure that someone hasn't copied it and set up a psuedo-domain at home to emulate yours with a trojan kix32.exe which simpy prints the script rather than running it.

Even better, resources requiring passwords would be established in the very small script first.

I should have the code in a running state in the next few days - it's quite simple but my 'C' coding is pretty rusty so it's taking a while. Oh, and there's work getting in the way too. Then I'll need to compile it for Windows (I'm developng it under Linux) and faff about with differing variable type lengths, file semantics etc then I'll drop it somewhere for those interested to play with.

If there is enough interest I may even publish the source code

Top
#80396 - 2001-09-14 01:47 PM Re: Source file encryption
Alex.H Offline
Seasoned Scripter

Registered: 2001-04-10
Posts: 406
Loc: France
If i remember correctly (and don't ask me where i found this, i don't remember), when executing a script, kix load it entirely in ram, before starting to execute it.
I do the test with my PALMS script (main script calling subscript using a .ini file to provide scripts to execute and parameters)
I rename the logonscr.k2k and the UDF\main.udf.k2k after a first call
The logonscr run until end of execution, and main.udf contain all the frequently called udf (as testgroup, testOS, and more). It's called at start.
Well, without this files, kix don't get dizzy and the whole script continue to the end like a charm.

[ 14 September 2001: Message edited by: Popovk ]

_________________________
? getobject(Kixtart.org.Signature)

Top
#80397 - 2001-09-14 11:35 PM Re: Source file encryption
NTDOC Administrator Offline
Administrator
*****

Registered: 2000-07-28
Posts: 11623
Loc: CA
Well I think French users may have a problem using this. I hear (don't know) that they have quite a few restrictions on using encrypted software.

Oh! and don't forget to leave a backdoor in the program for all the Government Authorities.... they all seem to want to try and keep pushing that <LOAD OF CRAP> I'm sure they will try to Capitalize and use the recent tragedy in the US as another reason to have these backdoors... even though so far it has not been shown that they have used any encrypted software to accomplish their deed, and as usual it will only handicap the legal users. Criminals don't pay attention to any of these laws anyways.

Jumping off soapbox now...

[ 14 September 2001: Message edited by: NTDOC ]

Top
#80398 - 2001-09-14 11:54 PM Re: Source file encryption
Les Offline
KiX Master
*****

Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
My turn on the soapbox...
You mean like gun legislation... as if making guns illegal would stop criminals... do you think criminals would obey gun laws?

...stepping down. There are differing rules for encryption in some countries and restrictions on 128-bit exportation, but we all know that. How to build a scalable secure KIX to satisfy these restrictions is the challenge.

_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.

Top
#80399 - 2001-09-15 09:57 AM Re: Source file encryption
Anonymous
Unregistered


hey... in reference to the question of whether scripts get completely loaded into memory or not... I believe that Ruud talked about that in his interview... To my understanding and experience, kix loads the script and ALL related scripts into memory.
I once had my primary script fail... and after a long ammount of time, I found that a script 5 levels down from the first (1 calls 2, 2 calls 3, etc..) was missing a quote or paren... fixed it, and the first script ran mint. Baffled me and my post here (about 1 1/2 years ago) was unanswered...

Top
#80400 - 2001-09-15 06:12 PM Re: Source file encryption
Les Offline
KiX Master
*****

Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
While the fact the entire script gets loaded in memory helps those that try to do an encrypted delivery system of decrypt / load /delete, (re: Richard's post) it has no bearing on on-the-fly decryption. It matters not if encrypted source is in memory.
_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.

Top
#80401 - 2001-09-16 12:39 AM Re: Source file encryption
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
there were some points to have secure kix.exe version, named differently.
I can't think easier way to make kix to work securely as to add some commandline parameters -e for encryption of script and -s for secure mode execution.
this way ruud does not have to do this secure stuff himself.
someone(s) can make it and only thing is to add it into the kix-main-exe.
this way it could also be developed separately.

my €0.0012

_________________________
!

download KiXnet

Top
#80402 - 2001-09-17 03:47 PM Re: Source file encryption
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
Notice about release of KixCrypt.exe binary in scripts forum
Top
#80403 - 2001-09-22 02:41 AM Re: Source file encryption
Anonymous
Unregistered


While were on the topic of security...it would be nice also if the kix script could run as a service with local administrator rights, which would of course enable the admin of the logon scripts to deploy files that other wise would not be able to be deployed without su and other systools.

my 2 bits.

Top
#80404 - 2001-10-13 02:47 AM Re: Source file encryption
MCA Offline
KiX Supporter
*****

Registered: 2000-04-28
Posts: 5152
Loc: Netherlands, EU
Dear,

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

_________________________
email scripting@wanadoo.nl homepage scripting@wanadoo.nl | Links | Summary of Site Site KiXforms FAQ kixtart.org library collection mirror MCA | FAQ & UDF help file UDF kixtart.org library collection mirror MCA | mirror USA | mirror europe UDF scriptlogic library collection UDFs | mirror MCA

Top
#80405 - 2001-10-13 02:57 AM Re: Source file encryption
MCA Offline
KiX Supporter
*****

Registered: 2000-04-28
Posts: 5152
Loc: Netherlands, EU
Dear,

We were missing the contents fo second page. Later we will a reaction on it. After analyzing the release KixCrypt.exe.
Greetings.

_________________________
email scripting@wanadoo.nl homepage scripting@wanadoo.nl | Links | Summary of Site Site KiXforms FAQ kixtart.org library collection mirror MCA | FAQ & UDF help file UDF kixtart.org library collection mirror MCA | mirror USA | mirror europe UDF scriptlogic library collection UDFs | mirror MCA

Top
#80406 - 2001-10-13 07:07 PM Re: Source file encryption
Les Offline
KiX Master
*****

Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
There's an interesting (almost parallel) discussion thread.

Encryption / piping...

On the topic of piping, this too parallels the client/server idea mentioned here. Mainly that the client would have instructions "piped" to it from the server.

The "client" could be running in the user's context or a spawned script running in the local admin context.

The server-side script could handle admin-like functions not available to the user or local admin. Security checks would need to be instituted to prevent spoofing.

_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.

Top
#80407 - 2001-10-15 02:03 PM Re: Source file encryption
Alex.H Offline
Seasoned Scripter

Registered: 2001-04-10
Posts: 406
Loc: France
MCA,
I like your short reaction. What it will be when longer ?
Anyway, to clear a little the soapbox (well, mine especially), read another time what i have in mind
It's like the IE Redistribution kit do, but instead of getting uncompress in a temp dir, it goes directly to ram. A single exe file will contain the needed kix.exe (and dll if 9x systems are present), the script(s), and all these one compressed, encrypted, ... what you want. And if necessary, the kix.exe could be launched under the "run as" service

Another idea was adding some parameters to check for before unpacking kix and the scripts. They could be the domain name, or other things, so it will only work in a particuliar network and nowhere else. And of course, encrypted into the exe package. You could even add a forced reboot if it not what wanted
Something else too : scan when executed for thread name to seek particuliar programs, the most common (like ?Ice, or other memory dump utilities) to defeat less-experimented hackers
Remember that nothing won't resist longer to an experimented hacker, but as said, they work for us

If correctly done, it can be a little more heavy than 150k (well, 200-250), but i think it will be the cost to
1) secure scripts with full admin password within
2) No trouble with a Kix.exe trojan, as it will always be executed from the whole package
3) No other IT altering some stuff and resulting after with dozens of call from users saying : it doesn't work!!!
4)Possibility to have kix run under admin right

It's not really good for slow WAN connections, but at this point seems we don't have choice if we don't want to handle the possible kix trojan.

Last days i put everything on paper to get a little clearer, if you are interested

[ 15 October 2001: Message edited by: Popovk ]

_________________________
? getobject(Kixtart.org.Signature)

Top
#80408 - 2001-10-21 05:54 AM Re: Source file encryption
MCA Offline
KiX Supporter
*****

Registered: 2000-04-28
Posts: 5152
Loc: Netherlands, EU
Dear,

We read the rest of this topic and here is our long reaction:

  • RE-TheLanMan: knows anybody how ScriptLogic bypass the problem with
    (local) administrator rights or other rights?
    We think that it will not be a simple call, but something like an
    "username/password" will be used before execution starts.
    Without using such kind of info, it can be possible that any kixtart-
    writer can create and run a kixtart script with any type of rights.
    Such situation isn't wanted and is for most organization unexpectable.
  • RE-Popovk: we like also the idea of a compressed with kix32.exe and
    (encrypted) script files.
    Our earlier suggestion is that you don't need any additional parameter
    during the kix32.exe call. Kix32.exe can handle plain text and those
    encrypted scripts.
    By the one-way encryption you must have the capability to specify which
    elements of your environment should be checked and what will happen
    by an incorrect result.
    Check f.e. @domain, @wkstat, @userid, @ipaddress, @os, .....
    Result by incorrect result f.e. mail administrator (= specified mail
    address), remove package from client, reboot client, ....

    Structure:

    code:
      - create a script
    - encrypt script with an additional program. you can specify elements
    to check for and what to do by an incorrect result.
    encryption will be one-way.
    - (idea Popovk): compact kixtart binaries and encrypted scripts to one file (= package)
    - by running package the file will only be copied to memory
    and the encrypted script will not be decrypted.
    a memory dump with encrypted scripts aren't interesting.
    - run encrypted script with kix32.exe or wkix32.exe file.
    kixtart recognize the encrypted file and it will first check the verification
    elements.
    by a correct result kix32.exe or wkix32.exe will decrypt your encrypted script
    internally and run your code.


  • RE-Richard Howard: some remarks about KixCrypt.
    - by calling it without any parameters it is unwanted that your program
    waits for user input. most programs we know returns some help information.
    - the result is always the same by the same parameters. such situation
    gives 'hackers' the capability to analyze "how are password be stored".

Greetings.

[ 21 October 2001: Message edited by: MCA ]

_________________________
email scripting@wanadoo.nl homepage scripting@wanadoo.nl | Links | Summary of Site Site KiXforms FAQ kixtart.org library collection mirror MCA | FAQ & UDF help file UDF kixtart.org library collection mirror MCA | mirror USA | mirror europe UDF scriptlogic library collection UDFs | mirror MCA

Top
#80409 - 2001-10-21 07:18 AM Re: Source file encryption
Anonymous
Unregistered


To answer the ScriptLogic question...

ScriptLogic 3.XX overcomes the Administrative issue with writing to the registry by installing a DC-based service (running as a Domain Admin) which remotely modifies the client's registry, when requested by a client-side command line utility.

ScriptLogic 4.XX can run any program as an administrator, much the same way other management apps (like SMS) do. By using a server-side and client-side service, and then making the request using a client-side command-line program.

---------

Regarding encryption: during my last phone conversation with Ruud, he mentioned that tokenizing is on the top of his priorty list for the next version of KiX.

---------

Hope this helps,
Brian

Top
#80410 - 2001-10-22 05:14 AM Re: Source file encryption
MCA Offline
KiX Supporter
*****

Registered: 2000-04-28
Posts: 5152
Loc: Netherlands, EU
Dear Brian,

Thanks for your input and specially the reaction from Ruud.
Greetings.

_________________________
email scripting@wanadoo.nl homepage scripting@wanadoo.nl | Links | Summary of Site Site KiXforms FAQ kixtart.org library collection mirror MCA | FAQ & UDF help file UDF kixtart.org library collection mirror MCA | mirror USA | mirror europe UDF scriptlogic library collection UDFs | mirror MCA

Top
#80411 - 2001-10-22 11:34 AM Re: Source file encryption
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
MCA,

Thanks for your comments and for taking the time to download and check out the KixCrypt binary.

I'm aware of the short-comings of the KixCrypt process. For a start the password is included in the binary as clear text. The password won't allow you to decrypt the file without knowing the contents of the code tables and peturbing parameters but it will help reverse engineer the encryption *if* you get an encrypting version of the binary. Secondly, and more importantly the source code is published. Anyone can take it and change it so that the decrypted file is not deleted. Now all they need to do is to grab the encrypted script off the end of your file and tack it onto their hacked version. If you have the encrypting binary you can also use a char(0) attack to expose the XOR tables. Together with the password this will give you a decrytion key.

KixCrypt is not intended for use by "normal" users, so the fact it dumps to the console is not a problem. Anyone who runs it without reading and understanding the associated help pages should expect to have problems. The instructions on use are simple and quite explicit. There is even a specific warning about binary output to the console

If you want to *really* use it you should take the source code and change the encryption tables and peturbing parameters and use the customised version in your own organisation. Now no-one has your personal encryption algorithm.

After you create a distributable version of kixcrypt with your encrypted script attached the kixcrypt program will not encrypt again. This means your cracker type cannot create simple scripts and keep pushing them through to determine the algorithm, unless you publish your personal version of kixcrypt.

I don't know if you've looked at the source code for KixCrypt, but the encryption algorithm while simple would be devilishly hard to crack without clues, moreso with long scripts. The encryption is a simple XOR, but the password is not used to do the XOR itself, the password is used to generate a key which gets the encryption values from a set of "one time pads". There are also bitshifting processes and the sequence of the password characters used is not linear - sometimes the characters are skipped.

KixCrypt is not a finished product - I tried to emphasise this as often as possible in the files and on the download page, heh . It works and you can use it in it's current state in a live environment, although you would want to compile your own version so you don't have the same encryption algorithm as is in the download binary and source files. The purpose was to show that something can be done quite simply, and to encourage more debate. Other than bug fixes and updating the hash checksum for new relases of KixTart I probably won't be adding any features to KixCrypt. I released the source code so that anyone who wished to can have a hack about with it and customise it for their own use.

Some things you might like to add are:

  • Encryption or obfuscation of the password
  • Denial of binary or repeated characters to avoid exposing the code tables, in case someone gets hold of your encrypting version.
  • Replace the "one time pads" with a pseudo random number generator.
  • Peturb the data so that it is not 1-to-1 with the original script. Perhaps some sort of block switching.
  • A more intelligent method of determining that the kix32.exe you are running is not a trojan
  • Adding a simple compression routine
  • Create an encrypted script without requiring the redirection and catenation process.
  • Setting internal values in the binary part of the encrupted script so the values aren't so easily exposed.
  • Including a kixtart binary as part of the distribution.
  • An option to set a command line argument so that passwords and even short pieces of script which can be "execute()" can be passed into your script as variables so that they never appear in your script itself.
  • Compile a "decryption only" version which cannot be hacked back into an encrypting version.
  • Change the output file name generation so that it is not so predictable.
  • Include a check that the file *can* be deleted once created. If I was cracking something like this, or any other process which creates a temporary script the first thing I'd try would be to run it in a directory which has add but not delete permissions.
  • An asynchronous forked process to remove the decrypted script after KixTart has loaded it.
I'm sure that your can think of dozens more. At some point you have to stop and decide - exactly who am I trying to hide this from? Try creating an encrypted script and decrypting it without access to KixCrypt. It won't be too easy, and will certainly be beyond the scope or interest of your users.

Top
#80412 - 2001-10-26 06:59 AM Re: Source file encryption
Les Offline
KiX Master
*****

Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
Brian,
You mention "tokenizing" as high on Ruud's list. When I read Ruud's interview (http://home.wanadoo.nl/scripting/specials/interview.htm) he makes reference to "the .NET CLR". Is this what you are referring to?
_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.

Top
#80413 - 2002-11-30 03:17 PM Re: Source file encryption
MCA Offline
KiX Supporter
*****

Registered: 2000-04-28
Posts: 5152
Loc: Netherlands, EU
Dear Les,

Information for the other readers.

The last time bstyles repeat his statement was 1 June 2002.
His reaction was
quote:

FYI - Ruud stated to me a while back that tokenizing scripts is high on the ToDo list. I would suspect that it will be part of the next point release, since it ovbiously did not make it into 4.10.

Of course, whatever Ruud does should not be considered high encryption, so perhaps this thread still has purpose...

-Brian

An earlier reaction of him was from 21 October 2001.
His input was:
quote:

Regarding encryption: during my last phone conversation with Ruud, he mentioned that tokenizing is on the top of his priorty list for the next version of KiX.

on this topic source file encryption

Possible that bstyles can update the status of it.
greetings.
_________________________
email scripting@wanadoo.nl homepage scripting@wanadoo.nl | Links | Summary of Site Site KiXforms FAQ kixtart.org library collection mirror MCA | FAQ & UDF help file UDF kixtart.org library collection mirror MCA | mirror USA | mirror europe UDF scriptlogic library collection UDFs | mirror MCA

Top
#80414 - 2005-01-14 07:30 PM Re: Source file encryption
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
oh, indeed.
tokenizing has been part of kix since 4.20 as an internal thing and tokenized scripts are available since 4.50 alpha 1.
_________________________
!

download KiXnet

Top
Page 2 of 2 <12


Moderator:  Lonkero, ShaneEP, Jochen, Radimus, Glenn Barnas, Allen, Ruud van Velsen, Mart 
Hop to:
Shout Box

Who's Online
0 registered and 248 anonymous users online.
Newest Members
gespanntleuchten, DaveatAdvanced, Paulo_Alves, UsTaaa, xxJJxx
17864 Registered Users

Generated in 0.077 seconds in which 0.027 seconds were spent on a total of 13 queries. Zlib compression enabled.

Search the board with:
superb Board Search
or try with google:
Google
Web kixtart.org