Live data from Hacker News

Reverse engineering a car key fob signal

0x44.cc

51–60 of 85 posts

Re: Reverse engineering a car key fob signal

#51
post #49

Earlier quoted context omitted.

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

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.

Re: Reverse engineering a car key fob signal

#52
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…

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.

Re: Reverse engineering a car key fob signal

#53
post #42

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

I think what you wish is your phone to be your car key.

Re: Reverse engineering a car key fob signal

#55

Earlier quoted context omitted.

I have both. They both enjoy the warmth of my drawer :)

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.

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?

Re: Reverse engineering a car key fob signal

#56
post #38

> Receiving/analyzing raw signals Stock Flipper can receive raw signal.

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.

Re: Reverse engineering a car key fob signal

#57

Earlier quoted context omitted.

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.

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?

You could make some sort of art - in the climbing community old ropes often become chalk bags or carpets etc.

Re: Reverse engineering a car key fob signal

#58
post #57

Earlier quoted context omitted.

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?

You could make some sort of art - in the climbing community old ropes often become chalk bags or carpets etc.

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.

Re: Reverse engineering a car key fob signal

#59

Earlier quoted context omitted.

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

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

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.

Re: Reverse engineering a car key fob signal

#60
post #3

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

[deleted]
Post reply on HN