0

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.

First of all, I send a command "Disarm the system" from software provided by the producer and capture these packets in Wireshark. What I would like to do is to capture this packet, find out how and where this command is located in this packet and perform a replay attack by sending a generated frame to the controller. I am new to Wireshark and I am not sure how to begin analysing these packets - I focused on interface which is connected with controller and have few commands captured.

To be more specific - these are (with my knowledge) steps I need to perform:

  • Capture data with Wireshark
  • Analyse them, dump to a file
  • Generate proper packet/frame
  • Transfer it to the controller and achieve disarming system

Could anyone give me a tip or recommendation what should I do next to achieve the goals listed above? I am not sure how to capture these data to a file and transfer them next to the controller. If it helps to see any more Wireshark screenshots or connection configuration, just let me know and I will post them. 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. Wireshark capture. Disarm System.

3

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:

  1. 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.
  2. 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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.