Page 1 of 2 12>
Topic Options
#80375 - 2001-08-29 05:43 AM Source file encryption
Les Offline
KiX Master
*****

Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
There are a lot of posts looking for ways to encrypt the source code both to prevent reverse engineering and to prevent ripping of passwords etc.
To encrypt, command line parameters could be used. Something similar to KixStrip but with built-in encryption.
Decryption should be on-the-fly in memory. As a safeguard, Kix could check to see if it is called from a logon.
_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.

Top
#80376 - 2001-08-29 11:04 AM Re: Source file encryption
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4945
Loc: Leatherhead, Surrey, UK
The problem with encrypting the script is that you need to unencrypt it, in which case you need the password somewhere. Unless the encrypted file contains the password itself of course, hidden within in it using an algorithm that only the developers are aware of.
You wouldn't want the decryption to decrypt the entire file, otherwise a simple memory dump would show the original text. That means that you would be constantly reparsing the encrypted file with the associated processing overhead.

If the concern is obfuscating passwords used in logon scripts, wouldn't passing them as command line parameters in the logon script definition hide them better? Then they are never in the script itself and the only people who can see them are people with access to the user database.

As for hiding the working of your script, an option to compile to pseudo-code, or byte-code would be interesting. It would hide the workings from a casual browser, and speed up the run-time enormously. Of course on the downside a de-compiler for byte-code is very simple to write.

Top
#80377 - 2001-08-29 11:14 AM Re: Source file encryption
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22343
Loc: OK
well. what comes to pass for crypted, it's not needed. If you have crypt-engine that does crypt the stuff and write the random decryption key somewhere in the file.
the length of that key could be random or according to script size.
decrypt function would be runnable only when engine called from kix (that's obvious if engine is kix-script) and it does not output the crypted anywhere, it just translates directly to kix.
these kindoff script would be some 20 kb's which is not anymore easy to read, when stripped to one line.
and because it's full of execute-lines with some calculations integrated, it'll need guru to read out the correct way of working.
what comes to crypting, it can be in just 8 bytes or so, and noone can read it anymore.

my 1,5 cents

_________________________
!

download KiXnet

Top
#80378 - 2001-08-29 04:04 PM Re: Source file encryption
Les Offline
KiX Master
*****

Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
Richard,
I'm aware that if Kix were to decrypt in batch that a memory dump would defeat it. What I suggest, is that it be done byte by byte as it is being interpreted. A public key encryption, like SSL, is what I'm suggesting.
Your suggestion to pass the password as a parameter through the User Environment Profile is worth further investigation, but most have concern about reverse engineering.
It is often said that locks are for honest folk, and compiling to p-code would hide code from honest folk, but high encryption would keep more folk honest.
_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.

Top
#80379 - 2001-09-04 08:17 PM Re: Source file encryption
Anonymous
Unregistered


RE: Passing passwords to scripts as command line arguments.

Unfortunately, users' login scripts are considered "public" information by NT. Despite the fact that this information is stored with the user's account in the domain SAM, ANYONE could view the password argument.

Check it out from the command line:
net user <username> /domain

This procedure would be useful, say, to provide an admin password to use with su.exe. However, any password made visible to the user's security context would be visible to the user, regardless of whether that password were passed as a command line argument, or if it were contained in a file. Again, strong encryption is the only possible solution. Decryption should be handled inside the script, so that it executes in the client's memory space & not transmitted clear text over the network.

Top
#80380 - 2001-09-13 05:40 AM Re: Source file encryption
cj Offline
MM club member
*****

Registered: 2000-04-06
Posts: 1102
Loc: Brisbane, Australia
Don't tell anyone , but I have somtimes used passwords that do not look like passwords. For example:

NET USE [devicename | *] [\\computername\sharename[\volume] [password | *]]

I put this in a script

NET USE X: \\server\share /user:fred /domainname

and "/domainname" was actually the password. Looking at it, you would just think of it as another switch. Often you don't see what is in front of you.

I wouldn't recommend this type of security in the workplace though, but it give you an idea..

cj

Top
#80381 - 2001-09-13 06:19 AM Re: Source file encryption
NTDOC Administrator Offline
Administrator
*****

Registered: 2000-07-28
Posts: 11577
Loc: CA
cj, cj... Don't change your sig to one like Les has


RUUD,,,, what about something built in with an update, KiXtart 2001a ?

Top
#80382 - 2001-09-13 06:56 AM Re: Source file encryption
Les Offline
KiX Master
*****

Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
That's it! Time for a new sig...

I could see knocking off something that compiles to psuedo-code in the timeframe of 2001, but expect that strong encryption would run us into 2002.

So just like there is a console-less version (wkix32.exe), there could be secure version (maybe wkix32s.exe).

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

Top
#80383 - 2001-09-13 07:07 AM Re: Source file encryption
NTDOC Administrator Offline
Administrator
*****

Registered: 2000-07-28
Posts: 11577
Loc: CA
Teacher...Teacher

I have a question?

Shut up and finish your test!

Yeah, I'm sure it is not an easy task, but having something built-in I think is probably about the only real solution... or a Service Pack that would support all Windows clients with this type of support.

Top
#80384 - 2001-09-13 11:28 AM Re: Source file encryption
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4945
Loc: Leatherhead, Surrey, UK
I've been playing with some code with encrypts the script and generates a self decrypting executable. The executable writes the output to a temporary file and runs kix. The first thing the script does is delete itself. As long as the script is short enough and loaded into memory it works pretty well. The problem is that the temporary file is there, albeit for a short time. If kix could read its script file from stdin I wouldn't need the temporary file, although it'd still be subject to attack by a memory dump, or someone using a debug utility to step through the executable and stop before the script is called.

In all I can't think of a secure solution that doesn't require that the decrypting is done on the fly within the interpreter.

Top
#80385 - 2001-09-13 02:00 PM Re: Source file encryption
Alex.H Offline
Seasoned Scripter

Registered: 2001-04-10
Posts: 406
Loc: France
If your users can do "memory attacks", seems that they already have the admin password, no ?
I thought about a ramdrive style protection : an exe using a place only in memory to uncompress/store script, and which can be destruct when asked (and if script abort), so nothing can be get. On the other hand, the exe doing all this stuff must :
1) encrypt the added files it store within, or compress it with a modded header (if some players here looked to the old Diablo mpq files, it's nothing else than zip type with another header. Same things with Diablo 2 and Starcraft. Ok, everything is done with an external dll, but at this point, you can have it in the exe)

2) it won't allow to "extract" files to change some things within, but only execute them.

