Root attempt thread - 19_MUSEL_UHD_BASIC (UE50RU7172UXXH), Tizen 5.0, fw 1500.9 (T-MSLDEUC, 2024-12-03 build), kernel 4.
Posted: Thu Aug 20, 2026 9:30 am
Device: UE50RU7172UXXH, internal 19_MUSEL_UHD_BASIC, Tizen 5.0, fw 1500.9, kernel 4.1.10 (1500.9 kernel verified byte-identical to 1081.3). Goal: shell / root. I have a verified kernel LPE with no delivery, and the standard door is broken in a way I haven't seen documented.
The blocker - Dev Mode cannot be enabled at all:
The hidden dialog opens fine (Apps > App Settings > 12345). I enter host PC IP, press OK - no-op. No error, no state change, nothing. The toggle itself is not togglable; it has never once been ON. Tried physical IR, USB keyboard, and key injection over the WS remote control rail - same no-op. TV API stays developerMode: 0, developerIP: 0.0.0.0. SDB on 26101 is adb-protocol-aware but RSTs every CNXN while devMode=0. Not a persistence/revert issue - the switch simply never commits.
Factory/service menu (Mute 1 8 2 Power) - this is where it gets weird:
- Extracted and parsed the full factory table (factory_peq.img, both Factory_Part1/Part2.dat). No SPD item and no secure-boot/fuse/downgrade toggle exists in the table at all. Protection items are all flash write-protect (SPI_PROTECTION, SUBMICOM_PROTECTION, TCON_PROTECTION, FRC_PROTECTION) plus FACTORY_LOCK/LOCK_STATUS/WATCHDOG etc.
- HyperUART is NOT greyed out - it's a normal item sitting at OFF. No dispatch table entry writes item 2024 (TIFADaemon_L only handles 22/216/530/785/1302/1703/1894), and I have not found a generic FAnet opcode that takes arbitrary item IDs. If anyone has a known write path for factory items on this series, I want it.
- USB Serial = ON, daemon does not advertise. FAnet daemon answered historically on the console socket at 9600 (bare canary 1f 08 50 00 58 -> identity reply with model string MM:T-MSLDEUC-1500.9, serial 50D6AU1NNM, ACK on 0x53/0x9D/0x6B/0x88/0xD0). On current taps (both TV USB sockets, RS-232 Jack in UART and FANET mode) it's silent at every baud, bare and wrapped, with an ESP32 tap. USB Serial setting was ON and confirmed in-menu during sweeps. The old "USB Serial silently reverts OFF" bug I'd seen earlier is superseded - current state is ON and dead silent.
- Service menu cannot disable secure boot on this board. Downgrade lane via menu is closed.
Software lanes tried and closed:
- Browser: SamsungBrowser 2.2 (Chromium 63 / V8 6.3.292.48.1, ARMv7l, no BigInt, WASM present). CVE-2018-6065, CVE-2020-6383 (needs V8 7.x, absent), CVE-2018-17463 (JSCreateObject) all tested live - no-ops. Samsung backported the Chrome-70 fix into the v63 fork. Browser RCE lane dead.
- Kernel LPE: built and content-verified against the real 1500.9 vmlinux - init_task 0xC06859A0, task walk +0x190/+0x274, cred overwrite offsets confirmed, SMACK anchor removed (was zeroed .data). Payload is proven correct offline. Delivery is the only missing piece.
- MSDU11: 1500.9 is a single encrypted MSDU11 block, MuseL release-key scheme. Q60T decryptor doesn't decrypt this image; no public key. eMMC dump lane is circular (passphrase is TZ-encrypted, needs root to extract).
- DLNA/GStreamer: 63-probe CVE diff against libavformat.so.57, zero crashes - post-2015 guards backported. Generic armed files no-op.
Network:
- Full port map done. 8001 msf v2 API: channel connects UNPAIRED (earlier unauthorized was a framing bug), remote control works. Flipping devMode via the backend fails with errors. 8080 DIAL launches YouTube/Netflix but refuses browser launch (no URL delivery). 7678 = dead stub 402 on every key shape. 8187 = static 402. 15500 accepts and goes silent. 26101 = SDB gated by devMode.
- CEC: hdmicec-service runs as root, offline audit possible, heavy lift.
The ask:
- Anyone seen a 1500.9 (or any 2024-era T-MSLDEUC) where the 12345 Dev Mode dialog is a no-op? Known bug, or factory/NVRAM corruption symptom? What's the reliable tell (should I diff the factory partition against a known-good unit)?
- Known write path for factory item 2024 / HyperUART enable on Muse-L? Grey vs not-greyed - any case of HyperUART actually enabling via factory table write on this platform?
- FAnet daemon answered on the console socket at 9600 back in August, now silent on both sockets with USB Serial=ON in-menu. Known mux latch behavior on 19_MUSEL - is the daemon wedged after a factory reset, or is the tap position still wrong?
- Any lead on a Muse-L shell that doesn't go through Dev Mode - even a hint on where the public knowledge stopped is useful.
Will trade every finding/script I have for a direction.
The blocker - Dev Mode cannot be enabled at all:
The hidden dialog opens fine (Apps > App Settings > 12345). I enter host PC IP, press OK - no-op. No error, no state change, nothing. The toggle itself is not togglable; it has never once been ON. Tried physical IR, USB keyboard, and key injection over the WS remote control rail - same no-op. TV API stays developerMode: 0, developerIP: 0.0.0.0. SDB on 26101 is adb-protocol-aware but RSTs every CNXN while devMode=0. Not a persistence/revert issue - the switch simply never commits.
Factory/service menu (Mute 1 8 2 Power) - this is where it gets weird:
- Extracted and parsed the full factory table (factory_peq.img, both Factory_Part1/Part2.dat). No SPD item and no secure-boot/fuse/downgrade toggle exists in the table at all. Protection items are all flash write-protect (SPI_PROTECTION, SUBMICOM_PROTECTION, TCON_PROTECTION, FRC_PROTECTION) plus FACTORY_LOCK/LOCK_STATUS/WATCHDOG etc.
- HyperUART is NOT greyed out - it's a normal item sitting at OFF. No dispatch table entry writes item 2024 (TIFADaemon_L only handles 22/216/530/785/1302/1703/1894), and I have not found a generic FAnet opcode that takes arbitrary item IDs. If anyone has a known write path for factory items on this series, I want it.
- USB Serial = ON, daemon does not advertise. FAnet daemon answered historically on the console socket at 9600 (bare canary 1f 08 50 00 58 -> identity reply with model string MM:T-MSLDEUC-1500.9, serial 50D6AU1NNM, ACK on 0x53/0x9D/0x6B/0x88/0xD0). On current taps (both TV USB sockets, RS-232 Jack in UART and FANET mode) it's silent at every baud, bare and wrapped, with an ESP32 tap. USB Serial setting was ON and confirmed in-menu during sweeps. The old "USB Serial silently reverts OFF" bug I'd seen earlier is superseded - current state is ON and dead silent.
- Service menu cannot disable secure boot on this board. Downgrade lane via menu is closed.
Software lanes tried and closed:
- Browser: SamsungBrowser 2.2 (Chromium 63 / V8 6.3.292.48.1, ARMv7l, no BigInt, WASM present). CVE-2018-6065, CVE-2020-6383 (needs V8 7.x, absent), CVE-2018-17463 (JSCreateObject) all tested live - no-ops. Samsung backported the Chrome-70 fix into the v63 fork. Browser RCE lane dead.
- Kernel LPE: built and content-verified against the real 1500.9 vmlinux - init_task 0xC06859A0, task walk +0x190/+0x274, cred overwrite offsets confirmed, SMACK anchor removed (was zeroed .data). Payload is proven correct offline. Delivery is the only missing piece.
- MSDU11: 1500.9 is a single encrypted MSDU11 block, MuseL release-key scheme. Q60T decryptor doesn't decrypt this image; no public key. eMMC dump lane is circular (passphrase is TZ-encrypted, needs root to extract).
- DLNA/GStreamer: 63-probe CVE diff against libavformat.so.57, zero crashes - post-2015 guards backported. Generic armed files no-op.
Network:
- Full port map done. 8001 msf v2 API: channel connects UNPAIRED (earlier unauthorized was a framing bug), remote control works. Flipping devMode via the backend fails with errors. 8080 DIAL launches YouTube/Netflix but refuses browser launch (no URL delivery). 7678 = dead stub 402 on every key shape. 8187 = static 402. 15500 accepts and goes silent. 26101 = SDB gated by devMode.
- CEC: hdmicec-service runs as root, offline audit possible, heavy lift.
The ask:
- Anyone seen a 1500.9 (or any 2024-era T-MSLDEUC) where the 12345 Dev Mode dialog is a no-op? Known bug, or factory/NVRAM corruption symptom? What's the reliable tell (should I diff the factory partition against a known-good unit)?
- Known write path for factory item 2024 / HyperUART enable on Muse-L? Grey vs not-greyed - any case of HyperUART actually enabling via factory table write on this platform?
- FAnet daemon answered on the console socket at 9600 back in August, now silent on both sockets with USB Serial=ON in-menu. Known mux latch behavior on 19_MUSEL - is the daemon wedged after a factory reset, or is the tap position still wrong?
- Any lead on a Muse-L shell that doesn't go through Dev Mode - even a hint on where the public knowledge stopped is useful.
Will trade every finding/script I have for a direction.