philips-tv-speicher-voll/diagnostics/deep-forensics/emmc/emmc-kernel-agent.md

Tiefe eMMC-/Kernel-Forensik – lokaler Artefaktbefund

Stand: 2026-08-25
Gerät: Philips 43PUS7394/12, TPM191E, Android TV 12
Arbeitsweise: ausschließlich lokale, lesende Auswertung bereits gesicherter Bugreport-, Log- und Dokumentationsdateien. Es wurden keine neuen ADB-Gerätebefehle ausgeführt und am Fernseher keinerlei Änderungen vorgenommen.

Wichtiger Nachtrag – PRE_EOL inzwischen unabhängig belegt

Eine spätere, rein lesende Live-Abfrage des bereits vorhandenen Android- Eventlogs hat die zentrale damalige Lücke geschlossen. Sie lieferte:

storaged_emmc_info: [emmc 5.1,1,10,10]

Die geräteeigene Definition storaged_emmc_info (mmc_ver),(eol),(lifetime_a),(lifetime_b) beweist die Feldreihenfolge. Damit meldet Android Storaged für diesen Boot eMMC 5.1, PRE_EOL_INFO=0x01 (Normal), Lifetime A 0x0a und Lifetime B 0x0a. AOSPs Android-12-Implementierung gewinnt diese Werte aus den MMC-sysfs- Attributen beziehungsweise als Fallback aus EXT_CSD-Debugfs. Dieser Befund ist unabhängig von Philips' persistenter Property. Die nachfolgenden Tabellen sind auf diesen Gesamtstand aktualisiert; gesperrt bleiben nur der direkte Shell-Read, der vollständige EXT_CSD-Rohdump, CID/CSD und die Herstelleridentität.

Primärquellen: AOSP Storaged Android 12, AOSP EventLogTags.

Kurzfazit

Philips hat beim Booten zwei eMMC-Lebensdauerwerte 0x0a 0x0a gemeldet; kurz danach liegt derselbe Wert in einer persistenten Property vor. Mehrere voneinander getrennte Philips-Komponenten bestätigen beide Felder als Life Time A und B; TVStorageMonitorService ordnet den zweiten Wert dem Band „90–100 % device lifetime used“ zu. Diese Philips-interne A/B-Aussage ist direkt und mehrfach belegt. Nicht unabhängig belegt sind die aktuellen Rohbytes 268/269 des EXT_CSD, weil alle direkten Pfade gesperrt sind.

Der direkte sysfs-/EXT_CSD-Rohzugriff auf PRE_EOL_INFO bleibt der ADB-Shell verwehrt. Der logische Wert ist inzwischen dennoch unabhängig bestätigt: Android Storaged meldet eol=1, also PRE_EOL_INFO=0x01 (Normal). Auch der genaue Debugfs-EXT-CSD-Knoten existiert: /sys/kernel/debug/mmc0/mmc0:0001/ext_csd. Androids storaged versuchte ihn als Unix-UID root zu lesen und wurde von SELinux abgewiesen. Das ist der stärkste direkte Nachweis dafür, dass „UID 0“ auf diesem Produktions-Build allein keinen eMMC-Rohzugriff garantiert.

Im durchsuchbaren Diagnosefenster gibt es keinen nachweisbaren MMC-, Block- I/O-, EXT4- oder Journalfehler. Alle vier automatisch als Storage-Fehler erkannten Zeilen sind Netzwerk- beziehungsweise Incident-Pufferfehler. Diese negative Aussage ist jedoch stark eingeschränkt: dmesg, PStore/Last-Kmsg, EXT4-Fehlerzähler und ein OEM-Board-Dump fehlen. Aus dem Nichtfund darf daher weder „eMMC gesund“ noch „kein historischer Medienfehler“ abgeleitet werden.

Quellen und Auswertungsumfang

Primär ausgewertet wurden:

• diagnostics/bugreport/extracted/files/01790__bugreport-...txt (46.511.209 Byte, Standard-Bugreport);
• diagnostics/bugreport/extracted/manifest.tsv mit 1.790 äußeren Einträgen und zwei zusätzlich extrahierten inneren Dateien;
• diagnostics/bugreport/analysis/search-hits.tsv und storage-error-review.txt;
• die sechs Dateien 00012__update_engine... bis 00017__update_engine...;
• diagnostics/raw/emmc/emmc-property-init-and-bootlog.txt;
• diagnostics/raw/emmc/emmc-identity-and-access.txt;
• diagnostics/raw/emmc/emmc-filesystem-health-access.txt;
• die vorhandenen Berichte emmc-analysis.md, bugreport-analysis.md und privilege-analysis.md.

