I've had a good few emails regarding this page, which I always appreciate. :)
Some people wanted to know where they could get hold of their own RF receiver module such that they could use the code I have provided below. As luck would have it, a company is currently selling some off cheap on eBay - link here. This is the module I am developing with at the moment - it uses a superhet (rather than regenerative) architecture, so is fairly sensitive.
Also, people were interested in a more generic version of the receiver, that would be able to listen-to and decode any 433 MHz device rather than just the specific Peugeot and Vauxhall ones I have written code for below. As a result, I've started working on a more generic receiver. The code should be available on this site soon.
This site details the analysis of some popular Remote Keyless Entry (RKE) key fobs. They are typically used to lock and unlock cars, but can be used for all sorts of things, garage doors for examples.
I wanted to try to analyse and decode the data transmitted by these key fobs, more out of curiosity than anything else. Using a generic receiver module I'll write some code using a PIC to decode the key fobs on the fly, perhaps storing the data for further cryptanalysis.
For reasons given below, analysing and decoding the data transmitted by these fobs won't really help us break into cars. Lobbing a brick through the window is probably a damn sight easier than studying the key fobs anyway, if you did want to break into a car...
The very first key fobs in the early 90s used a static code system. That is to say that the fobs transmitted the same code every time the button was pressed, and all the car had to do was listen for that static code and when it received it, unlock the car doors. This system is clearly insecure, as all an 'attacker' would have to do is 'sniff' the code without the owner knowing, then replay it back to the car whenever they want to get in.
To combat this problem, rolling codes were introduced. This is a system whereby the key fob has a counter built in that increments by 1 every time the button is pressed. The car remembers what the count was last time the doors were successfully unlocked (i) and next time it receives the signal it checks that the count is somewhere between i+1 and i+n, where n could be any manufacturer-defined number between approximately 16 and 256 (just incase the fob has been pressed away from the car).
On the surface, it looks like it may still be trivial to circumvent the system. Just sniff the current count when the owner unlocks their car, increment this and then transmit it back to the car. It's not quite that simple though, as this counter is encrypted by the fob before being transmitted. The car then decrypts the data before checking the counter value. Both the fob and the car store the secret encryption key that enables this process to take place. To anybody sniffing the data sent from the fob, it appears to send a chunk of statistically random data. Only by decrypting this data does it become meaningful.
In the UK and Europe, RKE key fobs typically transmit on 433.92MHz whilst in the US and Japan 315MHz is used. These frequencies are used as they are one of the few bands in the frequency spectrum where no licence is required to transmit. 433.92MHz happens to be the centre of this band, hence the slightly odd frequency.
As one might expect, car manufacturers don't have time/skills/inclination to develop their own rolling code algorithms, and as such they will typically licence one from a specialist company. One popular RKE system that several manufacturers use is the Keeloq system, developed by Microchip. Looking at it simply, all the manufacturer needs to do is feed the current counter value into the Keeloq chip, which then handles the encryption. At the other end (in the car), a similar chip handles the decryption.
The diagram below shows a typical Keeloq transmission format, lifted from a Keeloq encoder datasheet from Microchip.
The 'Hopping Code Portion' on the right is the encrypted section of the message. This encrypted section contains the synchronisation counter as discussed above, a discrimination section ('DISC', typically the lower 10 bits of the serial number) and details of the button pressed on the remote ('BUT'). The discrimination section is used by the decryptor in the car to check that the message was decoded successfully. As can be seen, the serial number of the key fob is transmitted without encryption. The car can be sure it has decrypted the counter correctly if the decrypted DISC section matches the unencrypted serial number.
Even if a car key fob doesn't use the exact Keeloq algorithm as discussed above, it will almost certainly always follow a similar format - the serial number of the fob will be transmitted unencrypted, alongside an encrypted section that contains the counter.
In order to understand the system, we first need to capture the raw data that a key fob transmits and try to decode it by hand. I might as well start with my own key fob, which unlocks my 2001 Vauxhall/Opel Astra. An image of the key is given below, I suspect the same key is used on many Vauxhall/Opel models. The fob part number written on the back is Bosch RK203.
If you export this data into a program such as Excel, you will end up with something like below (only an excerpt of the full data is shown).
This is pretty meaningless at the moment, until we work out the coding scheme. This basically defines how a '1' or a '0' is transmitted. For various reasons, a transmitter can't just take the carrier high if the data bit for transmission is a '1', and low if it's a '0', a coding scheme must be used to ensure that the carrier is continuously rising and falling. The scheme used will most likely be either Pulse Width Modulation or Manchester Coding. It's possible to tell by looking at the trace above that the scheme used in Vauxhall's case is Manchester Coding. In order to transmit a '0' in this scheme, the carrier is taken from low to high within a bit period and in order to transmit a '1', the carrier is taken from high to low, as depicted below.
When analysing data by hand, it makes life easier to depict the start and end of each bit period. As can be seen from the blue trace above, the carrier is only ever high for one of two discrete lengths of time. In Manchester Coding, the only ever time the carrier would be held high for an extended period is across two bit periods, to signify the transmission of the code '01'. This is illustrated below on the data transmitted from the fob.
Now that we've captured the data and understand how it's encoded, we can decode it into a bit stream. All key fobs will send a 'preamble', which is basically a period when the carrier is repeatedly turned on and off. This allows the Auto Gain Control (AGC) in the receiver to get up to speed. Following the preamble there is usually a 'start sequence' that lets the receiver know that the code is about to follow. This could be a period of either an extended high or extended low (or both), as highlighted below.
Through analysis of the transmission we have now worked out how to identify where the code starts and how to decode it into a bit stream. Using a spectrum analyser as discussed above, I captured several transmissions from my Vauxhall key fob and analysed the data sent by it, using an Excel macro do decode the Manchester Coding. By looking at which bits change in the transmission we can make an educated guess at the format of the transmission.
After manually analysing a number of key presses, I have deduced that the Vauxhall key fob transmits data in the following form:
The serial number portion of the data remains constant whilst the 40 bits of encrypted data appear to change randomly. Chi square analysis of these 40 bits show that the data has been generated with a very good pseudo random number generator - it is statistically indiscernable from genuinely random data.
The 16 bit 'button function' portion seems a little peculiar. There are two possible bit sequences that appear here:
To add further confusion, if the final bit of the 'encrypted data' section is a '1', then the inverse of the above is sent instead. Perhaps this is a discrimination sequence, so the receiver can be sure it's received the data correctly, or perhaps it's something to do with the encryption scheme. Either way, it does seem a bit of a waste to take up 16 bits to describe which button has been pressed, so there must be more to it.
Analysis of the keyfob from a 2005 Peugeot 206 shows that the code is fairly similar to that of the 2001 Astra. An image of the fob is given below.
There are two differences; the code is 2 bytes longer and it appears that the button function is code is embedded within the encrypted data, as illustrated below. The fact that the Peugeot data format is so similar to the Vauxhall format gives us confidence that other manufacturers must use similar systems. A file containing data captured from the Peugeot fob may be found in the 'downloads' section.
Chi square analysis of the 64 bits of encrypted data tells us that this data isn't anywhere near as random as the data sent by the Vauxhall fob - infact it's very non-random. What this means for us is that either there is something hidden within the data that I haven't spotted yet (the 'button press' data for example), or the data was derived using a poor pseudo random number generator. If this is the case then it can probably be assumed that the encryption scheme isn't quite as strong as it could be.
As it stands, all analysis of the code has been manual, using traces gathered from a spectrum analyser. It would be beneficial, especially if we want to perform cryptanalysis on the encrypted data, to have a system whereby the data could be automatically captured and stored.
Firstly, the data needs to be captured. Rather than designing a board to capture the data and demodulate it, it makes sense to use one of many 433.92MHz ASK RF modules that are on the market at the moment. There are plenty of these modules around, some from as low as £1.50, up to ones offered by Microchip, for £17.
I used an 18F PIC to interface with the receiver module, making use of the built in Timer peripheral and interrupts to work out the length of each bit. This data can then be fed to a function to decode the Manchester Coding and work out the final bit sequence. Using a Microcontroller also has an advantage in that the data can be sent over RS232 to a PC to perform further analysis.
An LCD display has also been connected up to the PIC, and code written to display the code received on the screen. You can see the ASK demodulator, PIC and LCD display in the image below. The pin-header on the right hand side of the board allows me to connect the PIC to a PC to either program it or receive streams of keyfob data via RS232.
The PIC code I've written to decode the data, along with some data streams captured from the keyfobs I have access to may be found below, in the 'downloads' section.
Please contact me if you need any support or extra data. Let me know too if you have any luck in performing any analysis on the encrypted sections of data!
I'd like to look at some different key fobs, the only limit at the moment is the fact that I don't have any more fobs at home to play with!
As has been proven, the Vauxhall/Opel and Peugeot encoding methods are very similar. Therefore, it's probably safe to assume that it'd be trivial to incorporate fuctionality to decode the fobs of other manufacturers into the PIC.
My name is Andy Carvell, I'm 26 and I'm an RF Engineer, working in Defence Electronics. I live in Cheltenham, England with my Vauxhall Astra and my girlfriends Peugeot 206. And their associated key fobs, of course.
19th February 2011