By Robert Quattlebaum darco@deepdarc.com
Keywords: Remotizer, Teardown, Hack, Reverse Engineering
Official device website: http://www.remotizer.com
- Microchip PIC18F23K20 8-bit Microcontroller http://ww1.microchip.com/downloads/en/DeviceDoc/41303G.pdf
- Micrel MICRF219A ASK/OOK Receiver http://www.micrel.com/_PDF/MICRF219A.pdf
- ???
- DEBUG SERIAL OUT 9600 BAUD
- PGC
- VSS
- PGD
- ???
- VDD
- VPP/MCLR/RE3
UNLock. Batt level XXXXmV\r\nLearn mode.\r\nClear mem\r\n
- P1A -> LED
- RC3 -> MICRF219A.SCLK
- RC5/RB1 -> MICRF219A.DO
TODO: There is a lot more remaining to figure out:
- Optical stop (power, signal).
- H-Bridge control pins (power, direction)
- Motor current
- Battery Voltage
- Learn Button
- TP1 -> RB3
- TP2 -> ???
- TP3 -> ???
- TP4 -> RC3 (SCLK on MICRF219A)
- TP5 -> RC5/RB1 (DO on MICRF219A)
The remotizer "learns" remotes that you can buy. Marketing materials for Remotizer say there are over "4 billion" different codes. This likely means a 32-bit identifier of some sort.
Considering the simplicity of the learning mechanism and the high unliklihood of them using asymetric cryptography, it is quite likely that the system they are using for learning new remotes is not secure in any cryptographic sense.
The actual signal sent from the keyfob, not including the pramble, is a pulse-width modulated 69 bit code. The preamble and code is sent out four times per keypress.
There is no mention of "rolling codes" in the marketing literature, but that does appear to be what they are using:
The rolling code mechanism they are using is likely some sort of LCG permutation that loops through all 4 billion values. Each FOB is initlaized with one of these values and simply takes a step forward each time a button is pressed. They may end up using something more complex than an LCG, but in any case it doesn't really matter. Once you know the algorithm, the lock is broken and the security it little better than broadcasting a static code.
We could probabbly do some quick sanity checks on the values to see
if they are using any common LCG values for A or C. There may also
be an algorithm for determining LCG parameters from several outputs.
One of the properties of an LCG random number generator is that the least significant bit is also the least random: it is simply the inversion of the least significant bit of the input (previous) value. Based on a non-scientific observation of the codes, this appears to NOT be the case here... Which means this probabbly is not a LCG.
Ultimately, reverse engineering the firmware is the way to go to figure out the code generation algorithm. If the chips are locked, then glitching may be able to help extract the data.
