30 KiB
Lokale System-, Boot- und Partitionsinventur
Stand: 2026-08-25. Diese Auswertung wurde ausschließlich lokal aus dem vorhandenen Bugreport und bereits gesicherten Textartefakten erstellt. Es gab keine Live-ADB-Abfrage, keinen Reboot, keinen Wechsel in Recovery/Fastboot und keine Änderung am Fernseher.
Bewertungsmaßstab
- CONFIRMED – unmittelbar im Bugreport, in Properties, Kernel-Commandline oder Mountinfo beobachtet.
- LIKELY – mehrere lokale Indizien passen zusammen, aber der entscheidende Rohwert beziehungsweise die Implementierung fehlt.
- POSSIBLE – technisch mit dem Befund vereinbar, aber ohne positiven lokalen Beleg.
- DISPROVED – durch die lokale Momentaufnahme direkt widerlegt. Das gilt nur für die untersuchte Firmware und den aufgezeichneten Boot.
Quellenkürzel
- BR:
diagnostics/bugreport/extracted/files/01790__bugreport-PH9M_EA_5599-STT2.230526.001-2026-08-25-13-26-44.txt - MI: PID-1-Mountnamespace,
diagnostics/bugreport/extracted/files/00018__mountinfo - EA: Zugriffsprotokoll,
diagnostics/raw/emmc/emmc-filesystem-health-access.txt - EI: eMMC-Identitäts-/Zugriffsprotokoll,
diagnostics/raw/emmc/emmc-identity-and-access.txt - FS:
diagnostics/boot/fstab.mt5887 - FL:
diagnostics/boot/fstab.late.mt5887 - IA:
diagnostics/boot/vendor-init/hw/init.abupdate.rc - KI:
diagnostics/boot/vendor-init/hw/init.mt5887.rc - KC: lokal gesichertes
/proc/config.gz,diagnostics/kernel/proc-config.gz(SHA-2562C8DC79DBA98F4555684D0DED59C39232B4A4ADEAA4D92E5625FBB0C24D8F8C6)
Zeilenangaben hinter BR und MI beziehen sich auf diese unveränderten
lokalen Dateien.
Kurzfazit
| Aussage | Bewertung | Beleg |
|---|---|---|
| Android TV 12, API 31, Patchlevel 2025-11-01 | CONFIRMED | BR:248208-248211 |
Philips/TPV-Firmware TPM191E_R.211.000.103.000 |
CONFIRMED | BR:248246-248247 |
Produktionsbuild user, release-keys, nicht debuggable |
CONFIRMED | BR:248190-248200, 248219 |
MediaTek-MT53xx-Plattform, Kernel-Machine MT5887 |
CONFIRMED | BR:248049, 248053, 248221-248222; KC: CONFIG_MACH_MT5887=y, CONFIG_SOC_MEDIATEK_MT53XX=y |
OEM-Chipkennung MT5599 |
CONFIRMED als TPV-Property/Produktkennung, nicht als ausgelesene Silizium-ID | BR:247943; zusätzlich BR:10563-10569 |
TPVs Kennung MT5599 bezeichnet hier dieselbe physische Plattform/Familie wie mt5887 |
POSSIBLE | beide Kennungen treten auf demselben Gerät auf; eine physische Aliasbeziehung ist mangels Chip-ID/Herstellerunterlage nicht bewiesen |
Android-Userspace ist ausschließlich 32-Bit ARM (armeabi-v7a, armeabi) |
CONFIRMED | BR:248255-248259; Tombstones melden ABI: 'arm', z. B. BR:168856 |
| Kernel/CPU-Architektur ist ARM64; Android-Userspace bleibt 32-Bit | CONFIRMED | KC: CONFIG_ARM64=y, CONFIG_64BIT=y, CONFIG_COMPAT=y; ABI-Properties in BR:248255-248259 |
Kernel 4.9.310-ab4215, SMP/PREEMPT, GCC 5.5/Linaro |
CONFIRMED | BR:12 |
| Aktiver Bootslot ist A | CONFIRMED | BR:13, 248056 |
| Legacy/statisch partitioniertes A/B-System, keine Android-Dynamic-Partitions | CONFIRMED für diesen Boot | vollständige blkdevparts=-Tabelle in BR:13; kein super; direkte physische System-/Vendor-Slots |
| AVB/Verified Boot ist gesperrt, Zustand grün | CONFIRMED | BR:248050, 248057-248063 |
| dm-verity läuft im Enforcing-Modus | CONFIRMED | BR:13 und 248064 |
System-as-root über /dev/dm-0 |
CONFIRMED | BR:13, 248197; MI:1 |
| Öffentliches Bootloader-Unlock / Unlock-Fähigkeit | UNBEKANNT / nicht belegt | kein Fastboot-Test, keine Unlock-Ability-Ausgabe und keine modellspezifische Herstellerfreigabe vorhanden |
Phase 1 – System- und Buildinventur
Geräte- und Firmwaredaten
| Feld | Wert | Status / Fundstelle |
|---|---|---|
| Hersteller / Marke | Philips | CONFIRMED, BR:248254, 248263 |
| Modellproperty | TPM191E |
CONFIRMED, BR:248264 |
| konkretes TV-Modell | 43PUS7394/12 |
CONFIRMED, BR:13 (device_name) und BR:247942 |
| Produkt / Device / Board | PH9M_EA_5599 |
CONFIRMED, BR:248196, 248253, 248260, 248265 |
| TPV-Produkt-ID | TPM191E_R |
CONFIRMED, BR:248246 |
| Firmware | TPM191E_R.211.000.103.000 |
CONFIRMED, BR:248247 |
| Android | 12 / REL |
CONFIRMED, BR:248201-248209 |
| SDK | 31 | CONFIRMED, BR:248210 |
| First API level | 28 | CONFIRMED, BR:248261; dies belegt die ursprüngliche Plattformgeneration, nicht zwingend das ursprüngliche Verkaufs-ROM |
| Security Patch Level | 2025-11-01 |
CONFIRMED, BR:248211 |
| Build-ID | STT2.230526.001 |
CONFIRMED, BR:248191, 248195 |
| Incremental | 4215 |
CONFIRMED, BR:248204 |
| Buildzeit | Tue Dec 9 11:16:50 CST 2025 |
CONFIRMED, BR:248188 |
| Buildhost / User | TWTPSA398-ub1404 / jenkins |
CONFIRMED, BR:248194, 248200 |
| Fingerprint | Philips/PH9M_EA_5599/PH9M_EA_5599:12/STT2.230526.001/4215:user/release-keys |
CONFIRMED, BR:6 und 248192 |
Der vollständige Build-String lautet (BR:248190):
PH9M_EA_5599-user 12 STT2.230526.001 4215 release-keys
Produktions- und ADB-Sicherheitsstatus
| Property / Beobachtung | Wert | Bewertung |
|---|---|---|
ro.build.type |
user |
CONFIRMED |
ro.build.tags |
release-keys |
CONFIRMED |
ro.debuggable |
0 |
CONFIRMED |
ro.secure |
1 |
CONFIRMED |
ro.adb.secure |
1 |
CONFIRMED |
init.svc.adbd |
running |
CONFIRMED; BR:247638 |
service.adb.root |
nicht in der vollständigen Propertyliste publiziert | CONFIRMED als Nichtfund, nicht gleichbedeutend mit einem Wert 0; Vendor-Init besitzt nur einen Trigger, der bei Wert 1 den USB-Gadget toggelt und adbd neu startet (init.mtk_common.rc:74-84) |
| SELinux Runtime | Enforcing; Shell uid=2000, Domain u:r:shell:s0 |
CONFIRMED durch deep-forensics/selinux/access-summary.txt und Auditzeilen mit permissive=0, z. B. BR:68587 |
Build ist eng oder userdebug |
– | DISPROVED durch user, release-keys, ro.debuggable=0 |
Fundstellen: BR:248041, 248198-248200, 248219, 248294. Die Kombination ist typisch für einen Production-ADB-Kontext. Ob der Vendor dennoch einen speziell geschützten Engineeringpfad besitzt, folgt daraus nicht.
Vendor-/ODM-/Treble-Merkmale
| Merkmal | Wert | Bewertung |
|---|---|---|
ro.treble.enabled |
true |
CONFIRMED, BR:248325 |
| Framework VNDK | 31 | CONFIRMED, BR:248380 |
| Vendor VNDK | 26 | CONFIRMED, BR:248369; älterer Vendor-Unterbau trotz Android-12-Framework |
| ODM-Build | Android 12 / SDK 31 / Incremental 4215 / release-keys | CONFIRMED, BR:248233-248245 |
| Vendor-Build | Android 12 / SDK 31 / Incremental 4215 / release-keys | CONFIRMED, BR:248327-248337 |
| Vendor SPL | leer | CONFIRMED, BR:248331; daraus darf kein Kernel-/Vendor-Patchlevel abgeleitet werden |
ro.vendor.mtk.oem.lock |
1 |
CONFIRMED, BR:248342; Semantik vendorintern, daher nicht allein als Bootloaderbeweis verwenden |
ro.crypto.state |
unsupported |
CONFIRMED, BR:248217; /data erscheint direkt als ext4 auf mmcblk0p37 |
SoC, CPU und ABI
Direkt beobachtete Kennungen
ro.board.platform=mt5887
ro.boot.hardware=mt5887
ro.hardware=mt5887
ro.hardware.bootctrl=mt5887
persist.odm.tpv.sys.ACR_OemChip=MT5599
ro.product.board=PH9M_EA_5599
Fundstellen: BR:247943, 248049, 248053, 248221-248222, 248253.
Die Firmware enthält zudem MediaTek-TV-HALs und -Dienste; der HbbTV-User-Agent
nennt _TV_MT5599_2019 (BR:10563-10569). Damit ist CONFIRMED, dass es sich
um eine MediaTek/TPV-Plattform handelt und dass TPV sie als MT5599 ausweist.
Gleichzeitig ist CONFIRMED, dass Androids Board-/HAL-Plattform mt5887
heißt. Die Kernelkonfiguration verstärkt diesen Befund wesentlich:
CONFIG_MACH_MT5887=y und CONFIG_SOC_MEDIATEK_MT53XX=y; die alternativen
aufgeführten TV-Machines MT5886, MT5893, MT5895 usw. sind nicht gesetzt.
Die spätere /proc/cpuinfo-Abfrage nennt Hardware: MT5887 und vier
Cortex-A53-Kerne, liefert aber ebenfalls keine ausgelesene Silizium-ID. Ohne
Device-Tree-compatible, Chip-ID-Register oder passende Herstellerunterlage
ist die Aussage „MT5887, MT5690 und MT5599 sind exakt dasselbe Silizium“ daher
weiterhin nicht bestätigt. Die beste lokale Einordnung lautet:
CONFIRMED: Kernel und Android sind konkret für die MediaTek-Machine
MT5887gebaut. CONFIRMED: TPV bezeichnet den OEM-Chip/die Produktfamilie gleichzeitig alsMT5599. POSSIBLE: Beide Kennungen können Ebenen derselben Plattformfamilie bezeichnen. Die exakte Alias-/Siliziumbeziehung bleibt offen und darf nicht aus der Namenskorrelation abgeleitet werden.
Architektur
ro.product.cpu.abi=armeabi-v7a
ro.product.cpu.abi2=armeabi
ro.product.cpu.abilist=armeabi-v7a,armeabi
ro.product.cpu.abilist32=armeabi-v7a,armeabi
ro.product.cpu.abilist64=
Dies belegt einen ausschließlich 32-Bit-fähigen Android-Userspace. Native
Crashdumps melden ABI: 'arm'. Das inzwischen lokal gesicherte
/proc/config.gz bestätigt jedoch ausdrücklich Linux/arm64 4.9.310,
CONFIG_ARM64=y, CONFIG_64BIT=y und CONFIG_COMPAT=y. Damit sind ein
64-Bit-ARM-Kernel und die 32-Bit-Kompatibilitätsschicht CONFIRMED. Der
Fernseher verwendet also einen 64-Bit-Kernel mit reinem 32-Bit-Android-
Userspace. CONFIG_NR_CPUS=4 bestätigt, dass dieser Kernel für maximal vier
CPUs gebaut ist. Eine spätere rein lesende /proc/cpuinfo-Abfrage hat vier
Prozessoren mit CPU part 0xd03 direkt gezählt und damit vier Cortex-A53-Kerne
CONFIRMED. Das ist eine CPU-Kernidentifikation, keine Silizium-ID für die
offene MT5887/MT5690/MT5599-Aliasfrage.
Kernelinventur
Direkte Bugreport-Ausgabe (BR:12):
Linux version 4.9.310-ab4215 (jenkins@TWTPSA398-ub1404)
(gcc version 5.5.0 (Linaro GCC 5.5-2017.10))
#1 SMP PREEMPT Tue Dec 9 11:04:39 CST 2025
| Merkmal | Bewertung |
|---|---|
Kernelrelease 4.9.310-ab4215 |
CONFIRMED |
| SMP und PREEMPT | CONFIRMED |
| Compiler GCC 5.5.0 / Linaro 2017.10 | CONFIRMED |
| Kernelbuild vom 2025-12-09 | CONFIRMED |
ro.kernel.version=4.9 |
CONFIRMED, BR:248228 |
| exakte Kernelkonfiguration | CONFIRMED verfügbar als KC; Header: Linux/arm64 4.9.310 Kernel Configuration |
| Android-SPL belegt alle Kernel-CVE-Backports | DISPROVED als Schlussfolgerung; SPL und Kernelpatchstand sind getrennte Evidenz |
Der zugängliche Bugreport-Kernelabschnitt war leer beziehungsweise durch
klogctl beschränkt. dmesg, /proc/cmdline und /proc/partitions waren der
ADB-Shell direkt nicht zugänglich (EA:18-26). Dumpstate hat die Kernel-
Commandline dennoch im Bugreportkopf gesichert.
Relevante Kernelkonfiguration
| Option | Wert | Bedeutung für diese Inventur |
|---|---|---|
CONFIG_ARM64, CONFIG_64BIT, CONFIG_COMPAT |
y |
CONFIRMED ARM64-Kernel mit 32-Bit-Kompatibilität |
CONFIG_PREEMPT, CONFIG_SMP |
y |
entspricht der Versionszeile |
CONFIG_IKCONFIG, CONFIG_IKCONFIG_PROC |
y |
erklärt den jetzt gesicherten /proc/config.gz-Export |
CONFIG_CMDLINE_PARTITION |
y |
Kernel unterstützt das beobachtete blkdevparts=-Layout |
CONFIG_CMDLINE="loop.max_part=7", CONFIG_CMDLINE_EXTEND=y |
gesetzt | eingebaute Minimal-Commandline wird um die vom Bootpfad gelieferte Commandline erweitert |
CONFIG_EFI_PARTITION |
y |
GPT-Unterstützung ist einkompiliert; das beweist nicht, dass dieses konkrete Layout von GPT stammt |
CONFIG_DM_VERITY, CONFIG_DM_VERITY_FEC |
y |
bestätigt dm-verity/FEC-Unterstützung |
CONFIG_DM_CRYPT |
y |
erklärt unter anderem Device-Mapper-Verschlüsselung für adopted storage; /data ist trotzdem direkt ext4 gemountet |
CONFIG_EXT4_FS, CONFIG_SQUASHFS |
y |
deckt die beobachteten Dateisysteme ab |
CONFIG_MMC, CONFIG_MMC_BLOCK, CONFIG_MMC_MTK |
y |
MediaTek-MMC-Treiberpfad bestätigt |
CONFIG_MMC_BLOCK_MINORS |
64 |
passt exakt zur beobachteten Hauptnode plus p1–p63 |
CONFIG_MACH_MT5887, CONFIG_SOC_MEDIATEK_MT53XX |
y |
konkrete Kernel-Machine und SoC-Familie bestätigt |
CONFIG_NR_CPUS |
4 |
Kernelobergrenze vier logische CPUs; spätere /proc/cpuinfo-Abfrage zählt vier Cortex-A53-Kerne direkt |
CONFIG_SECURITY_SELINUX, CONFIG_DEFAULT_SECURITY_SELINUX |
y |
SELinux ist Standard-LSM |
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE |
1 |
Default ist enforcing; Runtime-Audit meldet ebenfalls permissive=0 |
CONFIG_SECCOMP, CONFIG_SECCOMP_FILTER |
y |
Seccomp-Filter verfügbar |
CONFIG_RANDOMIZE_BASE, CONFIG_CC_STACKPROTECTOR_STRONG, CONFIG_HARDENED_USERCOPY |
y |
relevante Kernelhärtungen aktiv |
CONFIG_USER_NS |
nicht gesetzt | unprivilegierte User-Namespaces nicht verfügbar |
CONFIG_KEXEC |
nicht gesetzt | kein einkompilierter kexec-Bootpfad |
CONFIG_DEVMEM, CONFIG_DEVKMEM |
nicht gesetzt | keine klassischen /dev/mem-//dev/kmem-Interfaces |
CONFIG_MODULES, CONFIG_MODULE_UNLOAD |
y |
Kernelmodule sind unterstützt |
CONFIG_MODULE_SIG |
nicht gesetzt | keine Kernel-Modulsignaturprüfung durch diese Option; dies verleiht der Shell keine Ladeberechtigung |
Die Konfiguration erlaubt außerdem SELinux-Development-/Disable-Codepfade
(CONFIG_SECURITY_SELINUX_DEVELOP=y, ..._DISABLE=y). Im tatsächlichen
Boot wurde aber kein Disable-/Permissive-Argument beobachtet; AVB ist locked,
die Runtime ist enforcing. Aus der einkompilierten Option folgt daher kein
nutzbarer Shell-Schalter.
Phase 2 – Boot- und Verified-Boot-Architektur
Relevante ro.boot.*-Momentaufnahme
| Property | Wert | Status |
|---|---|---|
ro.boot.bootreason |
reboot |
CONFIRMED, BR:248051; OEM-Properties führen daneben Cold Boot/CrashBoot, deren Semantik ist nicht identisch |
ro.boot.hardware |
mt5887 |
CONFIRMED, BR:248053 |
ro.boot.slot_suffix |
_a |
CONFIRMED, BR:248056 |
ro.boot.dtbo_idx |
0 |
CONFIRMED, BR:248052 |
ro.boot.serialno |
000070af24c031e7 |
CONFIRMED, BR:248055 |
ro.boot.phandle |
leer | CONFIRMED, BR:248054 |
ro.boot.vbmeta.device_state |
locked |
CONFIRMED, BR:248059 |
ro.boot.verifiedbootstate |
green |
CONFIRMED, BR:248063 |
ro.boot.veritymode |
enforcing |
CONFIRMED, BR:248064 |
ro.boot.flash.locked, eine Unlock-Ability und ein Rollback-Index werden in
den vorhandenen Properties nicht ausgegeben und bleiben UNBEKANNT.
Rekonstruierter Normalboot
eMMC / mmcblk0
-> U-Boot-artige Bootloaderpartitionen (uboot/ubootB + Umgebungen) [LIKELY]
-> aktiver Slot _a [CONFIRMED]
-> vbmeta_a = mmcblk0p8 [CONFIRMED]
-> boot_a = mmcblk0p14 [CONFIRMED als Partitionszuordnung]
-> system_a = mmcblk0p15 -> dm-verity -> dm-0 -> / [CONFIRMED]
-> vendor_a = mmcblk0p35 -> vendor-verity -> dm-1 -> /vendor [LIKELY für p35-Ziel,
CONFIRMED für dm-1/verity]
-> linux_rootfs_a = p17 -> dm-2 -> squashfs unter /mnt/vendor/linux_rootfs [LIKELY für p17-Ziel]
-> 3rd_a = p19 -> dm-3 -> squashfs unter /mnt/vendor/3rd [LIKELY für p19-Ziel]
-> userdata = p37 -> ext4 -> /data [CONFIRMED]
Die Bootloaderart ist LIKELY U-Boot-basiert, weil die Partitionen wörtlich
uboot, ubootB, uboot_env und uboot_envB heißen. Eine ausführbare
Bootloader-Versionsausgabe fehlt; ro.bootloader=unknown ist CONFIRMED
(BR:7 und 248065). Daher ist weder eine konkrete U-Boot-Version noch deren
Kommando-/Unlockoberfläche bestätigt.
Die lokal gesicherte Fstab bestätigt die Slot- und AVB-Zuordnung unabhängig
von der Commandline: system und vendor sind avb,slotselect,recoveryonly
(FS:6-7); linux_rootfs, 3rd und factory sind ebenfalls avb,slotselect
(FS:12-14). boot, vbmeta, dtbo, misc und tzbp werden als rohe
emmc-Bereiche mit slotselect beschrieben (FS:16-20). Die separate
recovery-Zeile ist auskommentiert (FS:15).
System-as-root
Die Commandline enthält (BR:13):
skip_initramfs root=/dev/dm-0 androidboot.slot_suffix=_a
Zusätzlich gilt ro.build.system_root_image=true (BR:248197). PID 1 sieht /
read-only als ext4 auf Major/Minor 254:0, /dev/root (MI:1). Die dm-Tabelle
in der Commandline nennt als Daten- und Hashgerät 179:15, also
mmcblk0p15 = system_a. Damit sind System-as-root und die Zuordnung von
dm-0 zu system_a CONFIRMED. /system ist in diesem Namespace kein
separater Mount, sondern Teil dieses Root-Dateisystems.
AVB und dm-verity
| Feld | Wert | Bewertung |
|---|---|---|
ro.boot.avb_version |
1.2 |
CONFIRMED, BR:248050 |
ro.boot.vbmeta.avb_version |
1.0 |
CONFIRMED, BR:248057 |
| vbmeta block device | 179:8 = mmcblk0p8 = vbmeta_a |
CONFIRMED, BR:13, 248058 |
| Device state | locked |
CONFIRMED, BR:248059 |
| Verified boot state | green |
CONFIRMED, BR:248063 |
| Verity mode | enforcing |
CONFIRMED, BR:248064 |
| vbmeta hash algorithm | SHA-256 | CONFIRMED, BR:248061 |
| vbmeta digest | 66eae984496730f2339e5e5531f513645ce32263ac24b95cd80d4f787d701dc6 |
CONFIRMED, BR:248060 |
| vbmeta size | 17,280 Byte | CONFIRMED, BR:248062 |
| System verity hash tree | SHA-1, 4096-Byte-Blöcke, FEC | CONFIRMED, BR:13 |
| Fehlerverhalten | restart_on_corruption, ignore_zero_blocks, use_fec_from_device |
CONFIRMED, BR:13 |
| Vendor-Verity | dm-Gerät vendor-verity vorhanden |
CONFIRMED, BR:7325; /vendor ist dm-1 ro (MI:8) |
locked + green + enforcing widerlegt für diesen Boot einen bereits
entsperrten/orangen Verified-Boot-Zustand. Ein beliebig gepatchtes boot_a
würde im gegenwärtigen Zustand deshalb LIKELY an Signatur-/Verified-Boot-
Prüfungen scheitern. Ob Philips/MediaTek einen autorisierten Signaturpfad oder
einen Unlockmechanismus implementiert, ist aus den lokalen Daten nicht
entscheidbar. Der konkrete AVB-Hashdescriptor für boot, dessen Public Key
und Rollback-Indizes wurden nicht exportiert; diese Details bleiben bis zur
rein lokalen Analyse eines originalen vbmeta-/boot-Images UNBEKANNT.
Partitionierung
Schema
Die Kernel-Commandline definiert die gesamte User-Area mit
blkdevparts=mmcblk0:... (BR:13). Das ist ein statisches, per Bootargument
benanntes Partitionslayout. Die 63 angegebenen Größen summieren sich auf
14.809 MiB beziehungsweise 14,462 GiB. Ein nominelles 16-GB-eMMC ist damit
LIKELY, seine exakte Rohgröße bleibt wegen gesperrtem
/sys/block/mmcblk0/size und blockdev --getsize64 unbekannt (EI).
Es gibt kein super in der vollständigen Liste und System/Vendor liegen auf
festen physischen A/B-Partitionen. Android Dynamic Partitions beziehungsweise
ein logisches super-Layout sind für diesen Boot daher DISPROVED.
Ob auf den ersten eMMC-Sektoren zusätzlich eine GPT- oder MBR-Tabelle liegt,
ist hingegen UNBEKANNT: KC enthält sowohl CONFIG_MSDOS_PARTITION=y als
auch CONFIG_EFI_PARTITION=y, der Rohblock war nicht lesbar. Die tatsächlich
vom laufenden Kernel verwendete Namens-/Größenzuordnung ist aber direkt durch
CONFIG_CMDLINE_PARTITION=y plus blkdevparts= CONFIRMED.
Die generischen Android-12-Dateien snapuserd.rc und lpdumpd.rc ändern diese
Bewertung nicht: beide Dienste sind disabled; lpdumpd enthält nur den
AOSP-Defaultnamen ${ro.boot.super_partition:-super}. Weder eine
ro.boot.super_partition-Property noch ein super-Blockgerät ist im
Gerätebefund vorhanden.
Vollständige mmcblk0-Zuordnung
Die folgende Tabelle ist in der Reihenfolge aus BR:13 rekonstruiert. Größen
sind die wörtlichen m-Angaben der Kernel-Commandline.
| Block | Größe | Name | Block | Größe | Name |
|---|---|---|---|---|---|
| p1 | 2 MiB | uboot |
p2 | 2 MiB | ubootB |
| p3 | 2 MiB | uboot_env |
p4 | 2 MiB | uboot_envB |
| p5 | 10 MiB | perm |
p6 | 8 MiB | dtbo_a |
| p7 | 8 MiB | dtbo_b |
p8 | 1 MiB | vbmeta_a |
| p9 | 1 MiB | vbmeta_b |
p10 | 1 MiB | ciplus |
| p11 | 2 MiB | dvbsDB_a |
p12 | 2 MiB | eeprom_A |
| p13 | 1 MiB | misc |
p14 | 40 MiB | boot_a |
| p15 | 2390 MiB | system_a |
p16 | 40 MiB | factory_b |
| p17 | 128 MiB | linux_rootfs_a |
p18 | 1 MiB | basic_a |
| p19 | 368 MiB | 3rd_a |
p20 | 256 MiB | 3rd_rw |
| p21 | 1 MiB | Panel_Table_b |
p22 | 1 MiB | channelA |
| p23 | 1 MiB | channelB |
p24 | 30 MiB | pq_a |
| p25 | 5 MiB | aq_a |
p26 | 1 MiB | bootlogo |
| p27 | 1 MiB | al_a |
p28 | 4 MiB | tzbp_a |
| p29 | 8 MiB | adsp_a |
p30 | 1 MiB | part_29 |
| p31 | 1 MiB | part_30 |
p32 | 1352 MiB | upgrade |
| p33 | 40 MiB | dolby |
p34 | 1 MiB | SCHEDPVR |
| p35 | 460 MiB | vendor_a |
p36 | 1 MiB | odm_a |
| p37 | 5115 MiB | userdata |
p38 | 1 MiB | al_b |
| p39 | 40 MiB | factory_a |
p40 | 1 MiB | Panel_Table_a |
| p41 | 4 MiB | r20_a |
p42 | 4 MiB | r21_a |
| p43 | 4 MiB | 3dlut_a |
p44 | 2 MiB | dvbsDB_b |
| p45 | 40 MiB | boot_b |
p46 | 2390 MiB | system_b |
| p47 | 128 MiB | linux_rootfs_b |
p48 | 1 MiB | basic_b |
| p49 | 368 MiB | 3rd_b |
p50 | 30 MiB | pq_b |
| p51 | 5 MiB | aq_b |
p52 | 1000 MiB | user_setting |
| p53 | 8 MiB | tpv_misc_a |
p54 | 4 MiB | tzbp_b |
| p55 | 8 MiB | adsp_b |
p56 | 460 MiB | vendor_b |
| p57 | 1 MiB | odm_b |
p58 | 1 MiB | Panel_Table_b |
| p59 | 4 MiB | r20_b |
p60 | 4 MiB | r21_b |
| p61 | 4 MiB | 3dlut_b |
p62 | 1 MiB | reserved2 |
| p63 | 8 MiB | tpv_misc_b |
Die doppelte Bezeichnung Panel_Table_b bei p21 und p58 steht wörtlich in
der Commandline und wurde nicht korrigiert. Welche davon aktiv/legacy ist,
bleibt unbekannt.
Zusätzlich sind /sys/block/mmcblk0boot0 und /sys/block/mmcblk0rpmb
CONFIRMED vorhanden (BR:156599-156600, 156627-156628). Ein boot1-Knoten
wurde vom Bugreport nicht aufgeführt; das ist kein Beweis, dass die eMMC-
Hardware keinen zweiten Bootbereich besitzt.
A/B-OTA
ro.build.ab_update=true (BR:248186) und ro.boot.slot_suffix=_a belegen ein
A/B-System. Die deklarierte OTA-Liste lautet (BR:248252):
boot,system,vbmeta,vendor,dtbo,linux_rootfs,factory,3rd,tzbp,pq,aq,adsp,
tpv_misc,uboot,uboot_env,ubootB,uboot_envB,dolby,r20,r21,3dlut
Nicht jede physische Partition ist geslottet; userdata, upgrade,
user_setting, 3rd_rw, misc, perm und weitere Daten-/Konfigurations-
bereiche sind gemeinsam. update_engine lief im Bugreport als root-Prozess
(BR:159499, 161329) und init.svc.update_engine=running (BR:247719).
IA:4-21 legt zur Bootzeit die generischen by-name-Symlinks auf den
aktuellen ${ro.boot.slot_suffix} um. IA:24-57 erzeugt für tatsächlich
ungeslottete Bereiche künstliche _a- und _b-Aliase auf denselben Block;
besonders wichtig sind hier misc, upgrade, userdata, uboot und deren
Umgebungen. Die bloße Existenz eines _a/_b-Alias beweist bei diesem Vendor
daher nicht, dass zwei physische Kopien existieren.
Zusätzlich ist ein root laufender Boot-Control-HAL registriert
(android.hardware.boot@1.0::IBootControl default in
android.hardware.boot@1.0-service.rc:1-5). Dies bestätigt die A/B-
Slotverwaltung. Der Dienst update_engine wird in
system-init/update_engine.rc:8-9 ausdrücklich bei vorhandenem
ro.boot.slot_suffix aktiviert.
Beobachtete Mounts und Dateisysteme
| Mountpoint | Quelle | FS / Optionen | Status |
|---|---|---|---|
/ |
/dev/root, Major/Minor 254:0 = dm-0 |
ext4, ro | CONFIRMED, MI:1 |
/vendor |
/dev/block/dm-1 |
ext4, ro | CONFIRMED, MI:8 |
/data |
.../by-name/userdata, 179:37 |
ext4, rw, data=ordered |
CONFIRMED, MI:46 |
/perm |
.../by-name/perm, 179:5 |
ext4, ro | CONFIRMED, MI:49 |
/data/ota_package |
.../by-name/upgrade, 179:32 |
ext4, rw | CONFIRMED, MI:51 |
/data/vendor/user_setting |
.../by-name/user_setting, 179:52 |
ext4, rw | CONFIRMED, MI:61 |
/data/vendor/3rd_rw |
.../by-name/3rd_rw, 179:20 |
ext4, rw | CONFIRMED, MI:62 |
/mnt/vendor/linux_rootfs |
dm-2 | squashfs, ro | CONFIRMED, MI:47 |
/mnt/vendor/3rd |
dm-3 | squashfs, ro | CONFIRMED, MI:48 |
Adopted USB unter /mnt/expand/... |
dm-4 | ext4, rw | CONFIRMED, MI:64 |
/storage/emulated |
/dev/fuse über adopted storage |
FUSE/sdcardfs-Schichten | CONFIRMED, MI:77-93 |
Der df-Snapshot bestätigt / mit 2.370.764 KiB, /vendor mit 434.492 KiB
und /data mit 5.089.920 KiB Dateisystemgröße (BR:248515-248525).
Vorhandene beziehungsweise fehlende Standardpartitionen
| erwarteter Bereich | Befund | Bewertung |
|---|---|---|
boot |
boot_a p14, boot_b p45 |
CONFIRMED |
system |
system_a p15, system_b p46 |
CONFIRMED |
vendor |
vendor_a p35, vendor_b p56 |
CONFIRMED |
odm |
kleine odm_a p36 / odm_b p57, aber kein eigener /odm-Mount |
Partitionen CONFIRMED, Inhalt/Funktion UNBEKANNT |
userdata |
p37, /data |
CONFIRMED |
misc |
p13 | CONFIRMED, nicht normal gemountet |
vbmeta |
p8/p9 | CONFIRMED |
dtbo |
p6/p7 | CONFIRMED |
recovery |
keine so benannte Partition; Fstab-Zeile ist auskommentiert | klassische separate Recoverypartition DISPROVED; Recovery in boot/factory bleibt POSSIBLE |
cache |
keine so benannte Partition und kein eigener Mount | separate Cachepartition DISPROVED; /data/cache ist nur ein Datenverzeichnis |
metadata |
keine so benannte Partition / kein Mount | separate Android-Metadatapartition DISPROVED in diesem Layout |
persist |
keine so benannte Partition | DISPROVED als Name; perm darf ohne weitere Evidenz nicht mit persist gleichgesetzt werden |
super |
nicht vorhanden | Dynamic-Partition-Schema DISPROVED |
factory |
factory_a/factory_b; Fstab beschreibt /factory als AVB-geschütztes, geslottetes SquashFS |
Abbildformat/-schutz CONFIRMED, genaue Recovery-/Service-Rolle LIKELY, aber nicht vollständig belegt |
upgrade |
p32, unter /data/ota_package gemountet |
CONFIRMED |
Recovery-, Fastboot- und Service-Modi
| Modus/Fähigkeit | lokale Evidenz | Bewertung |
|---|---|---|
| Android RecoverySystem/OTA | RecoverySystemService startet (BR:8008); upgrade-Partition, UpdateEngine, uncrypt und BCB-Dienste vorhanden |
CONFIRMED als Update-/Recovery-Infrastruktur |
| separate klassische Recoverypartition | fehlt in vollständiger Tabelle | DISPROVED |
Recovery steckt in boot_a/b |
mit Layout und fehlender Recoverypartition vereinbar | POSSIBLE, nicht verifiziert |
factory_a/b enthält ein OEM-Serviceabbild; eine Recovery-Rolle ist möglich |
Fstab: AVB-geschütztes SquashFS auf /factory; factory_service.rc definiert /factory/bin/factory_service oneshot in u:r:vold:s0 |
Serviceabbild/-definition CONFIRMED; Recovery-Rolle POSSIBLE, tatsächlicher Start/Inhalt/Bedienschnittstelle nicht beobachtet |
| Vendor-Recovery-Installationshook | vendor_flash_recovery.rc definiert /vendor/bin/install-recovery.sh als class main, oneshot |
Definition CONFIRMED, tatsächlicher Lauf sowie Ziel/Aktion des nicht gesicherten Skripts UNBEKANNT |
| BCB-Steuerung | uncrypt.rc definiert setup-bcb und clear-bcb, jeweils disabled/oneshot |
CONFIRMED als vorhandene, aber nicht ausgelöste Infrastruktur |
| TPV-spezifischer One-button-/USB-Recoverypfad | factory, upgrade, Install-Recovery-Hook und OEM-Pakete sind damit vereinbar, belegen aber keinen konkreten Bedienpfad |
POSSIBLE, nicht gestartet oder positiv nachgewiesen |
Android-Rebootziel bootloader |
system-init/apexd.rc:15 enthält als Fehleraktion reboot,bootloader,... |
Zielstring/Anforderung CONFIRMED; Verhalten des Bootloaders UNBEKANNT |
| Bootloader/Fastboot-Transport | keine Sitzung, Bootloader-USB-ID oder Fastbootausgabe im Korpus | POSSIBLE / UNBEKANNT; der Rebootzielstring allein beweist kein Fastboot-Protokoll |
fastbootd |
kein positiver lokaler Beleg; kein super/Dynamic-Partitions-Schema |
POSSIBLE, aber eher UNLIKELY; nicht als abwesend bewiesen |
| serielle Android-Konsole | Commandline console=ttyMT0,115200n1; KI:39-40 startet den Console-Service früh; system-init/hw/init.rc:1223-1230 definiert /system/bin/sh als User shell, Domain u:r:shell:s0 |
Konfiguration CONFIRMED; kein Root, keine Pinbelegung/Spannung und kein physischer Zugriff geprüft |
| Bootloader ist derzeit entsperrt | AVB meldet locked/green | DISPROVED |
| Unlock-Fähigkeit | get_unlock_ability/oem device-info nie sicher abgefragt |
UNBEKANNT |
Weder Fastboot noch Recovery sollte allein zum Nachweis neu gebootet werden, solange kein modellgenauer Rückweg und keine sichere Eingabemethode bestätigt sind. Der lokale Befund genügt nur für die Architektur, nicht für die Erreichbarkeit dieser Modi.
Offene Punkte und sinnvolle spätere Nur-Lese-Nachweise
Diese Befehle wurden von diesem Agenten nicht ausgeführt. Falls der Hauptauftrag sie später live erlaubt und die Shell sie freigibt, würden sie die verbleibenden Lücken ohne Flashen schließen:
getprop ro.boot.flash.locked
getprop ro.boot.dynamic_partitions
getprop ro.boot.super_partition
bootctl get-current-slot
bootctl hal-info
ls -lZ /dev/block/bootdevice/by-name
cat /proc/device-tree/compatible
ls -l /system/bin/fastbootd /system/bin/bootctl /system/bin/update_engine
Direkte Reads von /proc/partitions, /proc/cmdline,
/sys/block/mmcblk0/size und dem Rohblock wurden bereits als Permission denied dokumentiert; wiederholtes Probieren verspricht ohne geänderten
Kontext keinen Erkenntnisgewinn. Das Einsteigen in Fastboot/Recovery wäre kein
reiner Dateilesezugriff und ist nicht Teil dieser lokalen Auswertung.
Lokal ausgeführte Auswertungsschritte
Es wurden nur Host-Dateien gelesen und Text verarbeitet:
rg --files
Get-Content diagnostics\bugreport\bugreport-metadata.txt
rg -n <Property-, Boot-, AVB-, SoC- und Mountmuster> <lokaler Bugreport>
Get-Content <lokaler Bugreport> -First 30
Get-Content diagnostics\bugreport\extracted\files\00018__mountinfo
Import-Csv -Delimiter "`t" diagnostics\bugreport\extracted\manifest.tsv
Die Partitionsnummern und die Größensumme wurden lokal deterministisch aus dem
blkdevparts=mmcblk0:-Abschnitt bis blkdevpartenc= geparst. Kein Befehl in
dieser Phase kommunizierte mit <TV_IP>:5555.