Dissect traffic between Lutron RadioRa2 and Alarm.com

Question

I am looking at the Wireshark trace from a Lutron RadioRa2 repeater communicating with Alarm.com (209.222.135.33) over UDP port 1130. If I follow UDP stream in wireshark, I am getting gibberish.

Is there a way to decrypt and see what information is being sent to Alarm.com?

Thanks

Answer 1

2

I don't know what CASP traffic is (please explain), but on the webpage of alarm.com they claim to be able to do this with their products through a mobile app.

Lock/Unlock doors
Turn lights on/off
Adjust Temperature

I really hope they encrypt that traffic to prevent an eavesdropper from intercepting the door commands, modifying it and unlocking the door instead of locking it.

So I strongly assume (hope) they use encrypted communication and that's the reason why you 'get gibberish'.

If that is true, I don't see a realistic way to decrypt the traffic, unless you hack into their systems to steal the crypto keys ;-))

If the traffic is not encrypted, they are maybe using a binary protocol. Unless you know the structure of that protocol, there is again no realistic way to decipher the communication.

Regards
Kurt

answered 01 Mar '13, 10:08

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

edited 01 Mar '13, 10:09

this is what I found about CASP http://user.informatik.uni-goettingen.de/~casp/draft-schulzrinne-nsis-casp-01.pdf

Wireshark identifies Port 1130 as CASP traffic, so my guess it is CASP

(01 Mar '13, 10:24) net_tech

Hm.. can you please post a few sample packets (pcap format!) somewhere (google docs, one-click hoster, cloudshark.org)?

(01 Mar '13, 10:30) Kurt Knochner ♦

sure

http://www.cloudshark.org/captures/28719c863324

(01 Mar '13, 10:36) net_tech

1

If you look at the data, you will see, that there is a structure, based on the length of the packets.

All packets start with 0x7d. Packets with 60 Bytes seem to count up in the second octet: 0d, 0e, next? Then there is a repeating pattern 00:00:11:22:33:44:55:6a. Looks like a status message or some kind of keep-alive. #1 7d 0d 00 00 11 22 33 44 55 6a 79 75 00 fc 61 31 #5 7d 0e 00 00 11 22 33 44 55 6a 7c 83 75 00 fc 64 3d Packets with 77 Bytes start with 7d202028, then 'gibberish' #2 7d 20 20 28 a0 3c a7 62 5a 03 1a f8 db 5f c0 0d 25 4c 8b 0d a5 5f 5e 38 1b fe b5 4c 90 41 54 b6 49 63 f6 #6 7d 20 20 28 da 93 ee ff 04 00 0b 00 22 46 ad 6e 61 b0 29 8e 05 12 da c3 c1 43 a1 69 f0 66 81 3f 64 db f0 Packets with 93 Bytes start with 7d3020 then 'gibberish' #3 7d 30 20 50 85 98 09 0e 5a 99 38 86 4b c3 9d df d0 0e 39 a5 23 e7 3d e9 ec 11 8c 78 d6 8b 35 c4 d6 f2 ec cb 0e 0f 74 fe 13 fb b4 6f 79 b8 31 81 96 a1 a0 #7 7d 30 20 1a d5 61 e1 88 97 10 5d 00 d7 63 29 7f d5 aa db e3 36 db d5 b8 39 b7 64 95 9d ae 17 1b 67 84 1e 6b 4f 6f 5a 9d 5a 8c 30 5d 06 f4 fd ba de 40 3b #8 7d 30 20 f7 cd 61 03 1a 76 fe d6 02 95 3b 42 60 b3 13 99 e2 63 f7 b6 00 dd 21 12 01 18 bc c3 45 7f 54 25 87 0f 73 20 1c 24 09 0f 84 1a 31 c8 dd 08 9a a9

I guess those "prefixes" (7d2020 and 7d3020) are different message types and the rest may or may not contain encrypted data.

(01 Mar ‘13, 11:20) Kurt Knochner ♦

UPDATE: As @SYN-bit figured out, 0x7d is probably a protocol identifier, the second octet is the data length and the third octet probably flags an/or message type!?!

(01 Mar ‘13, 12:56) Kurt Knochner ♦

Answer 2

From /etc/services:

[email protected]:~/Wireshark/trunk$ grep casp /etc/services 
casp            1130/tcp    # CAC App Service Protocol
casp            1130/udp    # CAC App Service Protocol
caspssl         1131/tcp    # CAC App Service Protocol Encripted
caspssl         1131/udp    # CAC App Service Protocol Encripted
[email protected]:~/Wireshark/trunk$

So traffic on port 1130 should probably not be encrypted at the transport layer. The document you refer too has one paragraph on security:

The session ownership problem described in [8] makes an efficient security protection
difficult. For this version of CASP confidentiality protection of the session identifier
can be provided by both IPsec and TLS (as provided by most cipher-suites for TLS and
IPSec ESP without NULL encryption) to Security protection for the session ownership
first version of the protocol may rely prevent eavesdroppers to learn the 128-bit
randomly generated session identifier.

So, it might be IPsec. Or it might be encryption at the application layer.

In any case, wireshark currently has no casp dissector AFAICT. So the first steps would be to create a casp dissector (based on the protocol specification).