Security+ 2.0 wireline usage?

[dcode]

I'm interested in implementing a device that can interact with the Liftmaster systems that use Security+ 2.0, but from a wired interface. Looking at the patent application you linked, it reads:

[0097] So configured, a given movable barrier operator, using a single protocol, can Successfully communicate with
both wireless and wireline-based user interfaces.

So, seemingly the encoding would be the same, but how would you interact with the two-wire interfaces? Namely, I'm interested in receiving state information that is presumably transmitted by the wall-mounted opener. My garage door opener has a wireless light, a wall mounted operating panel, a deadbolt, and a battery backup. Presumably all the state information is transmitted using the wireline protocol.

Any ideas how one might transmit and recieve those wireline signals?

[argilo]

Unfortunately I don't know anything about the wireline protocol, and I don't have any equipment that uses it. If you can probe the data lines using a logic analyzer, that would be a good way to start reverse engineering the system.

[PaulWieland]

I am investigating this very same thing. Just found this repo and am hoping to find answers.

Here is the original post I started on stack exchange.
https://electronics.stackexchange.com/questions/598717/reverse-engineering-garage-door-opener-signal

I now have a bunch of recorded signals that I have decoded, but I do not know how to interpret them. I am hoping that someone here might recognize whether the wired signal is the same as the wireless one and that this library might give some clues as to how to interpret the data.

[PaulWieland]

Here's my gist with some of the recorded signals and my attempt at decoding them (can be executed in your web browser's console).

I've made a lot of assumptions so far. One of them is that there are three messages with each event and that the first and third messages are sent by the button, and the second message is some sort of response from the opener. This assumption may be totally wrong.

You can see the middle message is pulled closer to 0v than the first and third - which is where i came up with the theory about it being two different devices sending the signals. Anyway, the decoding effort in the gist focuses on that first message of the three.

And here's the result of the decoding one of the "handshake" signals (just the first of three). This handshake happens whenever the wired button is powered on. A different message is sent every time the button is powered on.
01010101011 01000000011 00000000011 00101000011 00011110011 00110101011 01101010011 01011010011 00110110111 01111101111 01011111011 00010010111 01110100011 00101110011 00111100111 00111101111 01011000111 01101111011 01001010111

A few ms later, another message comes through, then a short pause of a few ms then a final message.

