Tuesday, November 6, 2012

MaxTV nastavak...

Dakle, opet sam došao u doticaj s MaxTV opremom (točnije, prijemnikom) i ovaj puta sam pripremio sve potrebno da se ubacim između prijemnika i ADSL rutera. Zvuči kao da sam povezao kamion opreme sa sobom, a u stvari sam samo ponio laptop s PCMCIA mrežnom karticom tako da je dotični imao dvije mrežne kartice. Taman ono što treba. Pri tome sam imao više sreće nego pameti, naime nisam ponio cross-over mrežni kabl ali je ispalo da su mrežne na laptopu (ili na nekom od uređaja) to prepoznale i promijenile smjer kontakata.

Prikupljanje informacija

Uglavnom, ono što sam napravio je da sam isključio MaxTV prijemnik iz rutera te ga potom spojio na laptop, a laptop (koristeći drugu mrežnu utičnicu) spojio na ruter gdje je prije bio spojen prijemnik. Dodatno, kao root korisnik izvršio sam sljedeće naredbe:
# brctl addbr br0
# brctl addif br0 eth0
# brctl addif br0 eth1
# ip link set br0 up
# /etc/init.d/iptables stop
Te naredbe podrazumijevaju nekoliko stvari. Prvo, instaliran je paket bridge-utils u kojemu se nalazi naredba brctl. Konačno, mrežna sučelja na koja su spojeni prijenik i ADSL ruter zovu se eth0 i eth1. Zadnja naredba isključuje firewall, iako u načelu to ne bi trebalo, al' sigurno je sigurno. Ovo sam radio na CentOS 6 distribuciji i ako je neka druga u pitanju, treba napraviti odgovarajuće modifikacije.

Nakon toga sam isključio MaxTV prijemnik te sam pokrenuo snimanje prometa na laptopu:
# tcpdump -s0 -i br0 -w boot.pcap
i uključio MaxTV prijemnik. Promet je sniman u datoteku boot.pcap te sam ga puštao da snima promet dok god nije s ekrana televizora nestala oznaka Učitavam....

Dodatno, ispostavilo se da je komunikacija koja me zanima bila isprepletena s video zapisom zbog čega je datoteka bila vrlo velika. S obzirom da tako velika datoteka jako usporava rad prilikom njena anliziranja, odlučio sam izeliminirati video promet korištenjem tcpdump naredbe. U mom slučaju radilo se o video i audio podacima koji se šalju na adrese 224.1.2.81 i 224.1.1.1 (History i HTV1 kanali). Dakle, eliminacija je jednostavna:
# tcpdump -r boot.pcap -w boot1.pcap not host 224.1.2.81 and not host 224.1.1.1
Navedena naredba čita datoteku boot.pcap primjenjuje filter (not host 224.1.2.81 and not host 224.1.1.1) i zapisuje rezultat u datoteku boot1.pcap u kojoj više nema video (i audio) podataka. Nego, jesam li spomenuo da obožavam naredbu tcpdump? :)

Koliko god tcpdump naredba bila dobra, u određenim situacijama wireshark je ipak zakon. I sada dolazimo u baš takvu situaciju, analiza snimljenog mrežnog prometa.

Analiza snimljenog mrežnog prometa

Snimljeni mrežni promet učitao sam u wireshark korištenjem sljedeće naredbe:
wireshark boot1.pcap
Ovdje sada neću pričati o tehnikalijama kako sam nešto točno napravio već ću se prvenstveno zadržati na onome što sam uspio pronaći.

