|
|
|||||||
A couple of observations... There is no option to specify the resultant filename or extension which defaults to .KX and then .KX is not searched for and run like .KiX is. One must rename it after tokenizing if wanting the search to work. Any thought of adding .KX to the list of extensions searched? When running the tokenized version, there is no possibility of running it in debug mode. Is this by design? I realize that with DEBUG ON the script would no longer be obfuscated and understand why the /D option is disabled, but should the in-line DEBUG ON also be disabled? Some people embed DEBUG ON in conditionals which will no longer work. 'Suggestions' might be a better place to discuss this but while I'm here... perhaps adding a password option for DEBUG. Is there going to be an option to reverse the tokenization, that is to return it to text format? I presume all the comments and indenting would be lost... well the commenting anyway, maybe the indenting could be made more consistent. |
||||||||
|
|
|||||||
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... |
||||||||
|
|
|||||||
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 |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
I'd also drop the .SCR extension and give priority for the .KX over the .KIX extension. De-tokenization is not important to me but it would be nice if there would be a detokenizer. This would keep KiXtart an open system as people would not be able to distribute UDFs in a tokenized way without others being able to see the source code. |
||||||||
|
|
|||||||
where can i get my hands on the 4.5 alpha? It seems that my email/domain went down for about a week or so... did Ruud email it out like usual? Bryce |
||||||||
|
|
|||||||
Yes, he did. |
||||||||
|
|
|||||||
don't feel bad... I didn't get it either :-( |
||||||||
|
|
|||||||
you got mail |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
Hmm, great, no ability to un-tokenize a script. Let me just write a little UDF that is really helpful with a small side effect of destroying the computer it is run on via a timebomb. Easy to make and impossible to detect with a tokenized script/UDF. The end-result is that you cannot trust tokenized scripts that have not been tokenized by yourself as you have no way of verifying the content, functionality, and integrity of the script. Just think of an employee making a little change to the login script right before he's been shown the door. It's not such a far-fetched idea as is already happened in real-life. Anyway, I'd prefer if there would be a way to untokenize the script. |
||||||||
|
|
|||||||
I would rather not have a way to un-tokenize. |
||||||||
|
|
|||||||
I knew this could be a contentious issue between the right to know versus the right to protect intellectual property. If you can de-tokenize, you no longer have obfuscation, which has been a long-standing request. I guess one has to ask what the main intent was for tokenization, performance or obfuscation. Since Ruud does tokenization in 4.22 and obfuscation in 4.5 alpha, I have to assume obfuscation. When it comes to blind faith, we have plenty of it when we download and use compiled programs that are freeware, shareware, or commercial. That is the risk we take when doing so. There is always the possibility of an unwelcome going away gift, and that risk must be mitigated through policy and monitoring. There is nobody forcing you to use obfuscated scripts. |
||||||||
|
|
|||||||
To assume that no one will write a method of their own sooner or later to dechipher the code back to an original readable format is in my opinion to attempt to hide from reality. If you're on a ship that just hit something that ripped a large hole in it and was now sinking and the Captain and Crew are now asking you to man life boats and you just hide in your stateroom pretending it is not happening, is about the same type of mentality as I see it. Also similar reasons that Jens has stated. 1. You write a cool logon script and it is working great then you accidentally drop the original readable version into a file shredder program along with some other files. Now you no longer have the original and have to start all over from scratch. Or some other Admin deletes that original accidentally as you Company mandates that all shared code is kept on one location. What ever the case, this is just an idea to get a point accross. 2. One of your Admins is laid off or let go but is now PISSED OFF and leaves a time-bomb like a script that schedules a task on all systems desktop and server that now on a certain day and time deletes every thing it can in the registry and overwrites all files it can with 0-byte size files. I don't care how nice of an organized shop you run, IF something like that were to happen it would take a LONG time to recover from the damage inflicted. However, if the code was in readable format it would be much harder to hide such an act. 3. You are hired on at a new Company and the VP says he really LOVES the script the last guy wrote and all it working great just the way they want it, but he wants to add just a couple little items to the original. Well, without the original or without being able to restore to readable format your kind of stuck. Perhaps allowing something like during setup of the program it is "signed" or pass-phrase etc first before the EXE can be used. Then only Admins with this pass-phrase can decipher the tokenized code. Then if an Admin is let go, the process can re-code a new EXE and replace the file on the Servers so that that Admin won't know the new pass-phrase. I myself don't view this as a "SECURITY TOOL" so much as I see it as an added measure of protection to prevent non admins from knowing what is going on in the script if wanted. Just because KiX will now support Obfuscation does not mean all Companies will use it either. It also may be possible that in some Countries it "might" be illegal to support Obfuscation without a means to restore the original source. Possibly opening a means of litigation against Ruud. (not that they would have any legal recourse against him, but something to ponder I guess) I'm sure this is a subject that as with most other subjects that not EVERYONE will agree with each other. Regardless of what or how Ruud moves forward with supporting this hopefully no one runs into any real problems with it in the future. |
||||||||
|
|
|||||||
However, the main question is, whether tokenization the way Ruud implements it is actually reversible in such a way that the original script is more or less recreated. It might not even necessarily be a one-to-one recreation of the original script down to the variable names or comment fields. |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
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 |
||||||||
|
|
|||||||
I dont see any reason yet that would convince me to want to be able to un-tokenize a script. All the problems that are being pointed out would still exist if tokenized was not in the picture at all. If your login scripts accidentally get deleted and there are no tokenized scripts you are still in the same boat arent you? I dont think the purpose for the tokenized scripts are in any way a means of backup. And I would hope that any scripts or scheduled tasks that suddenly and mysteriously appeared on servers/clients around the same time an angry ex-employee leaves would be removed whether you were able to read them or not. I would only opt for the de-tokenizing if there was some kind of unique password protection or something like that. The whole point of it for me would be so that other admins/users couldn't get in there and "improve" login scripts that they did not write. None of our scripts are so big that the comporession aspect plays a big role. Its mostly the obfuscation that Im looking forward to. And if anyone simply has to find the correct command line switch to convert it back to clear text then I dont see any point in the obfuscation to begin with. Just my 2 cents on the subject. |
||||||||
|
|
|||||||
Quote: Variable names must be maintained. Consider two scenarios where tokenising the variable name will fail:
|
||||||||
|
|
|||||||
rich, nope... have to disagree on that one. example tokenization of: $foo="bar" $bar="test" $=Execute('"The value of $$$$'+$foo+' is "+$$'+$foo+' ?') should lead to something like: $1="bar" $2="test" $3=Execute('"The value of $$$$'+$1+' is "+$$'+$1+' ?') what comes to called scripts, if they are to share same namespace, they will have same names. if they are executed via run or shell, their namespace is own and then it does have no effect. know this from my expirements with kixtart-compressor. |
||||||||
|
|
|||||||
Quote: Lonk, look again at the example and you will see why tokenising variables names is a problem. I'll bet you didn't try to execute your sample tokenised code, did you? The tokenised code returns: Code: The value of $bar is When of course the script should be returning: Code: The value of $bar is test |
||||||||
|
|
|||||||
Quote: No, when it comes to tokenised names that is not correct. Ok, consider two very simple scripts: S1.KIX Code: Global $sApple, $sOrange S2.KIX Code: Global $sPear, $sOrange, $sApple Run these and you get what you'd expect: Quote: Now, tokenise the variables: S1.KIX Code: Global $1, $2 S2.KIX Code: Global $1, $2, $3 Now when you run the scripts, you will get an incorrect result: Quote: These are contrived examples, but you can easily see why variable names must be preserved in tokenised code. |
||||||||
|
|
|||||||
k, now I get what you mean. but what I'm after would not allow this. if script is to be tokenized, either it's called subs are included (ey, we still don't have include statement in kix) or they are tokenized too. and once got here, we need to get include in keywords if call is not gonna handle that. |
||||||||
|
|
|||||||
think I need to give example, of both ways in my head. using your initial scripts. btw, isn't there double declaration in your script? so much time when I last coded... can't remember how these go now, if tokenizing and having call and ruud makes call work as include, results is like: Code: Global $1, $2 when not using include, the result might be: S1.kx Code: ] Global $1, $2 s2.kx Code:
anyway, looking at your code's var declarations, it seems that it shouldn't work anyways... |
||||||||
|
|
|||||||
Quote: The code has to be monolithic - individually tokenised scripts will have the same problem. If all subscripts are included in-line before tokenisation and you never need to expand variable names (variable-variables, indirection, Execute statements) then you could probably tokenise variable names, although I might have missed something. I knew there was something else nagging me - the following will not work with tokenised variable names: Code: kix32.exe $sMyDomain="ACME" tokenised.kx IMO the loss of these and other features far outweighs the very minor gains that tokenising variable names would give. Perhaps tokenisation of variables names could be a tokeniser option for hardcore golfers Reducing variable names to single character can be handled by a pre-parser, if that is all that is required. |
||||||||
|
|
|||||||
the commandline var input is pretty outdated already. now we got one more reason to get rid of it. if we finally would get our hands to the full commandline via macro or so, this would be no problem and we could FINALLY introduce more "standard" switches in there with slashes and all. anyway, indeed the difference is not huge but lets take as an example a simple compiler. there you can choose a optimization of speed, size etc... here both of above would be gained and nothing really lost. |
||||||||
|
|
|||||||
I am against tokenizing variables, too. Dynamically created variables are also used in KiXforms GUIs in addition to heavy use of EXECUTE(). KiXforms scripts should be tokenizable as well. |
||||||||
|
|
|||||||
Quote: OK, will admit it was a bit of a brain fart. Did not think it through. Still, have to wonder (BF Alert) if Execute() could be pre-parsed for var names. |
||||||||
|
|
|||||||
Quote: The quick answer is "no". The long answer is that Execute() statements have to be parsed at run-time. You cannot substantiate a variable until it has a value, and it does not have a value unless the code is executing. In the case of the example I gave the value of the (indirectly referenced) variable is constant as it is a very simple example. In a more complex example the variable name may be constantly changing. |
||||||||
|
|
|||||||
k, nice observation for you all. I just tokenized my first script. in my own handwriting the size was amazing 4,30K when tokenized, the size came to 4,66K! now, talk about down-sizing. I bet that this thing is gonna make all my scripts lot bigger. |
||||||||
|
|
|||||||
First sorry for deviating from the main subject. I am a user of the KiXtart version 4.22, I want to test and use KiXtart that supports the tokenizing functionality. Can anyone point me to the place where I can get the build that supports this feature? Or do I have to mail anybody in obtaining it? Thanks for your help, Bala |
||||||||
|
|
|||||||
Hello Balu and welcome to the board. At this time I don't think you can get it. Ruud asked that we not post or host it. I do think that he will be releasing a public beta in the near future. I recieved email from him a couple of weeks ago and he is very busy at his normal job. supporting includes in this new version is proving to be a little more difficult for supporting the debug information, but hopefully it won't be too long before we see an update. Keep an eye on on the board. |
||||||||
|
|
|||||||
If you would like to test the latest Alpha build, please send me a direct email. Kind regards, Ruud |
||||||||
|
|
|||||||
Just to let all of you know that I've sent out a second Alpha release of KiXtart 4.50. Depending on the feedback on this release, a public beta will be available in May/June. Kind regards, Ruud |
||||||||
|
|
|||||||
KiXtart 2010 ??? Very Clever, no more worries for the next 6 years |
||||||||
|
|
|||||||
I'm sure you can guess what the next version will be called.... |
||||||||
|
|
|||||||
ummm, KiXtart 2061, right ? |
||||||||
|
|
|||||||
So, where's the secret HAL easter egg? Can't find anything. Even using HAL or HAL2000 doesn't produce anything inside the script. |
||||||||
|
|
|||||||
I'm still scratching my head over this 2010 thingy ... saw the movie and know about the HAL thingy but is that really the thingy ? |
||||||||
|
|
|||||||
KiXtart Odyssey |
||||||||
|
|
|||||||
Yeah, I was thinking 2061, but keep the suggestions coming ;-) |
||||||||
|
|
|||||||
I still think the REAL version numba should be only number in the naming. so instead of anything kixtart 20xx call it kixtart. |
||||||||
|
|
|||||||
Quote: I'll second that. Could anyone mail me the latest build to me. Got some free time now since W2k migration has finished. |
||||||||
|
|
|||||||
Hi Ruud, I am dying to view the latest build, would you please send it to me? I would very much appreciate it! Richard.Mallesch@csiro.au |
||||||||
|
|
|||||||
Does anyone know what the status of a 4.50 public beta is? I notice that May/June was the expected beta release but no sign yet. Sounds like it would sort alot of my issues with sizes of scripts and possibly the security as well. Rory |
||||||||
|
|
|||||||
just made a query towards ruud. been quite silent lately. |
||||||||
|
|
|||||||
Thanks. If the beta is a long way off do you think there is any chance of a copy of the 4.5 alpha. Rory |
||||||||
|
|
|||||||
You would have to sign up with Ruud for the alpha. Send him an email. |
||||||||
|
|
|||||||
just remember that even though you get it, it's not for use in production. |
||||||||
|
|
|||||||
Can someone send me his email address via private message then? Rory |
||||||||
|
|
|||||||
it's in the manual. |
||||||||
|
|
|||||||
Hi Rory, his email address is in the KiXtart manual. ruudv AT microsoft.com |
||||||||
|
|
|||||||
Thanks guy I have just emailed my request to him. Rory |
||||||||
|
|
|||||||
His contact email is in the KiXtart Manual, IIRC. |
||||||||
|
|
|||||||
I guess you didn't read the above posts Jens. |
||||||||
|
|
|||||||
Actually, I didn't because I answered to the original post which was ont he previous page, thus didn't realize there was another page coming. Hapens when you try to answer posts late at night. |
||||||||
|
|
|||||||
wonder what pages you are talking about... |
||||||||
|
|
|||||||
The 50 posts in this thread that are on the first page. I'm norally limiting the threadview to 50 posts. |
||||||||
|
|
|||||||
57 replies, the first answer is in the 49th reply and the question is in 48th reply... am I missing something else too? |
||||||||
|
|
|||||||
Yes, my 16-hour workdays for the last couple of weeks (straight, no weekends off) ;-) |