Unpacking an Off-the-Shelf Car Hacking Kit

A Curious Device

Recently, the PlaxidityX research team encountered a curious item – a stylish handheld PSP-like device, with seven conveniently-placed buttons, a cool design and a mysterious name. The brochure boasted about the device’s ability to register new key fobs (either for remote entry or for passive keyless entry) to a large number of vehicles, without the need for OEM authorization. 

The device’s intended purpose is to allow unlicensed auto shops to offer such services, at a cheaper price than the licensed service stations. Needless to say, if this self-description is true, the device can also be used by sneaky up-to-no-good crooks to steal cars (grand theft auto – GTA). The method is simple:

1. Physically break into the vehicle
2. Plug the device into the OBD port
3. Register a key fob of your own
4. Turn the ignition on and drive away before anyone notices
5. Congratulations on your new car

Not coincidentally, upon activation, the device displays a disclaimer shifting any legal liabilities to the user. As automotive security researchers, this device piqued our interest, and we simply had to check it out (for professional reasons, of course).  

As you probably noticed, I intentionally didn’t disclose the name of the device in question. This is because despite its somewhat shady nature, it didn’t “fall off a truck”, so to speak, but rather was obtained in a completely legitimate manner – it was purchased on eBay. Since I don’t want the takeaway of this blogpost to be “stealing cars is easy with this magical device” (and I don’t think stealing cars is easy even if you do have it), I will withhold this information in perpetuity. You  never know who might be  reading automotive cyber security blog posts online, which warrants a cautious approach. 

I will say this however – a quick search will uncover many devices with similar capabilities, some of which even offer monthly updates and customer support at an affordable price. But worry not, the supposed problem posed by this device can be easily neutralized in several ways, as discussed below.

Experimenting with the Tool

When the device arrived at our lab, there was much rejoicing, and we started working on it right away. The first thing we did was to examine its UI. As promised, we found an overabundance of supported vehicle models from a variety of OEMs. Some of the models were even newer than those mentioned in the brochure, having entered the market the same year (updates containing more models can also be obtained). Furthermore, the device allows the user to do more than just register and deregister key fobs. For some models, the device even has a “turn ignition on” function – and these aren’t necessarily the cheaper models. Obviously, turning on the ignition would render the key registering stage of the car theft unnecessary, making the process easier.

Since we are busy people here at PlaxidityX, instead of trying to dissect it, extract its firmware and reverse engineer it (as we would do for an  ECU), we decided to use a completely black-box approach. Since the device is meant to be connected to the vehicle’s OBD port, we simulated that and tried to communicate with the device ourselves. Choosing a bunch of random car models from the list, we tried to register and deregister keys, turn the ignition on, and other less interesting supported functions. 

To do this, we had to mimic what we expected the vehicle’s response to be to the various CAN messages sent by the device. This was usually a pretty easy task, as the protocol used was UDS in most cases and the exchange was quite short, consisting of two or three messages for each action. In most cases, we were able to predict the correct response or brute force it, reaching a successful conclusion (meaning, the message “key successfully registered” was displayed on the device’s screen). However, since we never tested the device on a real car, it might all be a ruse (although we found some youtube videos demonstrating that it works). 

Challenges and Discoveries

This device holds a large amount of proprietary information (proprietary information that doesn’t even belong to the developers of the device). These kinds of devices tend to have some kind of protection mechanism that locks them when it detects suspicious behavior. Despite that, we decided to run the risk. And so, while running a scan to try and find the correct response to one of the devices messages – a scan that required to hit “register key” on the device over and over again – the device became locked. It displayed a new screen, demanding a password from which there was no escape, and resetting it didn’t work. 

What do we do now? We could reverse engineer the device and try to find a solution that way, but what about trying something much simpler – contacting the seller for support? We were  skeptical – after all, this is a marginally legal device manufactured by a questionable company none of us have ever heard of. But a few hours later we got a response from the seller: “Why did it get locked? Are you developing software?!”. “No”, we answered innocently (just researching). “Well, OK then. Here you go, sorry for the inconvenience”, the seller said, and gave us the password. Kudos on the customer support experience. Five stars.

Back to the research. In most cases the key registration process had two stages:

