Hacking A PSP-like Car Key Registration Device – PlaxidityX Ep 16

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 style. 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 Placidity X 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 episode 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 listening to our automotive cybersecurity podcast, 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, which we will discuss.

Experimenting with the tool. When the device arrived at the Placidity X 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 de register 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 Placidity x, 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 canned 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 2 or 3 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 device's 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, okay 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 2 stages. 1, extracting the pin code using the read pin code 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 2 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 research 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 proof of concept, 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 in 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 photo 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 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 a security access service for these purposes.

There are better methods now based on more secure cryptographic schemes, both symmetric and asymmetric. 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 back end 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. That's all for today's episode. Keep your engines running smooth and your cyber defenses sharp. Stay connected by subscribing and visiting placidityx.com.

Until next time, stay safe on the road and in the cloud.