3) A "builder" must me created, as it will be needed to create the exe with the specified file, and the command the exe will run

4) find someone to create a such thing

Advantage of this one is that it would be completly independant of any scripts language

That was my 4 cents
A last thing : before thinking about the size, it should be interesting to see what size it show after an UPX (exe compressor, with an incredible rate. 2 Mb => 150 kb)

[ 13 September 2001: Message edited by: Popovk ]

_________________________
? getobject(Kixtart.org.Signature)

Top
#80386 - 2001-09-13 02:53 PM Re: Source file encryption
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4945
Loc: Leatherhead, Surrey, UK
No, you don't have to have the administrator password.

If you have a robust operating system which will allow a process to allocate a private area of memory and place security controls on it so that no other process can read it even if the process is spawned by the same user, then you are safe from memory scanning. Unless your smart user forces a crash and preserves a swap file with the information in it of course.

If your operating system won't allow this then the memory (including RAM drives) can be read, and possibly changed.

The other problem is, if I can read the program I can take a copy to another computer which I have complete control over and fiddle to my heart's content.

A quick search at www.download.com gave me WinHack and MemoryBrowser, both of which will allow you to browse your local PC memory and RamDump which will dump the contents so you can play with it off-line.

Of course you need to be quite a sophisticated user to think about cracking the encryption that way, or using a debugger to step through the code and interrogate internal buffers.

You need to decide whether you simply want to deter accidental disclosure of passwords and the script code, or if you need a highly secure solution.

Top
#80387 - 2001-09-13 04:17 PM Re: Source file encryption
Les Offline
KiX Master
*****

Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
I realize that since KIX is an interpreter and doesn't run compiled code, a good portion of the script would have to be unencrypted and buffered in memory. This leaves the code vulnerable to any memory ripping. Passing of some passwords will allways be too risky. One needs to weigh the risk and decide for themself. If the password only gets you local admin rights, the risk may be worth taking, maybe not. FE, If I stole my HR manager's laptop, got local admin rights, and scoured the HD for say, union negotiations... well, you get the picture.

