Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverse engineering a car key fob signal

0x44.cc

Post reply on HN
Print view View original

41–50 of 85 posts

Re: Reverse engineering a car key fob signal

#41

Post by tkems »

seidleroni wrote: post #9
tivert wrote: post #7

> 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 th…

My understanding is that most garage door openers do not use rolling keys, they send the same code each time.

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

Re: Reverse engineering a car key fob signal

#42

Post by gigel82 »

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).

Re: Reverse engineering a car key fob signal

#43

Post by tkems »

tivert wrote: post #7

> 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 th…

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

Re: Reverse engineering a car key fob signal

#44

Post by sgerenser »

tivert wrote: post #7

> 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 th…

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).

Re: Reverse engineering a car key fob signal

#45

Post by sgerenser »

sgerenser wrote: post #44
tivert wrote: post #7

> 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 th…

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 b…

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.

Re: Reverse engineering a car key fob signal

#46

Post by mmh0000 »

orra wrote: post #17
elif wrote: post #12

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 find it wild how pervasive passive keyless entry is. Completely form over (security) function.

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.

Re: Reverse engineering a car key fob signal

#47

Post by topspin »

MuffinFlavored wrote: post #25
elif wrote: post #12

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?

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.

Re: Reverse engineering a car key fob signal

#48

Post by rainbowzootsuit »

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.

https://wp.nastf.org/?page_id=367

https://wp.nastf.org/wp-content/uploads/2023/07/ApplicationC...

Re: Reverse engineering a car key fob signal

#49

Post by diggan »

MuffinFlavored wrote: post #23
tibbon wrote: post #20

Earlier quoted context omitted.

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.

> checking of things like what?

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.

Re: Reverse engineering a car key fob signal

#50

Post by livueta »

MuffinFlavored wrote: post #24
AnarchismIsCool wrote: post #5

Earlier quoted context omitted.

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.

what benefit does being able to read the entire ham 70cm at once bring/what usecases does it unlock? interested in learning

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.
Post reply on HN