Die vorhandene reproduzierbare Analyse hat 1.787 textartige Dateien geprüft, fünf Binärdateien wegen ihres NUL-Anteils ausgelassen und 2.450 kategorisierte Trefferzeilen erzeugt. Zusätzlich wurden die ernsthaften MMC-/EXT4-Muster nochmals exakt über den extrahierten Textkorpus geprüft.

Evidenzklassen

Kennung	Bedeutung	Anwendung in diesem Bericht
E1 – direkt belegt	Wortlaut, Pfad, Property, Audit oder Prozesszustand liegt im lokalen Artefakt vor	zum Beispiel 0x0a 0x0a, AVC-Denial für ext_csd, Prozess-UID/-Domain
E2 – stark gestützte Schlussfolgerung	mehrere E1-Indizien bilden eine konsistente Kette, ein entscheidender Rohzugriff fehlt aber	der Boot-Reader gewinnt A/B sehr wahrscheinlich aus dem eMMC-EXT_CSD
E3 – begrenzter Nichtfund	im tatsächlich verfügbaren Textfenster nicht gefunden; fehlende privilegierte Quellen begrenzen die Aussage	keine sichtbaren MMC-/EXT4-Fehler
U – unbekannt/nicht prüfbar	kein Wert oder keine ausreichende Quelle vorhanden	CID/Hersteller, vollständiger EXT_CSD-Rohdump, vollständiger historischer Kernelzustand

E3 ist ausdrücklich keine schwächere Form eines Gesundheitsnachweises, sondern eine Aussage über den untersuchten Korpus.

Physische und logische Speicherzuordnung

Folgende Zuordnung ist aus den gesicherten Rohdaten direkt belegt:

MediaTek-Host: 1006d000.MSDC0
eMMC-Gerät:    mmc0:0001
Blockgerät:    mmcblk0
/data:         /dev/block/mmcblk0p37, ext4, rw
Debugfs:       /sys/kernel/debug/mmc0/mmc0:0001/ext_csd
sysfs:         /sys/block/mmcblk0/device -> .../mmc0:0001
Blocknode:     /dev/block/mmcblk0, brw------- root root, major:minor 179:0

Der Kernel-Commandline-Eintrag enthält eine statische blkdevparts=mmcblk0:...-Partitionstabelle und bestätigt unter anderem die userdata-Partition. Die rohe Blockgröße blieb dagegen unlesbar; aus der Partitionstabelle wird deshalb hier weder Modell noch exakte physische Kapazität abgeleitet.

Status der eMMC-Gesundheitsinformationen

