Files
TCFDONMEZandClaude 2fd7b2dde1 Fatih'sMG4 — ABRP telemetry for an MG4 EH32 on SWI69
A fork of malys/EVABRPUploader (itself a fork of Leon Kernan's ABRP_Uploader)
carrying the changes that make it work on this car. History starts here: the
tree is what matters, and the upstream projects are where the earlier work
belongs.

EVHardware is vendored rather than tracked as a submodule, so one clone
builds.

Telemetry. SOC, battery power and range read as unavailable on SWI69 because
the vendor fallbacks were gated to SWI68 alone, while the property ids they
use are the ones this car publishes — the gates now admit SWI69. Tyre
pressure, the odometer and charge status come from the vendor block too,
since the generic properties for all three are declared here and never
publish. Tyre pressure is confirmed on the vehicle; the other two are not
yet.

Vehicle page. Every signal the car answers, in a table. One that it does not
publish shows a dash: an unimplemented VHAL property returns zero, and
"0 °C" would read as a measurement.

Wi-Fi page. Joins a network the unit already has saved, so a phone hotspot
does not need a trip into Settings on every drive. Tried on the upload tick
and from a button, skipped while already associated. This leans on the unit
being API 28 and the build being platform-signed — getConfiguredNetworks and
enableNetwork are closed to ordinary apps from API 29 — and fails quietly
where that does not hold.

The OTA updater points at this repository. An APK from upstream is signed
with a different key, which Android will not install over a platform-signed
build.

Co-Authored-By: Claude <noreply@anthropic.com>
2026-09-22 10:45:00 +03:00

41 lines
1.9 KiB
Markdown

# Security policy
This library is the one place its consumer apps read and write a car. That makes it
security-relevant even though it holds no credentials and opens no network.
## Reporting a vulnerability
Please **do not** open a public issue for a vulnerability. Use GitHub's
[private vulnerability reporting](../../security/advisories/new) instead. Say what you were
able to do, on which firmware generation, and whether the vehicle was moving.
## In scope
- A road-behaviour write reaching the vehicle above 0 km/h, or on an unreadable speed
(the gate must fail closed).
- A gated setter missing `@RequiresStandstill`, or the gate being bypassable.
- A catalogue entry that maps to a vehicle capability outside its declared `@SupportedOn`
set, or a wrong property id that writes an unintended vehicle property.
- Deserialization of a crafted `DrivingProfile`/`ProfileBackup` causing unintended writes.
## Not in scope
- The library declaring no permissions and no `sharedUserId`. Granting vehicle access is
the **consuming app's** decision (platform signature / privileged install); report those
choices against the app, not here.
- Climate/window reads returning null on a firmware that does not expose them — that is the
unverified-and-read-only design.
- OEM firmware vulnerabilities — report to SAIC.
## Design decisions
- **The 0 km/h gate lives here**, applied inside the low-level write primitives, so every
consumer inherits it in one place. `@RequiresStandstill` documents each gated setter and
a test asserts the set.
- **No raw "write property 0xNNNN" API** is exposed to consumers beyond the typed setters;
the action catalogue is a closed vocabulary.
- **Climate/window writes are intentionally absent.** Reads are unverified; a write path
waits on on-vehicle confirmation.
- **Reflection targets are kept via `consumer-rules.pro`** so R8 in a consumer app cannot
strip the `android.car`/SAIC/model/catalogue names resolved by name at runtime.