TechniSat DigitRadio 580

Unser als Küchenradio genutzes Noxon iRadio ist leider nicht geeignet, um in unserer UPnP-Künstlerliste zu navigieren. Es hat offenbar einen Fehler der dazu führt, daß man beim Navigieren nach 2-3 Bildschirmseiten (mit jeweils 5 Einträgen) wieder ins Hauptmenü zurückgeworfen wird, wenn man einen Ordner öffnen will. Bei einer Musiksammlung mit ~140 Künstlern nicht brauchbar.

Weiterhin ist es auch für Podcasts nicht brauchbar.

Zeit für ein neues Gerät.

• Anforderungen
• Auswahl
• App
• Analyse
  • Portscan
  • SSDP
  • Dekompilieren der App
  • Wireshark
    • Netzwerksetup
    • Überraschung!
• API
  • Interessante URLs
• Frontier Silicon
  • App
• Ports
  • Port 514
  • Port 8080
  • Port 10003
  • Port 52299

Anforderungen​

• UPnP, um Musik vom lokalen Server abzuspielen
• Komplett mit Tasten bedienbar, ohne Fernbedienung nutzen zu müssen
• DAB fürs Radiohören
• Kabelnetzwerkanschluss (Ethernet), nicht nur W-LAN
• (Wertiges Aussehen, nicht wie die Plastikwürfel von Hama mit den ätzenden Minidisplays)

Auswahl​

Beim Kauf eines Satellitenreceivers für die Verwandtschaft hatte ich gesehen, daß Technisat auch Internetradios im Angebot hat. Ich hab mich dann durch deren Website geklickt und die Radios rausgesucht, die Ethernet, UPnP und DAB konnten.

Viel blieben nicht übrig, und dann bin ich ins lokale Conrad um die auszuprobieren. Beim DigitRadio 600 gibt es keinen Zurück-Knopf, der beim Navigieren im UPnP-Verzeichnisbaum immens wichtig ist. Er existiert nur auf der Ferbedienung.

Das DigitRadio 580 gabs im Conrad nicht, aber ich konnte es mir zur Ansicht in die Filiale liefern lassen und 2 Tage später ausprobieren.

Es passte alles, und ich habs für 270€ gekauft.

App​

Zum Radio gibt es die App Technisat CONNECT, mit der man das Radio anschalten und komplett bedienen kann. Leider ist sie 40 MiB groß, was für ein Radiosteuerprogramm viel zu viel ist.

Um eine eigene App zu bauen oder das Radio in die Heimnetzsteuerung einzubinden braucht es aber Kenntnisse der Schnittstelle. Der Technisat-Support meinte nur lapidar:

Bitte haben Sie Verständnis dafür, dass wir Ihnen die Schnittstellendokumentation nicht zur Verfügung stellen können.

Das Verständnis fehlt mir hier völlig, aber ich gehe auch nicht davon aus, daß ich irgendeine Unterstützung seitens der Hersteller bekomme. Das ist ziemlich bedrückend.

Analyse​

Portscan​

Mir war unbekannt, wie die App mit dem Radio spricht. Also erstmal nen Portscan:

$ nmap -p1-65535 digira
Starting Nmap 7.70 ( https://nmap.org ) at 2019-05-13 21:40 CEST
Nmap scan report for digira (192.168.3.46)
Host is up (0.0043s latency).
rDNS record for 192.168.3.46: digira.home.cweiske.de
Not shown: 65530 closed ports
PORT      STATE SERVICE
80/tcp    open  http
514/tcp   open  shell
8080/tcp  open  http-proxy
10003/tcp open  documentum_s
55299/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 333.03 seconds

Auf Port 80 läuft das Webinterface, mit dem man dem Radio einen neuen Namen geben kann. Der Rest ist unklar, aber Port 10003 könnte ein Fernsteuerungsport sein. Eine Telnetverbindung dahin brachte Binärzeugs, was auf eine Verschlüsselung hindeutet :/

SSDP​

Im vom UPnP verwendeten SSDP-Gerätfindeprotokoll meldet es sich neben den üblichen UPnP-Informationen so:

uuid:46C19E4A-472B-11E1-9F67-0022616E9730::urn:schemas-frontier-silicon-com:undok:fsaudsync:1

(via gssdp-discover)

Dekompilieren der App​

Da ich die für die verschlüsselte Kommunikation nötigen Schlüssel und Algorithmen nicht erraten kann, beschloß ich in der App nachzusehen wie es gemacht wird.

Also die App per adb vom Handy ziehen:

$ adb root
$ adb shell crackling:/ # pm path com.technisat.multiplay.main
package:/mnt/expand/123457890/app/com.technisat.multiplay.main-1/base.apk
$ exit
$ adb pull /mnt/expand/123457890/app/com.technisat.multiplay.main-1/base.apk

Jetzt noch den Decompiler jadx-gui gestartet und ... rausgefunden, daß der Java-Code eigentlich nur nen dünner Wrapper ist, der die libMultiPlayAndroid.so (35 MiB) startet, eine binäre Bibliothek, die nicht so einfach zu dekompilieren ist :/

Wireshark​

Der letzte Ausweg war jetzt der Netzwerksniffer Wireshark, mit dem ich die Netzwerkpakete zwischen App und Radio mitschneiden wollte. mitmproxy konnte ich nicht verwenden, weil der nur HTTP kann, ich aber diesen komischen 10003er Port belauschen muss.

Netzwerksetup​

Das machte das Setup etwas schwierig, denn das Konfigurieren des Gateways im DHCP-Server reicht leider nicht aus - die Handy und Radio kommunizieren nach den ersten Paketen dann doch lieber direkt.

Mir fiel eine Alternative ein: Laptop zum Access Point machen, Handy mit diesem verbinden und schwupps, schon hab ich den Traffic. Der im NetworkManager-Applet eingebaute Hotspotmodus funktionierte leider nicht, da dieser einen neuen IP-Bereich aufmachte, der nicht mit dem echten Heimnetzwerk sprechen wollte.

Die Lösung war dann create_ap, dem man direkt sagen kann, daß das W-LAN ins normale Netzwerk gebrückt werden soll:

$ create_ap -m bridge wlan0 eth0 myssid mypassword

Jetzt bekam ich den kompletten Handydatenverkehr mit!

Überraschung!​

Nach dem Starten der App werden erstmal UDP-Pakete an eine Multicastadresse geschickt, genauso wie SSDP-Suchpakete. Das Radio meldet sich dann direkt beim Handy, die App zeigt das Gerät dann an.

Und nun die Überraschung: Die App redete nicht wie vermutet über Port 10003, sondern über HTTP auf Port 80. Anstatt des Webinterfaces sprach es aber einen anderen Pfad an, nämlich /fsapi/.

Der mitmproxy hätte also doch geholfen, und ich hätte mir den ganzen Aufwand sparen können :/

API​

Nachdem ich um die 30 verschiedene API-Aufrufe mitgeschnitten hatte suchte ich im Netz nach dem offensichtlichsten, dem An- und Ausschalten:

GET /fsapi/GET/netRemote.sys.power?pin=1234

... und es stellt sich raus, daß andere schon 2015 mit der API-Dokumentation angefangen haben:

• FSAPI: Umfangreiche Dokumentation
  (Blogpost von Lukas Rademacher dazu)
• PMR4000RMKII-03.pdf: Control command list

Auch Implementierungen gibt es einige:

• fsapi (PHP)
• fsapi (Python)
• afsapi (Python asynchron)
• FsAPI (C#)

Dann gibt es noch Anbindungen an Heimautomatisierungssysteme:

• OpenHAB: Frontier Silicon Radio Binding
• HomeAssistant: Frontier Silicon Internet Radios

Interessante URLs​

/device

XML-Dokument. Liefert Name, Versionsnummer und URL zur API.

ip:8080/dd.xml

Liefert die UPnP-Gerätebeschreibung und verlinkt auch Bilder vom Radio selbst, die die App anzeigt.

Frontier Silicon​

Die Firmwareversion meines DigitRadio 580 ist

ir-mmi-FS2026-0500-0286_V2.11.12.EX65933-1A22

FS ist "Frontier Silicon", heißt jetzt Frontier Smart und liefert Chips, in denen DAB, FM, Internetradio, UPnP, CD und Bluetooth integriert ist, sowie die passende Software dazu.

Das 2026 in der Versionsnummer steht für das VENICE 6.5 FS2026-5 Internet radio/Network streaming/DAB/FM/iPhone audio module , auch "Neptune" genannt.

Wie es aussieht, nutzen sehr viele Gerätehersteller Chips dieses Zulieferers um ihre Radios zu bauen. Also keine Eigenentwicklungen.

Einige Radios von Hama und viele von Medion haben inzwischen FrontierSilicon-Chips drin.

App​

Frontier Smart bietet auch gleich eine App an, und zwar UNDOK . Die macht genau dasselbe wie die Technisat-App, ist aber 10 MiB groß - 30 MiB gespart.

Ports​

Port 514​

Scheint ein Debug-Port zu sein:

I tried telnet on port 514 and discovered what appears to be a debugging system log.

Das kann ich bestätigen.

Es gibt 2 änlich klingende API-Methoden, die die Ausgabe wahrscheinlich beeinflussen:

• netRemote.misc.fsDebug.component
• netRemote.misc.fsDebug.traceLevel

Update 2023-11: Ist wirklich so: Digitradio 580: <Empty> audio folders und Document debugging API endpoints #27.

Port 8080​

Wird für UPnP-Informationen benutzt, wie die dd.xml.

Port 10003​

Unbekannt. Der Technisat-Support meinte, der Port ist für die Multiroom-Funktionalität da.

Port 52299​

Unbekannt. Das ist aber eine dynamische Portnummer, die sich ändern könnte.