I had to reverse engineer some cheap key fob purchased on AliExpress for an electronic project. It was simple enough that thanks to an oscilloscope and wikipedia I was able to do it after persisting long enough.
Next time I will try the method from this blog post. And maybe become a better hacker.
> These keys are generated and tracked using a counter which has to stay in sync between the remote and the car. This ensures that the car doesn’t reuse an old key, and that the remote always generates fresh keys.
Something I've always wondered about is, how do learning remotes defeat this?
My car has a couple of built-in garage door buttons, and I'm pretty sure I programmed it by just hitting the remote button in the garage while the car was in a learning mode. Is that a much more sophisticated feature than you would assume (e.g. decoding the signal, recognizing the type, then initiating a pairing with the opener, instead of just replaying the signal)?
This sounds like HomeLink and is indeed more complex. My understanding of it is that they partner with lots of companies to support their rolling/fixed codes and remotes so that they can be paired to your garage door.
I linked this in a sub comment, but the largest garage door maker in the US is Chamberlain [0] (which owns a ton of other brands) and uses known rolling code algorithms that can be decoded. [1]
My understanding is that the earlier rolling code systems are easily defeated and I think this can be done (possibly with stock firmware) using a Flipper Zero.
Prior to that, garage doors had a set of DIP switches (16, or 32, I can't remember). You matched the switch configuration on your opener with the switch configuration on the controller. And as you might imagine, in a typical suburban area about 80% of the garage doors are set to all zeros.
Because the range of the devices was "lucky if you can open the door from the bottom of your driveway", most people didn't notice this. Of course that meant you could open a large number of garage doors by sending the "0" signal for each manufacturer with enough wattage.
Compatible models are made by reverse engineering each individual model's rolling code implementation (in the early days) and making an accessory that had the necessary seed value or other component to allow it to be "paired" with a compatible door head unit. Considering it wasn't uncommon for the higher-end models to charge $150 for an accessory remote, manufacturers had a bit of incentive to roll their own slightly incompatible implementations.
This is from memory and minimal memory at that, but -- late 90s or early 00s, I think, "HomeLink" was created, which basically allowed car manufacturers to integrate a door opener into the car. If you bought a higher-end model, your visor might have the buttons in it. I believe licensing allowed third-parties to easily create fully compatible accessories at that point (pay a fee, get the patent license/datasheets sort of arrangement).
[0] Genie thinks they were first in 1995 but I seem to recall we had a rolling code door installed as early as 1993.
There were also so-called "learning codes" that overlapped substantially with the introduction of rolling codes. Think fixed-code remotes with a random preprogrammed code instead of dip switches. Chamberlain's "billion code" is representative. They have to be paired with the opener receiver in the same way as rolling code remotes.
The largest garage door manufacture in the US uses the Security+ and Security+ 2.0 algorithms that are rolling, but can be fairly trivially decoded to gain the serial number and rolling value of a remote. [0] This is how the flipper zero decodes remotes for playback later.
They use rolling frequencies at least our 2021(?) garage opener does, to retry in the presence of narrow band noise from fcc violating devices. We seem to have neighbors blasting rf in the band that our previous builder installed 2014 model used, because it rarely worked unless super close.
You have it backwards, the main garage opener is doing the learning, the cars button is just transmitting a signal. Doing this process, you’re telling your garage door opener “hear this new remote? Please allow him to open the door as well.” Presumably the car side buttons just cycle through a few common protocols (realistically there’s only 4-5 ones in common use, almost all garage door openers I the U.S. are made by Chaimberlain/Liftmaster or Genie).
Actually I take it back, there might be learning on the car side as well, where you press a button on an existing remote, but all that does is tell the car “Oh, this is a Chamberlain SecurityPlus 1.0 remote, I’ll start acting like one of those.” The actual rolling code and security algorithm is never decoded/cloned on the car side.
Let's start with fixed code systems. In those the remote sends the same signal every time. There will usually be some way to customize this signal, such as a set of DIP switches in the remote and in the head unit so that you can set your system to a different fixed signal than you neighbor's fixed signal.
A learning remote for such a system could work by simply replaying whatever it heard when it recorded during learning. So if you press the "learn" button, press the button on your current remote, and then do whatever tells the learning remote you are done it could save everything its radio picked up during that few seconds, and then play that back whenever you press the open/close button.
You probably wouldn't want to take that bare bones approach though. The recording might include other things. Suppose while you are setting it up someone happens to come to your house and press the button on your wireless doorbell, which just happens to operate in the same band as your garage opener. That gets picked up and is part of your recording.
You don't notice this when you test the recording afterwards because you are in the garage and can't hear the doorbell, but your spouse inside is getting spurious doorbell dings. It might take a while for someone to realize that your plague of spurious doorbell rings is connected to the garage door.
You'd want to at least look at the recorded signal and crop it down to just the part with the actual door signal. If the signal has both a door signal and something else like the aforementioned wireless doorbell the new remote might pick the wrong one, but in that case you'll know right away and can try again.
Better would be if the new remote could actually decode the signal to get the code, and then generated a new signal with that code every time. The record and replay method, even if cropped down to the right signal, might have recorded a weak or noisy signal which might be hard for the header for end to handle. By figuring out the code and generating a clean strong signal every time you'll get better performance.
That approach does require understanding the details of the code systems of each manufacturer whose remotes you want to be able to clone.
Nearly every home garage door opener company in the US switched to rolling codes for their new models during the '90s, and so if you are dealing with any system installed less than ~25ish years ago it almost certainly uses rolling codes.
These typically work like this. They have a pseudorandom sequence determined by a seed value. The seed is determined by the remote. I don't know if the seed is built in at manufacturing time or selected at random by the remote when it is first powered up or what. The remote generates the sequence and keeps track of where it is in the sequence. Each press of the open/close sends the next value.
The head end has a "learn" mode. You put it in learn mode and then press the open/close button a couple of times on the remote. The head sees those, recognizes they are in the right format for its system, and is able to figure out what seed would have had to been used for that system's sequence function to produce those two consecutive values. It adds that to a table of known remotes.
In operation when you press open/close, the head decodes the signal to get the sequence value, checks its table to see if that matches the value it expects from any of the known remotes. If it does the door operates and it updates its idea of where that remote is in its sequence.
There's some slack in there so that it will accept a sequence value several values ahead of what it last saw from a remote so if say your bored kid on a trip pressed the remote button a dozen times you won't get home and find your garage won't open.
You could make a learning remote that could clone an existing rolling code remote by following the same procedure the head follows for learning a remote. The learning remote would have to know the rolling code systems for all the systems it supports, but that would be doable.
The problem would be if you got the learning remote because you wanted an additional remote. To the head end the cloned remote is the original remote. Say you have one remote and two people, and you clone the remote this way. As long as neither of you goes too long without using their remote it would be fine. But if for some reason one of you doesn't use yours for a while the other might advance the sequence past the slack that I mentioned earlier and yours would stop working.
You'd have to re-pair it with the head end. How well that would work would depend on details of the system. If the pairing works by recovering the initial seed value, and that is used as the key for the head's table of remotes, it might cause problems because the two remotes have the same seed but are farther apart in their sequences than the slack.
(I suppose you could clone the old remote, then take the battery out of the old remote long enough for it to re-seed when you put the battery back in--assuming the seed isn't fixed at manufacturing time--and then pair it with the head).
The way every universal remote for rolling codes that I've seen works is that you don't use an existing remote to teach them. They have a way to tell them what your head end is. You do that, then you pair them with your head just like you would pair a new remote bought from the head's manufacturer.
These things don't usually have rich user interfaces. Telling it what system you have will probably mean looking up a number in a table in the manual, and then pressing some button on the remote (probably hidden in the battery compartment so it won't accidentally be hit), then pressing the button you want to program N times where N is the number you looked up in the manual.
You might need several tries because some manufacturers have changed code systems multiple times. If you don't know what year yours was made you might have to try them all. Even knowing the year might not help. Genie for example has one from 1995, one from 2005, and one that I think is from 2011, and they didn't stop using the old ones when the new ones came out.
It could be a nice feature if the universal remote could look at the signal from your existing remote to learn what rolling code system your head end uses. But it would also mean the universal remote would need a receiver, and that would be the only thing the receiver is used for so it is hard to justify. Pairing with the head and telling the head to open/close the door is strictly one way: remote to head.
Samy Kumar did a project about 10 years back, where he worked out how to brute force a 12 bit garage door code in under 10 seconds, using a childs toy: http://samy.pl/opensesame/
My garage door opener uses a 12 but dip switch config (and my last place used an 8 dip switch config, and I'm pretty sure still does).
Re reading that OpenSesame post was fun. It reminded me of a few names I need to go find out what they're up to these days (Travis Goodspeed and Michael Ossmann are names I remember seeing doing/writing-up some really cool stuff), and that the Mattel IM-ME toy he was using uses that same CC1110 "sub gHz"
OpenSesame is really cool. It depends on the receiver using a shift register and the protocol not having stop bits (or equivalent), otherwise running a DeBruijn sequence that contains all the possible codes won't work.
He decoded everything, but he didn't actually open a car door. He still has to defeat the rolling code. It's not like you can add 1 to it and resend it. From the outside world, the next rolling code should appear random.
Is it hard to brute force? If so, it is still something that can be sniffed, though you can't unlock the car without first recording a genuine button press.
I wish car manufacturers would start making tiny (maybe RFID) remotes I could stick in my (minimalist) wallet. Alternatively, looking forward to a tiny Flipper-like (credit-card sized) that can achieve the same result.
Seriously, the car fob is the largest thing in my pocket after the phone (thickness-wise at least).
There's a standard for this using NFC and UWB, Digital Car Key; BMW has support for either 2.0 (NFC) or 3.0 (UWB) across their entire range. The Hyundai Motor Company group (Hyundai/Kia/Genesis) is starting to add support as well. See [1] for exact models (look for the little key icon). Several other makes are members of the Car Connectivity Consortium that standardized this protocol so it's reasonable to expect wider compatibility in the near future. The protocol incorporates significant countermeasures against relay and replay attacks like some that are mentioned in other comments here.
On my Ford I just walk up to it and it's unlocked and I can start it without taking my phone out of my pocket. I pretty much never carry an actual key on me.
Interesting related development that access to key programming is being put behind some more "security" due in part to easier access of key programming devices, but it's on the manufacturer to say what's part of the "security" system. Not just keys but can extend to tons of modules.
It's arguable if this would have any effect on criminals who are known to follow rules (/s), but will definitely have an impact on some businesses.
A criminal record can disallow participation. One way for people who have a record to enjoy success after serving their sentence is to start and run their own business, but I guess they are screwed. <shrug-emoji></shrug-emoji>
Why bother intercepting, decoding, and encoding your own signal when you can just use a big antenna and MITM the fob and the vehicle and convince them they are closer than they really are?
I wouldn't be so quick to say that - it's unquestionably more convenient than old-fashioned transponder keys in a few really important ways. You can't lock your keys in the car, you don't need more than one free hand to open a door (and sometimes not even that), and you don't need to deal with a massive bundle of keys jangling against your knees.
Honestly... As an end user, I prefer convenience over security in my everyday life. I have insurance for the rare instance someone steals it.
The same goes for my house. I could live in a concrete bunker with no windows and steel doors, but I would much rather live in a home with large windows and a door with a crummy deadbolt.
The risk of someone stealing my car or breaking into my house is low. If that risk increases (and thus the area's overall quality decreases), I'll move to a different location.
These keyless systems enable these cars to be broken into really easily. I’ve had friends see thieves operate in pairs, one by the front door, one by the car, and effectively use repeaters between the house and the car to unlock his Range Rover, and then drive away with it, in under a minute (as captured by his home security system).
The question then becomes more of a value proposition / opportunity cost. If you can steal any keyless car trivially, why wouldn’t you target the vehicles that can net you the greatest return?
what kind of consumer level antenna can forward/amplify key fobs (in the gigahertz range, no?) without causing excess “signal to noise” ratio that the car can detect?
I think your conception of the sophistication of all this is a good deal too high. Fobs are extremely low power devices with truly terrible (undersized) antennas. Fabricating a digital repeater to produce a modest amplification is not difficult. The high frequencies involved are a benefit to the attacker because a high gain antenna remains reasonably portable. The active bits are low cost, widely available COTS digital transceivers and MMICs; the same stuff the fob and vehicle is made from.
A obvious countermeasure for such attacks would be to have the car measure the RTT between the car and fob, exchanging some cryptographic credential. If it takes too long the fob is too far away and/or an attackers repeater is adding delay.
Typically the fob is the transponder. The fob has a tiny battery: frequent transmissions would rapidly kill that battery. The car has an ample battery, so it transmits periodically and detects the responses from the fob transponder.
For the purposes of a "relay attack" this doesn't actually matter: all else being equal you could devise a relay system that works regardless of the roles of car and fob in the protocol.
What’s more interesting is that if you get into a car now, there are OBD tools that just let you program a new key and drive off, which is wildly insecure.
You might be able to get it to output raw demodulated FSK or OOK data without further processing, but I really doubt you are getting raw IQ samples from it.
>Note: Transceiver SDR devices do exist of course, but they tend to be very pricey
A HackRF clone is cheaper than a Flipper, and way more capable in my opinion. I would bet most flippers either lie in drawers or are used by stupid teenager kiddies for trolling.
I've got a Flipper, LimeSDR (non-mini), some old-school ham equipment, a cheapo $10 RTL-SDR receiver, a few cheap HTs, some RFID tools, etc.
Each has their use. The Flipper is nice for quick and lightweight checking of things. LimeSDR is incredibly capable, but also a bit of a pain in the ass to use. Not something you'll flip out to quickly check something or run an experiment.
Biggest value I got from my Flipper was when a security company was installing a security alarm in my business local, and made a claim that their tags were "unhackable" and "unclonable".
~20 seconds and one cloning later, the installer said something like "Wow, guess we need to update the employee handbook" and I no longer felt comfortable with the installation so asked them to leave after that.
I also once forgot the garage opener to the public garage I usually use, but had the signal saved on my Flipper, so that saved me like 5 minutes of not having to park, go home, go to the car and then park inside the garage.
Like, I've got some serial cables, some co-ax, a bunch of old TV cables, some audio cables.
I tell myself I'm keeping them because if I ever need them I'll never be able to (or want to) buy them again. Moreover it feels like such a waste to throw them away.
I have a box in my garage and if cables start overflowing I go through and toss anything that makes it overflow that seems the least useful or likely to be used. It keeps me from starting a new box. :) . I have another box of old gadgets in static bags but I still have a ton of room left in that :)
I'm holding on to my coax for a few more years and then getting rid of all of it (electronics recycling, probably). I am so looking forward to never using coax again.
My local search and rescue team made door mats for their station with old 1/2" ropes. They came out really nicely.
Doing so with serial or coax cables seems like an invitation for bits of the plastic sheath breaking off in a few months and polluting the ground around your door though...
> I would bet most flippers either lie in drawers or are used by stupid teenager kiddies for trolling
I find my FZ most useful, not for the radio stuff, but as a wireless (read: untethered) way to dump and write EEPROMs using a POMONA clip, otherwise, yes, it sits in a drawer.
The flipper isn't really a full sdr though, it just has a very minimalist RF IC that has almost non-existent bandwidth.
For $400 you can get a limeSDR mini that can read and write 30MHz of spectrum at a time, ie the entire ham 70cm band all at once.
If you think a flipper is dangerous, plug in a dummy load and dump noise on L1 then watch your phones GPS stop working, or alternatively decide it's on another continent.
I think it's a case of good marketing and good packaging. Realistically you need a laptop to do serious field stuff with a flipper, but only if you plan on doing any testing and reconfiguration and only initially. The flipper isn't much bigger than the limesdr card, but it's nicely packaged and portable so once you have it ready to go you can throw it in a pocket.
The community also helps. The flipper is wildly overpriced for being a glorified happy meal toy but millions of people squeezing every ounce of functional potential out of a happy meal toy is better than a few dozen people writing academic papers with mostly high end industrial (cellular base station) and military applications.
Depends very broadly on your area of interest, but to throw out some random numbers and thoughts:
If you want to move data between two points, 30MHz of "bandwidth", depending on noise and signal, can be on the order of 30MB/s data rates or more assuming you're good at doing QAM or similar modulation. That's 50x what the CC1101 in the flipper maxes out at
If you want to search for a particular signal of interest (ie why does turning on my LED lamp open my garage door), that's more spectrum you can view at once, about 3x wider than what an RTL-SDR can receive. Similarly, you can view the entirety of a 30MHz wide emission as opposed to only seeing pieces of it.
You could monitor two different narrow bandwidth signal sources that are within ~30MHz of each other simultaneously, ie the 101.5FM broadcast channel and 121.5 airband guard channel. This provides the capabilities of something like a police radio scanner, covering the entire VHF or UHF land mobile band but without having to stop listening to find another signal and the ability to record the entire spectrum capture to disk so you can review all concurrent transmissions separately at a later time.
Above is a spectrum plot of an FM broadcast station using wide FM modulation and with some digital sub carriers on either side for song info etc. Other stations will be to the left and right of it and the "bandwidth" of the receiver determines how wide the plot you can view is.
Decoding trunked protocols frequently involves simultaneously listening to the control channel and data channels. If you only have access to low-bandwidth receivers, you'll need multiple, which gets into time sync problems.
Why would you need such a stack?
Article is analyzing unidirectional fobs, HackRF is half duplex so you could easily capture and analyze and/or replay the signal.
Only additional thing you need is a PC.
One thing to consider is that the payload will be encrypted so you wont be really able to tell apart what is the rolling code.
Hopefully fobs have stronger encryption so collecting enough sniffs and analyzing is insufficient (looking at tesla with their 64bit encryption, hopefully they upgraded).
Honda replay myth mentioned in the article is BS, it was popularized by ppl faking a simple replay attack while doing a more complicated one. If you record the fob command and the car never receives it, of course you can immidiatly after replay it to the car and car will accept it since RC is valid. But if you're sniffing while car is receiving it, RC gets updated.
If Honda didn't have RC, it would have been far worse than the KIA boys (overriding immobilizer protection and hotwiring the car) issue that did a lot of damage to KIA in US.
Next time I will try the method from this blog post. And maybe become a better hacker.