I'm trying to recycle an Anti-theft system keypad.
My goal is use this keypad as my system peripheral.
This keypad is interfaced with its master device phisically using bus rs485.
The first step in order to exploit this keyboard, is understand the communication between this two devices, the master and its keypad.
My first idea have been tap the bus and sniff the traffic.
Doing this, I collected few dumps of estabilished dialogs between those two devices, but because the tap, I can't have any idea of the direction the bytes I logged.
So my second step have been play the man-in-the-middle game.
I setup a device to put between the master and its keypad cutting the bus and using two transceiver, one facing the master an another facing the keypad.
Then I wrote a simple program to forward everything from an interface to another.
In this scenario however, it seems keypad does not react to the messages sent by its master, received by my device ad forwarded to it.
Having the feeling something in the transmission could be wrong, the rs485 chip on my usb dongle and the one on the keypad are different (sipex sp485ec keypad - st 485ecdr usb dongle), I tried to tap directly a logic analyzer to the serial pin on the microcontroller. Doing this I verified that sending bytes through my usbdongle I could receive them on the pins on the MCU.
Can someone give me any direction to step forward my project?
2 Answers
It is quite possible the master device requires keypad to answer within a specific time window. Adding a man-in-the-middle violates these conditions.
To analyze data direction, you can try connecting a small value resistor (100 — 1k) in series in the line between the devices. Connect an oscilloscope to the line. Signal voltage level will be slightly different depending on which side is driving the line.
As often happen, solution is easiest than you might have thought.
But before proceed telling you which was the problem, I want to ask a simple question to you all:
Did you know that, if in serial communication the stop bit setting is wrong, you can receive and decode successfully the stream?
Frankly I didn't know, and that's the main cause I waste all this time on a simple problem such as this.
Well you should also understand that in my experience, I never ever had the need to change the stop bit setting.
Never ever... until now.
As you might have guessed, the problem laid in the fact that "stop bit" setting was wrong.
Instead of the classic 9600,8,n,1 this setup needed 9600,8,n,2.
Guess what, I needed a very long time to figure it out.
I ended up probing serial data, directly on the MCU serial pins tx and rx pins, that because I feared the rs485 driver could have something wrong.
At last, comparing a sniffed waveform from original MASTER and the waveform I produced I finally saw the difference.
Now I can successfully transmit bytes to the devices on this bus and proceed with my original goal of reverse engineer the protocol to use this hardware on my custom Anti-theft system.