Is it possible to make a program which can write to that parallel port
buffer/register which stores the input data to the parallel port (from
the printer). In effect, I am trying to manipulate the data registers
of the parallel port.
That is, without an external device sending input data to the port,
is it possible to fill the buffer with data so as to make the
operating system into believing that an external device is connected.
Also please specify when this can be done,that is:-
1) can I manipulate the data the BIOS reads/stores
2) can I manipulate the data the O.S reads on booting.
3) can this be done once the O.S. is loaded and running.
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 Walz firstname.lastname@example.org ftp://ftp.armory.com/pub/user/rstevew
Electronics Site!! 1000's of Files and Dirs!! With Schematics Galore!!
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
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
There are numerous protocols, e.g. based on ANSI X.509, for
authenticating users across an insecure link. Google for
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
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...
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.
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.
http://www.beyondlogic.org/ 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.
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.