Re: Access to parallel port in Linux and WinXP

• Previous message: Allen: "Can you encrypt and dycrypt CDs and CDRWs ?"
• In reply to: karan: "Re: Access to parallel port in Linux and WinXP"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: 20 Oct 2004 09:06:13 GMT

In article <547d92f1.0410192228.105335f8@posting.google.com>,
karan <karan@iitk.ac.in> wrote:
:As for the answer to my question,I still haven't understood if one
:could 'fool the computer into believing there is a device connected to
:the parallel port when none is '

If you aren't running the WinXP on some military-grade hardened machine,
then Yes, a program *can* mess around with the values that WinXP
reads when it thinks it is reading from a parallel port.

:I repeat my query... when can this be done.
:Say, if the O.S is being loaded during boot-up ,can I have some
:assembly code running to fool it right there?

If the hardware is under the user's control, then they can tell it to
boot off any of several devices instead of the hard drive containing
Windows XP. Their boot program then reads in the standard Windows boot
program, modifies that program to do whatever the user wants and then
sets the modified code to executing. The modified code reads the
Windows XP kernel into memory (as per usual), but before setting the XP
kernel executing, the modified code patches the XP kernel to replace
the parallel port driver-reading code with code that will feed back
whatever the user wants. Windows NT based systems make this relatively
easy to do because NT uses a Hardware Abstraction Layer (HAL) to hide
device details, so with Windows NT/2000/XP the hacked code would not
have to know any details about how the parallel port on that particular
machine is supposed to work: it would just feed back the desired data
without ever talking to the hardware.

:When can this program that 'fools my computer' be loaded in
:WindowsXP,Linux?
:I believe this can be done once the O.S. is loaded,but can I make
:another program that makes sure it gets the correct information
:regarding the states of the pins.Basically, I want to read the pins
:and make sure no 'diruptive program' is changing my data
:register/status registers.

Oh, you want to build a dongle. Why didn't you just say so? ;-)

If you want an effective dongle, then a method that helps -reduce-
misuse is to use a challenge/response system. Encode into the program
two RSA-type asymmetric encryption keys, one being a private encryption
key for the program, and the other being the known public key for the
dongle. Then, on the dongle, encode in two keys as well, one being the
known public key of the program, and the other being the secret private
key of the dongle. The program generates a random "challenge" and puts
that into a string along with some constants known to both sides that
will signal that the random part has been successfully transferred.
Then the program encrypts that string with its public key and sends it
to the dongle. The dongle decrypts the string it receives with the
known public key of the program, verifies that the constant positions
match was expected, and then encrypts that decoded string with the
private key of the dongle and sends it to the program. The program,
upon receiving that, decrypts it using the known public key of the
dongle, and verifies that it matches the original randomized string
that it had generated; if there is a match, then the program knows that
it is talking to a live dongle. If the dongle was replaced by a program
that just always returned the same string, then the string it returns
is not going to decrypt back to the random key generated by the program
for this session, and the program will know there is something wrong.

I say that this method helps -reduce- misuse because there is
an attack against it. If a cracker can intercept the program
after it has generated the random key, then the cracker can record the
random key, and the cracker can record what the dongle replies back.
After that, the cracker jimmies the program so that no matter
what random key would have been generated, the random number gets
overwritten with the same one that was used the first time
around, and then the cracker jimmies the program to believe that
the recorded response was read in reply. When the program goes to
verify the results, it finds that the string it got decrypts to the
cooked "random" string that it wants to see, and the program
thinks it has authenticated okay.

One way to deal with this is to put in -lots- of challenge/response
hooks, and make the ways of generating and storing the random
keys different, so that the cracker gets tired of tracking them all down.
But that approach won't help against a particularily determined
cracker. There are other obfuscation techniques that can be used
to make it harder.

-- 
Admit it -- you peeked ahead to find out how this message ends!

• Previous message: Allen: "Can you encrypt and dycrypt CDs and CDRWs ?"
• In reply to: karan: "Re: Access to parallel port in Linux and WinXP"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]