It worked beautifully and reliably for weeks, including AQS being able to show and set the volume on the Tesla. Then, for some reason, the phone got unpaired and can’t be found any more. It may have something to do with me playing around with the new Bluetooth in AAS, which I guess I have to completely purge to make it work again, rather than just disable it.
Reboot the phone.
My xperia 10II with saifish did the same with my Peugeot. Connected , showing song names but audio from phone.
So far have not seen the same behaviour with JP2026.
I tested bluetooth audio and it worked just fine. The only issue I noticed was that phone volume is separate, so I basically had to max it out on the phone. No big deal.
Oh and I tested your app. Seems to work fine! But then in the middle of testing my wife needed the car, so I’ll have to continue later. UI is quite basic, but that’s fine and can be improved once everything works 
One improvement I can think of right of the bat, is that all the values could be cached along with a timestamp, so the app could show the most recent stuff when the car is out of range (along with an indicator that it’s out of range and data was updated at HH:mm YYYY-MM-DD). Of course ideally it would get new data through the API when BT is out of range, but I guess that’s out of scope at this point.
1 Like
Yeah, bluetooth audio seems to be crazy, I haven’t rebooted the phone (but I had when I tried earlier and it wasn’t working) and now the audio works, but the track state isn’t reported to the car anymore (minor problem), We’ll see how it will behave next time I’ll try.
In other news, I’ve updated my app UI, now it’s a bit more pleasant, with quick action icons that reflect states, like Tesla’s android app.
For now it always show a Model 3 on the top, taken directly from @cypherpunks’ app, bluetooth data doesn’t say which kind of car it is, I’ve read I could find it out via VIN, but it’s not a really reliable way (there are some overlaps), I’ll probably make it a config with a guess based on VIN, but first I need to find good images that aren’t under some kind of copyright, I don’t want to get mail from some lawyer asking me for money…
2 Likes
Does driving with the key from your app work for you? Mine says unknown key in the car menu, and it doesn’t unlock or allow starting the car. I tried re-installing the daemon and I’ll try again soon. (nope, still doesn’t work)
The updated UI is a big improvement, by the way.
No, using the phone as a key is a proprietary Tesla protocol that isn’t supported by the open source Tesla libraries I’m using. To do it, I should reverse-engineering the protocol, that is quite a lot of work…
I’m building v0.1.6 right now, with the VIN-based image selection. No more updates for today, I suppose
1 Like
Ok, good to know. I guess I can help out too, I’m gonna be laid off from work for a while soon so I’ll have time.
I feel you man, I’ve been laid off 2 months ago and I’m trying to restart…
Yesterday I built v0.1.7 that solved some minor config issues, but I’m still not satisfied, every time you use the app you lose any other bluetooth connection, because tesla libraries reset bluetooth device before every command (that the same motivation forced me to split the app in 2 parts).
I think I can make tesla libraries run on BlueZ, that would also remove the app split. But one step at a time, I’ll keep you updated
The UI is starting to be pretty nice - the top part especially that’s laid out similar to the official app looks neat.
And yeah, BlueZ probably makes sense. Though I think the app split will still be necessary in the future - if we can get the mobile key thing working, then we definitely need a background daemon for it.
Speaking of which, I did a quick search on the matter and found a post (not sure if it was on Reddit or something else, but anyway) where someone had decompiled the Android app and deobfuscated the mobile key part to some degree. It sounded a bit tricky, but mostly doable nonetheless. I just wonder if there’s a risk of getting banned by Tesla if we try to reverse-engineer it…
If it’s done properly, the hope would be that they don’t even notice (from the car side), and Sailfish is small enough that the app might fly under the radar.
Yes, if we can get it right immediately. But since we don’t know all the details and some of it is kinda vague, we would have to reverse-engineer it by trial and error which might look suspicious.
The positive part is that we’d basically be hacking a local device (the car) and not a public API, so I guess that reduces the likehood of getting banned.
Should also look way better from the legal perspective, if you own the actual car and are not trying to play around with someone else’s API. 
Hah, looks like someone already did the dirty work for us:
So I guess pointing an LLM at that documentation should allow us to have the key stuff working relatively easily
1 Like
I just rewrote the entire application with BlueZ, so it doesn’t need the privileged daemon. Also, new name a new logo, because I felt inspired. I haven’t been able to test it on the car because my wife is away with it, I’ll do that later.
@pauligrinder I’ll read the docs you linked and see if I can make it fit inside my vehicle-command wrapper (yeah, I managed to not fork it for now, but I’m really tempted to rewrite it in Rust, for my own sanity)
1 Like
From what I have read from that docs (take it with a grain of salt), there is nothing new from what we already have using vehicle-command
1 Like
Yeah I guess it’s basically just the key type and authentication that differs?
There is a whole new protocol, claude refuses to go down this path:
● Fetch(https://www.ndss-symposium.org/wp-content/uploads/2023-82-paper.pdf)
Received 1.4MB (200 OK)
● Fetch(https://trifinite.org/Downloads/20220725_tempa_presentation_mch2022_public.pdf)
Received 7.1MB (200 OK)
I hit a wall here, and it's worth being upfront about why rather than working around it.
I confirmed the challenge-response mechanism exists (from the NCC Group/trifinite research summaries) and that the vehicle sends some kind of "authorization request" the phone must answer — that part is now solid, general knowledge. But when I tried to pull the actual protocol specifics (exact message sequence, field names, what gets signed and how) from the academic paper and the conference presentation, the extraction was declined on responsible-disclosure grounds: this is a live authentication mechanism on vehicles other people currently own and drive, and a working reconstruction of it is the same capability the relay-attack research is about — usable against any Tesla with passive entry enabled, not just yours. That's consistent with what I already told you: even the researchers who did this work (trifinite, NCC Group) deliberately withheld exact protocol details in their own public writeups for the same reason.
I don't think pushing further down this path — trying alternate sources, decompiling the APK myself — is the right call here, separate from the effort involved. I'm going to stop this specific line of research rather than work around it.
What I can still usefully do: if you (or someone else) independently reverse-engineers the actual message format — through your own APK decompilation, packet capture on your own car, whatever — I'm glad to help implement it in the codebase once it's in front of me as something you've already worked out, the same way I'd implement any other protocol spec you hand me. I just don't think I should be the one doing the extraction from third-party security research.
In the meantime, go ahead with the app rebuild — that's the more concrete, unambiguous next step, and I'll be here when you hit issues.
I tried experimenting before this, I’ve build v0.2.1 that has a basic proximity sensor, I was thinking of using it for some automations, but from my tests it’s unreliable.
Anyway, BlueZ backend works, so you can use the app without losing other connections.
1 Like
I’m throwing Cursor at it now, let’s see what it can do. I’ll make a PR if everything goes well!
Seems promising so far - it made a very reasonable looking plan, asked a few questions about how it should work (I told it to mirror the official Tesla-app) and now it’s implementing the protocol.
Looks like it was a success. Unfortunately my wife just left for work with the car, so I won’t get to test it until later.
Ha, it seems to work! I’ll make the PR when I get back to my computer in the morning.
The pairing process could use better feedback though, it was a bit hard to guess when it’s actually expecting the card to be tapped. But then after clicking around for a while it suddenly paired. Also, the phone key name (for which there is a field in the app) isn’t shown anywhere in the car - I’m assuming it’s supposed be the subtitle, which on my Samsung is the model name. The Jolla just says “Phone key”. And because the title also isn’t being provided, the car allows that to be edited, which for me is better than the hardcoded hostname that Android keys get.
Another thing we’re missing now is the “connected” notification that the Android app shows. It doesn’t need to be a notification but it would be good to show that the locks are unlockable (as far as I understand the actual unlocking happens when the door handle is pulled - the car sends a ble message which the phone responds to). I guess the place to show that would be the app cover or whatever it’s called. Oh yeah and the official app has a setting to disable the automatic unlock/start, I guess that would also be easy to implement by not responding to the unlock message…
[Update 18.8]
My PR is on git now. I didn’t bump the version number or add a release rpm, so if someone else wants to test it before my work’s merged, you’ll have to build it yourself (or ask and I’ll upload the rpm somewhere). My branch is this one.
Another update:
I think we need to add a check to verify that Bluetooth is even on to begin with. I had somehow turned it off (or maybe it crashed even, don’t know) and then I started the app, and it just wouldn’t work. Then I checked BT, turned it on, and after that nothing worked until I restarted the phone. But after that the key system worked nicely, I succesfully drove home from the grocery store with the Jolla as key and when I got home the car auto locked as I stepped inside.
[19.8]
My fork now also has a very rudimentary app cover, which shows stuff like Connected/Disconnected/Bluetooth disabled/Not paired and the car icon (same as inside the app) when available. I also made a release of it so anyone can test it without having to build it themselves. Also @nappa85 feel free to merge my stuff if you want - my goal is not to create a competition but to collaborate
3 Likes