After the Wired article today, I’ve received a couple of email from
people who are concerned that the USRP could be used to clone their
keyfob transmitters for car alarms and garage doors. I’m not concerned,
since there are already many ways to do this (just check the back of
pupular science magazine). However, I am curious about it. I know that
we can capture and play back any rf signal. The question is whether
that replayed signal would result in the door being unlocked. I was
under the impression that most of those systems allow an unlock code to
only be used once, but does anyone out there know for sure?
Matt
On Tuesday 06 June 2006 05:59, Matt E. wrote:
After the Wired article today, I’ve received a couple of email from
people who are concerned that the USRP could be used to clone their
keyfob transmitters for car alarms and garage doors. I’m not concerned,
since there are already many ways to do this (just check the back of
pupular science magazine). However, I am curious about it. I know that
we can capture and play back any rf signal. The question is whether
that replayed signal would result in the door being unlocked. I was
under the impression that most of those systems allow an unlock code to
only be used once, but does anyone out there know for sure?
“It depends”
Some car systems are pretty sophisticated and cycle through codes to
prevent
replay attacks.
AFAIK most garage door openers are pretty simple, although I guess it
would be
fairly easy to check by listening to one and seeing what, if anything,
changes from press to press.
Microchip make a tx/rx pair that has funky crypto (although I haven’t
looked
at how good it really is).
Don’t forget dorbells! I have a 433MHz wireless doorbell which could be
cloned
Michael M. wrote:
Matt
keypress. It’s hard to really see what the data is. Is there anything in
GnuRadio that will let me measure the pulse widths?
Thanks for looking into this. I think that most keyfobs use SAW
oscillators instead of crystals to save money. This results in very bad
frequency drift, which the receiver will need to compensate for.
Matt
Matt E. wrote:
Thanks for looking into this. I think that most keyfobs use SAW
oscillators instead of crystals to save money. This results in very
bad frequency drift, which the receiver will need to compensate for.
Matt
Many of these systems use OOK (On/Off Keying) of the SAW-based
transmitter. The receiver is a wideband
TRF design, with square-law detector and post-detector gain. The
fact that the transmitter drifts is of little
consequence, since the receiver has a large bandwidth. Since each
receiver has a “unique” address code
that it responds to, the fact that there may be other transmitters in
the vicinity doesn’t seem to matter that
much.
Matt
I just took a look at my car’s keyfob with the USRP RFX400 board (it
seems
to transmit around 433.923MHz. It is using FSK modulation, a few tens
of
kilohertz deviation. It demodulates pretty well, but the centre
frequency
isn’t very stable (Is there any way to automatically detect the centre
frequency within a range?)
Just eyeballing the data with the scope, it seems to change with every
keypress. It’s hard to really see what the data is. Is there anything
in
GnuRadio that will let me measure the pulse widths?
Mike
Johnathan C. wrote:
I looked up the FCC ID for mine. It’s allocated for use between 314.5
and 315.5 MHz, which is I’m sure to allow cheap oscillators to be used.
Woah…the FCC search has a “detail” option that comes up with a list of
PDFs describing the whole key fob (URL will wrap I’m sure):
https://gullfoss2.fcc.gov/prod/oet/cf/eas/reports/ViewExhibitReport.cfm?mode=Exhibits&RequestTimeout=500&calledFromFrame=N&application_id=102455&fcc_id=‘CWTWB1U331’
In my case:
CIRCUIT DESCRIPTION
TRANSMITTER
The hand-held RF transmitter consists of the housing, three or four
control buttons, microcontroller, an UHF oscillator (Colpits
configuration) and a 3 volt battery. The microcontroller uses an
internal oscillator running at 4.0 MHz, and the RF oscillator uses a SAW
based oscillator to resonate at 315.0 MHz. The modulation format used
will be ASK, with a Rolling/Manchester code data format. Once the user
presses a button power is applied to the microcontroller which turns the
RF oscillator on and off at the rate of the Rolling/Manchester code data
being sent. The signal is then sent to the receiver module via RF data
transmission. The module will then act upon the RF data received and
will perform certain functions in correspondence to which transmitter
button is pressed.
-Johnathan, AE6HO
On 6/6/06, Johnathan C. [email protected] wrote:
… the sequence seems to change with each
key press. See attached JPEG.
I sure hope it changes every time. or you just posted your car keys
on-line 
Michael M. wrote:
I just took a look at my car’s keyfob with the USRP RFX400 board (it seems
to transmit around 433.923MHz. It is using FSK modulation, a few tens of
kilohertz deviation. It demodulates pretty well, but the centre frequency
isn’t very stable (Is there any way to automatically detect the centre
frequency within a range?)
Might be one of these …
http://pdfserv.maxim-ic.com/en/an/AN3765.pdf
The older SAW filter designs would “wiggle” the TX frequency to
compensate for any slight mismatch between the TX and RX filters.
-rick
Michael M. wrote:
I just took a look at my car’s keyfob with the USRP RFX400 board (it seems
to transmit around 433.923MHz. It is using FSK modulation, a few tens of
kilohertz deviation. It demodulates pretty well, but the centre frequency
isn’t very stable (Is there any way to automatically detect the centre
frequency within a range?)
Just eyeballing the data with the scope, it seems to change with every
keypress. It’s hard to really see what the data is. Is there anything in
GnuRadio that will let me measure the pulse widths?
I looked up the FCC ID for mine. It’s allocated for use between 314.5
and 315.5 MHz, which is I’m sure to allow cheap oscillators to be used.
Found it with the TVRX at 314.875 MHz. Looks like OOK with a minimum
pulse width of 250us. Like yours the sequence seems to change with each
key press. See attached JPEG.
-Johnathan, AE6HO