Information	Zugriff/Beobachtung	Blockade	Benötigte Rechte bzw. Funktion	Legitimer risikoarmer Weg	Evidenz
Life Time A	Philips-Property 0x0a 0x0a; OnBootLogger dev_lt_a="a"; Storaged-Event lifetime_a=10	direkter EXT-CSD-Bytezugriff fehlt	lesender Zugriff auf EXT_CSD-Byte 268 für einen Rohdump	autorisierter TPV/Philips-Serviceexport	exportierter Wert 0x0a E1; Rohbyte weiterhin U
Life Time B	dieselbe Property; dev_lt_b="a"; TVStorageMonitor wertet zweiten Wert als 90–100 % aus; Storaged-Event lifetime_b=10	direkter EXT-CSD-Bytezugriff fehlt	lesender Zugriff auf EXT_CSD-Byte 269 für einen Rohdump	autorisierter Service-/Engineering-Dump	exportierter Wert 0x0a E1; Rohbyte weiterhin U
PRE_EOL_INFO	sysfs-Knoten existiert, direkter Shell-Read erhält AVC-Denial; Storaged-Event meldet eol=1	nur der direkte Rohbytezugriff bleibt gesperrt	passende SELinux-Domain nur für unabhängigen Rohdump von EXT-CSD-Byte 267 nötig	signierter OEM-Diagnosedienst bzw. autorisierter Engineering-Build	logischer Wert 0x01 (Normal) E1; Rohbyte weiterhin U
vollständiger EXT_CSD	exakter Debugfs-Knoten ist durch Audit belegt	storaged:s0 wird trotz UID root an debugfs_mmc:s0 abgewiesen; Shell schon am Verzeichnis	Verzeichnissuche plus open/read/getattr für debugfs_mmc; ein hierfür erlaubter OEM-/Kernelkontext	Philips/TPV-Servicewerkzeug, das nur lesend exportiert	E1 für Existenz/Blockade, U für Inhalt
CID	sysfs-Knoten existiert, cat durch shell:s0 abgewiesen	SELinux; zusätzlich Rohblock-DAC ist restriktiv	erlaubter sysfs-Lesekontext	OEM-Board-/Service-Dump	U
CSD	sysfs-Knoten existiert, cat durch shell:s0 abgewiesen	SELinux	erlaubter sysfs-Lesekontext	OEM-Board-/Service-Dump	U
Hersteller/Modell/Serienkennung	manfid, oemid, name, serial und weitere Attribute wurden angefragt	AVC-Denials beziehungsweise Permission denied	erlaubter sysfs-Lesekontext	OEM-Serviceausgabe; alternativ offizielle Firmware-/BOM-Unterlage	U
Rohblock /dev/block/mmcblk0	Node ist brw------- root root; blockdev --getsize64 scheiterte	Unix-DAC und voraussichtlich SELinux-Blockdevice-Policy	Root-DAC und erlaubte SELinux-Domain; nur lesender Blockzugriff	OEM-Werkstatttool; kein allgemeiner Root-/Exploitversuch	E1 für Blockade, U für Rohinhalt
EXT4-Fehlerzähler für /data	/sys/fs/ext4/mmcblk0p37/{errors_count,first_error_time,last_error_time,lifetime_write_kbytes,session_write_kbytes} sind bekannt	alle Leseversuche Permission denied	erlaubter sysfs-/ext4-Diagnosekontext	privilegierter, signierter Read-only-Dump	U
Kernel-Ringpuffer	Bugreport-Sektion: Unexpected klogctl return value: -1; direktes dmesg war nicht erlaubt	Kernel-/SELinux-Loggingrechte	Dumpstate-/Kernelkontext mit zulässigem klogctl, typischerweise zusätzlich entsprechende Capability/Policy	OEM-Bugreport/Engineering-Dump	U für nicht sichtbare Kernelereignisse
PStore/Ramoops/Last-Kmsg	/proc/last_kmsg fehlt; Incidentd wird an pstorefs abgewiesen und kann console-ramoops* nicht öffnen	fehlender Pfad und SELinux-pstorefs-Denial	erlaubter PStore-Lesekontext, sofern Daten existieren	autorisierter Crash-/Board-Dump	U
OEM-Board-Dump	No IDumpstateDevice implementation; keine dumpstate_board.bin/.txt	HAL nicht im VINTF-Manifest implementiert	passende OEM-IDumpstateDevice-Implementierung	zukünftige offizielle Philips-Firmware oder Hersteller-Servicebuild	U
Implementierung emmclifereader	Init-RC, Root-Start, Dateilabel und Ausgabe sind bekannt	Shell darf an tpvdebug_exec:s0 weder getattr noch read	autorisierte Systemimage-/Quellcodeanalyse oder erlaubter Servicekontext	offizielle Firmwaredatei/TPV-Servicepaket lokal analysieren	E1 für äußere Kette, U für internen Codepfad

Beweiskette für 0x0a 0x0a

Die gesicherten Artefakte bilden folgende Kette:

init: service emmclifereaderd /system/bin/emmclifereader
      oneshot, user root, group system
             |
             | Boot-Log: eMMCLifeReader: eMMC life time 0x0a 0x0a
             v
persist.odm.tpv.sys.emmc_lifetime = 0x0a 0x0a
             |
             +--> OnBootLogger: dev_lt_a="a", dev_lt_b="a"
             |
             +--> TVStorageMonitorService:
                  propvalue = 0x0a 0x0a
                  EmmcLifetime 90%-100% device lifetime used

Direkt belegt sind Init-Definition, Root-Anforderung, Boot-Ausgabe, persistente Property und beide Philips-Verbraucher. Der Dienst ist beim Bugreport bereits stopped, passend zu oneshot; ro.boottime.emmclifereaderd ist gesetzt. Das ausführbare Objekt trägt das Label u:object_r:tpvdebug_exec:s0.

Nicht direkt belegt sind:

• die Laufzeit-SELinux-Domain des sehr kurz laufenden Readers;
• welcher seiner möglichen Kernelpfade tatsächlich geöffnet wurde;
• die im Moment des Bugreports vorhandenen Rohbytes 268/269.