Slijed događaja odmah nakon uključenja samog uređaja je sljedeći:
  1. Dohvat mrežnih podataka korištenjem protokola DHCP. Pri tome DHCP poslužitelj koristi ARP kako bi provjerio da adresa nije korištena, te kako bi nakon dodjele adrese provjerio da ju je uređaj doista i prihvatio. U DHCP podacima nalazi se informacija o DHCP poslužitelju (172.29.162.9, 172.29.162.12), DNS poslužitelju 172.27.130.4 i domeni nat.myrio.net, NTP poslužiteljima 172.27.130.21 i 172.27.130.24. Zanimljivo da je tu i opcija DOCSIS full security server IP s vrijednošću 31 kraj koje stoji oznaka "[TODO]". Čini se da to nije podatak s poslužitelja već da Wireshark trenutno ne dekodira tu informaciju.
  2. DHCP poslužitelj s IP adresom 172.29.162.9 provjerava korištenjem ICMP echo request/response proba (efektivno, ping naredba) da li je klijent dostupan.
  3. Slijedi sinkronizacija vremena korištenjem NTP protokola.
  4. Ponovo DHCP upit, pri čemu se ovaj puta traži niz privatnih opcija, ali niti jedna nije pružena u odgovoru!
  5. Upit za ime sap.nat.myrio.net. Odgovor je višeodredišna adresa 224.1.3.207.
  6. SRV upit DNS poslužitelju za _vqe_channel_cfg._tcp.nat.myrio.net. Ovo je standardizirani upit kojim se traži informacija o usluzi _vqe_channel_cfg putem TCP protokola. Odgovor su poslužitelji vqe2.nat.myrio.net. (IP adresa 172.26.246.3) i port 8554 te vqe.nat.myrio.net (IP adresa 172.26.246.2) i port 8554.
  7. Pristup na poslužitelj vqe.nat.myrio.net korištenjem protokola RSTP. Rezultat je popis svih raspoloživih kanala u SDP formatu. O njoj ću malo kasnije.
  8. Spajanje na grupu 224.1.3.207 (IP adresa dobijena u 5. koraku). S te adrese stalno se prihvaćaju podaci u SDP obliku. Primjer podataka koji se razmjenjuju.
  9. Upit za ime vss.verimatrix.com (IP adresa je 172.27.131.194) i spajanje na port 12697 tog poslužitelja. Koliko sam vidio, dohvaćaju se certifikati. Tvrtka verimatrix izgleda da se bavi metodama naplate TV sadržaja.
  10. Dva puta se spaja na port 12698 poslužitelja vss.verimatrix.com i dohvaća nešto nepoznato.
  11. Spajanje na vks.verimatrix.com (IP adresa je 172.27.131.194) port 12700 i dohvat nekakvih binarnih podataka.
  12. Dohvat podataka poslanih na adresu 224.1.3.213. Podatke šalje poslužitelj 172.27.130.21 (to je NTP poslužitelj ali očito ima još neku funkciju).
  13. Pokušaj spajanja na adresu 172.27.130.2 i po port 8443, međutim došlo je do isteka vremenskog ograničenja (timeout). Kasnije je došao ICMP odgovor Destination unreachable (Communication administratively prohibited).
  14. Upit za imenom avr.nat.myrio.net (IP adresa 172.27.131.164) i potom slanje UDP paketa na port 2498. Odgovora na taj paket nije bilo.
  15. Upit za imenima mds.nat.myrio.net (IP adresa 172.27.130.107) i webapp.nat.myrio.net (IP adresa 172.27.130.2).
  16. Spajanje na webapp.nat.myrio.net port 8085. U ovom slučaju radi se o autentifikacijskom zahtjevu koji je uspješno obavljen. Zahtjev se šalje korištenjem metode GET protokola HTTP. Rezultat se vraća u XML obliku.
  17. Potom ponovno spajanje na webapp.nat.myrio.net port 8085 rezultat je bio "Success".
  18. Potom ponovno spajanje na webapp.nat.myrio.net port 8085. Ovaj puta se traže podaci o pretplatniku koji su dobijeni u XML obliku unutar tijela odgovora.
  19. Potom ponovno spajanje na webapp.nat.myrio.net port 8085. Prijenos nepoznatih podataka.
  20. Spajanje i dohvat podataka s grupa 224.1.3.209, 224.1.3.219, 224.1.3.216, 224.1.3.211 i 224.1.3.212.
  21. Spajanje na webapp.nat.myrio.net port 8085.
  22. Spajanje na grupu 224.1.3.208.
  23. Pet spajanja na webapp.nat.myrio.net port 8085. Prijenos nepoznatih podataka.
Nakon ovoga izgleda da dalje idu samo video i audio podaci između prijemnika i T-Com-a. U nastavku su produbljeni neki dijelovi gornjih koraka

Popis kanala

Popis kanala dohvaća se korištenje protokola RTSP. Datoteka se sastoji od dva dijela, upita i odgovora. Upit čine prve tri linije:

