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.
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”

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

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.