1. Extracting the PIN code using the “READ PINCODE” function. This stage usually requires passing a UDS Security Access stage, which the device was able to do. Apparently, the device knows the correct response to every random seed given to it as a challenge by the vehicle’s security access mechanism.
2. Registering the new key using the “REGISTER KEY” function. This usually required entering the PIN code by hand (for whatever reason, they didn’t combine the two stages for user convenience). Further vehicle-specific instructions, such as “open the door” and “place the key fob on the ignition button”, were given by the device. 

So how did the developers of this mysterious device know how to pass the security access and the key registration process in general? We can’t be sure exactly how they did it, but this is how they might have done it (again, please don’t take it as a recipe on how to develop a car stealing gadget). Our hypothesis is that the developers acquired a set of authentic OEM testers from licensed service stations, recording the legitimate key registration process and mimicking it. This explains how they know the general process, but it still doesn’t explain how they are able to pass the security access. 

Indeed, in some cases the security access was so simple that we were able to infer its entire algorithm simply from a small set of examples, but in other cases it seems to have been more complicated. One possibility would be that they fed all possible seeds to the tester (which is feasible if the seed length is short enough, which in many cases it was), and recorded its responses. This requires a lot of storage space, which lowers its feasibility. A more probable explanation would be that they researched the OEM tester or the ECU responsible for key registration, at least in some of the car models.This requires some work, but it is entirely possible, given the fact that they typically only need to extract the security access key computation algorithm. It’s easy to imagine a workshop renting a different car each month, extracting the relevant ECU, extracting its firmware, researching the code a bit, developing a key registration PoC, returning everything to its place, and then returning the vehicle to the car rental (with a full tank of gas of course). Since many car models use the same systems, by researching one model, you usually know enough to unlock a bunch of vehicles. 

Conclusions and Safeguards

So, is it really possible to steal cars using this device? In some cases, it wasn’t – registering a new key requires the user to know the PIN code (or some other information) in advance. However, in many cases, it seems to be entirely possible. Again, we didn’t use the device on a real car, so we can’t be 100% sure. However, the customer reviews and an array of tutorial youtube videos seem to suggest that  the device indeed works as promised. Hopefully, the OEMs are aware of that, and have fixed the vulnerable car models by now in a FOTA update. Even so, some instances probably remain outdated and can still be stolen this way.

So how can OEMs avoid a possible theft scenario? Here are some relatively simple methods that OEMs can use to render this device ineffective:

1. Using longer seeds in the UDS security access process would make it impossible  to make a seed-key dictionary by simply recording the communication from an official OEM tester. Of course, the seeds should be random, to avoid the possibility of seed duplication.
2. The security access algorithm should contain a secret element stored in the HSM. This way the device will not be able to pass the security access, while the OEM tester will be able to acquire this information by contacting the OEM’s servers, where this data is accessible. Naturally, the algorithm should also be complicated enough so inferring it from a small number of samples would be impossible.
3. There is no reason today to use the security access service for these purposes. There are better methods now, based on more secure cryptographic schemes (both symmetric and asymmetric), like UDS service 0x29 or SecOC. 
4. Avoid using a 4-digit PIN code as the only secret required in order to register a key (a weak mechanism in its own right). If you must use a PIN code, make sure that the PIN code is not extractable from the vehicle. Only the licensed service stations should be able to access the PIN code from the OEM’s backend in a secured manner.
5. Protecting the physical interfaces, such as JTAG, and not storing the firmware on external flash could make it harder to extract the firmware and reverse it. For the same reason, the update packages should always be encrypted.

By employing these simple measures, the risk of car theft by unlicensed devices can be mitigated. 

About PlaxidityX Research Group

Harnessing decades of cyber security and automotive expertise, the PlaxidityX Research Group has extensive experience working with OEMs and Tier 1s in dozens of penetration testing and research projects to verify and elevate their cyber security posture, and help them comply with UNR 155, UNR156 and ISO-21434 regulations. With an unparalleled understanding of automotive architectures, protocols and standards, the PlaxidityX Research Group provides a comprehensive set of automotive cyber security services, including Automotive Penetration Testing, TARA and Cyber Security Architecture Design, and UNR 155 and ISO 21434 Cyber Security Compliance.