#128985 - 2004-11-04 03:22 AM
Detokenize as an option in new version
|
ciper
Fresh Scripter
Registered: 2004-11-03
Posts: 36
|
When using kix32 with the /t argument to create a tokenized script an additional argument should be available to enable/disable extraction of the original script.
In other words, make it possible to create a file that cannot be extracted if thats needed (to hide contents) or a file that can be extracted at a later time (for faster/smaller scripts without a concern for hiding content)
|
|
Top
|
|
|
|
#128992 - 2004-11-04 02:36 PM
Re: Detokenize as an option in new version
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
Quote:
Sure ... didn't meant that as an argument pro reverse engineering. Just tried to think out loud on possible reasons.
IMO this option should never make it to the release. Sorry if you misunderstood
Not at all. I understand entirely. It was the only thing I could think of as well and (as we agree) it's a misuse.
I was just waiting for someone to suggest it so I could jump on it 
|
|
Top
|
|
|
|
|
#128993 - 2004-11-04 10:25 PM
Re: Detokenize as an option in new version
|
ciper
Fresh Scripter
Registered: 2004-11-03
Posts: 36
|
It would help when you need to sit at the machine not working properly and you want to debug the script. If I want to run the script manually and step through the commands using the debugger how will this work with a tokenized file?
Sounds like many of you suggest using an archived copy (which should be the same as on the system but you cant be entirely sure) and running it on the machine in detokenized format. That means either the script must be modified to run from the users system (instead of the shared location it was originally on) or I have to store the detokenized version on the central location and point the machine to it. I wont have access to the same resources at a users desk as I would at my workstation so I have to go back to retrieve this archived copy.
What if the problem with the machine was that he didnt get the latest version of the script. Preventing me from detokenizing and comparing agaisnt the standard copy makes troubleshooting a little harder. I could do a CRC check against the two to verify this but this again takes another application I may not have access to at a users desk.
All of this adds up to more time troubleshooting. If I have access to the tokenized file and a kix executable I should be able to extract then debug the script at the location.
I do have a use for a script that is unreadable. Engineers love to circumvent our standard software installations, virus scanners for example. They will reverse engineer the method to detect virus scan installation and create dummy positives. If I could hide this script from them it would be very hard. This data would be stored in a second script with the "do not allow detokenize" enabled.
|
|
Top
|
|
|
|
|
#128995 - 2004-11-08 10:11 AM
Re: Detokenize as an option in new version
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
Quote:
It would help when you need to sit at the machine not working properly and you want to debug the script. If I want to run the script manually and step through the commands using the debugger how will this work with a tokenized file?
Not very well 
Quote:
Sounds like many of you suggest using an archived copy (which should be the same as on the system but you cant be entirely sure) and running it on the machine in detokenized format. That means either the script must be modified to run from the users system (instead of the shared location it was originally on) or I have to store the detokenized version on the central location and point the machine to it. I wont have access to the same resources at a users desk as I would at my workstation so I have to go back to retrieve this archived copy.
I don't understand this at all. You say you are going to run the original script manually - what does it matter where you get it from? You surely aren't suggesting that you want to leave a "detokenised" copy unprotected on the netlogon share? There is of course no reason not to have a restricted folder on the netlogon share which contains the original script so it is easy for you to retrieve. You will update the two in parallel when you release a new version.
Quote:
What if the problem with the machine was that he didnt get the latest version of the script. Preventing me from detokenizing and comparing agaisnt the standard copy makes troubleshooting a little harder.
Not at all. Whenever I make an amendment to my login script I update the version number and the last changed date. The script has an internal record of all changes. When a user logs on a hidden log file is written to their home directory containing the version number of all scripts, where they log in from, which logon server they are authenticating against, all the process stages that occur and and errors. An error causes the log to be mailed to me.
Identifying the script that has been run is therefore trivial.
If you don't want to go to this much effort, add a handler which on seeing the $VERSION flag on the command line just dumps the version info and exits.
Quote:
I could do a CRC check against the two to verify this but this again takes another application I may not have access to at a users desk.
Simple command line utilities like this do not require installation and can be executed from any available share.
Quote:
All of this adds up to more time troubleshooting. If I have access to the tokenized file and a kix executable I should be able to extract then debug the script at the location.
You have access to the original file. Running it at the user location is no more time consuming or complex than de-tokenising.
You certainly do not want the KiXtart executable to contain de-tokenising code, as that would uneccessarily bloat it so the de-tokeniser would be a stand-alone exe.
Quote:
I do have a use for a script that is unreadable. Engineers love to circumvent our standard software installations, virus scanners for example. They will reverse engineer the method to detect virus scan installation and create dummy positives. If I could hide this script from them it would be very hard. This data would be stored in a second script with the "do not allow detokenize" enabled.
This sort of situation must be covered by company policy. Any attempt to subvert security procedures is at the very least gross misconduct. Hiding scripts is not the right way to combat such blatant stupidity. If it were me I'd have an email off to company security, the engineers line manager and human resources as soon as I discovered this sort of nonsense, and leave them to sort it out.
The point of this long ramble is that detokenising does not add anything useful to these scenarios. As the detokenised code will not match the original code anyway it is likely to be less useful in your debugging tasks than the alternatives.
There are better tools and methods to achieve what you need.
While detokenising might at first seem to fit the bill it is the lure of the Dark Side - seemingly simple and easier at first you will find that it will only bring trouble, pain and undesirable results if you stray down that path.
|
|
Top
|
|
|
|
|
#199830 - 2010-09-13 07:53 PM
Re: Detokenize as an option in new version
[Re: Richard H.]
|
tremainv
Just in Town
Registered: 2010-09-13
Posts: 1
Loc: Michigan, USA
|
This topic has been sitting out here for a while, but I have a situation that has arisen today where "detokenizing" would be of great value. I have just been given responsibility over a app we are running in Citrix and we use a tokenized Kix script. I have no idea of what all is included in the script and there is no source code for the tokenized script. There are no backups anywhere. The 2 people who new about the script and what it held have left the company in the past 2 weeks. I now need to try and find out what this script is doing. If detokenizing is still not an option, I would welcome suggestions on how to proceed in piecing this puzzle together.
|
|
Top
|
|
|
|
Moderator: Lonkero, ShaneEP, Jochen, Radimus, Glenn Barnas, Allen, Ruud van Velsen, Mart
|
0 registered
and 718 anonymous users online.
|
|
|
