Userbase

Na de aanschaf van een nieuwe Digicorder (AD-2100) wou ik eens kijken of het mogelijk was de Digibox aan ons interne netwerk te koppelen, aangezien ik geen all-in-one modem (HGW) heb, om van de DLNA mogelijkheden gebruik te kunnen maken. Ik heb tevergeefs gezocht of anderen al een werkende oplossing hadden, maar voorlopig loopt het verkeer naar de Digicorder dus nog steeds over een VLAN dat dan op de router gebridged wordt met de WAN interface, zodat dat verkeer ongehinderd naar Telenet kan.

Na het systematisch monitoren van het netwerkverkeer van en (unicast) naar de Digicorder, heb ik een aantal zaken zien passeren die mogelijk anderen ook interesseren.


DHCP
De Digicorder verstuurt bij elk DHCP verzoek ook enkele eigen gegevens, vermoedelijk ter identificatie van de Digicorder:

• Optie 60: "DVBC.ADB5723"; modelnummer van de Digibox
• Optie 43: 8 velden met de strings "STB", "ADB5723", "ADB", enkele (vermoedelijke) versienummers, en het serienummer van de Digicorder

De antwoorden van Telenet bevatten onder meer de volgende informatie:

• Optie 12: host name: stb-XXXXXXXX
• Optie 224: CSP=10.16.2.7:8211
• Optie 225: 'INHOME' gateway ip lijst: http://195.130.128.104:8203/dhcp/DHCPoption.txt;60

Zou iemand met een HGW eens het DHCP verkeer van zijn Digicorder kunnen bekijken, om te zien of hier opties instaan die erop zouden kunnen duiden dat de Digicorder/Digibox moet op zoek gaan naar een router? Mijn Digicorder vraagt normaal namelijk wél DHCPoption.txt op, maar begint vervolgens geen ARP verzoeken te verzenden om een gateway te zoeken, zoals eerder op dit forum werd beschreven. Ik vermoed dus dat er elders nog een andere trigger moet zijn.


SNMP
Buiten UPnP/DLNA (info te bekijken op poort 8080 van je Digicorder) ondersteunen de Digicorders blijkbaar ook SNMP v2c. De communicatie die ik gezien heb zijn voornamelijk get requests, maar ook — en dit maakt het mogelijk interessant — set requests, hoewel die laatste slechts op één welbepaalde OID werd uitgevoerd (zie SNMP+HTTP).

Buiten enkele standaard OIDs (zoals .system.sysUpTime) is er ook een heleboel informatie die zich onder de 1.3.6.1.4.1.23423 OID bevindt. De informatie in deze boom kan je bekomen met het snmpwalk commando en je vindt dan onder meer:

• .1.1: Osmosys softwareversie
• .1.6: Lijst van uitleesbare bestanden uit /proc en hun inhoud.
• .4: Lijst van tuners met al hun eigenschappen. Zoals te bekijken in het menu van je Digicorder, maar dan voor alle drie (twee) tuners apart.
• .5.1, .5.5.1: Info over de geïnstalleerde software, zoals getoond op je Digicorder.
• .5.3: Taalinstellingen (?)
• .5.5.3.2/.5.5.3.3: Aantal kanalen, gevolgd door een lijst van kanalen met tunerinfo.
• .6.1.2: Info over de harde schijf.
• .7.1: Status van de harde schijf en partities.
• .10.4, .10.5, .10.6: Standaardinstellingen voor opnames, opnames (gepland en uitgevoerd) en op te nemen series.
• .10.9.1: Lijst van alle kanalen: zendernummer en standaard nummer, beschikbaarheid...
• .10.9.2: Lijst van alle zenderpakketten: naam, beschikbaarheid...

Met deze OIDs kan je dus zelf een service opzetten die bv. de signaalkwaliteit monitort m.b.v. de tuner informatie, als je Digicorder bereikbaar is vanaf je interne netwerk. Misschien kunnen we zelfs enkele MIBs proberen opstellen om deze gegevens gemakkelijker uit te lezen.