Die Formulierung „Philips hat beim Boot A/B als 0x0a/0x0a ermittelt“ ist daher E1. Die engere Formulierung „der Reader hat genau /sys/kernel/debug/mmc0/mmc0:0001/ext_csd geöffnet und daraus unmittelbar die Bytes 268/269 gelesen“ bleibt E2. Dass der persistente Wert bloß eine Belegungsanzeige sei, ist durch die getrennte A/B-Telemetrie und die Philips- Zuordnung widerlegt.

Unix- und SELinux-Barrieren

Die Befunde zeigen vier getrennte Zugriffsebenen:

1. Unix-DAC: Der rohe Blocknode ist nur für root:root lesbar. Eine normale ADB-Shell scheitert bereits hier.
2. SELinux Type Enforcement: UID root hebt die Policy nicht auf. storaged läuft als root, aber in u:r:storaged:s0; der Zielknoten ist u:object_r:debugfs_mmc:s0, und { read } wird verweigert.
3. Domain-spezifische Debugfs-Rechte: dumpstate:s0 darf einzelne generisch gelabelte Binder-/DMA-Buf-Debugfs-Dateien lesen. Daraus folgt nicht, dass es auch debugfs_mmc:s0 lesen darf. Die getrennten Zieltypen sind gerade der Zweck der Policy.
4. fehlende Exports/Schnittstellen: Selbst mit einem geeigneten Prozess muss eine Diagnosefunktion den Wert ausgeben. Der Standard-Bugreport hat keine OEM-IDumpstateDevice-Implementierung und exportiert deshalb keinen Board-Health-Dump.

Weitere direkt beobachtete SELinux-Beispiele stützen diese Einordnung:

• shell:s0 -> sysfs:s0: life_time, pre_eol_info, CID, CSD, manfid, oemid und serial werden beim Lesen abgewiesen;
• shell:s0 -> debugfs_mmc:s0: schon read/search am Verzeichnis mmc0 wird abgewiesen;
• shell:s0 -> tpvdebug_exec:s0: getattr und read am Reader-Binary werden abgewiesen;
• incidentd:s0 -> pstorefs:s0: Verzeichnissuche wird abgewiesen;
• tpvdebug:s0 -> proc_uid_io_stats:s0: TPVs root-Prozess storagedcapture erhält wiederholt getattr-Denials.

Damit wäre die Aussage „Root genügt“ technisch unpräzise. Erforderlich ist eine Kombination aus passender Unix-UID/GID beziehungsweise Capability, einer von SELinux zugelassenen Domain, zugänglichen Zieltypen und einer read-only implementierten Ausgabefunktion.

Privilegierte und speichernahe Prozesse

Prozess/Dienst	beobachtete Unix-Identität	SELinux-Domain	Speicherbezug im Artefakt	Forensische Grenze
emmclifereaderd	Init fordert root, Gruppe system; beim Bugreport beendet	Laufzeitdomain nicht beobachtet; Binary tpvdebug_exec:s0	erzeugt direkt beobachtbar die Boot-Logausgabe; steht zeitlich vor der gleichlautenden Property	Property-Schreibcode, Binary und exakter Quellpfad gesperrt; kein PRE_EOL-Export
storaged PID 2644	root	u:r:storaged:s0	publiziert eMMC 5.1, EOL 1 und A/B 10/10; versucht zusätzlich /sys/kernel/debug/mmc0/mmc0:0001/ext_csd zu lesen	Eventwerte E1; zusätzlicher Debugfs-Rohread durch AVC blockiert
storagedcapture PID 2613	root	u:r:tpvdebug:s0	TPV-Prozess, liest periodisch Storage-/UID-I/O-Daten und schreibt laut Log eigene Capturedateien	sogar /proc/uid_io/stats ist per SELinux gesperrt; keine EXT-CSD-Ausgabe im Bugreport
vold PID 1442	root	u:r:vold:s0	Mount-, fscrypt- und Volumeverwaltung; e2fsck des adoptierten dm-4	kein eMMC-Health-Export; Can't find service: vold im Dumpstate-Log betrifft den Dumpsys-Lookup, nicht den laufenden Daemon
installd PID 2630	root	u:r:installd:s0	erkennt Quota-Mounts auf userdata, user_setting und adoptiertem Volume	Paket-/Quota-Verwaltung, kein roher MMC-/EXT4-Health-Dump
system_server PID 3007	system (UID 1000)	u:r:system_server:s0	StorageManagerService, DeviceStorageMonitor und Paket-/Quota-Koordination	liefert logische Speicherzustände, keine EXT-CSD-/PRE_EOL-Rohwerte
TVStorageMonitorService PID 5636	system (UID 1000)	u:r:system_app:s0	liest die TPV-Property etwa alle 30 Sekunden und klassifiziert Life Time B	Property-Verbraucher, kein unabhängiger Hardwareleser
OnBootLogger/candeebug PID 4186	system (UID 1000)	u:r:system_app:s0	teilt die Property in dev_lt_a und dev_lt_b und protokolliert Dateisystemtelemetrie	bestätigt A/B semantisch, aber ebenfalls nur abgeleiteter Wert
Standard-dumpstate PID 21293	shell	u:r:dumpstate:s0	sammelt den Bugreport und darf ausgewählte Debugfs-Typen lesen	Kernel-Log scheitert; kein IDumpstateDevice; kein MMC-spezifischer Board-Dump
TPV ddg PID 2609	root	u:r:dumpstate:s0	laufender Debug-Dump-Daemon mit Thread uart-dumper; Log meldet nur ddg alive	keine eMMC-Healthdaten oder dokumentierte sichere Schnittstelle im Artefakt
TPV tpv_top_service PID 2610	root	u:r:dumpstate:s0	TPV-Diagnoseprozess	keine eMMC-/EXT4-Ausgabe im Bugreport
TPV errlogservice PID 2578	system	u:r:hal_tv_errlogservice_default:s0	möglicher OEM-Fehlerlogdienst	lshal debug endet mit FAILED_TRANSACTION; Inhalt nicht verfügbar