I'm assuming the first bit is a start bit (it's always LOW) and the last two bits are stop (they're always HIGH). The 8 in the middle become:
10101010 10000000 00000000 01010000 00111100 01101010 11010100 10110100 01101101 11111011 10111110 00100101 11101000 01011100 01111001 01111011 10110001 11011110 10010101

Converted to HEX:
AA 80 00 50 3C 6A D4 B4 6D FB BE 25 E8 5C 79 7B B1 DE 95

@argilo - if you have any insight into this, it would be really appreciated!

[PaulWieland]

Here is a capture straight from my scope of the first message:
https://pastebin.com/raw/hibfC5L5

And here is a zoomed out capture which contains all three messages (at lower resolution though)
https://pastebin.com/raw/aP1BwsV9

Right now I am trying to load these into PulseView to see if it can decode them, but so far I haven't had any lucky importing the CSV.

@argilo Is there any better approach to this?

[PaulWieland]

I solved this. Here is my project which gives wireline control over the door.

[argilo]

I now have some wireline equipment to experiment with, and I've added support to secplus.

The devices use 9600 baud serial (8 data bits, no parity, 1 stop bit). I used a voltage divider to drop the 12V signal down to 3.3V, which I could easily decode and log on a Raspberry Pi Pico. (I expect it will be possible to transmit with a Pico as well, by running the UART output pin to a transistor which would short the data wires.)

The packets are 19 bytes long. The first byte (0x55) probably signals the start of a packet, the second byte (0x01) may indicate the payload type (1 = "supplemental data payload"), and I'm not sure what the third byte (\x00) means. The remaining 16 bytes are the two halves of a Security+ 2.0 packet. As noted in #6, secplus can now handle the supplemental data payload. I also added encode_wireline and decode_wireline functions to encode and decode 19-byte serial packets.

The next task is to determine what the 32-bit "data" payloads (and 8 upper bits of the "fixed" data) mean.

[PaulWieland]

I ported the code generator over from stm8 assembler. The problem is that it’s copyrighted so I cannot publish the source code. That’s why ratgdo uses a database of pre-generated codes.

But if you have any questions I’m sure I can help.

EDIT: every wireline message starts with 0x55, 0x01, 0x00. This is just a header of some kind.

[argilo]

@PaulWieland I decoded the hard-coded packets from ratgdo, and noticed a couple unusual things:

1. The remote_id value is zero.
2. The rolling code for DOOR2 is out of sequence. The rolling codes for DOOR1 - DOOR7 are: 41045, 75440214, 41047, 41048, 41049, 41050, 41051.

[argilo]

Do you have any useful insights into the meanings of the data bits? At the moment I'm just pushing buttons and writing down which bits come out.

Interestingly, it seems like the opener is also a transmitter, and it sends out status messages.

[PaulWieland]

I should mention that the rolling code version is on a different branch at the moment. There you will find the database with 64,000 pre-generated codes.

You are correct that the opener transmits data, but these messages do not seem to be needed by the wired button. As long as you transmit the right messages, the opener will respond.

When the button is rebooted, it will send a sequence of messages to the opener. I am calling these "reboot" or "sync" messages as they seem to be used to tell the opener what counter value the button is on and they are sent when the button is rebooted. After the reboot/sync happens, the light on the button will stop flashing and the door opener will begin responding to light or door open commands.

On 50 series logic boards, you can send the sync message and the door opener will then accept an open or light command. In effect, its a simple replay attack (this is how ratgdo 1.0 works). What I found out though is that older door openers with 45 series logic boards do not accept sync messages if the counter value is re-used.

Each 16 byte code is generated from a 32 bit counter combined with a message type. The message types are as follows:

reboot1 = 0x0100908000;
reboot2 = 0x0000618b04;
reboot3 = 0x0000b18000;
reboot4 = 0x0000809203;
reboot5 = 0x0000809203; // repeat of reboot4, but with next counter sequence
light = 0x0000928102;
door1 = 0x0101828002;
door2 = 0x0100928002; // not needed

Four 32 bit numbers are then generated and then assembled in an out of order sequence. The numbers are stored at memory addresses:

0x67
0x6b
0x73
0x77

Those four 32 bit numbers + the 3 fixed header values are then assembled into a 19 byte code as follows:

0x55 // 0
0x01 // 1
0x00 // 2

mem[0x6f] // 3

mem[0x6b] // 4
mem[0x6c] // 5
mem[0x6d] // 6
mem[0x6e] // 7

mem[0x68] // 8
mem[0x69] // 9
mem[0x6a] // 10
	
mem[0x7b] // 11

mem[0x77] // 12
mem[0x78] // 13
mem[0x79] // 14
mem[0x7a] // 15

mem[0x74] // 16
mem[0x75] // 17
mem[0x76] // 18

[PaulWieland]

I just remembered two of the bytes (position 3 & 11) are not from the 4 32 bit numbers.

I'll have to dig through the code again to refresh my memory on what 0x6f and 0x7b are based on.

[PaulWieland]

@argilo can you post an example of how to use your library to generate or decode wireline messages?

[argilo]

$ python3
>>> import secplus
>>> packet = bytes.fromhex("550100453df7db6dbedbee943ffffeff1faeff")
>>> rolling, fixed, data = secplus.decode_wireline(packet)
>>> print(rolling, fixed, data)
128 0 16814208

>>> new_packet = secplus.encode_wireline(rolling + 1, fixed, data)
>>> print(new_packet)
b'U\x01\x00D=\xf6\xff\xff\xf7\xff~\x85-\xbe\xdfoV\xcb\xef'
>>> print(new_packet.hex())
550100443df6fffff7ff7e852dbedf6f56cbef

[argilo]

Here's an example that can reproduce ratgdo_codes.hex:

import secplus

fixed = [0x0000000000, 0x0400000000, 0x0000000000, 0x0300000000, 0x0200000000, 0x0200000000]
data = [0x01009080, 0x0000618b, 0x0000b180, 0x00008092, 0x01018280, 0x00009281]

with open("ratgdo_codes.hex", "wb") as f:
    for rolling in range(128, 128+64000):
        packet = secplus.encode_wireline(rolling, fixed[0], data[0])
        f.write(packet[3:])

        for i in range(1, 6):
            packet = secplus.encode_wireline(rolling, fixed[i], data[i])
            f.write(packet[6:8] + packet[10:11] + packet[16:])