Some one suggested this to me off the list... unfortunately it does not
work on NT flavors. It requires no hardware and its free. =] . I fired
it up and set it to "attach" to COM1. I plugged in the barcode reader
and then opened the software that sends the "init" to the device. Theres
a nice play button on the software and it begins sniffing the data on
the port. In data is highlighted in red and out data in blue with a hex
and ascii dump of both directions. This did the job nicely ... I was
able to snag the data very easily. I was able drop it into a small c
program which will be used to avoid using a proprietary software to turn
this device on.

This would definately be useful for sniffing sessions in other scenarios.

http://www.rtcomm.com/comlab32.html
-KF

yatima wrote:

>I am not altogether familiar with your predicament. But with a bit of
>elbow grease/common sence I am sure you can whip up a simple hardware
>splitter. then you can watch the datastream from both machine to device
>without conflicts/etc. I imagine the only difficult part (if not
>documented with the device) will be determining comm parameters (baud
>rate, etc). Another issue is getting the pinouts right (if the cable is
>fixed on the device it might cross (or not) pins within the cable that
>convert it from null to otherwise. You can trial/error this, or use a
>serial LED device (device with bi-color leds for each pin). Using the
>device you can test your splitter by putting it between the device and the
>computer (as normally connected) noting the led states. Using the LED
>states as a reference build a splitter to replicate the pin
>configuration. If the device isnt entirely proprietary, you shouldnt have
>any problems intializing by replicating the init sequences, however the
>possibility does exist that drivers/etc for the software has an abstract
>layer above the commport connection where the
>device itself may handshake with the machine. For ps/2 AT
>barcode/magstripe/etc devices this wouldnt be an issue, but with a serial
>device this is a possibility, and as such should be a consideration.
>Just an idea from a ranting neophy
>I am not an electrical engineer, nor do I have similar inclinations,
>Infact, I am made entirely of cheese.
>
>On Fri, 26 Jul 2002, KF wrote:
>
>>I have an application that I need to steal data from. This application
>>is initalizing a bar code reader and I would like to see the escape
>>sequences that are used to initialize this particular device. There are
>>bajillions of DOS apps that claim to spy on a com port but I have had no
>>luck with them. Every app I try to use results in a com port in use
>>error when I fire up the app I want to sniff. Does anyone have any
>>applications to try? I need one that will allow me to monitor a comport
>>passively in win2k or XP and it must at the same time allow another
>>application to query or connect to the com port. I need to be able to
>>see the data being passed back and forth between the application and the
>>device.
>>-KF
>>
>
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]