Files
hisense-root/modding
2026-10-27 15:56:27 +01:00
..
2026-10-27 15:56:27 +01:00
2026-10-27 15:56:27 +01:00
2026-10-27 15:56:27 +01:00
2026-10-27 15:56:27 +01:00
2026-10-27 15:56:27 +01:00
2026-10-27 15:56:27 +01:00
2026-10-27 15:56:27 +01:00
2026-10-27 15:56:27 +01:00
2026-10-27 15:56:27 +01:00

Modding Docs — Hisense HE40E5600FFWTS (Vidaa U, V0100.01.00A.N0410)

Stand: 2026-10-26
TV: Hisense HE40E5600FFWTS, FW V0100.01.00A.N0410, LAN 192.168.188.94
Host/Server: 192.168.188.150:9000
Root/SSH: siehe ../root/ROOT-GUIDE.md
Status: Root + Dropbear-SSH (key-only) live; Modding-Recipes in diesem Ordner sind static/live belegt, aber noch nicht alle am TV getestet (siehe 07-evidence-unknowns.md).


Die drei Fragen in 30 Sekunden

Welches Linux ist das?

Ein Hisense/MediaTek Embedded Linux, kein Standard-Distro:

  • Kernel: Linux 3.18.25 (ARMv7, SMP PREEMPT, Linaro GCC 4.8.2, Build 2023-04-10)
  • SoC: MediaTek MT53xx/MT5863-Klasse (Kernel-Cmdline mt53xx-emmc; Browser-Build mt5863_sa_768_linux; Cortex-A53, ARMv7, NEON/VFPv4)
  • Userland: glibc 2.18 (/lib/libc-2.18.so, ld-linux.so.3), BusyBox 1.18.5, GNU/BusyBox-Mix
  • Init: SysV-artig (/etc/inittab, /etc/init.d/rcS, /etc/rc.d/rc.local), kein systemd
  • Kein /etc/os-release, keine Distro-Version; Firmware-String V0100.01.00A.N0410
  • Storage: squashfs-ro Rootfs (/, 38.8 MB, 100 % voll), /3rd squashfs-ro (141 MB, 100 %), /3rd_rw ext4-rw (1.1 GB, 56 % belegt), /data ext4-rw (1.9 GB, fast leer), /perm ext4-rw (3.9 MB), /spdata ext4-ro
  • Kein overlayfs im Kernel; Modding läuft über rw-Partitionen + mount --bind und die vorhandenen rw-Verzeichnisse (/3rd_rw, /data, /perm).

Gibt es einen Package Manager?

Nein. Kein apt, dpkg, opkg, ipkg, rpm, apk, yum oder pacman; keine /etc/opkg, /var/lib/dpkg o. ä. (Root-Check, siehe 07).
Konsequenz: Eigene Tools/UI/Services werden als statische ARM-Binaries (oder Shell-Skripte) gebaut und per File.download, SSH/base64/tar, USB oder (nach optionalem SFTP-Install) per sftp/scp nach /3rd_rw gebracht. Es gibt kein Paket-Repo, kein opkg install.

Wo ist das UI und wie läuft es?

Das TV-UI ist eine Web-UI im hisenseUI-Browser (Opera/Chromium-Basis, root, GLES):

