I want to mimic a replay attack on controller PR402. I connected my
computer with this controller via TCP/IP <-> Serial Bridge and I would
like to analyse packets sent between computer and controller.
Because you're dealing with TCP/IP ↔︎ Serial Bridge, you can assume the data portion of the TCP packet is what's getting carried over onto the Serial line. So you can ignore everything except the data portion of the TCP packet.
First of all, I send a command "Disarm the system" from software
provided by the producer and capture these packets in Wireshark
I assume you're using Roger's PR Master software or the equivalent. Two things that you'll want to do:
- Repeat the "Disarm the system" command several times, separated by time. This will allow you to see if the command is an exact duplicate each time, or if it includes something that varies like an incrementing counter or a timestamp.
- Perform several other commands, several times each. Again, are they static repeats or do they morph? Do they have common aspects (e.g., each begins with 0xb03e) or are they all unique?
I upload 2 captures. These are just some packets from running the same
command - "Disarm system". I found out that packets from 1st to 8th
from the first screen and from 2nd to 9th have the same length and I
think there this "Disarm system" command was transmitted. Let me know
if this is the right direction of analysis.
Looking at the first capture, I see several small bits of data being exchanged. (Going back to what I said at the beginning, you only care about data. You can tell when a packet has data in this example because PSH (TCP "Push" Flag) is being used on all data packets, and the Wireshark view shows "Len=X" to indicate X bytes of data.
1: You -> PR402 3 bytes (0xbe3e01)
2: You -> PR402 9 bytes (???)
3: PR402 -> You 3 bytes (???)
4: PR402 -> You 7 bytes (???)
6: You -> PR402 3 bytes (???)
7: You -> PR402 3 bytes (???)
9: PR402 -> You 1 byte (???)
Where a 3 byte message commonly initiates a directional series (1, 3, 6), that might be the command, or it might be a meta-command - e.g., packet 1 means "REQUEST", packet 2 means "DISARM", packet 3 means "REPLY", packet means "DONE".
This is where differential analysis, the comparison of capturing different repeats of the same command and different commands, comes in - if you send "ARM", and packet #1 is still 0xb03e01, then that's not ARM/DISARM, it's an attention/request/etc message.
You know you need to:
Analyse them, dump to a file
With packets this short you're probably just as well off clicking through each packet in Wireshark and typing in the 1-10 data bytes per packet by hand.
So, go through your captures, and summarize what's saying what to whom, write it out just like I did above (but replacing ??? with actual bytes). Do that for several DISARM and several non-DISARM sequences. (If you do something like add a user with PIN, then you should see the user id and the PIN in one of the data packets, which will help you understand how these exchanges think of the data as they're exchanging it.)
Once you have those patterns, you'll be able to make a guess at how to implement the DISARM pattern yourself.
Generate proper packet/frame
You can use something like scapy for this. If send a TCP packet with data of 0xb03e01, for example:
# scapy
>>> packet=IP(dst="192.168.0.21")/TCP(dport=771)/"\xb0\x3e\x01"
>>> send(packet)
.
Sent 1 packets.
Putting that in the context of a well-formed TCP connection is a little more work. If you do need to run multiple packets across a single connection, you'll need to dig a little deeper into scapy (for example, reusing sockets), but that's the tool that will quickly and easily do what you want to do. You could also put a Perl/Python wrapper around nmap, for example, although that gives you a little less per-packet control.
Since you're dealing with a TCP-to-Serial connection, sending individual packets like that - one TCP connection, one packet, and closed - is probably fine. The Serial bridge probably might care less how many TCP connections are used.
Transfer it to the controller and achieve disarming system
If you have TCP access to the Serial bridge, then all you need to do is send the packets. If it works for the PR Master software, and you mimic it correctly it'll work for you. Remember, this is a physical security device and it likely operates under the assumption that all Serial input is trusted because the Serial line isn't exposed to untrusted physical spaces. The data size we're seeing in these packet exchanges makes encryption or authentication precautions unlikely.
