Für alle die mal ein wenig rumprobieren wollen, hab ich einen Grossteil der remote-commands des port 8080 zusammengestellt.
Wenn ich mich recht erinnere muss das ganze als HTTP GET an die box geschickt werden.
eine Antwort wird wahrscheinlich nicht zurückkommen... habs allerdings noch nie getestet.
wichtig ist scheinbar das als erstes mit "m=new" ein neues remote object erzeugt wird.
die id die dort vergeben wird, muss bei allen commandos die sich darauf beziehen, angegeben werden.
... das ist alles nur Theorie, die ich mir aus dem source der tv2client.exe zusammengereimt hab.
wenn jemand irgendwas damit zustande bekommt, schreibts mal in diesen thread.
ach ja.. ich glaub das dies nur funktioniert, wenn die box komplett initialisiert ist (aber ich kann mich auch irren)
commands
remoteAvEngine:
close "m=close"
detune "m=detune"
flush "m=flush"
open "m=open&pipeid={0}" pipeId(String)
pause "m=pause"
pauseLive "m=pauselive&dvrurl={0}" fileUrl(EscapedString)
playDvrFile "m=play&speed={0}&dvrurl={1}&rap=0x{2}" speed(float), fileUrl(escapedString), startTime.NTPTime.ToString("X")
"m=play&speed={0}&dvrurl={1}" speed(float), fileUrl(escapedString)
scan "m=play&speed={0}&dvrurl={1}&secs={2}" speed(float), fileUrl(escapedString), scanDuration(long)
seek "m=seek&ntp=0x{0}&dvrurl={1}" seekTime.NTPTime.ToString("X") fileUrl(escapedString)
setlanguage "m=setlang&comp={0}&lang={1}&pid={2}" esitem(string) iso639Language(int) pid(int)
setSap "m=setsap&sap={0}" useSap(int [0/1])
step "m=play&dir={0}" direction(int)
tune "m=tune&url={0}&pipe={1}&ticks={2}&cc608={3}&cc708={4}&sap={5}&audiopid={6}&blockvideo={7}&blockvideobounds={8}&blockaudio={7}&blockaudiobounds={8}" url(escapedString), pipeId(string), Environment.TickCount, cc608(int), cc708(int), useSap(int), audioPid(int), blockState.Blocked, blockState.TimeBounds
tuneRefresh "m=tunerefresh&blockvideo={0}&blockvideobounds={1}&blockaudio={0}&blockaudiobounds={1}" blockState.Blocked, blockState.TimeBounds
tuneRefresh "m=tunerefresh&url={0}&pipe={1}", new object[] url(escapedString) pipeId(escapedString)
tuneRefresh "m=tunerefresh&url={0}&pipe={1}&cc608={2}&cc708={3}" url(escapedString) pipeId(escapedString) cc608(int) cc708(int)
remoteRecordingAV:
start "o={0}&m=record&url={1}&start={2}&end={3}&pri={4}&bitrate={5}" id(int) sourceUrl(escapedString) requestedStart(long), requestedEnd(long), priority(int), bitRate(int)
stop "o={0}&m=stop&del=true&url={2}&end={3}", new object[] id(int), sourceUrl(escapedString), requestedEnd(long)
timeset "o={0}&m=timeset&url={1}&start={2}&end={3}" id(int) sourceUrl(escapedString) newStart(long), newEnd(long)
remoteObject:
new "m=new&o={0}&t={1}" id(int) type(String) type: "recordernode" "itunersession"
delete "m=delete&o={0}" id(int)
Wenn ich mich recht erinnere muss das ganze als HTTP GET an die box geschickt werden.
Sicher, dass das nicht über SOAP läuft? Das Kommandoformat erinnert mich jedenfalls irgendwie an SOAP. Womöglich auch noch mit der hässlichen Verschlüsselung versehen?
Ansonsten sieht es ja danach aus, als wäre das für ein "Remote Recording" Feature vorgesehen. Ob das gar mit dem "MSN Remote Record" kompatibel ist?
http://tv.msn.com/help/tv/rrfaq
Wäre damit eine Steuerung über Netzwerk möglich?
ich gehe ganz stark davon aus, das diese schnittstelle auch für das "multiroom" feature vorgesehen ist, womit man dann auch remote-aufnahmen, remote-resourcen-sharing usw. machen kann.
das ganze ist ganz sicher ohne soap und ohne verschlüsselung... das ist ne rein interne 127.0.0.1 kommunikation ... von daher auch kein bisschen abgesichert.
und solange man nicht genau weiss was man an den port schicken muss, kann damit ja auch keiner was anfangen ;)
security-by-obscurity war bei MS schon immer hoch im kurs :P
ich gehe ganz stark davon aus, das diese schnittstelle auch für das "multiroom" feature vorgesehen ist, womit man dann auch remote-aufnahmen, remote-resourcen-sharing usw. machen kann.
FWIW, aus einer heute veröffentlichten Pressemeldung der Deutschen Telekom AG zum Thema künftige Features der Entertain-Plattform:
Ein besonderes Highlight wird die internet-basierte Steuerung der Set-Top Box sein. Das heißt für Entertain-Kunden: Programmieren von Aufnahmen einzelner Sendung, Verwalten von ge-planten Aufnahmen usw. via Internet.
link zur pressemeldung, genauer zum Inhalt:
http://www.teltarif.de/arch/2008/kw05/s28650.html
Na sowas, da ist ja schon des Rätsels Lösung ;)
Hört sich ja gut an! ;D
na ich glaub nich das der remote-command port etwas mit internet-fernsteuerung zu tun hat.
das geht viel zu sehr in technische details, die für ne billige "nimm sendung xy, zum zeitpunkt zz auf" total unpassend wären.
solche infos können sie doch jetzt schon über die config+settings download vom t-home server durchführen.
ich gehe davon aus das dieses aufnahme-fernsteuerungs-feature, ne webseite bei t-home sein wird, über die man praktisch die box config verändern kann.
es wäre sehr unschön wenn man erst port 8080 durch die firewall forwarden müsste... ich glaub nich das ein grossteil der nutzer sowas hinbekommen würde. daher bin ich mir sicher das der port8080 nur innerhalb der box oder maximal im LAN angesprochen werden soll.
Hmm, also soweit ich das sehe basiert die Kommunikation aber doch auf Microsoft.TV2.HttpTransaction, welches in VerifyRequestHeader() eine digitale Signatur des Requests prüft - also doch verschlüsselte Kommunikation mit digitaler Signatur.
Oder sehe ich das falsch...?
es ist zumindest vorgesehen das man die signatur in einem request checken kann.
das betrifft aber scheinbar nur eingehenden Kommunikation, und wird auch nur verwendet wenn der httpMuClient benutzt wird.
der port 8080 wird allerdings von der tv2engine.dll gemanaged. keine ahnung ob dort signaturen erwartet werden...
aber mir ist zumindest nichts aufgefallen wo die requests signiert werden auf der c# seite.
der port 8080 wird allerdings von der tv2engine.dll gemanaged. keine ahnung ob dort signaturen erwartet werden...
Bin da noch nicht recht durchgestiegen, aber mir ist aufgefallen, dass die Fehlermeldung "Bad Request" offenbar vorgesehen ist - dummerweise haut die Box aber bei jedem Versuch, irgendeinen Befehl an Port 8080 abzusetzen, gnadenlos die Verbindung mit einem TCP RESET weg. Ich befürchte ja, dass man den Befehlsport doch irgendwie deaktiviert hat... :(
Ich habe mir tv2enginece.dll mal etwas unter die Lupe genommen und herausgefunden, dass da 3 "httpd extensions" implementiert sind:
1) "/" - Zeigt ein Inhaltsverzeichnis der gespeicherten DVR-Dateien an, erlaubt löschen und möglicherweise auch Abruf
2) "/dvrfs/" - Virtuelles Verzeichnis, unter welchem man wohl die DVR-Dateien abrufen kann.
3) "/cmd" - Die Schnittstelle für die von @mce2222 geposteten remote commands
Zu 1) und 2) passen auch die (pseudo-UPNP) NOTIFY-Requests, welche die Box unablässlich ins LAN multicastet:
NOTIFY * HTTP/1.1
x-type: display
x-location: http://192.168.x.y:8080/dvrfs/info.xml
x-debug: http://192.168.x.y:8080
<node count='0'><activities></activities></node>
Die virtuelle Datei "info.xml" ist in der httpd-Extension 2) auch vorgesehen.
Zu dumm nur, dass nichts von alledem funktioniert, auf alles hagelt's immer nur ein RST als Antwort (Verbindungsabbruch) - irgendwo scheint der Zugriff doch abgeriegelt zu sein :(
So, ich glaube ich habe die richtigen Codestellen jetzt gefunden. Da gibt es wohl zwei mögliche Objekte, die http-Verbindungen entgegennehmen:
1) Macht nach accept() den socket gleich wieder zu.
2) Vergleicht nach accept() die Adresse des verbindenden Rechners mit der von gethostbyaddr(gethostname) [zugewiesene IP-Adresse] oder gethostbyaddr("localhost") [immer 127.0.0.1], und macht den socket zu, wenn die Adresse nicht übereinstimmt.
Also leider nix mit "remote", da werden nur Verbindungen von lokal laufenden Anwendungen akzeptiert. Es gibt auch keine Ausnahmebedingung, welche obigen Vergleich ausschliessen würde.
Man könnte bestenfalls per "IP-Spoofing" Pakete an die Box schicken, aber dann würde man keine Antworten bekommen, könnte also das DVR-Webinterface auch nicht benutzen...
FWIW, aus einer heute veröffentlichten Pressemeldung der Deutschen Telekom AG zum Thema künftige Features der Entertain-Plattform:
Ein besonderes Highlight wird die internet-basierte Steuerung der Set-Top Box sein. Das heißt für Entertain-Kunden: Programmieren von Aufnahmen einzelner Sendung, Verwalten von ge-planten Aufnahmen usw. via Internet.
Die Serien- und aufnahmeplanung wird bei T-Home auf einem Server gespeichert, ist also nicht auf dem Receiver hinterlegt. Geplante aufnahmen werden also von einem Server von der Telekom "angeschupst"
Wahrscheinlich hat das eher mit der geplanten Schnittstelle für den Media Receiver 100 zu tun.
http://www.teltarif.de/arch/2008/kw10/s29193.html
Über den MR 100 kann der Nutzer den Personal-Videorecorder der Hauptbox bedienen, Filme darauf aufzeichnen und abrufen. Zeitversetztes Fernsehen (Timeshift) oder der Zugriff auf aufgezeichnete Sendungen der Hauptbox seien, wie das Unternehmen weiter mitteilt, über den MR 100 mit der aktuellen Softwareversion noch nicht möglich.
Irgendwie müssen sich dann ja die Boxen miteinander unterhalten können.
Zu 1) und 2) passen auch die (pseudo-UPNP) NOTIFY-Requests, welche die Box unablässlich ins LAN multicastet:
Ich habe mir die Messages auch noch mal genauer angeschaut mit der Idee, ob die Box zwar derzeit keine Verbindungen über TCP Port 8080 annimmt aber möglicherweise ja auf fremde Multicast Messages an diese Gruppe (239.255.255.250, Port 8082) reagiert. Leider bin ich etwas ratlos, wie eine gültige Nachricht wohl aussehen müsste zumal ich auch denke, dass es kein echtes UPnP ist. Hab also schon einiges probiert, aber nie eine Reaktion bekommen - auch keine Fehlermeldung.
Außerdem ist mir aufgefallen, dass die von der Box gesendeten Messages mit einem 25 byte String vor dem eigentlichen NOTIFY beginnen (copy&paste kann leider nicht alle Zeichen übernehmen aber es sind 25) z.B.:
+1×?¦Ëšœ\Mà=ÿMÁAë°NOTIFY * HTTP/1.1
x-type: dvr
...
Dieser Teil gehört zur Payload des Multicast Paketes. Möglicherweise handelt es sich hier ja tatsächlich um eine Signatur o.ä.!?