Het nagaan van interactiviteit op 'Mijn Telenet' lijkt ook te verlopen via SNMP, al verzenden ze wel hopen SNMP requests. Vandaar dat deze controle zo lang duurt en dat ze al eens durft te mislukken.


SNMP+HTTP
Dan is er nog de .13.1.0 OID die werd gebruikt voor set requests, maar enkel om de waarde van een token in te stellen tijdens HTTP communicatie met stbprv.prd.telenet-ops.be. Tijdens deze communicatie (waarvan ik slechts één burst gezien heb) werd er een heleboel informatie verstuurd naar Telenet via XML. Deze communicatie werd geïnitialiseerd door Telenet door een token in te stellen op .13.1.0. Vervolgens vroeg de Digicorder welke informatie verzocht werd bij dit token, waarna deze werd verzonden.


UDP via poort 1200 en 1600
Na elke DHCP DORA voert de Digicorder een tweede handshake uit via UDP. De poorten die hiervoor gebruikt worden zijn 1200 op de Digicorder (local) en 1600 (remote). Vervolgens wordt elke 15 minuten een pakketje verzonden, waarop een antwoord volgt.

Wireshark kent het protocol niet, en ik raak er ook niet echt uit. Wat ik echter wel heb kunnen ontrafelen, is dat elke UDP payload uit een veelvoud van 16 bytes bestaat, waarvan de eerste 16 een header zijn met de volgende velden: Deze header wordt gevolgd door een binaire payload, maar hier heb ik nog niet veel kunnen uit afleiden. Vooraan in de verzonden payloads zit echter altijd het MAC adres van de Digicorder, dus waarschijnlijk is deze informatie niet versleuteld. Mogelijk is de rest van de data dan padding om aan een veelvoud van 16B te komen. De pakketten (buiten de handshake) bevatten gewoonlijk slechts een blok van 16B (en geen in de reply), maar ik heb ook één reply gezien waarbij zeer veel data (8.2kB) verzonden werd. Hierbij waren de flags ook anders dan bij andere communicatie.

Indien anderen meer (te) weten (komen) over dit protocol, laat maar horen! Ik vind het namelijk bijzonder intrigerend dat Telenet informatie verzendt die we niet kunnen ontcijferen, terwijl al de rest onversleuteld over standaard protocols verloopt.


HTTP
Bij DHCP werd een URL doorgegeven bij optie 224, met als omschrijving 'CSP'. Geen idee wat het juist betekend, maar mijn Digicorder gebruikt de URL alleszins. Vreemd genoeg echter op poort 8215 i.p.v. 8211. De HTTP headers zijn hier een pak minder uitgebreid dan deze van de communicatie uit SNMP+HTTP, wat erop kan duiden dat dit verschillende applicaties zijn.

Het betreft hier enkelvoudige POSTs op de URL http://10.16.2.7:8215/IDTV/FrontController waarbij alle informatie wordt gecodeerd in een URL argument. Deze informatie komt soms overeen met diegene die ook via SNMP kan worden opgevraagd, maar wordt in dit geval actief verzonden naar Telenet. Vermoedelijk gebeurt dit na aanpassing van een instelling of opname. Ook wanneer aan de profielen iets wordt gewijzigd, wordt naar deze server informatie verzonden. Bemerk dat hierbij zowel de PIN code als het eventuele wachtwoord van een e-mailaccount (net zoals alle andere informatie) onversleuteld verzonden worden!


ARP
Eigenlijk geen communicatie van de Digicorder, maar iets wat je zelf kan doen. Wanneer je een ARP request verstuurt richting je modem, voor een IP in dezelfde range als de Digicorders, krijg je vaak een antwoord. Mogelijk kan je dan ook SNMP verzoeken versturen naar deze IPs, aangezien de Digicorders niet zo kieskeurig zijn wanneer het op SNMP verzoeken beantwoorden aankomt.


Telenet blijkt dus heel wat redundantie te hebben ingebouwd om bepaalde informatie te verkrijgen (HTTP, SNMP+HTTP, SNMP). Probeer gerust of je deze bevindingen kan reproduceren, of wat de verschillen zijn, en laat het ons dan vooral weten!

