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>
This commit is contained in:
+37
@@ -0,0 +1,37 @@
|
||||
# Security policy
|
||||
|
||||
This app runs on a car. It reads vehicle data and holds credentials for a third-party
|
||||
service, so security reports are welcome and taken seriously.
|
||||
|
||||
## Reporting a vulnerability
|
||||
|
||||
Please **do not** open a public issue for a vulnerability. Use GitHub's
|
||||
[private vulnerability reporting](../../security/advisories/new) instead.
|
||||
|
||||
Include what you were able to do, on which firmware generation, and whether the vehicle
|
||||
was moving. A proof of concept helps; a working exploit is not required.
|
||||
|
||||
## What is in scope
|
||||
|
||||
- Anything that lets another app on the head unit read the stored ABRP credentials.
|
||||
- Anything that gets attacker-controlled code installed through the unstable updater.
|
||||
- Anything that makes the app write to the vehicle. **It should never write at all** — this
|
||||
app is read-only towards the car — so any write path is a bug by definition.
|
||||
- Telemetry that leaks credentials into logs, URLs or crash reports.
|
||||
|
||||
## What is not in scope
|
||||
|
||||
- Requiring physical access to an unlocked head unit with developer mode enabled.
|
||||
- The stable channel not auto-updating. That is deliberate; see `LICENSE.md` and the
|
||||
README's channel table.
|
||||
- Vulnerabilities in the OEM firmware itself. Report those to SAIC.
|
||||
|
||||
## Design decisions you should know about
|
||||
|
||||
- Credentials live in `EncryptedSharedPreferences` and are sent in a POST body, never a
|
||||
URL. `allowBackup` is off and both preference files are excluded from backup rules.
|
||||
- The unstable updater accepts an APK only over https, only from an exact-match GitHub host
|
||||
allowlist, and only when its signing certificate matches the running app's. All three
|
||||
checks fail closed. The stable channel does not contain the updater at all.
|
||||
- The VHAL probe helpers, which enumerate the whole vehicle abstraction layer, exist only
|
||||
in debug builds.
|
||||
Reference in New Issue
Block a user