Die Existenz von Root-Diagnosedaemons ist kein Beleg dafür, dass deren Schnittstellen den gesuchten Wert exportieren oder gefahrlos interaktiv aufrufbar sind. Sie wurden in dieser Untersuchung nicht angesprochen.

Prüfung sämtlicher Storage-Fehlertreffer

Die Kategorie storage_errors enthält genau vier Zeilen:

Treffer	tatsächlicher Kontext	MMC-/EXT4-Relevanz
resolv: SSL_connect write error ... Try again	DNS-/TLS-Netzwerkpfad	keine
NativeCrypto: ... I/O error ... Connection reset by peer	TLS-Socket wurde vom Gegenüber zurückgesetzt	keine
NativeCrypto: SSL shutdown ... I/O error ... Broken pipe	TLS-Socket beim Shutdown geschlossen	keine
incidentd: Buffer corrupted: expect 145 bytes, read 148 bytes	Serialisierung beziehungsweise interner Incident-Puffer	keine belegte Blockgeräte- oder Dateisystemzuordnung

Zusätzliche exakte Volltextprüfungen ergaben keinen Treffer für:

• EXT4-fs mit Error/Warning/Abort/Corruption;
• Buffer I/O error, blk_update_request, Block-I/O-/End-Request-Fehler;
• MMC-Timeout, MMC-CRC/ECC, MMC-Reset oder MMC-Command-Error;
• JBD2-/Journalfehler oder Journal-Abbruch;
• Remount eines Dateisystems als read-only;
• SQLite disk I/O error, database disk image is malformed;
• ENOSPC beziehungsweise No space left on device.

Die sechs Update-Engine-Logs enden jeweils mit ErrorCode::kSuccess und Processing Done. Die davor erscheinende Meldung über nicht aktivierbare Binder-Oneway-Spam-Erkennung (Invalid argument) ist kein OTA-Schreibfehler.

vold führte e2fsck auf /dev/block/dm-4 aus und meldete dieses adoptierte USB-Volume als clean. Das ist kein Check von /data auf mmcblk0p37 und darf nicht als interner eMMC-/EXT4-Gesundheitsbeleg verwendet werden.

Ein separat gesicherter älterer Bootlog enthält einmal Icing: Array storage bad crc .... Das ist ein beschädigter Google-App-Suchindexdatensatz. Der Ausdruck crc stammt hier aus der Anwendungsdatenstruktur, nicht aus dem MMC-Controller. Ohne begleitenden Block-I/O-, EXT4- oder MMC-Fehler bleiben Softwareabbruch, unvollständiger Schreibvorgang, Anwendungsfehler und Medienfehler ununterscheidbar. Auch der vorhandene Google-Icing-Tombstone zeigt einen Check failed: is_initialized()-Abort, keinen Blockgerätefehler.

Warum der Nichtfund nur E3 ist

Vier besonders wichtige Quellen fehlen:

