I made a bunch of short-hand methods to make the two demo's simpler. Ideally we can test these, but I'm not entirely sure how to approach with the default Rust TCPListener.

In https://github.com/grdw/viper-client/issues/11 I discovered a rule which is pretty consistent in the CTPP calls. It has to do with byte 11 till 14. The following pattern holds true:

• W: Every c0 request resets these 4 bytes to whatever four bytes you write
• R: The response transforms these bytes to:
  • (11) Adds 128 (0x80) to it
  • (12) Stays the same
  • (13) Swaps with byte 14
  • (14) Swaps with byte 13, 1 is added
• W: The acknowledgements (00 and 20) you should return from here have an identical four bytes as the first request, but the last byte is +1'd

After tracing quite some of the interaction between the Comelit Android application and the doorbell it seems that the initial channel bytes are randomly picked. It's just two numbers between 0-255. Just like CTPP we should pick some random digits, instead of hardcoding them:

https://github.com/grdw/viper-client/blob/main/src/viper_client.rs#L39

Note: the third byte ('0') is not necessary at all in the channel bytes, but should be integrated somewhere in the command.

The command is called UCFG and looks as follows:

{"message":"get-configuration","addressbooks":"none","message-type":"request","message-id":2}

The 3rd byte is set to 5e in hex or 94 in decimal.

I'm curious how this currently works, in all honesty. The only thing I had to provide were my username and password, and off it went to register a device on my Comelit device. I'm assuming this is all done over the same TCPStream in some shape or way.

Todo:

• [ ] Deregister the device -> run PCAPDroid -> register the device (repeat three times for three files)

It would be pretty great if we could actually watch the streams of bytes that are returned over the UDPM channel. Currently, we read a blurb of hex data, up to a max of 1300 bytes. The format is kind of the same as always, the header is the same, and what follows is a blurb of data f.e.:

0000   45 00 05 38 00 00 40 00 40 11 bc 2b c0 a8 01 09 <-- UDP HEADER 
0010   0a d7 ad 01 fa 64 98 b2 05 24 00 00 <HEADER> 00 06 14 05
0020   25 12 00 00 <HEADER/> 80 63 70 1e 00 01 83 12 fd 72 6a 0a
0030   7c 05 ca 22 78 92 3d 86 b0 82 59 a0 06 73 d0 37
0040   00 11 34 66 b3 24 43 dd fd e0 30 00 10 00 39 19
0050   c2 f1 5a 51 ab 65 92 5e 06 c0 44 3d 03 0d b5 25
0060   c4 7e b6 12 ef 00 18 1b d2 28 a8 5e fa a4 f7 e8
0070   62 9d 17 84 6c 36 10 0b a3 12 a1 2e 82 f2 5a 40
0080   00 08 00 80 00 81 60 01 6c bc 00 61 7d ed 40 14
0090   8d ad c0 e5 bc e0 a4 05 19 98 ec 20 51 92 2a b6
00a0   64 c7 87 bf fd c0 18 4d 6e 84 1a ba 3c 35 c6 2c
00b0   67 78 c0 90 5b 3c ab 15 49 9f 91 88 d0 80 00 10
00c0   01 00 01 02 c0 d6 5c 30 c7 c1 54 4f 1f e1 e0 ae
00d0   2a a4 ef 01 96 28 71 a4 e6 c7 2e 97 a3 3c 02 00
00e0   14 55 45 b4 d5 40 cc 25 3a de a8 cb 6b 56 3a 45
00f0   df 2c 8a f9 5f 09 ea 00 02 71 ce 62 3f f2 13 10
0100   c4 61 19 8a 21 4c 62 81 f8 06 2b 52 1e 3d 25 b1
0110   e3 2d 08 14 93 20 10 0c 67 01 62 4c 71 ec 3b 1e
0120   96 00 4a 20 27 b1 4a f0 9b 81 54 3f 7f f8 21 fe
0130   d4 60 14 8d ad bd 99 65 0e f8 62 aa a0 f0 73 76
0140   dc 74 a2 ed 2f 85 10 18 86 f6 0b 59 85 50 bf 58
0150   27 50 0a 10 c5 bc da 2c b4 6e d7 02 2a 1d 80 70
0160   82 78 ae be 7b 9b ff f8 c0 00 10 00 00 06 00 c1
0170   69 6e 00 5c 41 cd 09 6d b6 9b 66 b6 fa 29 68 03
0180   30 81 5e 61 c9 5d a2 41 99 ba 7b 41 01 3f 45 54
0190   77 89 b9 21 9a 75 1f fa e1 00 00 80 60 15 0d 40
01a0   0d 13 9a dd 2d 43 80 87 fd a1 84 60 bb 5d 14 38
01b0   2e a3 09 d4 b0 64 a8 3b 3c 7c d6 ed 6f 57 83 8e
01c0   bb 59 e8 6d bc a3 99 1a 37 58 8c b8 8c 73 fb 10
01d0   88 3b 84 d8 8b 84 99 60 dd ab 00 80 0c 46 04 0e
01e0   a0 55 dd 13 36 3f df d5 80 00 40 4e 15 71 c9 a6
01f0   e9 bf 1c b6 7e 79 40 00 20 00 1c 90 3c 49 b8 b9
0200   79 00 00 80 98 aa 02 2c d7 e1 35 72 cd 98 9f 06
0210   3f 49 1c a0 1d 0b 63 02 d2 eb ff fb c3 13 29 67
0220   94 47 ea 94 f4 92 be 00 00 40 04 a0 8a 25 a0 22
0230   4a b7 fd 3d dd 7f f7 80 6e e0 80 82 23 58 e3 3d
0240   aa ad 63 8a af 1a 07 01 a2 c3 63 a5 e2 f4 0a 01
0250   8e 00 9d 05 34 41 a4 50 e9 42 e4 6f cd a0 00 4e
0260   e0 04 03 ae 8a 37 e8 57 1c 53 f7 f7 88 6c 41 50
0270   21 04 6d d5 0c 09 61 6c 80 00 20 00 10 24 82 28
0280   8b e0 85 b3 ae 6a 65 83 01 40 7a 75 a4 49 37 1f
0290   f7 e6 00 00 80 00 00 30 06 35 2c 10 35 58 82 a3
02a0   78 28 ea e7 75 13 bc 91 03 ea 51 79 de dc 98 73
02b0   10 03 98 99 c4 44 48 47 e8 30 52 2a 0a 8a 41 29
02c0   26 dd ff b7 81 6e 1d c0 0b 12 cf 2a e8 a2 b8 ef
02d0   4d 60 03 3c c0 01 09 ee bc 01 28 7b fc f0 cc 98
02e0   a3 ea b7 51 dd 0b df 04 02 4e 9e e9 3b 59 47 88
02f0   67 d1 f3 01 14 ec 00 e1 12 e5 52 bd e0 5c 97 80
0300   18 bc 50 ee 92 e9 0d 27 d3 3d 66 5c 00 9e c0 04
0310   18 3d 84 95 65 ea 2a f5 ff c0 00 00 84 37 c0 c6
0320   bf 30 f2 7c 6a 94 fa 81 a5 11 07 00 01 00 20 00
0330   10 33 00 04 b5 c0 08 08 4e 0b 20 1d 43 35 1d f2
0340   d9 ff ff 77 88 6c 41 50 92 09 e6 98 d2 48 6f a2
0350   24 0c 83 50 41 e1 29 19 36 32 3a d1 80 66 88 00
0360   e4 ac c3 00 92 0a 57 f7 f7 86 46 40 e9 c0 e4 6b
0370   22 84 48 c2 a0 b1 05 a4 46 a0 f8 a1 e7 2e 13 71
0380   b0 d0 c2 17 ff 14 44 63 11 13 1c e2 01 fd 04 2c
0390   1a 01 4e b8 9a 52 88 85 b5 71 c1 81 d4 31 78 4c
03a0   56 3c b1 e9 df 8c 7f f1 80 00 20 02 00 0c 01 a2
03b0   92 d6 31 94 62 04 5c 83 44 98 68 dd af 18 98 a2
03c0   a6 08 23 9a 69 b8 41 e1 f8 30 bd 8c 34 0b 42 d7
03d0   ee 0c 8e e2 a3 c0 09 50 a3 83 1b 8c 2b ec 79 d2
03e0   e5 3c 08 55 cf 74 e3 30 90 fb 94 2d f8 00 00 40
03f0   00 28 41 14 50 f9 08 bb fc d0 3d f8 01 03 63 0d
0400   7a 09 9b 34 fe f1 82 38 c7 06 84 64 96 3d ea df
0410   e8 36 f2 1b 10 e4 51 1f cb 29 2d 63 4c 00 01 00
0420   10 00 70 0d 12 96 e0 0c c2 d6 53 9b c4 ac 30 2d
0430   4b cf eb 18 c6 70 ad b8 41 a7 83 e5 a7 ff fd c1
0440   99 88 05 eb 0c 53 39 99 58 eb 60 bb d5 c1 f3 b3
0450   a6 7d 73 11 39 91 89 88 88 8f 00 61 53 33 80 07
0460   c1 3d 49 e1 78 94 cf e4 90 0f 18 d4 1d 45 27 d9
0470   a3 ee 64 fb f4 af b4 42 20 00 33 c9 13 61 74 3d
0480   21 e5 a5 fb c0 20 5e 35 63 d9 11 8a f9 e4 83 26
0490   93 f0 17 44 03 86 bf 5d d1 65 70 90 47 b8 10 45
04a0   21 46 8e 84 90 c0 63 f8 74 de 01 a0 7d 41 80 2f
04b0   08 41 06 4e 26 db 9e 18 ae 4a 92 74 d2 b2 c1 e4
04c0   9e 80 78 c0 80 44 00 41 d6 5a e9 d1 1b b6 7f bd
04d0   01 30 01 82 01 2e bf 4c ac 9c d4 4a a7 81 e7 71
04e0   c1 c9 b3 16 3c 81 01 4e 5d d8 c4 11 c2 f3 62 0c
04f0   90 6d 93 ff fe e6 f4 7c b4 00 08 0a e1 0c 0d 53
0500   4f 50 f7 4a df 7d e0 9d 86 13 f4 c2 a8 25 09 77
0510   cb 33 44 c3 f3 65 64 8c a2 ed 64 bf 12 21 e2 22
0520   31 f2 00 01 a7 00 01 01 72 44 5d b2 2c 78 43 f8
0530   f2 2f 64 47 c9 bc 80 00

I assume the image is actually in here somewhere, but how to actually display it is a mystery.

When requesting the intercom, responses sometimes arrives in two separate requests from the doorbell. Not sure why ... This could just be a test fault.

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:

• [x] Do both CTPP and CSPB channels need to be open? → No.
• [x] 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 :grimacing:

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 :tada:

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