Is it possible to use 433MHz ASK modules s.a. RXD1 with Arduino, connected to my PC, to snoop on communication between a 433MHz keyfob used to open my garagedoor, and the door-controller ? This is a 100% legit application, and for use within my own house.
I attempted a very simple experiment where-in I rigged up the RXD1 with Arduino as explained by the VirtualWire-1.5 documentation, i.e. connect the “Data” out of the RXD1 with one of Arduino’s digital input ports, and reading this pin every 100ms, and print it on the serial console. What amazed me was that even without any known 433MHz source nearby, the receiver kept picking up what might be noise… I am not sure though.
Could someone explain how, without a Scope, Logic-Analyzer, or other expensive RF test/measurement gear, can I figure out the code sent out by the garage-opener keyfob-remote ? Is the 100ms delay in my Arduino code, “too long” ?
Depending what you want to use for, it is usually easier to get another FOB and just harvest and modify the circuit board. I have seen several examples on the web where people just removed the buttons and attached the controller outputs to those connection points.
This is generally done because most modern garage openers have an algorithm to change the code every time. This algorithm is put in as a security feature, as well as allowing more openers to operate in a compact urban environment.
diamus:
Depending what you want to use for, it is usually easier to get another FOB and just harvest and modify the circuit board. I have seen several examples on the web where people just removed the buttons and attached the controller outputs to those connection points.
This is generally done because most modern garage openers have an algorithm to change the code every time. This algorithm is put in as a security feature, as well as allowing more openers to operate in a compact urban environment.
Thanks @diamus. That’s a great idea, yet springs up some new challenges –
Wasn’t aware of this code-hopping business, so will need to figure out how it is done. In fact I was hoping to do some such code-hopping, myself to secure such communication.
Also, I was also interested in the “receiver” side, as I am hoping to receive such message on the Arduino connected to my PC, trigger a Processing app to fire my webcam.
Code hopping seems to be an ordinary pseudo-random number generator (PNG, computer science).
The first random number used for a new remote is the seed. Every successive number is predictable by the receiver (door opener controller) since it and the sender have the same idea of the PNG sequence algorithm and number of bits in each PNG number (say, 12).
I understand that the receiver will accept any of the next n possible PNGs (n is about 200) so that extra pushes of the remote won’t get the two out of synch.
And I believe that the controller must remember in non-volatile memory the last valid PNG for every paired remote. The controller has a “learn” button, to accept and store a new remote’s PNG.
This is what I understand “rolling codes” to be. The standard C library’s PNG could be used, if the modulo is adjusted to n bits. One could use say 16 bits of PNG. I think controller use 12, and send two bytes, with 4 bits being the function code such as door 1 open, lights on, etc.
I may be wrong on some or all of this - because if you know the brand of the remote, you know what PNG algorithm/modulo it uses, and you could, I suppose, calculate how to do a replay attack.
stevech:
Code hopping seems to be an ordinary pseudo-random number generator (PNG, computer science).
The first random number used for a new remote is the seed. Every successive number is predictable by the receiver (door opener controller) since it and the sender have the same idea of the PNG sequence algorithm and number of bits in each PNG number (say, 12).
I understand that the receiver will accept any of the next n possible PNGs (n is about 200) so that extra pushes of the remote won’t get the two out of synch.
And I believe that the controller must remember in non-volatile memory the last valid PNG for every paired remote. The controller has a “learn” button, to accept and store a new remote’s PNG.
This is what I understand “rolling codes” to be. The standard C library’s PNG could be used, if the modulo is adjusted to n bits. One could use say 16 bits of PNG. I think controller use 12, and send two bytes, with 4 bits being the function code such as door 1 open, lights on, etc.
I may be wrong on some or all of this - because if you know the brand of the remote, you know what PNG algorithm/modulo it uses, and you could, I suppose, calculate how to do a replay attack.
Thanks @stevech. That’s a pretty nice summary, and having skimmed some bits-n-pieces on Keeloc (from Microchip folks), I think it’s pretty much in line, although I didn’t quiet figure out as to what role does the 40-bit or (later) 60-bit block-cipher play in all this. I mean, if one relies purely on PNG algo & secret seed of the remote, why use block cipher, unless the PNG’s outcome is used as the cipher’s shared-key!
Does anyone have an idea of what “code learning” (as in the initial sync between remote and base-unit/controller) is, and how it is done ?
“Code Learning” is most likely just the remote and receiver syncing with the same seed number for the PNG. Again, it would depend on the specific manufacturer.
It might be easier to save your pennies and get an Xbee setup to handle comms between a remote and your PC. Something like this would be a great start:
diamus:
“Code Learning” is most likely just the remote and receiver syncing with the same seed number for the PNG. Again, it would depend on the specific manufacturer.
Okay, that makes sense.
diamus:
I retract my suggestion, if the point is to tinker with something to just figure it out.
That (tinker & learn) was definitely definitely one of the prime objectives.