1. Die Kernel-Logsektion ist leer (klogctl Rückgabewert -1).
2. /proc/last_kmsg existiert nicht; PStore/Ramoops konnte von Incidentd nicht gelesen werden.
3. Die EXT4-Zähler von mmcblk0p37 sind für Shell gesperrt.
4. Mangels IDumpstateDevice gibt es keinen OEM-Board-Dump; mehrere TPV-/MTK- HIDL-Debugaufrufe scheitern mit FAILED_TRANSACTION.

Deshalb sind folgende Aussagen nicht zulässig:

• „Die eMMC ist gesund.“
• „Es gab nie MMC-/EXT4-Fehler.“
• „Der normale PRE_EOL-Wert beweise insgesamt eine gesunde eMMC.“
• „Ein Ausfall ist ausgeschlossen.“

Für die Fehlerhistorie zulässig ist nur: Im verfügbaren Android-/Bugreport- Textfenster ist kein Speichergeräte- oder Dateisystemfehler nachweisbar. Der separat bestätigte PRE_EOL-Wert 0x01 bewertet nur die Reserveblockachse.

Forensische Gesamtbewertung

Aussage	Bewertung
Philips hat beim erfassten Boot beide Life-Time-Felder als 0x0a gemeldet	E1 – direkt belegt
Philips versteht A und B als getrennte eMMC-Life-Time-Felder	E1 – direkt belegt durch dev_lt_a/dev_lt_b und DEX-/Laufzeitbefund
Beide 0x0a entsprechen dem Band 90–100 % geschätzter Lebensdauer verbraucht	E1 für Philips' eigene B-Zuordnung; zusätzlich durch die vorhandene JEDEC-/Herstelleranalyse gestützt
Der Reader liest die Werte aus dem eMMC-EXT_CSD	E2 – sehr wahrscheinlich, aber nicht durch Binary oder Rohdump geschlossen
Der Reader verwendet genau den beobachteten Debugfs-Pfad	E2, nicht direkt beobachtet
PRE_EOL_INFO ist normal/warning/urgent	E1: 0x01 (Normal) über Storaged-Event und lokale Felddefinition; direkter Rohread bleibt U
CID, Hersteller und konkretes eMMC-Modell	U
Es gibt aktuell sichtbare MMC-/EXT4-/Block-I/O-Fehler	E3-Nichtfund im verfügbaren Fenster
Es gab historisch keine solchen Fehler	U, weil Kernel-/PStore-/EXT4-Quellen fehlen
Die eMMC fällt unmittelbar aus	nicht belegt
Die eMMC weist einen ernstzunehmenden Verschleißindikator auf	E1, da A und B im höchsten regulären 10-%-Band stehen

Legitime nächste Beweisquelle

Der technisch präziseste nächste Schritt wäre kein allgemeiner Root-Zugang, sondern ein autorisierter Philips/TPV-Diagnosekontext, der ausschließlich lesend folgende Werte exportiert:

1. EXT-CSD-Bytes 267, 268 und 269 samt vollständigem Rohdump;
2. CID/CSD und Herstellerkennung;
3. /sys/fs/ext4/mmcblk0p37/errors_count, first_error_time, last_error_time und lifetime_write_kbytes;
4. Kernel-/PStore-Zeilen zu mmc0, mmcblk0, ext4 und jbd2;
5. Zeitstempel und Rückgabestatus des Readers, damit ein persistenter Altwert sicher ausgeschlossen wird.

Legitime Wege wären ein signierter Engineering-/Servicebuild, ein offizielles TPV-Werkstatttool oder eine zukünftige Firmware mit korrekt implementiertem IDumpstateDevice. Auch eine lokale statische Analyse einer offiziell bezogenen passenden Firmware kann die Reader-Implementierung schließen, ohne das Gerät zu verändern. Nicht erforderlich und nicht angemessen sind Root-Exploit, Bootloader-Entsperrung, Recovery, Flashen oder das manuelle Starten privilegierter TPV-Dienste.

Reproduzierbarkeit und Sicherheitsgrenze

Die entscheidenden lokalen Rohfundstellen wurden gegen eMMC-, Init-, Bootlog- und Bugreport-Ausgaben geprüft. Diese Rohdateien sind aus Datenschutzgründen nicht veröffentlicht. Enthalten bleibt die Bugreport-Gesamtanalyse.

Diese Vertiefung beruht ausschließlich auf bereits vorhandenen lokalen Artefakten. Es wurden keine neuen Geräteabfragen, keine Prozessaufrufe am TV, keine Einstellungsänderungen und keine Speicherzugriffe außerhalb der bereits gesicherten Daten vorgenommen.