Theatre Mode

[HamzaObaidat]

Isn't it possible to enable theatre mode while driving?
Something similar to: https://www.tbgauto.com/theatre-mode

I sniffed 0x118 and tried to keep the DI_gear value at P. It worked for a second, then it started glitching

system gear D.txt
system gear P.txt

[fboulegue]

Really interesting wonder how they do it ,... I dont think D and P is the right way togo

[fboulegue]

@HamzaObaidat set gear to P and Speed to 0 and It works :)

[HamzaObaidat]

Hey @fboulegue, thanks for the input on P + speed=0 🙏
I want to try this out, and I'd like to understand exactly what combination worked for you.
Could you share:
Which CAN ID did you use for the speed=0 frame?
What's the exact signal name inside that frame?
Any offset/scaling I should be aware of?

[hypery11]

Nice experiment @HamzaObaidat — and @fboulegue is right about the combination. Two things are going on:

Why gear-P alone "worked for a second, then glitched": 0x118 (DI_systemStatus) isn't a plain frame — it carries DI_systemStatusChecksum + DI_systemStatusCounter right alongside DI_gear (both are in your own decode). When you inject a modified 0x118 with the gear flipped to P but a stale/unchanged checksum+counter, the MCU accepts a frame or two and then rejects the ones whose checksum doesn't match, snapping back to the real gear (D). To hold P you have to recompute the counter (increment it each frame) and the checksum on every injected 0x118 — not just flip the gear bits. Otherwise it self-corrects within a frame or two, which is exactly the glitch you saw.

Why P + speed 0 is the right pair (@fboulegue): the car cross-checks gear against actual motion — claiming Park while a speed signal still says the car is moving is inconsistent, so it's rejected. You have to force the vehicle-speed signal to 0 as well (that's a separate frame from 0x118), consistently with the P claim, so the parked-check passes cleanly. That's why the two together hold and gear-alone didn't.

One serious caution: this is spoofing Park + zero speed to the MCU while the car is actually moving. Stability control, regen, driver monitoring, and the drive unit itself read that same gear+speed, so forcing it mid-drive can have effects well beyond the screen — and Theatre Mode while driving is a distraction risk on top of that. Worth characterising stationary / on the bench, but I'd be careful on a moving car.

To take it further, the two missing pieces are: the exact 0x118 counter+checksum (Tesla's additive checksum over the payload plus the per-frame counter) and which frame carries the speed the MCU trusts here. A full-rate 0x118 capture is enough to crack the checksum — the gear-P dump you posted is close, but grab one where the counter/checksum are captured at full rate and we can work it out.

[hypery11]

Jumping in with the frame details since I have the DBC open — @fboulegue can confirm which one he actually used:

The vehicle-speed frame is 0x257 (DI_speed), on the Party bus (same tap as the nag). Two speed fields:

• DI_vehicleSpeed — bits 12|12, factor 0.08, offset −40, kph. This is the one the park / drive-unit logic reads (in the DBC its receiver is literally park). Mind the offset: raw 0 is not 0 kph — for 0 kph the raw value is 500 (0x1F4). Zeroing the bytes would read as −40 kph and get rejected.
• DI_uiSpeed — bits 24|8, the on-screen speed; set to 0 for a 0 display.

And the catch that'll bite you the same way gear-P did: 0x257 carries DI_speedChecksum (byte0) + DI_speedCounter (byte1 low nibble) — same protection as 0x118. You have to recompute the checksum ((0x57 + 0x02 + sum(bytes 1..7)) & 0xFF → byte0) and keep the counter stepping every frame, or it self-corrects in a frame or two — exactly the "worked for a second then glitched" you already hit on the gear side. If you modify the car's own 0x257 in place, you inherit its counter for free and only need to fix the checksum.

So the recipe is: gear = P on 0x118 and speed = 0 on 0x257, both with valid checksums, held together. @fboulegue — was 0x257 the frame you zeroed, or a different one?

[fboulegue]

It was 0x257 but need to admit I only did a small test as I simply moved away and created a webpage that use canvas streaming without html video or audio tag - as I m afraid that the speed adjustments might break some assistants while driving et

[hypery11]

Thanks for confirming it was 0x257 — good to have it pinned.

And your instinct to back off is the right one. 0x257 isn't only read by the screen's parked-check — vehicle speed off that frame feeds stability control, ABS, regen, and the driver-assist stack, so faking it to 0 while the car is actually moving can have effects well beyond enabling the video. That's genuinely bench/stationary territory, not something to run on a moving car.

The canvas-streaming page (no <video>/<audio> tags) is the sane route for @HamzaObaidat too — it gets you the content without touching the CAN speed at all, so there's nothing to break. Nice workaround.

[fboulegue]

Only thing so to say is, it require a "host" running at home