DESCRIBE rtsp://172.26.246.2/vqe-channels RTSP/1.0
CSeq: 1
Accept: application/sdp
Nakon upita slijedi prazna linija te odgovor. Odgovor je dalje sačinjen od dva dijela, zaglavlja i tijela. Zaglavlje čini pet linija:
RTSP/1.0 200 OK
CSeq: 1
Date: 2 Nov 2012 22:16:49
Content-Type: application/sdp
Content-Length: 152588
Nakon toga dolazi prazna linija i tijelo. Tijelo se sastoji od opisa programa u SDP obliku. Po jedan blok za svaki program. Ovdje je primjer jednog bloka:
v=0
o=- 1350979665943 1350979665943 IN IP4 vcpt2
s=DiscWild HD
i=Channel configuration for DiscWild HD ( Unicast Retransmission Only )
t=0 0
a=rtcp-unicast:rsi
a=group:FID 1 3
m=video 3058 RTP/AVPF 96
i=Original Source Stream
c=IN IP4 224.1.2.58/255
b=AS:9000
b=RS:13
b=RR:130000
a=fmtp:96 rtcp-per-rcvr-bw=13
a=recvonly
a=source-filter: incl IN IP4 224.1.2.58 172.29.162.99
a=rtpmap:96 MP2T/90000
a=rtcp:3059 IN IP4 172.26.245.206
a=rtcp-fb:96 nack
a=mid:1

m=video 3058 RTP/AVPF 98
i=Re-sourced Stream
c=IN IP4 224.1.2.58/255
a=inactive
a=source-filter: incl IN IP4 224.1.2.58 172.26.245.206
a=rtpmap:98 MP2T/90000
a=rtcp:3059 IN IP4 172.26.245.206
a=mid:2
m=video 50206 RTP/AVPF 99
i=Unicast Retransmission Stream
c=IN IP4 172.26.245.206
b=RS:13
b=RR:13
a=recvonly
a=rtpmap:99 rtx/90000
a=rtcp:50207
a=fmtp:99 apt=96
a=fmtp:99 rtx-time=3000
a=mid:3
Ovdje se može razaznati četiri bloka: globani dio od početka do prve linije m=, i potom po jedan blok od kojih svaki započinje s linijom m=. Globalni blok daje informacije o kojem programu se radi. U ovom slučaju u pitanju je Discovery Wild HD. Od preostala tri bloka, zanimljiv nam je (za sada) samo prvi. Ovi ostali su retransmisija, nagađam u slučaju da se može naknadno gledati. U prethodnom ispisu masnim slovima sam označio što pripada prvom bloku. Iz toga se mogu iščitati sljedeće informacije:
  1. Radio se o RTP/AVPF video podacima koji se šalju na port 3058 (linija m=).
  2. Za primanje tih video podataka koristi se adresa 224.1.2.58 (linija c=).
  3. Format u kojemu se prenosi video i audio je MP2T.
Web aplikacija

Web aplikacija nalazi se na IP adresi 172.27.130.2, port 8085. Poslužitelj je JBoss/Apache, a pristupa se sljedećim URL-ovima:
  • /broker/fcs/authenticate?
  • /broker/fcs/stbProperties?
  • /broker/fcs/subscriberInfo?
  • /broker/fcs/reminder?
  • /broker/fcs/rentedItems?
  • /broker/fcs/customCallerIDList?
  • /broker/fcs/favorite?
  • /broker/fcs/ContactManagement?
  • /broker/fcs/playList?
Tijekom autentikacije šalju se podaci o modelu prijemnika, programskoj podršci koja se izvršava i slično. Ne vidim nikakve tajne informacije u tom URL-u pa mi se čini da je autentikacija samo prijava pri čemu se MAC adresa koristi kao identifikator (jer se u svim ostalim URL-ovima javlja MAC adresa).

Analiza video i audio podataka

Ovo mi se čini kao put da se otkrije iz kojeg razloga nije moguće dekodirati strane kanale. Naime, iz snimljenog prometa izdvojio sam pojedini kanal i potom ga učitao u Wireshark. Izdvajanje kanala obavlja se po IP adresi. Primjerice, kako bi se izdvojio kanal 224.1.2.81 može se koristiti sljedeća tcpdump naredba:
tcpdump -r boot.pcap -w stream1.pcap host 224.1.2.81
Na temelju popisa kanala, radi se o History kanalu. U toj naredbi pretpostavljam da je prilikom nastajanja datoteke boot.pcap bio odabran taj program na prijemniku. Nakon što se naredba izvrši, rezultat će biti pohranjen u datoteku stream1.pcap. Kada se ta datoteka učita u Wireshark on će analizirati promet samo do protokola UDP. Kako bi nastavio dalje treba mu reći da se radi o RTP prometu, što se postiže klikom na desnu tipku na nekom paketu, odabirom opcije Decode As... i potom se u listi protokola pronađe RTP. Nakon toga on će ispravno dekodirati i MP2T.

