In today’s automotive landscape, the rise of connected cars, fuelled by IoT, have paved the way for remarkable advancements. At the heart of these IoT-driven advancements lies the Connected Car API (Application Programming Interface), which serves as a gateway for seamless communication and interaction among various components within the connected car ecosystem. By employing a set of protocols, tools, and standards, this API enables the exchange of data and services between the vehicle itself, external systems, and diverse applications.
In the connected car API world, reverse engineering is the process of figuring out internal APIs of vehicle manufacturers and making unauthorised use of them.
Background
Every connected car has an official companion app. For BMW it is MyBMW, for Mercedes-Benz it’s MercedesMe, for Ford it’s FordPass — and the list goes on. All of these apps share common functionality: Once the vehicle owner signs in with their account, they can see the location, mileage, upcoming services and other data related to their vehicle in the app. In some cases they can also trigger remote commands such as unlocking the vehicle. It’s also possible to edit their personal information and even unlink the vehicle from their account.
How reverse engineering works
For a skilled software engineer, it is not difficult to figure out how the companion apps are accessing the internal manufacturer APIs in order to query the data to be displayed. There are lots of tools available to monitor the network traffic and to decompile the source code. Obviously, the Terms & Conditions of these apps don’t allow such operations — but there is little that can be done to prevent it.
Consequently, independent developers have been reverse engineering APIs for a long time and publishing the results on GitHub, for other enthusiasts to try out. The best known example is the Tesla APIs but there are many other examples such as BMW.
While it has been seen as less harmless in open source projects, there are companies that have made reverse engineering as part of their enabling business (Reverse Engineering Actors = REAs). By using the reverse engineered APIs, these companies can also use the same APIs as the companion apps and thus access vehicle data, personal data of the owner and execute remote commands. By having this capability, the REAs can offer a service to 3rd party services to access data across all brands without having any collaboration with any of them.
There is of course a prerequisite however, and that is that to authenticate with the manufacturer servers, the REAs need to have the username and password that the vehicle owner is using to access their account in BMW, Mercedes-Benz and so on. In order to get the username and password, the vehicle owners are required to complete a consent journey of the REA. In this consent flow, the vehicle owner is passed on from the 3rd party service to the REA, where the vehicle owner is prompted to choose their brand and then enter their login credentials to that brand. The vehicle owner seemingly signs in to the owner portal of the manufacturer, whereas actually the username and password is handed over to the REA, and is then used to authenticate using the reverse engineered APIs.
What’s wrong with it?
There are a few aspects to consider with this method. Obviously the vehicle manufacturers are not pleased with it, but the main reasons should be seen from the vehicle owner’s and the 3rd party service’s perspective.
Vehicle owner risks
When a vehicle owner provides their manufacturer account username and password to the REA, they effectively hand over full access to their account to the REA. Even if the REA is making assurances that no malicious use will be done, the access that the credentials provide is full scope, meaning that there is technical possibility for the REA to access any personal information or setting of the vehicle owner. As a comparison, you would not hand over your GMail username and password to a 3rd party.
Even if the REA is acting in good faith, there is always a risk of the REA having a data breach or alike, which would leave the vehicle owners who have been using their service vulnerable.
3rd party service risks
Even if the 3rd party services using the REAs are not doing anything wrong, they are sending their users (the vehicle owners) to REAs service in order to get the data access.
The other risk is about providing a scalable service. The reverse engineered APIs have no guarantees to not change from one day to another. If something changes on the manufacturer side, it can easily break the reverse engineering of the REA and they need to figure out what changed. No availability can be guaranteed and effectively 3rd party services are paying the REA for something that is hanging on a shoestring. An example of this is from last year where Tesla revoked all of their tokens on one day.
Vehicle manufacturers
Vehicle manufacturers are obviously not keen about the idea that REAs are using their logos and collecting the vehicle owner’s credentials. The REAs are also many times using aggressive use of the APIs causing an irregular amount of vehicle data updates, in some cases even causing vehicle batteries to drain.
Some manufacturers have taken legal action such as VW North America.
The official way
Nowadays all manufacturers are implementing APIs to be used by 3rd party services. These APIs have been designed to be opened to external companies and include things like an integrated consent journey based on known standards, whereas no vehicle owner credentials have to be exposed.
Why don’t the REAs use them? Hard to say. Of course the APIs that are made available by manufacturers charge money for their use, compared to reverse engineered APIs that are “free” for the REA.
There’s plenty of other editorial on our sister site, Electronic Specifier! Or you can always join in the conversation by commenting below or visiting our LinkedIn page.