Demystify the CTPP calls

[grdw]

Somewhere in my PCAP files there are calls made to link the Comelit extender to a relay, and that relay to another relay etc. It's all very unclear how and why all these bytes are supposed to be set.

Questions to answer:

• Do both CTPP and CSPB channels need to be open? → No.
• What's the purpose of the CSPB channel, since I see almost no calls being made to that channel? → Nothing
• How are these requests formed, is there a generic format?
• In my apartment complex there are two camera's and two doors. How does the CTPP request know which of the doors I'm opening and which of the camera's I'm looking at?

Nice to have questions:

• What are these abbreviations for?

Data

The "handshake":

This is data, with speculation about what these bytes could mean. All the requests have been stripped off the footer part, as it's the same for all CTPP requests, and I found it therefore not relevant to show.

The CTPP channel always starts with the same type of handshake request, in the three PCAP captures I have I see the following initial group of bytes being written to the intercom:

c0, 18, 5b, 45, 2b, 3d, 00, 11, 00, 40, e6, 5f, 53, 42, 30, 30, 30, 30, 30, 36, 32, 00, 10, 0e, 00, 00, 00, 00
c0, 18, 38, 1d, b3, 09, 00, 11, 00, 40, 31, 94, 53, 42, 30, 30, 30, 30, 30, 36, 32, 00, 10, 0e, 00, 00, 00, 00
c0, 18, 3c, e9, d6, 6d, 00, 11, 00, 40, 7b, 8f, 53, 42, 30, 30, 30, 30, 30, 36, 32, 00, 10, 0e, 00, 00, 00, 00

If you strip it to the consistent bits and inconsistent bits:

c0, 18, __, __, __, __, 00, 11, 00, 40, __, __, 53, 42, 30, 30, 30, 30, 30, 36, 32, 00, 10, 0e, 00, 00, 00, 00

The empty spaces (__) are randomly (?) set and there's no consistency to it from what I can see. The 00 11 00 40 is fixed, and I have no idea what that means. However, they feel static because they are also present in the icona-bridge client.

The application will then proceed to read from the stream until it receives a message starting with 60:

W: c0, 18, 5b, 45, 2b, 3d, 00, 11, 00, 40, e6, 5f, 53, 42, 30, 30, 30, 30, 30, 36, 32, 00, 10, 0e, 00, 00, 00, 00
R: 60, 18, db, 45, 3d, 2c, 00, 10, 00, 41, e6, 5f, 53, 42, 30, 30, 30, 30, 30, 36, 32, 00, 00, 00

W: c0, 18, 38, 1d, b3, 09, 00, 11, 00, 40, 31, 94, 53, 42, 30, 30, 30, 30, 30, 36, 32, 00, 10, 0e, 00, 00, 00, 00
R: 00, 18, b8, 1d, 09, b4, 00, 00
R: 60, 18, b8, 1d, 09, b4, 00, 10, 00, 41, 31, 94, 53, 42, 30, 30, 30, 30, 30, 36, 32, 00, 00, 00

W: c0, 18, 3c, e9, d6, 6d, 00, 11, 00, 40, 7b, 8f, 53, 42, 30, 30, 30, 30, 30, 36, 32, 00, 10, 0e, 00, 00, 00, 00
R: 00, 18, bc, e9, 6d, d7, 00, 00
R: 60, 18, bc, e9, 6d, d7, 00, 10, 00, 41, 7b, 8f, 53, 42, 30, 30, 30, 30, 30, 36, 32, 00, 00, 00

If we replace all the actuators with __, we get:

W: c0, 18, 5b, 45, 2b, 3d, 00, 11, 00, 40, e6, 5f, __, 00, 10, 0e, 00, 00, 00, 00
R: 60, 18, db, 45, 3d, 2c, 00, 10, 00, 41, e6, 5f, __, 00, 00, 00

W: c0, 18, 38, 1d, b3, 09, 00, 11, 00, 40, 31, 94, __, 00, 10, 0e, 00, 00, 00, 00
R: 00, 18, b8, 1d, 09, b4, 00, 00
R: 60, 18, b8, 1d, 09, b4, 00, 10, 00, 41, 31, 94, __, 00, 00, 00

W: c0, 18, 3c, e9, d6, 6d, 00, 11, 00, 40, 7b, 8f, __, 00, 10, 0e, 00, 00, 00, 00
R: 00, 18, bc, e9, 6d, d7, 00, 00
R: 60, 18, bc, e9, 6d, d7, 00, 10, 00, 41, 7b, 8f, __, 00, 00, 00
           ^   ^   ^   ^ 
           2   3   4   5

A couple of facts:

