#110849 - 2003-12-27 01:40 AM
Re: 4.5 alpha
|
Howard Bullock
KiX Supporter
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
|
The tokenized version of my logon script code turned out to be half the size of the original non-tokenized scripts.
Just begining to test...
|
Top
|
|
|
|
#110850 - 2003-12-29 08:42 AM
Re: 4.5 alpha
|
Anonymous
Anonymous
Unregistered
|
Excellent observations! I'll consider adding an option to specify the resultant filename.
As for adding ".KX" to the auto-search list: I considered this and did not add this as it adds yet another network roundtrip to the startup time of KiXtart. Any thoughts on this are welcome (Maybe I can drop ".SCR" from the auto-search list? Also, if I add ".KX", should it be first in the list?)
As for debugging a KX-file: this is disabled on purpose. Without the source, all KiXtart has is the tokenized stream, and the current implementation of debugging does not deal with that.
Lastly, on 'de-tokenizing': any thoughts on this are appreciated. It's certainly possible, and it probably will only be a matter of time before someone does it. The question is whether I should provide it from day 1.
Ruud
|
Top
|
|
|
|
#110851 - 2003-12-29 08:03 PM
Re: 4.5 alpha
|
Les
KiX Master
Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
|
Ruud, I do not have a clear understanding of how KiX searches for the script. The manual says that \Netlogon is searched first, the location where KiX32 started from second, and the current directory third. If it makes its rounds of these locations for each extension before trying another extension then yes, it would add significant delay but if it searched on all possible extensions at each location, I believe the delay could be less if a match is found. Maybe you could provide a search order switch as you do for the RPC.
As for the .SCR extension, I am all for dropping it, since that one is already associated with screensavers. None the less, it is bound to break some implementations.
A primary reason to pre-tokenize might be for speed and bandwidth so putting .KX ahead of .KiX makes sense since it would have a slight leg up on speed and traffic.
As for the debugging, I wasn't sure if you were de-tokenizing in 4.22 while debugging, if you kept both the clear text and tokenized in memory, or if you tokenized line-by line while in debug mode. Some of the challenges that you would face with error reporting if you INCLUDE or MAKE several files into one .KX file, would be the same with in-line debugging. Namely, that you need to represent in clear text, the line and/or line number.
Lastly, a de-tokenizer utility is something that someone may build anyway through reverse engineering. If the intent is to obfuscate the code, the de-tokenizer would make quick work of exposing it which, contrary to Martha, would not be a good thing. If you made available a de-tokenizer, there would have to be some sort of encryption/decryption key to maintain obfuscation. The question is would the benefit of a de-tokenizer outweigh the reduced complexity of cracking the key versus having to crack the built-in key AND tokenization algorithm? Since presumably, the key would have to be embedded in the script, it may also make it easier to crack.
_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.
|
Top
|
|
|
|
#110855 - 2003-12-30 04:51 PM
Re: 4.5 alpha
|
Radimus
Moderator
Registered: 2000-01-06
Posts: 5187
Loc: Tampa, FL
|
don't feel bad... I didn't get it either
:-(
|
Top
|
|
|
|
#110857 - 2003-12-31 07:58 PM
Re: 4.5 alpha
|
MCA
KiX Supporter
Registered: 2000-04-28
Posts: 5152
Loc: Netherlands, EU
|
Dear,
Some testings show us - overall the tokenized scripts are shorter - debugging mode not possible. our alternative with kixstrip still works in a proper way. - error messages generated by kix32/wkix32 are the same for both versions. First impression shows no problems with it. All our scripts work in a proper way. Second impression: a very good extension to kixtart to get more secure scripts.
Our suggestions: - don't introduce a backdoor to recreate original source. - for people who want something like a backdoor we suggest that they should tokenize their scripts with a password. only by specifying this password someone can recreate his source.
greetings.
|
Top
|
|
|
|
#110863 - 2004-01-02 04:49 AM
Re: 4.5 alpha
|
Les
KiX Master
Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
|
Since Ruud holds the secret to how the tokenizing works, he is the best one to answer just how much of the original would be restored. I have run some experiments to see if the var names are tokenized or not. I thought they too would have been tokenized to really optimize the code but if I use longer var names, the tokenized file is larger. I think var names should also be converted to tokens for best performance.
Comments seem to not make it through the tokenization since changing the amount of comments does not change the resultant file size.
I can see where some companies may try to ban the use of KiX if we have obfuscation without reversal. Very often, it is not mainstream programmers that code scripts but rather sysadmins. I work for divisional IT and constantly run into red tape by corporate IT that wants DivIT to be nothing more than PC monkeys yet CorpIT cannot provide the level of service that my users need. There are a lot of companies that ban KiX because it is viewed as ShareWare without full support. Add to that, the argument that sysadmins, who may not follow rigid procedures of version and change control with the potential to build obfuscated code and not protect the source, will have the potential to create a vast legacy of unsupportable scripts.
There are a lot of people that are pinning their hopes on obfuscation being a panacea of encryption to not only protect their code as proprietary, but also as a secure(?) way to delegate admin rights through their scripts. It is not now and probably will never be truly secure, at least not as long as it runs in the security context of the user.
If the emphasis is more on simple obfuscation, Brian's suggestion to use compression after the tokenization might suffice. Still, it is a matter of time before someone cracks either the simple or the more complex obfuscation and then publishes it on the web.
I just can't think of how one can have obfuscation and the guaranteed ability to reverse it to clear text without a backdoor password that would soon enough be in the public domain. About the only thing I can think of is to embed the domain name and SID in the script and to only allow a Domain Admin to use the backdoor password. While the domain name could be duplicated, the SID would not be the same.
Edited by Les (2004-01-02 04:51 AM)
_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.
|
Top
|
|
|
|
#110864 - 2004-01-02 05:35 AM
Re: 4.5 alpha
|
Radimus
Moderator
Registered: 2000-01-06
Posts: 5187
Loc: Tampa, FL
|
Here is my 2 cents...
Since it would seem to be impossible (or just really difficult) to encrypt the tokenized file for the really hard core security guys, don't try.. save that for a compiler version
I don't know how much detail Ruud put into the tokenizer routine... but he makes enough efforts to call it a tokenizer, and not a compiler
If possible, make a detokenizer for reading a tokenized file. Stripped comments are fine, varibles names aren't that big of a deal (find/replace)
However, Ruud is not resposible if your shop loses your source code... that is your problem.
I really like the make-exe concept
|
Top
|
|
|
|
#110866 - 2004-01-05 11:39 AM
Re: 4.5 alpha
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
Quote:
I have run some experiments to see if the var names are tokenized or not. I thought they too would have been tokenized to really optimize the code but if I use longer var names, the tokenized file is larger. I think var names should also be converted to tokens for best performance.
Variable names must be maintained.
Consider two scenarios where tokenising the variable name will fail:
- When calling an external script.
Variables which are shared between the scripts are unlikely to have the same "tokenised" names so data cannot be passed. Worse, unrelated variables are likely to have the same tokenised names, so will be passed/overwritten accidentally.
- Executed code.
Consider this somewhat contrived example: Code:
$foo="bar" $bar="test" $=Execute('"The value of $$$$'+$foo+' is "+$$'+$foo+' ?')
This will never work if the variable names are tokenised.
|
Top
|
|
|
|
Moderator: ShaneEP, Arend_, Jochen, Radimus, Glenn Barnas, Allen, Ruud van Velsen, Mart
|
0 registered
and 557 anonymous users online.
|
|
|