This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Decoding TCP request to IoT device

0

I am trying to decode the request/response to a generic IoT device (with no documentation) so that I can integrate it with my exiting home automation hub. The IoT kit contains a hub that connects to the router and a set of electrical switches + temperature/humidity sensor that talk to the hub over 865mhz RF (WIR1186) The switches are controlled via an android app that seems to be sending requests to an aws server that in turn sends a request to the hub What I want to do is decode the request so that I can send the request directly from my home automation server on the LAN

I captured the packets to and from the aws server via wireshark running on a PC as man-in-the-middle - the on/off request packets seem to be simple TCP requests Unfortunately I am not very conversant with the TCP protocol and am unable to decode it any further

Here is a sample request

+---------+---------------+----------+ 13:40:15,856,271 ETHER |0 |b8|ae|ed|ea|a3|3f|e4|f4|c6|03|d8|13|08|00|45|00|00|39|3d|9b|40|00|6e|06|ba|fa|34|1d|1e|ff|c0|a8|00|65|30|39|f3|c5|3c|48|b0|48|00|00|1d|25|50|18|f8|e5|cd|1e|00|00|55|aa|ff|ff|11|00|02|6e|ff|ff|11|13|0a|0b|00|a2|23|

asked 10 Jul '16, 08:34

superczar's gravatar image

superczar
1111
accept rate: 0%

Here is the request in what is possibly a more east to understand format

Sending a switch on request for switch 1 results in the following TCP request from port x of remote server to port y of hub

55 AA FF FF 11 00 02 B8 ED 00 11 00 0D 31 00 B7 23 55 AA FF FF 11 00 02 B8 ED 30 11 00 0D 32 05 B2 10

Unfortunately translating the hex string to ascii doesn't yield anything

(10 Jul '16, 09:18) superczar

One Answer:

0

I think the data you show is actually 2 messages:

55 AA FF FF 11 00 02 B8 ED 00 11 00 0D 31 00 B7 23
55 AA FF FF 11 00 02 B8 ED 30 11 00 0D 32 05 B2 10

55 AA is a typical start message sequence that is easy to pick out and synchronise on for radio transmissions, The last 2 bytes are likely to be some form of checksum. Try capturing the same operation to a different switch to determine which parts of the message are the switch identifier.

Also, can you name the manufacturer of the device, it's entirely possible someone else has already decoded the protocol.?

answered 10 Jul '16, 10:42

grahamb's gravatar image

grahamb ♦
19.8k330206
accept rate: 22%

The device is called Oakter (oakter.com) I somehow doubt that this has been decoded before

Here is another capture through a man-in-the-middle- This is the request sent from the remote server when switching on switch 1 (same as the earlier one)

Summary 29 3.693913 52.29.30.255 192.168.137.212 TCP 71 12345 → 42087 [PSH, ACK] Seq=1 Ack=1 Win=64301 Len=17

HEX dum (the part from 55 AA onwards is the actual request)

0000 18 fe 34 f3 c8 21 02 db df c2 db 11 08 00 45 00 0010 00 39 10 75 40 00 6d 06 5f b1 34 1d 1e ff c0 a8 0020 89 d4 30 39 a4 67 95 ce bc d1 00 06 18 a9 50 18 0030 fb 2d 9d 45 00 00 55 aa ed 30 11 00 02 ca ff ff 0040 43 0d 32 31 01 db 6c

The response back to the server Summary: 31 3.755657 192.168.137.212 52.29.30.255 TCP 54 42087 → 12345 [ACK] Seq=1 Ack=18 Win=5721 Len=0

HEX 0000 02 db df c2 db 11 18 fe 34 f3 c8 21 08 00 45 00 0010 00 28 03 ba 00 00 ff 06 1a 7d c0 a8 89 d4 34 1d 0020 1e ff a4 67 30 39 00 06 18 a9 95 ce bc e2 50 10 0030 16 59 bb e1 00 00

(11 Jul '16, 01:26) superczar