/basic/autorun.sh (Zeile 168)
  → /3rd/opera4x/hisenseUI/start-UI.sh
    → ./bin/hisenseUI --hw-gles --jsplugins-dir=/3rd/UI_jsplugins \
         --disable-web-security ... -u /3rd_rw/UI/index.html
  • UI-Prozess: hisenseUI (z. B. PID 589), root, --hw-gles, --disable-web-security, JS-Plugins aus /3rd/UI_jsplugins, DevTools-Port 9223 (wenn /3rd_rw/appdata/enable_developer_tools existiert)
  • UI-Seite: /3rd_rw/UI/index.html (PIXI-basierte UI; lädt model/model.js, sdk/UI.js, lib/launcherDataInterface.js, pub/HisProductConfig.js usw.)
  • Launcher-/App-Daten: /3rd_rw/appdata/launcher/
    • preset.txt — die 26 vorinstallierten App-Tiles (Netflix, Prime Video, Disney+, YouTube, …; aktuell inkl. VidaaRecon)
    • Appinfo.json — vom Nutzer installierte Web-Apps (unser VidaaRecon)
    • deletedPresetApp.txt — JSON-Array der ausgeblendeten Tiles (Stand 2026-10-26: [], alte Probe-URLs entfernt)
    • data/CategoryIndex.xml, CategoryList_*.xml, Category_1001_*.xml, Category_57_*.xml, PicInfo.xml — Kategorien/App-Daten (aktiv, wenn serviceUpdate.xml zum Land passt; sonst UI/data/-Default)
    • res/*.png — Tile-Icons; cache/index.json — Icon-Cache
  • LauncherService: /3rd/launcherservice/bin/LauncherService (startet per /3rd/launcherservice/startLS.sh aus delayrun.sh nach ca. 15 s); liefert/aktualisiert Launcher-Daten; Strings u. a. /3rd_rw/appdata/launcher/data/CategoryIndex.xml, PicInfo.xml, /tmp/launcher/launcherServiceAuth.xml
  • Native Apps / AM: /basic/app_man -c /basic/am_config -s /basic/am_start.ini -input_fifo; startet dtv_svc (TV), netflix, dialserver, samba_relay_agent, browser_base, securetime usw.; App-Steuerung über :am,<app>,:<verb>=<val>
  • Web-Browser (nicht das TV-UI): hisense_browser (z. B. PID 1320), gestartet über /3rd/opera4x/browser/run-Browser.sh (AM-App opera4x), --hw-dfb, --allow-file-access-from-files, DevTools 9224; hier läuft unsere Recon-Seite. Der „TV Browser“-Tile startet diesen Browser.

Wichtig: hisenseUI (TV-UI) und hisense_browser (Web-Browser) sind zwei verschiedene Prozesse mit unterschiedlichen Startskripten, Renderern (GLES vs. DFB), JS-Plugin-Verzeichnissen und Debug-Ports.


Ordnerstruktur

Datei Inhalt
01-system-linux.md Linux/Kernel/SoC, glibc/BusyBox, Package-Manager-Negativ, Dateisysteme, Partitionen, Toolchain-Constraints
02-boot.md U-Boot/eMMC, Kernel-Cmdline, init/rcS/rc.local, autorun.sh, developer.sh, AM/UI/Delayrun, Services, Boot-Hooks
03-ui.md hisenseUI vs. hisense_browser, /3rd_rw/UI, ldi.js, Launcher-/App-Daten, preset/Appinfo/deleted, LauncherService, AM/:am, Plugins, DevTools, Restart
04-modding.md Rezepte: Custom-App-Tile, Custom-UI, Launcher-Skin/Daten, eigener Service, developer.sh, patch/opera4x, Bind-Mounts, :am/JS-APIs, Rollback
05-bloat.md 26 Preset-Apps, Native-Apps/Services-Matrix, was man gefahrlos deaktivieren kann, developer.sh-Stubs, Platz/Reclaim, Risiken
06-toolchain-deploy.md Kein Package Manager: statisch für ARM bauen, deployen (File/SSH/USB), glibc-2.18-/Kernel-3.18-Fallen, Dropbear/PTY, Checks
07-evidence-unknowns.md Belege, Pfade, Hashes, Verification-Status, bekannte Unknowns
templates/ developer.sh, custom-app.json, hide-preset.json, custom-ui.html, start-UI-custom.sh, README
../root/ROOT-GUIDE.md Kompletter Root-/SSH-Weg (USB-ext4-Symlink, libtvsysinfo-Shadow, Root-Loop, Dropbear, PTY, Persistenz)

Schnellstart (was zuerst?)

  1. Root/SSH prüfen: ssh root@192.168.188.94 'id; ps | grep -E "hisenseUI|hisense_browser|dropbear"' — Details im Root-Guide. SFTP (optional): ../root/scripts/host/install_sftp.sh (testet Port 2222, dann 22); danach sftp root@192.168.188.94.
  2. UI ansehen: Im UI-Prozess DevTools 9223 (falls enable_developer_tools), im Web-Browser 9224. Die UI-Seite ist /3rd_rw/UI/index.html.
  3. Sicherster Modding-Schritt: Eine eigene App-Tile über /3rd_rw/appdata/launcher/Appinfo.json (siehe 04-modding.md, Route A). Das ist reversibel und macht das UI nicht kaputt.
  4. Dann: Launcher-Daten/Tiles über preset.txt / deletedPresetApp.txt / Category_*.xml anpassen (Route C).
  5. Erst danach: Die UI-Seite /3rd_rw/UI/index.html ersetzen (Route B) — Backup, SSH/Web-Browser als Rettungsweg, UI-Prozess neu starten.
  6. Bloat: Preset-Tiles ausblenden (deletedPresetApp.txt), native Apps/Services über am_start.ini/am_config/delayrun.sh und developer.sh deaktivieren (05-bloat.md). Kein Flash nötig.
  7. Eigene Services/Funktionen: /3rd_rw/developer.sh (früher Root-Hook) oder der vorhandene HamService-Wrapper (spät, nach 15 s); statische ARM-Binaries; :am/Hisense_*/HiBrowser APIs.

Die wichtigsten Pfade (Cheat-Sheet)

# TV-UI
/3rd_rw/UI/index.html                 # UI-Seite (PIXI), rw
/3rd_rw/UI/{model,sdk,lib,pub,templates,module,assets,language,keyboard,data}
/3rd/opera4x/hisenseUI/start-UI.sh    # startet hisenseUI (ro)
/3rd/UI_jsplugins/                    # JS-TV-APIs der UI (ro)

# Launcher / Apps
/3rd_rw/appdata/launcher/preset.txt
/3rd_rw/appdata/launcher/Appinfo.json
/3rd_rw/appdata/launcher/deletedPresetApp.txt
/3rd_rw/appdata/launcher/data/{CategoryIndex.xml,CategoryList_*.xml,Category_*.xml,PicInfo.xml,serviceUpdate.xml}
/3rd_rw/appdata/launcher/res/         # Icons
/3rd_rw/appdata/launcher/cache/index.json