Mijn opstelling is vrij simpel. Alles (behalve de digicorders) via een 24 poort gigaswitch geconnecteerd naar de TN router. De digicorders zijn via powerplugs rechtstreeks op de TN router geconnecteerd.

De dc-2100 krijgen een 192.x en een 10.x adres.

De 192.x zit in de range van mijn home netwerk waardoor mijn dc2100 mijn nas vinden met daarop plex draaiend. Dlna werkt via de digicorders.

Http naar poort 8080 en 8000 geven info over de digicorder.
Ik heb nog geen sniffing gedaan, maar zal dat ook een doen om te zien wat we tezien krijgen. Opnames kunnen afgespeed worden via ps3, ik ben opzoek om deze ook allemaal te kunnen afspelen op ipad. Dat is mij nog niet gelukt. De decrypting werkt niet.

Als je aan het packetscannen bent, kijk dan ns of je het vlan nummer kunt identificeren? Wss gaat dat eruit gestript zijn maar wie weet. Dan moet het in theorie mogelijk zijn om met een eigen router de telenet router na te bootsen, en dan zijn we een stap verder om in te breken op die vlan vanuit ons eigen netwerk.

[ Post made via mobile device ]

Ik denk dat we er ondertussen wel al uit zijn dat Telenet geen VLANs gebruikt op de interne netwerken van klanten met een HGW. Als ik mijn Digicorder rechtstreeks met een UTP kabel verbind met mijn laptop en vervolgens het verkeer dump, is geen enkel pakket getagd met een VLAN.

Ik heb overigens nog eens geprobeerd om DHCP relaying te gebruiken voor de Digicorder, maar die pakketten worden blijkbaar volledig genegeerd door Telenet... In de DHCP requests is de oorsprong van het pakket dan niet meer dezelfde als het aanvragende MAC-adres, maar dat zou op zich geen probleem mogen zijn. Als ik echter mijn WAN interface in de gaten hou voor DHCP pakketten, zie ik de mijne enkel vertrekken, maar daar komt nooit een antwoord op. Mocht het gewoon een probleem zijn met mijn firewall, dan zou ik normaal wél binnenkomende pakketten moeten zien op mijn WAN interface, dus dat lijkt me uitgesloten.

Mijn doel is vooral van een werkende, veilige oplossing te vinden, waarbij de Digicorder interactief is en benaderbaar vanaf mijn interne netwerk.

Ondertussen heb ik ook de context van het SNMP+HTTP verkeer gevonden. Deze communicatie wordt namelijk gebruikt om de Digicorder vanop afstand te bedienen, bv. als je via yelotv.be opnames beheert.

Zoals eerder vermeld, stelt Telenet eerst een token in op een welbepaalde OID. Vervolgens vraagt de Digicorder op http://stbpvr.prd.telenet-ops.be/stb1/command met een POST verzoek op welke actie met dit token geassocieerd is. Deze actie wordt uitgevoerd, waarna het antwoord verzonden wordt naar http://stbpvr.prd.telenet-ops.be/stb1/respone, wederom met een POST verzoek. Alle communicatie verloopt met behulp van XML.

Acties die ik reeds heb gezien zijn:

• get-freespace: Beschikbare ruimte (voor opnames),
• get-recordings: Lijst val alle bestaande en geplande opnames,
• get-recording: Details van één opname,
• create-recording: Opname toevoegen,
• cancel-recording: Geplande opname annuleren,
• delete-recording: Bestaande opname verwijderen

Wanneer een opname wordt gecreëerd, wordt ook naar http://sarsc.prd.telenet-ops.be een formulier verzonden (met een GET verzoek) met de nieuw aangemaakte opname. Bemerk dat de Digicorder zelf aanvraagt bij Telenet welke actie uitgevoerd dient te worden. Je kan dus niet direct zelf opnames gaan beheren via deze interface.
Tenzij je natuurlijk zelf alles gaat nabouwen en DNS queries voor stbpvr.prd.telenet-ops.be gaat spoofen, maar dat lijkt me nogal veel werk voor wat het maar opbrengt.