While safeguards could be put in place to test whether KIX is running from logon, whether the speed of execution is reduced by an external debugger, etc., these too could be overridden by a good hacker. I think what is needed is a server-side service that the client-side service sends security requests 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
#80388 - 2001-09-13 09:59 PM Re: Source file encryption
Alex.H Offline
Seasoned Scripter

Registered: 2001-04-10
Posts: 406
Loc: France
I think you're asking too much. You have users, not hackers.
You are speaking of good (great) user that clearly looking for damaging your company. Even if password is encrypted, it won't stop them at this point
_________________________
? getobject(Kixtart.org.Signature)

Top
#80389 - 2001-09-13 10:32 PM Re: Source file encryption
Les Offline
KiX Master
*****

Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
Popovk,
You may be right, but still I have to ask...
These hackers are users for some LAN Admin somewhere. So who's network? My network is connected to a corporate WAN with about 6000 users. I routinely have 6 to 12 Failure Audits per day per server in my security logs. Some I recognize as IT from other divisions, others I don't.

We use a term called "due diligence" which means we need to take all reasonable effort to secure our environment. FE, I use SSL on my intranet to secure confidential HR and Payroll information. Maybe nobody sniffs packets on my network to pick up clear text, but I would be remiss to use "security by ignorance".

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

Top
#80390 - 2001-09-14 01:05 AM Re: Source file encryption
NTDOC Administrator Offline
Administrator
*****

Registered: 2000-07-28
Posts: 11577
Loc: CA
Calm down folks... nothing to get hot under the collar about.

I think Ruud knows by now that we are all looking for something that would be handle our needs.

Have a Nice Day...

Top
#80391 - 2001-09-14 03:42 AM Re: Source file encryption
Les Offline
KiX Master
*****

Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
Hey DOC... I'm calm.

Like you, I enjoy playing the Devil's advocate. I am simply echoing the sentiments I see on this board. I also don't like to see security by ignorance. By that I mean the user's ignorance. Mind you, my / our ignorance is the greater sin.

Aside from conveying our needs / thoughts, I believe this thread has helped to raise awareness of different perceptions of "security".

In the end, Ruud will decide if / and / or what level of security and encryption to implement. This decision, we eagerly anticipate.

[ 14 September 2001: Message edited by: LLigetfa ]

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

Top
#80392 - 2001-09-14 04:54 AM Re: Source file encryption
Anonymous
Unregistered


Perhaps, if it would help, we could have a poll for this feature. I asked about source encryption a while back... so I obviously would like it. Just my 2...
Top
#80393 - 2001-09-14 05:56 AM Re: Source file encryption
Shawn Administrator Offline
Administrator
*****

Registered: 1999-08-13
Posts: 8611
We had a similar discussion to this a number of months back. I remember at the time MCA mentioned that VBSscript (WSH) has an encryption feature (implemented through a command line switch) - anyone know more 'bout that ? Might be a good model to work toward ...

-Shawn

[ 14 September 2001: Message edited by: Shawn ]

Top
#80394 - 2001-09-14 08:15 AM Re: Source file encryption
cj Offline
MM club member
*****

Registered: 2000-04-06
Posts: 1102
Loc: Brisbane, Australia
NTDOC, I created that sig when the new board came online. I have been "away" for a few months so you have prob not seen it. I have probably lost my position as a high poster too I was 4th or 5th at one stage.

Richard, I was toying with this idea, but never got around to implementing it. When you say small.. what have you found? I had an idea to use the EXECUTE() function with an entire script inside, but I found a size issue there too.

Shawn, LTNH, how's tricks. I was thinking of the VBsecure thing too.

cj

Top
Page 1 of 2 12>


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

Who's Online
0 registered and 142 anonymous users online.
Newest Members
KatieQuinn, Brennnnn, MKubicsek, xguixa, mdress
17681 Registered Users

Generated in 0.043 seconds in which 0.013 seconds were spent on a total of 14 queries. Zlib compression enabled.

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