Panasonic Viera i zdekodowanie/odszyfrowanie nagrań z HDD USB

Witam zainteresowanych.

Sprawa się tyczy nagrań tworzonych przez telewizory Panasonic z serii Viera (V20, V10, G10 i pewnie innych też) na dysku twardym podłączonym przez USB. Jak zapewne większości z Was wiadomo, do telewizora możemy podłączyć HDD (co najmniej 160GB) i nagrywać sobie na nim to co oglądamy. Lecz nagrania te można oglądać tylko i wyłącznie na tym samym telewizorze na którym zostały one utworzone. Wg Panasonica niemożliwe jest obejrzenie tych nagrań na innym identycznym modelu telewizora (winny za to jest KEY generowany przy wywołaniu funkcji SELF CHECK) a tym bardziej na komputerze PC.

Ale od czego mamy na karku „baniaki” , a przecież słowo „niemożliwe” nie istnieje dla pomysłowego Polaka – bo niby kto rozpracował Enigmę i niedawno opracował najsilniejsze szyfrowanie ? Mam nadzieję, że wspólnymi siłami (również międzynarodowymi – ale o tym na końcu) uda się nam rozpracować system zapisu danych wymyślony przez Panasonica. I będę baaardzo wdzięczny jeżeli któryś z serwisantów Panasonica przyłączy się i wesprze nas wiedzą oraz materiałami serwisowymi z pierwszej ręki.