# Web-Browser
/3rd/opera4x/browser/run-Browser.sh   # startet hisense_browser
/3rd_rw/opera4x/opera_home_browser/   # Profil (browser.db, opera.json, ...)
/3rd/opera4x/opera_dir/jsplugins/     # HiBrowser/JS-APIs des Browsers

# Native Apps / AM
/basic/app_man
/basic/am_config
/basic/am_start.ini
/basic/delayrun.sh
/3rd/launcherservice/startLS.sh
/3rd/hamservice/startHam.sh
/3rd_rw/hamservice/HamService         # aktueller Wrapper (SSH/Root-Loop)
/3rd_rw/developer.sh                  # optionaler früher Root-Boot-Hook (Zeile 90)
/3rd_rw/patch/opera4x                 # optionaler Vendor-Overlay (full bind mount)

# Root/SSH
/3rd_rw/appdata/root_loop.sh          # Root-Kommandokanal
/3rd_rw/appdata/root_proof.txt
/3rd_rw/sshd/                         # Dropbear, Host-Key, authorized_keys, start_sshd.sh

Warnungen / Spielregeln

  • Kein Flash, kein .pkg, kein Bootloader. Der Rootfs und /3rd sind squashfs-ro; Änderungen gehören nach /3rd_rw (rw), /data (rw) oder /perm (rw). Für ro-Dateien: mount --bind aus /3rd_rw (kein overlayfs im Kernel).
  • Backup vor jedem UI-/Launcher-/AM-Eingriff. Besonders /3rd_rw/UI/index.html, /3rd_rw/appdata/launcher/*, /basic/am_config/am_start.ini (Kopien nach /3rd_rw/backup/).
  • SSH/Root als Rettungsweg behalten. Das UI kann durch eine kaputte Seite schwarz werden; der hisenseUI-Prozess lässt sich per SSH/root-Loop killen und neu starten, die Seite aus dem Backup zurückholen.
  • developer.sh ist ein früher Root-Hook (vor ms_service, hisenseUI, app_man, delayrun). Ein Fehler dort kann den Boot/UI beeinflussen; immer mit set -x/Log und Fallback (SSH/Web-Browser) arbeiten.
  • /3rd_rw/patch/opera4x ist ein full bind mount über /3rd/opera4x: Es ersetzt das ganze Verzeichnis. Nur mit vollständiger Kopie oder Symlink-Baum verwenden; für einzelne Dateien lieber developer.sh + Datei-Bind-Mount.
  • Kein Package Manager: Keine opkg/apt-Pakete; statische ARM-Binaries bauen/testen; die TV-glibc ist 2.18, der Kernel 3.18.
  • /dev ist statisch/ro (kein devtmpfs); PTYs brauchen den devpts-Workaround (/dev/shm/pts → bind /dev/pts); siehe Root-Guide/06.
  • Keine Secrets in diesem Ordner: Kein Root-Hash, kein privater SSH-Key; nur Public Key/Host-Fingerprint.
  • Kein Internet-Exposure: Der TV ist im LAN; SSH ist key-only root; nicht ins Internet weiterleiten.
  • Getestet vs. ungetestet: Root/SSH/PTY sind live bestätigt; die UI-/Bloat-/Custom-UI-Rezepte sind aus statischen/live Daten abgeleitet und noch nicht alle ausgeführt (Status in 07). Erst eine Änderung, dann testen, dann die nächste.

Kurz: der rote Faden

USB-ext4 + tvi-Symlink
  → libtvsysinfo-Shadow (Index 17) → DT_INIT root
    → Root-Loop → SSH (Dropbear, key-only)
      → /3rd_rw/developer.sh (früh) oder HamService-Wrapper (spät)
        → UI/App-Daten/Services anpassen
          → /3rd_rw/UI (UI-Seite), /3rd_rw/appdata/launcher (Tiles),
            /basic/am_config|am_start (native Apps), delayrun (Services)

Viel Spaß beim Modden — und immer schön backupen. :)


Wo liegen die Root-/Deploy-Skripte?

Alles im Schwester-Ordner ../root/:

  • ../root/tools/pub/ — ausgelieferte Dateien (Payload, Dropbear, Keys, TV-Skripte)
  • ../root/scripts/host/ — USB, Server, Payload-Plant, Upload, Root-CMD, Builds, install_sftp.sh/build_sftp_server.sh
  • ../root/scripts/tv/ — start_sshd.sh, root_loop.sh, hamservice-wrapper.sh, deploy_sshd.sh, verify.sh, rollback.sh, install_sftp_stage.sh/enable_sftp.sh/swap_sftp.sh
  • ../root/ROOT-GUIDE.md — der komplette Root-Weg

Die Modding-Rezepte in 04-modding.md nutzen diese Skripte/Templates, aber du kannst alles auch manuell per SSH/Recon-Seite machen. Nichts hier erfordert den alten Run-Ordner.