• The reads all return a similar 4-byte signature (pos 2 till 5) to the write, where:
  • (2) The read byte differs 0x80 (128) from the written byte.
  • (3) These are the same
  • (4) This is the written byte at pos 5
  • (5) This is the written byte at pos 4 + 1

For the 60-requests the following also holds true:

• Writing 00 11 00 40 turns into 00 10 00 41
• The two random bytes that follow are returned identically. The 10 0e is dropped from the response. The 10 0e is also present in the icona client.

Acknowledgements:

After this process is over, follow two acks (stripping the actuator again with __):

R: 60, 18, db, 45, 3d, 2c, 00, 10, 00, 41, e6, 5f, __, 00, 00, 00
W: 00, 18, 5b, 45, 2c, 3e, 00, 00
W: 20, 18, 5b, 45, 2c, 3e, 00, 00

R: 60, 18, b8, 1d, 09, b4, 00, 10, 00, 41, 31, 94, __, 00, 00, 00
W: 00, 18, 38, 1d, b4, 0a, 00, 00
W: 20, 18, 38, 1d, b4, 0a, 00, 00

R: 60, 18, bc, e9, 6d, d7, 00, 10, 00, 41, 7b, 8f, __, 00, 00, 00
W: 00, 18, 3c, e9, d7, 6e, 00, 00
W: 20, 18, 3c, e9, d7, 6e, 00, 00
           ^   ^   ^   ^ 
           2   3   4   5

The acks are (what it looks like) based on the initial response from the handshake. They are essentially two writes where:

• (2) This byte differs exactly 128 bytes from the response
• (3) This byte stays the same
• (4) This byte swaps places with the 5th byte of the read response
• (5) This byte swaps places with 4th byte of the read response + 1

Probably this one opens the door

Next follows another c0 request (I stripped all the actuators from the bytes, and replaced them with __):

W: 20, 18, 5b, 45, 2c, 3e, 00, 00
W: c0, 18, 1f, 6b, fd, d0, 00, 28, 00, 01, __, 00, __, 00, 00, 01, 20, 6d, 3d, 42, 04, __, 00, 49, 49
R: 00, 18, 9f, 6b, d0, fe, 00, 00

W: 20, 18, 38, 1d, b4, 0a, 00, 00
W: c0, 18, 27, e0, 1b, d5, 00, 28, 00, 01, __, 00, __, 00, 00, 01, 20, 7d, 04, 7a, 3b, __, 00, 49, 49
R: 00, 18, a7, e0, d5, 1c, 00, 00

W: 20, 18, 3c, e9, d7, 6e, 00, 00
W: c0, 18, 70, 8d, 14, f9, 00, 28, 00, 01, __, 00, __, 00, 00, 01, 20, 6c, 7b, 4d, 6d, __, 00, 49, 49
R: 00, 18, f0, 8d, f9, 15, 00, 00

Things to notice:

• The c0 request resets the 4 bytes completely, it ignores the previous one's and there's not a recognizable pattern to discover here.
• The 00 28 00 01 remains consistent among all three requests
• The 00 00 01 20 remains consistent among all three requests.
• They all end on 49 49 which at the icona bridge client they don't.
• The response that's read holds true to the previous random byte rule, and should probably be used for the next request that's made. I feel like breaking that pattern will probably get you kicked from the CTPP channel 😬

In some of the traces I noticed more c0-requests, sometimes because I let a trace run for longer periods of time.

W: c0, 18, 0e, 10, ee, 25, 00, 28, 00, 01, __, 00, __, 00, 00, 01, 20, 1a, e9, c5, 4f, __, 00, 49, 49

W: c0, 18, 4d, f1, 69, bd, 00, 28, 00, 01, __, 00, __, 00, 00, 01, 20, 36, 3f, c3, 6e, __, 00, 49, 49

W: c0, 18, 29, 5f, 12, 17, 00, 28, 00, 01, __, 00, __, 00, 00, 01, 20, be, 13, 29, 2c, __, 00, 49, 49

W: c0, 18, 37, f6, 16, 5c, 00, 28, 00, 01, __, 00, __, 00, 00, 01, 20, d8, 4c, c2, 6e, __, 00, 49, 49

The 00 28 00 01 and 00 00 01 20 still hold true in these requests.
I'm still super confused about the four random bytes that follow right after 00 00 01 20 and I still can't explain the double 49.

---

Another discovery 🎉

When mixing in the "open channel" requests/responses with the CTPP responses, something interesting happens. It all of a sudden explains a different byte sequence.

Right after the c0-request (Which might or might not open the door). Two channels are opened:

• UDPM
• RTPC

Some of the 0x40-requests to the CTPP channel take the channel-type of the RTPC channel. Like such (Blue = write, Yellow = read):

Notice that the channel bytes are passed as arguments