Parallel Port Interfacing

-------------- No, the design of the parallel port input circuit simply allows the processor to read directly from the port input pins to the processor's accumulator! Even the chips that now implement the parallel port must]do that with fidelity to the original TTL design. However, with some of these there may be a way.

It actually sounds like you don't know what you're doing. Why don't you tell us what you FINALLY wish to achieve and we can help you better. There is no REASON to have to do what you have asked to do!

-Steve

My friend Siddharth and I are trying to put together an Identification system.I believe the details of the project are unnecessary.Basically we have a program running which finds out the address of LPT1 and then reads/writes data to it.There is a small electronic device connected to the parallel port(which we are yet to implement) which the 'user' can bring, plug in , work on the comp,plug out and walk away.The user has full access to all the resources of the computer for as much time as he can spare.Now, can he hijack our program so that the data it reads from the port differs from what is actually entered by the device(connected to the parallel port)? In other words, how can we make sure that our program always identifies the input from the device correctly.

We believe we will be able to encrypt our program sufficiently so that the user cant mess around with the source code of our program.

How are the data/control registers read.Where are these data registers in the computer?can somebody obtain the RAM address of these and write/change it. Are commands like "-d 40:8 " in debug(msdos) foolproof?how is it all implemented?

Since we have little knowledge of Parallel ports and operating systems,feel free to critisize/point out mistakes but please do correct us. Thanks Karan

In addition to my previous post:

I want to know if one can construct softwares for emulating parallel port like one does for CD ROM .There are many softwares like Daemon Tolls etc. which can emulate a CDROM.

Can this be done with LPTn? If possible,what measures are to be taken to enure that a program that I make reads the correct port data addresses.

-Karan

Like any other interface, the parallel port can be probed. Anyone with a logic analyzer can capture your entire transaction. The parallel port data rates are limited by legacy hardware considerations. It is not difficult to build a device to emulate the physical layer of your protocol, whatever it is. In order for this system to be meaningfully secure, you need to use strong crypto with a time-sensitive challenge-response protocol, for example similar to the systems used by smartcard readers. You also need to protect key material stored in the access device (your user's removable module). The fact that you're asking the question here, in the terms you used, indicates that you're not protecting anything very valuable, so it's probably sufficient merely to activate code protection on the microcontroller in your access device.

There are numerous protocols, e.g. based on ANSI X.509, for authenticating users across an insecure link. Google for "challenge-response algorithms".

has a nice tutorial about ports. However, if you want to access the ports from a proper OS (NT, 2000, xNIX) you need some extra work to get around the hardware protection, like DirectIO. The BIOS just stores the port addresses in around 0:40.

BTW, the robotics NG is a bit of a strange place for this question.

Wim

Wim

Dallas Semi already makes the device you are talking about. I have used it in a few applications and it works great.

There are numerous other outfits that make parallel/serial/USB hardware keys as well.

But as Edwards states, it's fairly simple to monitor your whole transaction and duplicate it with either hardware or software. We have found that it's kind of like a lock on your front door. The casual cheater is discouraged, but the guy willing to kick in your door in the middle of the day will get in anyway. Even if you go to a much more secure challenge/response system where simply recording the transaction will not work (as the transaction is different each time), you need to make sure you don't do something simple in your software like periodically call a function that checks the key and returns TRUE or FALSE. It's a fairly simple trick to hack your EXE to always return TRUE. When I was 14 I bought some game that did a trick to the formatting of the floppy, so that a copy would not work. Periodically throughout the game it would check the disk for the formatting quirk. Now, I had about 40 games and did not like to mess with the floppies all the time so I determined to hack the game. The program was written in some high level language and I did not have the source code, but it all compiles down the machine code at some point, so I was able to use a simple debugger to trace the code and ultimately found the spot where it did a "jump if false" after the fancy function that checked the disk. I simply replaced the "jump if false" (JNZ) with a no-op. So the result was the function would still check and return a fail condition, but the application could no longer jump to the "key failed" code.

Bottom line, there is no such thing as absolute security, someone who tries hard enough can break just about anything that you can come up with. I recently went to an ATMEL seminar where they were talking about the virtues of FLASH. Apparently it is possible to cut the chip open and use some sort of electron microscope to literally read the bits of a standard EEPROM array, but flash will be erased by this process.

How secure do you need to be? You can lock your door. Add a deadbolt. Add bars to doors and windows. Build the walls out of 14 inch steel reinforced concrete. Build a wall around your house. Get some guard dogs. Hire some guards to stand on the wall. Use radar to detect anyone or anything approaching. Or just kill everyone else so there is nobody left to break in. When does it become so ridiculous that you realize that your protection scheme costs so much more than what it's protecting...

--Steve

I guess that under a protected mode OS, you can write a devicedriver that is called LPTx. Even further, you can capture the trap that occurs when writing to the common hardware addresses used for parallel ports.

Wim