Na początek niezbędne informacje, które udało się już samemu rozpracować:
- dysk jest formatowany w systemie plików UFS (http://en.wikipedia.org/wiki/Unix_File_System),
- aby odczytać z niego dane musimy użyć jakiegoś Linuxa ze wsparciem UFS lub na WinXP skorzystać z programu UFS Explorer (http://www.ufsexplorer.com),
- pojedyncze nagranie składa się z czterech plików, np.
101.dat (informacje o kanale, tytule audycji, dacie itp.),
101_00.aid (zapewne skrót od Audio IDentyfication – prawdopodobnie dane do dekodowania strumienia audio),
101_00.vid (pewnie Video IDentyfication – prawdopodobnie dane do dekodowania strumienia wideo),
101_00.tts (plik największy objętościowo z zakodowanym strumieniem audio i wideo).
Jeżeli nagranie jest bardzo długie to następuje zwiększenie licznika, np. 101_01.tts, 101_02.tts, ...
Przykładowe pliki zamieściłem na swojej stronie http://jacek.prv.pl/panasonic. Pliki o numerach 1061, 1062, 1063, 1066 to nagrania z planszy testowej (zdjęcie tutaj http://jacek.prv.pl/panasonic/test%20picture2.jpg, sygnał praktycznie z zerową stopą bitową, wideo zamieszczę wkrótce). Pliki 1060, 1064 to też nagrania planszy testowej, ale bardzo krótkie których TV nawet nie chce odtworzyć.

Plikiem DAT na razie nie ma co się zajmować. Tekstem otwartym zawarte są w nim dane o których już wspomniałem.

Ciekawie robi się przy plikach AID i VID. Struktura plików jest podobna i zawsze tworzona wg określonego wzoru dla każdego z nagrań. Rozmiar plików AID, VID zawsze jest równy sobie i zależny jest od długości całego nagrania, czyli mamy zależność rozmiaru plików AID, VID od rozmiaru pliku TTS. Poniżej zrzuty ekranów z zawartością plików AID i VID – od razu widać podejrzaną strukturę danych.



Pierwsze 16 bajtów zawsze jest takie same (nagłówek, być może jest w nim ten KEY, trzeba będzie to sprawdzić). Wygląda na to, że są dwa liczniki. Pierwszy 3 bajtowy LICZNIK1 - COUNTER1 oraz drugi 2 bajtowy LICZNIK2 - COUNTER2 (ale tylko dla pliku AID). Pomiędzy nimi jakieś dane zmienne, czyli pewnie służące do dekodowania (DECODING). Jak widzicie ostatni bajt z tych danych, ma pewną zauważalną regularność, a wynika ona zapewne z tego, że analizowany sygnał audio to sygnał testowy o jednostajnej częstotliwości. Łatwiej to wszystko będzie to Wam zauważyć na przykładzie dłuższych plików: 535_00.aid, 535_00.vid. To już zwykłe nagranie audycji i nie ma już tak ewidentnie zauważalnej regularności w ostatnim bajcie danych dekodowania (DECODING) ale o wiele lepiej za to widać liczniki.

Plik TTS to już inna bajka. Nie ma w nim żadnych regularności, to po prostu czyste dane audio i wideo w jednym pliku. Poniżej przykładowy plik TTS z analizą kodu szesnastkowego. Nie widać w nim żadnych regularności czy zauważalnych znaczników.



Teraz transkodujemy dane z pliku AID według następującego wzoru:
- bierzemy pierwszych 8 bajtów (od 1 do 8) i tworzymy z nich pierwszy wiersz danych (każdy taki wiersz nazwijmy umownie SŁOWO – WORD),
- bierzemy kolejne 8 bajtów (od 9 do 16) i tworzymy drugi wiersz danych,
- znowu bierzemy kolejnych 8 bajtów (od 17 do 24) i tworzymy trzeci wiersz danych,
- znowu bierzemy kolejnych 8 bajtów (od 25 do 32) i tworzymy czwarty wiersz danych,
- znowu bierzemy kolejnych 8 bajtów (od 33 do 40) i tworzymy piąty wiersz danych,
(…)



Przyglądając się plikowi 535_00.aid możemy zauważyć jakimi prawami rządzą się LICZNIKI COUNTER1 i COUNTER2. Stosowane są zmienne od 0 do 9 oraz od A do F.
Czyli COUNTER1 wygląda tak: 00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 0A, 0B, 0C, 0D, 0E, 0F, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 1A, 1B, 1C, 1D, 1E, 1F, 20, 21, 22 …
Ale ta prosta zależność występuje tylko dla drugiego i trzeciego bajtu COUNTER1 oraz obydwu bajtów COUNTER2. Nie sprawdza się natomiast dla najmłodszego (pierwszego) bajtu COUNTER1 co widać poniżej.



Zauważyłem jedynie, że dla małych plików kroki są mniejsze (od 2 do 3) a przy większych plikach kroki są większe (jak powyżej od 5 do 9).
Warto też zwrócić uwagę na powtarzający się ostatni ciąg zmiennych w najmłodszym bajcie SŁOWA - WORD w postaci 3C, 9C, FC, 5C, BC, 1C, 7C (oznaczyłem na żółto). Przyglądając się całemu plikowi 535_00.aid zauważycie na pierwszej (młodszej) pozycji tego bajtu występują tylko dwie zmienne, w tym przypadku C lub 4. W innych plikach są to inne dwie zmienne, ale zawsze tylko dwie.

Na razie to tyle moich wypocin. Jak zauważę coś jeszcze ciekawego, to dam znać. Pozostaje mi tylko poprosić Was o rzucenie okiem na to wszystko i podzielenie się własnymi spostrzeżeniami. Może ktoś z Was już widzi zastosowany algorytm i będzie jakiś punk zaczepienia.

A na koniec obiecany międzynarodowy wątek. Znalazłem dwa fora na których ludzie też próbują coś zdziałać:
http://www.avforums.com/forums/lcd-led-lcd-tvs/1303759-panasonic-viera-tv-usb-hdd-pvr-supported-drives-pc-access-recordings.html
http://www.hackerboard.de/cryptography-encryption/41849-verschluesselung-knacken-von-tv-aufnahmen-panasonic-gw20-v20.html
Na dokładkę jeszcze Service Manual od TX-P42G20E, TX-P42G20ES, TX-PF42G20S, TX-PR42G20 - http://depanntv.pagesperso-orange.fr/schemas/TX-PF42G20S.pdf

PS do Administratorów: jeżeli uznacie, że temat powinien być w innym dziale to proszę przenieść, mi pasował ten dział i ewentualnie DSP.

1 29

Próbował kolega programu o niewdzięcznej nazwie "vcdgear"? Konwertuje pliki z rozszerzeniem dat na mpeg, a chyba o to chodzi.

0

Kcyś napisał:

Próbował kolega programu o niewdzięcznej nazwie "vcdgear"? Konweruje pliki z rozszerzeniem dat na mpeg, a chyba o to chodzi.

Jakby ten TV nagrywał w formacie MPEG1 (jak płytach VCD), to może to co napisałeś miałoby sens... Ale nie ma.

0

Próbowałeś? Mój tv nagrywa z rozszerzeniem bin i u mnie ten program się sprawdza. Pól godzinne nagranie zajmuje z rozszerzeniem bin 1GB.

0

Też mi się zdaje, że to nie będzie takie proste. Plik TTS tworzony przez telewizor nie ma żadnego nagłówka, regularności, znaczników itp. I trzeba jeszcze wziąć pod uwagę, że poprawny wynik uzyskamy prawdopodobnie dopiero przy znalezieniu zależności między wszystkimi trzema plikami AID, VID i TTS.

0

Kcyś napisał:

Próbowałeś? Mój tv nagrywa z rozszerzeniem bin i u mnie ten program się sprawdza. Pól godzinne nagranie zajmuje z rozszerzeniem bin 1GB.

Napisałeś o konwersji pliku .dat do mpg. Plik .dat na płycie VCD zawiera dane multimedialne (i nawet nie potrzeba konwersji do .mpg, po skopiowaniu wystarczy zmienić rozszerzenie pliku, aby go odtwarzać dowolnym programem niezależnie od pozostałej zawartosci VCD). Założyciel tematu wyraźnie napisał, że w opisanym przypadku plik .dat to tylko mały plik tekstowy z danymi, czyli nie ma nic wspólnego z .dat znanym z VCD, stąd moja uwaga.

0

Ja doszedłem do trochę innych wniosków:
aid: jeden 32 bitowy licznik, drugi idealnie stabilny to może być rozmiar kolejnego bloku danych audio w pliku tts.
vid: jeden 32 bitowy licznik[pierwsze 4 bajty], następne 4 bajty to chyba korekcja synchronizacji/opóźnień.

Pierwszy licznik zarówno w aid jak i vid jest taki sam, dodatkowo nie jest on idealnie stabilny więc według mnie to czas poszczególnych klatek.

Nie posiadam tego telewizora, więc przydał by się kawałek nagranej transmisji nie statycznej, dodatkowo dokładny czas nagrania, jego długość i parametry[możliwie dużo].

Załączam stosowne zrzuty[starałem się kadrować w tym samym miejscu, więc można je przełączać na kartach w przeglądarce]:

konsola[wartości bajtów w systemie dziesiętnym]: [bajty[0:3]] [różnica do poprzednich bajtów[0:3]] | [bajty[4:7]] [różnica do poprzednich bajtów[4:7]]

[aid]

[vid]


Dodatkowo rezultat z 535_00:

0

Problem wstępnie rozwiązano już w 2000r.
Czytaj http://www.ixbt.com/multimedia/vcd2mpeg4.html
http://vcdgear.yuku.com/forums/4/VCDGear-3-0-Q-A
Pomocne też http://www.videohelp.com/

Najnowszy Link_ VCDGear v3.55 jest bezapelacyjny.

0

skynet_2
Dzięki za analizę plików, od razu widać, że w masz do tego głowę i zauważyłeś inne zależności. Umieściłem dodatkowe nagrania (jacek.prv.pl/panasonic) :
- pliki 1082 (statyczna plansza testowa), około 51 sekund,
- pliki 1083 (statyczna plansza testowa), około 1 minuta 25 sekund, około 46 sekundy wystąpiło zakłócenie sygnału,
- pliki 1084 (nagranie z Polsat Sport), około 2 minuty 2 sekundy, wybrałem ten kanał ze względu na występujące u góry jakieś pozostałości po dodatkowym sygnale cyfrowym lub innych dodatkowych danych (plik 1084_00.jpg), myślę że później te pozostałości mogą się okazać przydatne przy dekodowaniu pliku TTS.

Nagrania te są typowym sygnałem DVB-T SD czyli powinny mieć następujące parametry:
rozdzielczość: 702x576, fonia zapewne MP2 (MPEG-1, 2 Layer II) 128kbs (http://www.kigeit.org.pl/stirc/pliki/20080403_parametry_techniczne_DTT.htm).
Dołożyłem też nagranie wideo test_video.avi na którym możemy zobaczyć co jest w tych plikach z nagraną planszą testową.



pandy
TTS już trochę oczywiście analizowałem i jeszcze się dokształcam .
Program TSDoctor nawet coś próbuje znaleźć w tych moich plikach TTS. Ale gubi się przy PMT lub PCR – będę próbował dalej, być może to wina tego szyfrowania Panasonica i będzie to ślepa uliczka.
TSReader nie rozpoznaje nic w pliku i wyrzuca komunikat o nierozpoznanym strumieniu z sugestią na MPEG-2 lub DSS.
Pomysł z indeksowaniem jest interesujący, zwłaszcza biorąc pod uwagę jakie wnioski ze struktury plików wyciągnął skynet_2, to może być rzeczywiście to. Telewizor ma możliwość zapamiętania gdzie ostatnio zakończyliśmy oglądać materiał i następnym razem jak do niego powracamy to zaczyna odtwarzanie od miejsca w którym skończyliśmy. Ale istnieje też ryzyko, że w tym indeksowaniu zawarte są również klucze do poszczególnych bloków danych i sprawa będzie się trochę komplikować. Czekam z niecierpliwością na kolejne wnioski od skynet_2.


lisek
Nie jestem pewien czy mam na myśli to samo. Nie chodzi o to by jakiś materiał przekonwertować i obejrzeć go na telewizorze. Odwrotnie – chcemy materiał stworzony przez telewizor przekonwertować i obejrzeć na PC. Widzę, że VCDGear ma rzeczywiście spore możliwości, ale nawet na forum programu nie znalazłem wzmianki, aby ktoś wykorzystał go do konwersji nagrań z Panasonic Viera. Wspominasz, że w 2000 roku już problem wstępnie rozwiązano – wtedy jeszcze chyba nie było tej serii TV. Jeżeli natrafiłeś na jakieś konkrety to poproszę o bezpośrednie linki – zajrzałem na te fora i jak na razie o moim przypadku nic nie znalazłem.


A ja sam zabieram się za service manual. Spróbuje znaleźć coś w schemacie ideowym. Być może obróbką i kodowaniem zajmuje się konkretny układ, a wtedy wystarczy znaleźć jego notę katalogową i będzie kolejny punkt zaczepienia. Może być też tak, że wszystko jest robione software'owo (z tego co wiem, to soft Panasonica oparty jest na Linuxie) i zaczną się schody. Wsady softu są dostępne na necie, ale są już skompilowane i praktycznie bezużyteczne w celu dalszej analizy kodu.

Mam też prośbę do posiadaczy podobnego Panasonica - jeżeli ktoś z Was próbował już odczytać dane z dysku, to niech zerknie na pierwsze 4 bajty w plikach AID i VID. U mnie w trybie HEX zawsze jest to samo, czyli : 53 45 02 5A - czy u Was też tak będzie, czy macie inny ciąg ? Być może w tych czterech bajtach jest zabezpieczenie przed odtworzeniem nagrań na innym TV (lub po SELF CHECK).

0

Cytat:

wszystko jest robione software'owo (z tego co wiem, to soft Panasonica oparty jest na Linuxie) i zaczną się schody. Wsady softu są dostępne na necie, ale są już skompilowane i praktycznie bezużyteczne w celu dalszej analizy kodu.

Właśnie wszedłeś na te schody , tam masz Linuks

0

Cytat:

pliki 1082 (statyczna plansza testowa), około 51 sekund
pliki 1084 (nagranie z Polsat Sport), około 2 minuty 2 sekundy

Ostatnie wpisy pierwszego licznika czyli dla:
1082_00.aid 35563 / 51 sec = 697.31
1084_00.aid 352134 / 122 sec = 2886.34
Pasują z pewnym błędem do średnich różnic pomiędzy kolejnymi wartościami licznika, może to oznaczać że każde 8 bajtów przypada na 1 sec nagrania[pomijając nagłówek].

Dodatkowo nagranie testowe[1082] zawiera znacznie mniejsze różnice[porównując do 1084] w liczniku pomiędzy kolejnymi sekundami, można by z tego wywnioskować że pierwszy licznik to współrzędne początków klatek[/pakietów] w tts, końcówka licznika w 1084 jest ok 10x większa od 1082 podobnie jak rozmiar pliku tts który również jest 10x większy.

-------------------------------------------------------------------------

Skompresowanie planszy testowej[1082] powinno zająć bardzo mało miejsca < 1/100 tego co w 1084, a zajmuje 1/10 można więc przyjąć że enkoder mpeg[2/4] na siłę wstawia klatkę kluczową co 1 sec, prawdopodobnie po to aby przewijanie było prostsze tyle że kosztem kompresji.

Teoretycznie w pliku vid te 4 bajty po prawej to może być odległość[w bajtach/pakietach ???] do najbliższej klatki kluczowej[tzw klatka I], gdyż tylko od niej można rozpocząć odtwarzanie.

Dla nagrania testowego pomiędzy klatkami I rozmiary klatek P[zawierających informacje o ruchu] będą bardzo małe, skoro rozmiar klatek I jest stały a P pomijalny, odległość do klatki I będzie bardzo mała, również dźwięk jest stały.

Przy nagraniu dynamicznych rozmiary klatek będą znacznie różnić się rozmiarem zarówno I jak i P, więc tutaj te wartości również będą większe.

Ale to tylko luźne przypuszczenie co do bajtów[4:7] w pliku vid.

0

Jestem zainteresowany tematem, niestety kompletnie się nie znam na tych kodach. Wiem jednak ze dla TV Viera z obsługą LAN otworzono specjalne forum developerskie w którym programiści mogą zasięgnąć porad PANASONICa. Może prościej napisać jakiś program do nagrywania obrazu w dowolnym formacie, pomijając systemowy record i jego kody:) Umieścić go w rozwijającym się MARKET'cie. Co wy na to?

Moja fantazja nie zna granic, lecz jeżeli można w tak szybkim czasie utworzyć program skype picca i wiele innych, to dlaczego nie program do nagrywania?

0

Popatrzyłem się trochę w te liczby i chciałbym kolegę trochę naprostować.

Struktura tych plików jest znacznie prostsza:)

Pierwsze 8 bajtów nagłówek. Następnie dane są w 64 bitowych (2x 32 bity) porcjach.
Piewsza porcja to dwa słowa 32 bitowe o wartości 0x0
Potem są kolejne dane po dwa słowa 32 bitowe (4bajty). Pierwszy jest jakimś adresem, może offsetem zapewne ramki, drugi, hmmm może długością tej ramki. Wielkości te są podane w jakichś jednostkach, może blokach ??

Doskonale to widać w pliku 1084_00.vid

W pliku aid druga liczba wygląda nieco inaczej nadal rośnie proporcjonalnie do "czasu" jednak jest dosyć spora lub ujemna .. tez nie bardzo wiem do czego to przypiąć.


I na koniec pierwsze liczby w obu plikach są jednakowe jakby wskazywały na tę samą ramkę.

Na koniec pobawiłem się nieco kalkulatorem, i wyszło że pierwsza liczba pokrywa się MNIEJ WIĘCEJ z liczbą bloków o rozmiarze 188 bajtów

0

willyvmm dokładnie to pisałem wyżej, 8 bajtów == 64 bity

willyvmm napisał:

Na koniec pobawiłem się nieco kalkulatorem, i wyszło że pierwsza liczba pokrywa się MNIEJWIĘCEJ z liczbą bloków o rozmiarze 188 bajtów

Jesteś pewny? też próbowałem to jakoś przyrównać do rozmiaru, ale zaczyna coś wychodzić dopiero przy założeniu te tts ma jakiś nagłówek, mimo tego nie było to wystarczająco dokładne.

0

Taniej wyjdzie kupić używaną nagrywarkę DVD z twardym dyskiem i nagrywać co się chce. Nie wiem po jakiego grzyba Panasonic wprowadził takie udziwnienia. Pewno, żeby przypadkiem ludziska materiałów video nie rozpowszechniali.

0

Napisałem prosty programik do liczenia entropii, oto rezultat pierwszych 524 kB z pliku 1082_00.tts:


Są 4 poziomy entropii, ciekawie wyglądają 2 najniższe poziomy, zostało tylko porównać to z plikami aid jak i vid.

0

Możesz je zliczyć ?

0

Pewnie że tak[liczone z całego pliku]:

Przy czym to jest tylko entropia dla kolejnych 16 bajtów, "elementy" o tej samej entropii nie muszą być takie same.

Punkty o niższej entropii trzeba przejrzeć w edytorze hex, sprawdzić czy są podobne, jeśli tak i ich liczba pasuje do pierwszego licznika to można będzie coś robić dalej.

Program do zliczania:

0

Do skynet_2 i willyvmm:
Przyznaję się bez bicia , zaczynacie mówić o rzeczach, o których mam znikome pojęcie. Ale już przynajmniej wiem (albo mi się zdaje) co to są poziomy entropii (http://securitymag.pl/entropia-%E2%80%93-pomiar-i-zastosowanie). Nie będę Wam przeszkadzać i będę na swój rozum analizował Wasze spostrzeżenia, może też coś mi zaświta, ale zajmie mi to pewnie o wiele więcej czasu niż Wam. A jeżeli będziecie potrzebować jakiś dodatkowych danych, plików, prób na telewizorze itp. to jestem do usług i posłusznie wykonam.
A na razie świta mi tylko wniosek, że pliki AID oraz VID mogą służyć jedynie do wskazania odtwarzaczowi z którego miejsca należy rozpocząć ponownie odtwarzanie jeżeli wcześniej przerwaliśmy oglądanie materiału np. w połowie – czyli Trick Mode o którym wspomniał pandy. Czy wg Was w plikach tych (AID, VID) mogą być jeszcze zawarte jakieś informacje służące do odkodowania strumienia danych w pliku TTS - coś w rodzaju offsetu albo klucza dekodującego ?

Cytat:

W pliku aid druga liczba wygląda nieco inaczej nadal rośnie proporcjonalnie do "czasu" jednak jest dosyć spora lub ujemna .. tez nie bardzo wiem do czego to przypiąć.

Wartości ujemne to być może wynik błędów w stopie bitowej podczas odbioru sygnału DVB. Starałem się robić nagrania z jak najlepszym jakościowo sygnałem, ale zawsze jakiś błąd w transmisji mógł się wkraść. Nagrania podczas odtwarzania na TV „zachowują” się tak, że jeżeli wystąpił błąd w odbiorze sygnału, to najpierw mamy ciszę w audio (nie ma żadnych trzasków) a dopiero po około 0.5s zakłócenia w obrazie (typowe makrobloki lub pozostałości po poprzednich ramkach). Inna ciekawostka objawia się przy przyspieszonym podglądzie nagranego materiału - jeżeli materiał ma dużo błędów do mamy dużo makrobloków na obrazie przy normalnej prędkości odtwarzania, ale jeżeli przyspieszymy materiał to wszelkie makrobloki znikają i na podglądzie mamy materiał bez jakichkolwiek makrobloków (???).
Warto też pamiętać, że w TTS mogą być zawarte napisy czy dodatkowa ścieżka audio, ale we wszystkich nagraniach które zamieściłem nie ma nic takiego.

Cytat:

Dodatkowo nagranie testowe[1082] zawiera znacznie mniejsze różnice[porównując do 1084] w liczniku pomiędzy kolejnymi sekundami, można by z tego wywnioskować że pierwszy licznik to współrzędne początków klatek[/pakietów] w tts, końcówka licznika w 1084 jest ok 10x większa od 1082 podobnie jak rozmiar pliku tts który również jest 10x większy.
(...)
Dla nagrania testowego pomiędzy klatkami I rozmiary klatek P[zawierających informacje o ruchu] będą bardzo małe, skoro rozmiar klatek I jest stały a P pomijalny, odległość do klatki I będzie bardzo mała, również dźwięk jest stały.
Przy nagraniu dynamicznych rozmiary klatek będą znacznie różnić się rozmiarem zarówno I jak i P, więc tutaj te wartości również będą większe.
Ale to tylko luźne przypuszczenie co do bajtów[4:7] w pliku vid.

Znalazłem w swoich archiwach nagranie w HD, może uda się Wam zauważyć różnice w stosunku do sygnału SD i okażą się one pomocne w dalszej analizie. Ja na razie zauważyłem znacznie większe przyrosty w pierwszym liczniku -> obraz HD = więcej danych = większy przyrost. Pliki w HD mają numer 15_00 - pliku TTS na razie nie zamieszczam, ponieważ ma około 670MB (czas trwania 10m 34s) i obawiam się o swój transfer na stronie.



Wczoraj do 1:00 (czyli jeszcze dziś) testowałem dystrybucje Linuxa ze współpracą UFS/UFS2 w trybie zapis/odczyt (Read/Write). Po męczarniach z FreeBSD, FreeSBIE, OpenBSD, INSERT (Inside Security Rescue Toolkit) w końcu zbawieniem okazał się najnowszy poczciwy Knopix Live CD. Udało się zamontować dysk i dokonać na nim zmiany. Poniżej zdjęcie ze zmienioną nazwą nagrania. Czyli możemy już modyfikować zawartość poszczególnych bajtów w dowolnym pliku i sprawdzić jak zareaguje na to TV podczas odtwarzania nagrania. W między czasie będę robił próby - sprawdzę jakie zmiany, w których plikach i na których bajtach dokonuje TV, sam pozmieniam inne podejrzane bajty i sprawdzę co na to „powie” TV.


Niestety analiza schematu ideowego nie przyniosła, żadnych obiecujących wniosków. USB jest bezpośrednio obsługiwane przez procesor i to zapewne w nim dochodzi do programowego generowania plików DAT, AID, VID i TTS (str. 34 manuala). A KEY zapisywany jest zarówno w procesorze jak i w dodatkowej pamięci EEPROM (to tak na marginesie). Wg manuala (str. 10) w modelu TX-PR42G20 nie jest stosowany KEY dla nagrań na dysku USB. I nawet gdzieś znalazłem wzmiankę, że ktoś już próbował wgrać do TX-P42G20 soft od TX-PR42G20 ale skończyło się to nieciekawie - TV przestał odpowiadać.
Wpadł mi za to do głowy pomysł aby zadać TV jakiś czysty sygnał z generatora sygnału DVB-T (z innych wejść TV nie pozwala na nagrywanie), np. idealnie czarną, białą, czerwoną, niebieską i zieloną planszę bez audio i przyjrzeć się takim plikom. Ale porządny generator DVB to koszty rzędu kilu tysięcy zł. a zrobiony własnoręcznie pewnie będzie niedoskonały (http://news.elektroda.pl/generator-testowy-dvb-t-t463730.html). Może ktoś w Szczecinie posiada takowe cudo i byłby w stanie wspomóc ?

Do lisek:
Idąc po schodach wspinamy się coraz wyżej i wyżej, a po drodze uczymy się oraz zdobywamy wiedzę. Być może w końcu spadniemy z tych schodów, ale zdobyta wiedza pozostanie. A mi (i innym użytkownikom serii Viera) pozostanie wtedy pokornie kupić jakąś nagrywarkę (jak zaproponował marek-zarzycki) i olać zabezpieczenia Panasonica.

Do jynjeay:
Sądzę, że Panasonic (nie udostępni potrzebnych informacji) nie pozwoli stworzyć aplikacji do nagrywania. Powód ? To o czym wspomniał marek-zarzycki: prawa autorskie itp. I właśnie dlatego Panasonic w taki sposób uniemożliwił użytkownikom swoich telewizorów, swobodne operowanie nagraniami programów.

0

@jaco777 spróbuj użyć fedory[ Link ] do UFS/UFS2 wsparcie tego powinno być w jądrze.

jaco777 napisał:

Czy wg Was w plikach tych (AID, VID) mogą być jeszcze zawarte jakieś informacje służące do odkodowania strumienia danych w pliku TTS - coś w rodzaju offsetu albo klucza dekodującego?

Wątpliwe, ale poznanie pozycji pakietów/klatek bardzo by pomogło.

Czy mógłbyś nagrać[3 razy] czarny ekran z wyłączonym dźwiękiem? potem mógłbym to przepuścić przez komparator ciągów binarnych.

Entropia jest przydatna, bo od razu widzisz czy plik ma jakieś części.

Co do szyfrowania jest to pewnie coś prostego, nie zmieniającego długości danych, może nawet jakiś XOR + licznik.
Mogę się mylić, ale wydaje mi się że przy tym transferze[np. zapis HD] szyfrowanie musi być bardzo szybkie == proste.

0

skynet_2 napisał:

Co do szyfrowania jest to pewnie coś prostego, nie zmieniającego długości danych, może nawet jakiś XOR + licznik.
Mogę się mylić, ale wydaje mi się że przy tym transferze[np. zapis HD] szyfrowanie musi być bardzo szybkie == proste.

Nie wiem jaki procesor tam użyto, ale współczesne procesory posiadają koprocesory kryptograficzne więc szyfrowanie strumieniowe nie wpływa na ich wydajność.

0

Do skynet_2
Knoppix (już nawet na pamięci USB) działa jak należy, wystarczają dwie linijki w konsoli do montowania dysku i śmiga. Tak jak wspomniałem, bez problemu można już modyfikować zawartość plików, podmieniać je itp. Pełna obsługa Read/Write UFS2.

Cytat:

Wątpliwe, ale poznanie pozycji pakietów/klatek bardzo by pomogło.

W pełni się z Tobą zgadzam. Wczoraj zaglądałem do normalnych (nie kodowanych) plików TS, TTS i też doszedłem do wniosku, że znajomość pozycji i rozmiaru zakodowanych pakietów będzie podstawą żeby coś dalej działać. A pliki AID i VID będą w tym przypadku dobrym źródłem. Jestem w trakcie zapoznawania się ze specyfikacją strumieniowania TS/TTS i jeszcze trochę mi to zajmie, ale jakieś podstawy teoretyczne muszą być, więc czytam, i czytam...

Cytat:

Czy mógłbyś nagrać[3 razy] czarny ekran z wyłączonym dźwiękiem? potem mógłbym to przepuścić przez komparator ciągów binarnych.

Też bym tak chciał , tylko skąd wziąć taki sygnał DVB ? Telewizor pozwala na nagrywanie tylko kanałów nadawanych cyfrowo. Pozostaje tylko wspominany już generator testowego sygnału DVB. Hmmm... a może na którejś satelicie jest taki "pusty" kanał, natknął się ktoś z forumowiczów na takowy ? Musiałbym zainwestować w talerz i konwerter, ale co tam, jak szaleć to szaleć .
A Twoja sugestia o prostym szyfrowaniu również przewija się na innych forach - inni także uważają, że musi to być coś w miarę prostego aby w locie mogło działać płynnie.



Do willyvmm

Cytat:

Nie wiem jaki procesor tam użyto, ale współczesne procesory posiadają koprocesory kryptograficzne więc szyfrowanie strumieniowe nie wpływa na ich wydajność.

Tutaj http://www.hackerboard.de/cryptography-encryption/41849-verschluesselung-knacken-von-tv-aufnahmen-panasonic-gw20-v20.html#post313612 coś wspominają o procesorze i użytym Linuxie, nie ma też chyba zaimplementowanego typowego szyfrowania. Nie są to informacje w 100% pewne dlatego będę jeszcze szukał w innych źródłach aby mieć pewność co siedzi w TV.
Poniżej tłumaczenie z translatora:

Cytat:

cześć

Interesuję się również możliwość wykorzystania nagrań, i google trochę.

Oto, co myślę, że znalazł się - jeśli wszystko jest prawdziwe również dla GW20 serii, ale nie mogę potwierdzić w tej chwili.

- Panasonic Viera TV najwyraźniej użyć Matsushita rodziny mikrokontrolerów AM34 (którego specyfikacja została utworzona w 2002 r.)

Matsushita AM34 mikroprocesor
32b rdzenia mikroprocesora RISC dla telewizji cyfrowej SoC zajmuje 14,8 mm 2 w 0.13μm CMOS z sześciu warstw Cu. Rdzeń pracuje z 400MHz z 500mW średnio rozpraszanie na 1.35V. Zintegrowany 4.0GB / s 3 × 4 cross-bar przełącznik autobus poprawia ciągłość pracy wydajność systemu o 1,75 razy

http://www.panasonic.com.sg/panasoni...?ContentId=142

Istnieje najwyraźniej w tym dual-core wersji, która jest prawdopodobnie AM34_2 wewnętrznie.

Działa dystrybucji Linuksa: Linux AM. Część kodu źródłowego może wyglądać tutaj:

http://www.am-linux.jp/dl/EUIDTV7/

Od tego jest ograniczona do (w pliku konfiguracyjnym):
Linux kernel version: 2.6.11.12
Config_Crypto not set
Config_CRC32 = yes
zlib_inflate=yes
zlib_deflate=yes
# CONFIG_NTFS_FS is not set [leider!]
CONFIG_SMP=yes
CONFIG_NR_CPUS=2
CONFIG_AM34_2=yes

Można sobie wyobrazić, że aktualizacje oprogramowania będą rozpakowane z zlib crc32 i sprawdzić, zanim zostaną one zainstalowane. Ale możemy tylko się domyślać.

Ponadto, najwyraźniej modułu kryptograficznego nie jest wkompilowana w jądro.

Istnieje między innymi cryptlib zwane biblioteka, która obsługuje również AM34 architektury:

http://www.cryptlib.com/downloads/manual.pdf
embedded Systems
wysoki poziom cryptlib w konfigurowalności i przenośność czyni go idealnym do zastosowania w
systemów wbudowanych z ograniczonych zasobów lub wymagań specjalnych, w tym te, oparte na ARM7, ARM9, ARM TDMI, Fujitsu FR-V, Hitachi SuperH, MIPS IV, V MIPS, Motorola ColdFire, NEC V8xx serii NEC VRxxxx serii Panasonic / Matsushita AM33 / AM34, PowerPC, Samsung CalmRISC, SH3, SH4, Sparc, sparc lite, StrongArm, TI OMAP oraz procesory Intel XScale. cryptlib nie wykonuje żadnych operacji zmiennoprzecinkowych i działa bezpośrednio na procesorach bez FPU.

Czy to zawsze jest do wykorzystania, ale nie mogę powiedzieć.

Cóż, to już teraz - Feieraband!

Na koniec dodam tylko, że z wstępnych moich obserwacji, wynika że telewizor potrafi chyba odtworzyć plik TTS nawet bez plików AID i VID - ale to tylko przypuszczenia, muszę się jeszcze upewnić.

0

Co prawda nie ma podłączonego dysku i nie wiem co się nagra ale co do pustego czarnego ekranu to zaraz po przełączeniu wciśnij Hold (pod niebieskim) głos też można wyłączyć Mute.

0

Czyli nagrywanie na pendriva 8 gb nie jest mozliwe musze miec dysk min 160 gb czy tak ?

0

Samuraj napisał:

Co prawda nie ma podłączonego dysku i nie wiem co się nagra ale co do pustego czarnego ekranu to zaraz po przełączeniu wciśnij Hold (pod niebieskim) głos też można wyłączyć Mute.

Mini bug działa ale mimo, że mamy czarny ekran i brak głosu to audycja nagrywa się normalnie (obraz i dźwięk).

BENYZBYSZEK napisał:

Czyli nagrywanie na pendriva 8 gb nie jest mozliwe musze miec dysk min 160 gb czy tak ?

Tak. Wystarczy przeczytać instrukcję obsługi - str. 56. Proszę nie zadawać takich podstawowych pytań i w dodatku nie powiązanych z poruszanym problemem (Regulamin).

pandy napisał:

Gdybym szukal zaleznosci - korelacji, uzylbym zwyklego odbiornika DVB-T na USB, zgral dokladnie ten sam program, przeanalizowal TS, wydzielil elementarne video, jesli beda User Data w MPEG-2 tym lepiej (H.264 jest troche gorzej bo nie ma az takiej ilosci narzedzi do analizy strumienia elementarnego ale zasada podobna jest do MPEG-2) Majac znany strumien odebrany przy pomocy DVB-T na USB mozecie probowac znalezc podobna struktura w plikach z TV.

Ciekawa propozycja i sądzę, że warta głębszej analizy. Mam jedynie wątpliwość, że dekoder DVB na USB zapisze mam strumień w typowym rozmiarze pakietów, czyli jak wspomniałeś 188/204 a TV Panasonic będzie zapisywał pakiety w innym rozmiarze a co gorsze może nawet ze zmiennym rozmiarem pakietów (chociaż nie jestem pewien czy standard to przewiduje). I w takiej sytuacji porównywanie strumienia z DVB USB a TV Panasonic kompletnie się "rozjedzie". Ale to są moje przypuszczenia - niestety nie mam jeszcze takiej wiedzy jak Ty, a widzę że sporo wiesz. Ja się dopiero zagłębiam w DVB, MPEG, TS i to jest moja słaba strona, mogę błądzić.



A ja nadal analizuję czy i co TV robi z plikami DAT, AID, VID, TTS. Ale trochę to jeszcze zajmie - w końcu każdy z Nas ma rodzinę, pracę, życie prywatne...

0

Tak jak obiecywałem, posiedziałem trochę przy nagraniach i poniżej tego efekty w formie Podsumowania. Są to bardziej podstawy sposobu obsługi nagrań i plików przez TV niż informacje przydatne do zdekodowania strumienia z plików TTS. Ale to też się może przydać, zwłaszcza że świta mi już w głowie program na PC do zarządzania nagraniami z TV.

PODSUMOWANIE

1. Dane z dysku sformatowanego przez TV Panasonic Viera (HDD TV) możemy odczytać pod WinXP za pomocą programu UFS Explorer lub odczytać/zapisać za pomocą jakiegoś najnowszego Linuxa z obsługą UFS (np. Knoppix Live CD).

2. Tak skopiowane pliki (o rozszerzeniu DAT, TTS, VID, AID) możemy zarchiwizować na innym dysku (FAT32, NTFS) i później ponownie nagrać na HDD TV aby je obejrzeć.

3. Dysk możemy formatować ile chcemy, nie ma to wpływu na kodowanie pliku TTS ani na późniejsze ponownie nagrywanie/odtwarzanie z niego zarchiwizowanych nagrań. TV formatuje dysk w systemie plików UFS2, formatowany dysk musi mieć minimalną pojemność 160GB.

4. Nie możemy zmieniać nazwy/numeru pliki, ponieważ TV wtedy nie odtworzy nagrania. Wg mnie nazwa pliku, czyli jego numer jest brany przy kodowaniu/dekodowaniu pliku TTS.

5. Na HDD TV możemy znaleźć następujące stale występujące pliki:

5.1 plik .journal o stałym rozmiarze 4 194 304 bajtów, jest to plik systemu plików UFS2 – nie ruszamy go, plik oczywiście nie istotny przy kodowaniu/dekodowaniu pliku TTS,

5.2 plik hdd_cleaner o stałym rozmiarze 4 bajtów, tworzony jest chyba po pierwszym kasowaniu jakiegoś nagrania, plik mało istotny, nie uczestniczy przy kodowaniu/dekodowaniu pliku TTS (patrz pkt. 3),

5.3 plik hdd_dummy_file o stałym rozmiarze 4 bajtów i zawartości 00 00 00 00, tworzony jest przy każdym formatowaniu, plik mało istotny, nie uczestniczy przy kodowaniu/dekodowaniu pliku TTS (patrz pkt. 3),

5.4 plik last_pos_hdd o stałym rozmiarze 4 bajtów, plik jest tworzony przy pierwszym nagraniu i zawiera wartość startową 00 00 00 01, wartość ta przyrasta w miarę przyrostu nagrań na HDD. Zapis następuje w HEX i należy go odczytać jako DEC aby uzyskać numer ostatniego istniejącego pliku nagrania, czyli jeżeli w pliku last_pos_hdd mamy 00 00 41 21 to w DEC będzimy mieli 1057 i to jest numer ostatniego istniejącego pliku nagrania. Plik istotny przy nagrywaniu zarchiwizowanych nagrań na nowo sformatowany HDD – zawartość pliku należy tak wyedytować aby jego cztery bajty odczytane w DEC były równe numerowi naszego najwyższego numerowo pliku nagrań z archiwum. Czyli jeżeli mamy w archiwum pliki nagrań o numerze 1057, musieliśmy sformatować HDD i chcemy teraz nagranie o tym numerze obejrzeć na TV, to po zapisaniu plików nagrań o numerze 1057 na HDD, należy w pliku last_pos_hdd wpisać 00 00 42 21 dzięki czemu TV nada następnemu plikowi nagrań numer 1058 i zapobiegnie to zdublowaniu w nazewnictwie/numeracji plików nagrań. Plik last_pos_hdd nie uczestniczy przy kodowaniu/dekodowaniu pliku TTS (patrz pkt. 3),

5.5 plik bind o stałym rozmiarze 32 bajtów, plik jest tworzony przy formatowaniu i nie zmienia się do następnego formatowania, zawartość pliku jest chyba generowana losowo, nie uczestniczy przy kodowaniu/dekodowaniu pliku TTS (patrz pkt. 3),

6. Oprócz wymienionych w pkt. 5 plików są oczywiście pliki powstające tylko przy nagrywaniu programu telewizyjnego:

6.1 plik z rozszerzeniem DAT o stałym rozmiarze 452 bajtów – zawiera dane informacyjne o nagrywanym programie telewizyjny takie jak data i godzina rozpoczęcia nagrania, tytuł programu telewizyjnego, nazwa stacji telewizyjnej, znacznik informujący czy już oglądaliśmy to nagranie. Pełna i dokładna rozpiska bajtów w pliku DAT poniżej, bajty nie opisane są raczej nieistotne. Plik DAT możemy dowolnie podmieniać z plikami DAT z innych nagrań i nic się nie stanie oprócz niewłaściwie wyświetlanych informacjach – dowodzi to, że plik DAT nie jest istotny przy kodowaniu/dekodowaniu pliku TTS,


6.2 pliki z rozszerzeniem AID oraz VID, rozmiar tych plików zawsze jest równy sobie i zależny jest od długości całego nagrania. Służą one do prawidłowego „indeksowania” zawartości pliku TTS (tzw. trick mode) dzięki czemu możemy na podglądzie przewijać nagranie do przodu i tyłu z różną prędkością. Jeżeli usuniemy pliki AID, VID to nagranie możemy dalej oglądać, ale przewijanie działa tylko z najniższą prędkością (skok co około 1 sek.) - dowodzi to, że pliki AID, VID także nie są istotne przy kodowaniu/dekodowaniu pliku TTS,

6.3 plik z rozszerzeniem TTS zawiera zakodowany strumień audio i wideo, w kodowaniu ważna jest z dużym prawdopodobieństwem nazwa/numer pliku (patrz pkt. 4) oraz tzw. KEY (patrz str. 10 service manual TX-PF42G20S.pdf). Plik najistotniejszy dla nas, którego sposób kodowania próbujemy rozpracować.

6.4 plik z rozszerzeniem RSP o stałym rozmiarze 16 bajtów, powstaje tylko wtedy gdy przerwaliśmy oglądanie jakiegoś nagrania, służy do rozpoczęcia oglądania nagrania od momentu w którym przerwaliśmy oglądanie. Plik nie istotny przy kodowaniu/dekodowaniu pliku TTS.

6.5 plik LOOP.TTS powstaje gdy mamy aktywną funkcję REW LIVE TV, to po prostu nagranie powstające na bieżąco podczas oglądania programu telewizyjnego, dzięki któremu możemy pauzować i przewijać do tyłu właśnie oglądany program. Plik oczywiście nie istotny przy kodowaniu/dekodowaniu pliku TTS.

7. Z powyższych punktów wynika jak na razie, że z dużym prawdopodobieństwem składowymi kodowania pliku TTS są:
- jego nazwa/numer (czyli zapewne 4 bajty – patrz pkt. 5.4),
- KEY generowany przez TV. Rozmiar KEY nie jest mi znany – siedzi on w EEPROMie który można odczytać za pomocą szyny I2C (mój TV jest jeszcze na gwarancji więc nie będę na razie w nim grzebał).

pandy napisał:

Dlatego mowie o tym by szukac danych na podstawie zawartosci jednego ze strumieni elementarnych - wystarczy z nagranego TS (przy pomocy DVB-T USB) wydzielic jeden strumien elementarny video, nastepnie przeszukac go np na okolicznosc SEI/VUI (nie wiem jak nadaja operatorzy w PL)

Rozpowszechniam prośbę wśród swoich znajomych. Jak już będą jakieś pliki to je umieszczę i dam znać. A tymi ostatnimi linkami to mnie "zabiłeś" - chyba prędzej się zestarzeję niż to wszytko pojmę. Ale dzięki, może coś więcej zrozumiem.

0

Ciekawe nazwa pliku wydaję się związana z szyfrowaniem.

Czy mógłbyś wykonać test?
1. usunąć partycję i pozwolić TV sformatować dysk
2. nagrać plansze testową
3. zarchiwizować wszystko używając programu tar
4. powtórzyć punkty 1 2 3
5. podmienić tts używając pierwszego który został zarchiwizowany
6. sprawdzić czy TV odtwarza podmienione + udostępnić 2 archiwa tar

archiwizowanie:

ls - wyświetla pliki w aktualnym katalogu
$(date +'%s') - zwraca datę[liczbę sekund od 00:00:00 01.01.1970]

Teoretycznie początki plików tts powinny być takie same w obu nagraniach, gdyż będą miały taki sam numer.

TV zawsze na czystym dysku zaczyna nazywać pliki od tego samego numeru?

0