@bruvv @jibing3987 Fair question, and apologies for the slow reply. The README description is more optimistic than reality. Honest answer:

What Ban Shield actually does:

Watches CAN ID 0x7FF (GTW_carConfig) for the 8 muxed frames.
On startup, learns your current "healthy" pattern by capturing what the GTW broadcasts before any potential ban push.
If Tesla's server later pushes a config update that changes the broadcast pattern, Ban Shield rewrites those frames back to the learned-healthy state on the bus in real time.

What Ban Shield does NOT do:

It does not prevent Tesla from writing to GTW NVRAM. The entitlement state is stored in NVRAM and survives reboots — Ban Shield only masks the CAN broadcast layer.
After a reboot, GTW broadcasts from NVRAM (which has the banned state); Ban Shield re-arms and re-masks, but this is continuous masking, not permanent prevention.
It does not undo Tesla's server-side flag. Your account can still get marked banned; other on-bus ECUs may not see the change in real time, but the entitlement is gone.

Empirical status: Ban Shield was added as a defense-in-depth measure based on attack-surface analysis, not on a confirmed case of "this car was about to be banned and Ban Shield prevented it." I do not have a single empirical confirmation that Ban Shield prevented a ban.

The "prevents Tesla from banning" framing in the README overpromises. I'll soften that wording in the next docs pass.

If your situation is banned-recovery (rather than ban-prevention), the confirmed working path is TLSSC Restore (0x331) + 0x3FD Mux 0 bit 38 — @RoyRakete confirmed reliable on HW3 / 2026.2.6 in #18.

Uh oh!

[Questions] explain banshield better #60

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions