Garage Door Hacking!
When we bought this place, it had two electric garage door openers. One never functioned, and the other took some finesse and later some repair (replacing a leaky electrolytic capacitor) to get working. But it does work, there’s just one teeny tiny problem…
It’s from probably the late 90s, or perhaps the early 2000s at the latest, and well… remote control security from that era has been demonstrated to be pretty weak, and I grow increasingly worried that with the proliferation of devices like the Flipper Zero, it’s only a matter of time until some little cunt driving down my street broadcasting signals in the several-hundred-megahertz range opens my garage up when I’m not paying attention.
So since I have the extra opener controller, I figured I’d take a look and work out if I can replace it with something better. What? Why, some internet-of-shit of course! The plan was to rip out the receiver portion, replace it with an ESP32 or ESP8266, that listens for MQTT events, and hook it all up to Home Assistant. I even had grand visions of configuring HA’s Android app to pop up on Android Auto when we come into range of home, so you could just hit a giant “open the pod bay doors, HAL” button on the dash. Eyes sparkling with possibility, I set out to figure it out.
The receiver is connected to the main controller board by five pins across two pin headers, so I figured it was a pretty good chance I could reverse engineer the protocol it spoke, then simply make a replacement board with a microcontroller and off I go.
First step, google for prior art. I found some mention of garage door controllers speaking HART internally, so I bookmarked a guide. Beyond that, I didn’t find much.
Next, start probing the pins. From just observing circuitry, I noticed I’d severely miscounted. The two pins at the far end, and one of the pins on the three-pin header are all grounds. Careful probing with a scope revealed that of the remaining pins, the end one is +5VDC and the other is some sort of communications that uses 5VDC, unipolar, and what appears to just be a serial protocol.
At this point I started wondering how it’d do the learning mode, so I searched for single-wire bidirectional protocols. I did find “1wire”, but this didn’t look anything like it. I also looked at RS-232, RS-422, and RS-485, but came away more confused than I was.
I spent a little time trying to pick out the smallest pulse width, and I figured it was about 28,800 baud (my working out: the smallest observed pulse width was ~35uS, which I think works out close to the 34.5-ish of 28,800)… far higher than the 1200 baud used in the HART examples. But fuck it, it looks like serial, so hook it up to a MAX232 and let’s see what I see.
I knocked together a quick serial python program to open the port and print the hexadecimal values of what I captured and… nothing. I tried various port rates, stop bit, and parity settings, and nothing made any sense. I tried using the scope (after checking to see if my scope had serial decode support, apparently some do, mine appears not to) to see if I could work out where the start/stop bits were, and I noticed that I couldn’t really tell… it just seemed like a stream of ones and zeroes of varying lengths and nothing else.
After several hours, it dawned on me. I don’t think this is proper digital communication at all. I’m almost certain the reason it’s noisy is because the receiver is just sampling the RF signal, and dumping the digital representation of it, and all of the logic happens on the controller. The receiver’s only on a separate board to allow it to use different frequencies, methinks.
This is very unfortunate, because it means my plan of making my own receiver board is mostly flawed: the best I can do is figure out how to make a signal that looks like the binary representation of a remote, set the controller into learn mode, and trigger it. That’d work, but not give me the full “user experience” I’m looking for (like being able to tell the state of the door). Worse still, if it’s rolling code (the jury’s out on that, there’s conflicting literature on the remotes and controller, I am suspecting it’s not though) I would have to figure out that as well.
On the whole though I think I’m going to pause this… I can probably do better by just replacing the entire thing with a Shelly instead? I’ll need to think.
Other information I might want: the controller itself is based off an MC908JL3ECDWE, which is an 8-bit microcontroller. The remotes are Guardian 303RTX, which are rebranded a bunch of different times, but broadcast on 303mhz. I’m 99% sure they’re fixed-code, but there are no DIP switches so I’m not sure. I thought maybe the 7 diodes soldered on the board were how the code was set but I have two remotes with the exact same diode settings and they have different codes.
fwagglePublished:
Modified:
Filed under:
Location:
Horsham, VIC, AustraliaNavigation: Older Entry Newer Entry