This happened to me with GM

I tried to get developer access via a form and never got a response, so I tried sending a message the head of the infotainment on LinkedIn

Thankfully he was able to get my application to the dev site moving... but unfortunately, they required a business use case to get an API key once you had access to the site.

So I tried to pick the API key out of the app.

They had the most novel obfuscation I've ever seen for an app's API key

The key was inside the image data for the launcher icon

There was a weird transformation applied to it too, so instead of trying to reverse engineer it I just fired up Charles and intercepted it from there

With the API key and the documentation for the API from the dev site I was able to write a program that started preconditioning my Volt when I left my apartment (the car was in an attached underground garage, so it'd be at the right temperature by the time I got down)

Nice! I've been trying to do some RE myself to no avail. This project (https://github.com/TheCrypt0/yi-hack-v4) maintainer puts a paid DRM atop the main functionality (enabling rtsp streaming for Yi cams). I tried bypassing the DRM by replacing the MC command in ghidra but it didn't work. Do you have any learning resources you can share so I can bypass/crack this DRM?

Unfortunately I don't have anything that would be helpful

Reverse engineering Android apps is pretty easy because there's a very well defined application format, and a ton of hints about the original source in the bytecode

Your situation sounds a little more complicated than that

Did you have to disable SSL cert pinning too? Or was it happily MITM’ed so that all this obfuscation is completely pointless?

Nope, they went through all that trouble and didn't pin the certs haha

But in general, getting around cert pinning is pretty straightforward though with Objection and Frida.

It's a little bit of a cat and mouse game since they can probably be detected by a determined app developer, but I haven't run into any issues yet

I am thoroughly impressed! How did you find that the key was obfuscated inside the image though?

Similar to what netsharc describes

Found the call that added the header for the API key to each request (even with Proguard's obfuscation string literals are preserved, so searching for "x-api-key" worked)

From there I followed the call chain to their transformer, then looked at the input for the transformer and it was loading a subset of bytes read from the same resource as the launcher icon (and sure enough, opening it in a hex editor there was some weird "garbage" that I'm honestly surprised Android doesn't choke on)

My guess is that a function that looks like fetchKey() loads that image. Although maybe that's too easy to discover?

Hi, selpop. Do you have a GitHub, GitLab account, or Twitter?

I updated my HN profile with Github and Hackaday

There's not much to show though, I have a bad habit of not putting stuff in VC "because it's just a quick experiment"... then it becomes a long term project with no backups

While I agree that companies should share development libraries/SDKs, this will not prevent reverse engineering and if closed source gives reverse engineers another avenue to gain access. BMW likely declined due to possible liability. If someone creates a smartphone app than anyone could download that unlocks the vehicles and is sued, it is easier to convince lawyers, judges and nontechnical plaintiffs that the company is not at fault if they provided no access to the software regardless of whether the SDK provided was utilized or not. Even if there was an explicit opt in for each vehicle to allow users to utilize a SDK, the auto industry does not have protocols on how to do factory resets after the vehicle changes hands.

I could imagine a lot of scenarios where BMW wasn’t ready to publicly share its SDK for security reasons