[HN Gopher] Reverse engineering a car key fob signal
___________________________________________________________________
Reverse engineering a car key fob signal
Author : wolframio
Score : 325 points
Date : 2024-03-14 09:45 UTC (13 hours ago)
(HTM) web link (0x44.cc)
(TXT) w3m dump (0x44.cc)
| bombela wrote:
| 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.
| tiagod wrote:
| >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.
| stavros wrote:
| > A HackRF clone is cheaper than a Flipper
|
| Yes, but a "HackRF clone, plus a Proxmark3, plus IR, plus
| whatever" probably isn't.
| AnarchismIsCool wrote:
| 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.
| stavros wrote:
| That's true, but more people want to do a little bit of
| everything than a lot of something. That's why the Flipper
| is popular.
| twosdai wrote:
| And it has a fun dolphin mascot!
| shon wrote:
| Yeah!
| AnarchismIsCool wrote:
| 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.
| MuffinFlavored wrote:
| what benefit does being able to read the entire ham 70cm at
| once bring/what usecases does it unlock? interested in
| learning
| baby_souffle wrote:
| Comes in handy when you're hunting for a signal but don't
| know where it is exactly. Think flash light with wide
| beam versus narrow beam.
| AnarchismIsCool wrote:
| 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.
|
| https://en.wikipedia.org/wiki/Waterfall_plot#/media/File:
| SDR...
|
| 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.
| hex4def6 wrote:
| Kind of a tangent, but websdr.org is one of those sites
| that you can spend hours searching for interesting radio
| signals in waterfall plots.
| livueta wrote:
| 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.
| wallaBBB wrote:
| 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.
| alias_neo wrote:
| > 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.
| alexb_ wrote:
| Ok but do the clones have a cute dolphin? Very important
| feature
| tibbon wrote:
| 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.
| MuffinFlavored wrote:
| > checking of things
|
| like what?
| greenavocado wrote:
| Door handles
| diggan wrote:
| 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.
|
| Otherwise, it's mostly just for fun.
| 0x457 wrote:
| Out of curiosity - does flipper handle cloning of IC/ID
| 125khz/13.56Mhz fobs and is smart enough to trick the
| receiver into accepting it?
|
| Reading and cloning of those fobs was easy, but the
| receiver wasn't accepting reusable fobs. I had to buy a
| special write-once fob from Lab401.
| byteknight wrote:
| I have both. They both enjoy the warmth of my drawer :)
| bongodongobob wrote:
| Realest comment here. I have a few drawers full of these kind
| of toys I used once and forgot about. Right next to my serial
| cables and bits of wire.
| MikeTheGreat wrote:
| Your post inspired a random but genuine question:
|
| Does anyone have a good use for obsolete cables?
|
| 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.
|
| Maybe a makerspace could make use of them?
| aareet wrote:
| You could make some sort of art - in the climbing
| community old ropes often become chalk bags or carpets
| etc.
| abakker wrote:
| You've made me imagine a doormat made out of old cat5 and
| usb cables, and I'm horrified in an amused kind of way.
| tivert wrote:
| > 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)?
| seidleroni wrote:
| My understanding is that most garage door openers do not use
| rolling keys, they send the same code each time.
| jjtheblunt wrote:
| 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.
| mdip wrote:
| They've been in use since the 90s, actually[0].
|
| 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.
| buescher wrote:
| 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.
| porkbeer wrote:
| They have been rolling codes since the early 2000s. 80s and
| most 90s doors are static codes.
| tyingq wrote:
| Mine has rolling codes and a "learn button" on the head end
| to accept a new remote.
| throwaw33333434 wrote:
| my 2016 gate use rolling codes.
| tkems wrote:
| 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.
|
| [0] https://github.com/argilo/secplus
| tkems wrote:
| 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]
|
| [0] https://www.chamberlain.com/ [1]
| https://github.com/argilo/secplus
| sgerenser wrote:
| 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).
| sgerenser wrote:
| 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.
| tzs wrote:
| 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.
| 0xfeba wrote:
| What a refreshing article. One I can understand for a change.
| mdip wrote:
| Just keep hanging around here and you'll start understanding
| more of them ;)
| elif wrote:
| 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?
| orra wrote:
| I find it wild how pervasive passive keyless entry is.
| Completely form over (security) function.
| SR2Z wrote:
| 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.
| elif wrote:
| tumber locks are built on even more hopes and dreams than
| security.
|
| proper PSK cryptographic locks can (and are) implemented for
| cars already, just not all cars.
| mmh0000 wrote:
| 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.
| MuffinFlavored wrote:
| 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?
| VBprogrammer wrote:
| It's a super common form of theft in the UK at the moment.
| Not sure exactly what equipment they are using but it's
| clearly consumer level.
| ihattendorf wrote:
| One example:
| https://youtu.be/uxzm_6SYBFo?si=BSav_oEKiFBT8cf8&t=41
| topspin wrote:
| 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.
| MuffinFlavored wrote:
| isn't the car keyless go system the transponder and the key
| fob the receiver or vice versa?
| topspin wrote:
| 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.
| JosephRedfern wrote:
| There's also a gnu-radio flow graph which serves a similar
| purpose: https://github.com/bastibl/gr-keyfob.
|
| Presentation here: https://www.fleark.de/keyfob.pdf
| pajko wrote:
| And there's a multiformat receiver block too:
| https://github.com/merbanan/rtl_433
| zzz999 wrote:
| Just buy a fob from eBay and program it using your car...
| Instructions can easily be found online
| platz wrote:
| 429 Too Many Requests = no images lololololol
| lukasm wrote:
| > Receiving/analyzing raw signals
|
| Stock Flipper can receive raw signal.
| mordae wrote:
| https://www.ti.com/lit/ds/symlink/cc1101.pdf
|
| 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.
| gigel82 wrote:
| 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).
| 0x457 wrote:
| I think what you wish is your phone to be your car key.
| imp0cat wrote:
| And you can already have that!
| 0x457 wrote:
| Yes. However, I'm only aware of a Tesla that actually turns
| your phone/watch into an actual proximity key fob.
|
| Not to be confused with what others do:
|
| - open an app
|
| - login again because devs can't figure out persistence
| between updates
|
| - wait for thing to connect and load slow af UI
|
| - click on unlock button in the app
|
| - wait
|
| - wait
|
| - wait
|
| - wait
|
| - give up
|
| - do not renew service after 1 year trial expired because
| it never worked
| sebk wrote:
| 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.
|
| [1]https://www.apple.com/ios/carplay/available-models/
| vel0city wrote:
| 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.
| fileoffset wrote:
| New BYD EVs come with a credit card sized NFC key which can be
| used to unlock and start the car...
| rainbowzootsuit wrote:
| 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>
|
| https://wp.nastf.org/?page_id=367
|
| https://wp.nastf.org/wp-content/uploads/2023/07/ApplicationC...
| swamp40 wrote:
| 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.
___________________________________________________________________
(page generated 2024-03-14 23:00 UTC)