Međutim, za sada nisam uspio otkriti u tim podacima kako je video točno kodiran i u čemu je problem. Ako netko želi pogledati izdvojio sam taj promet u dvije pcap datoteke koje se mogu učitati direktno u Wireshark. Obje su veličine oko 1M. Prva sadrži HTV1, dakle ono što se može bez problema gledati. Druga sadrži History kanal s kojim je problem u dekodiranju. Obje datoteke možete direktno podmetnuti nekom programu za prikaz videa (kao što je primjerice mplayer) i primjetit ćete kako HTV1 prikazuje, History ne. Dodatno, mogu se datoteke učitati u Wireshark te potom ekstrahirati video pa pokušati, iako, rezultati će biti gotovo isti.

Podaci na kanalu 224.1.3.207

Podaci s ovog kanala se stalno prihvaćaju SDP opisi nekakvih binarnih podataka. Ovo su podaci (sadržaj linije s=):
  • 7710.HE.30.14.0000.00.reno.rel6-myrioi-71
  • 7710.HE.32.14.0000.00.reno.rel6-myrioi-110
  • 8000.HE.30.14.0000.00.reno.rel6-myrioi-71
  • 8000.HE.32.14.0000.00.reno.rel6-myrioi-110
  • DTVLINEUP
  • DTVLINEUP_v.3.0
  • DTVLINEUP_v.3.1
  • GLOBALINSTALL
  • GLOBALLYFEATURED
  • GROUPS
  • MESSAGES
  • NPVRUPDATEDRECORDINGS
  • PIPEDSCHEDULE
  • PIPEDSCHEDULE_small
  • sw_update.SAIPP330HD.SCIATL
  • sw_update.SAIPP330HD.SCIATL.reno.rel6-myrioi-110
  • sw_update.SAIPP330HD.SCIATL.reno.rel6-myrioi-71
  • ui_default
  • ui_reno.rel6-46_tcom
  • WEBACCESS
  • WEBACCESS_en
  • WEBACCESS_hr
Interesantno da sam pretražujući Internet za ključnom riječju "x-carousel" naišao na ovaj forum. Međutim, radi se o postu na Francuskom jeziku koji baš ne razumijem. :)

Linije koje su istaknute masnim slovima označavaju datoteke koje je moguće dohvatiti korištenjem HTTP protokola. Za dohvat treba koristiti sljedeći URL:
http://webapp.nat.myrio.net/broker/documentName=GLOBALINSTALL.xml.gz
Kao što primjećujete, datotekama treba dodati ektenziju .xml.gz.

Pristup Internetu

Putem MaxTV mreže moguće je pristupiti Internetu ali se za to mora koristiti proxy. Proxy je na adresi 172.27.131.173, port 3128. Primjerice, putem njega moguće je na Facebook ali uglavnom je pristup ograničen, odnosno, nije moguće posjetiti bilo koje Web stranice. Inače, zanimljivo je da port 3128 po "defaultu" koristi Squid pa se vjerojatno radi o toj poslužiteljskoj aplikaciji.

Zaključak

Dakle, očito je jasno kako još nisam uspio odrediti zašto se ne vide pojedini kanali i trebat će na tome još poraditi. S obzirom da mi audio/video nije baš jača strana trebat će vremena. Međutim, ako netko drugi želi istražiti što je problem u tekstu sam stavio linkove na snimljen promet dva programa, jednog koji se ispravno prikazuje (HTV1) i jednog koji se ne prikazuje ispravno (History Channel).

Za kraj, ovdje je link na raspravu na Bugovom forumu u kojemu se raspravlja o STB-u i njegovoj prenamjeni. Čini se interesantno, ali još nisam stigao detaljno pročitati post.

No comments:

About Me

scientist, consultant, security specialist, networking guy, system administrator, philosopher ;)

Blog Archive