Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Europejski lider sprzedaży techniki i elektroniki.
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Panasonic Viera i zdekodowanie/odszyfrowanie nagrań z HDD USB

jaco777 01 Gru 2011 22:36 48413 52
  • #31 01 Gru 2011 22:36
    jaco777
    Poziom 24  

    Do skynet_2:
    Myślimy podobnie - od razu gdy się upewniłem, że nazwa pliku TTS ma wpływ na jego dekodowanie, zacząłem kombinować co by tu zrobić aby uzyskać dwa pliki TTS o takiej samej nazwie i z tym samym sygnałem wejściowy (czyli plansza testowa). Rozwiązania są dwa: pierwsze to formatowanie, po którym licznik plików zawarty w pliku DAT jest resetowany i tworzenie plików na czystym HDD zaczyna się zawsze od numeru 0 (zero), a drugi to ręczne wyzerowanie licznika w pliku DAT. Obydwa sposoby oczywiście już wypróbowałem i mój entuzjazm trochę opadł. Niestety brak zauważalnych analogii w plikach o tych samych numerach. Przykładowe nagrania (o tych samych numerach) po formatowaniu HDD zamieściłem w katalogach from HDD format 01-03 a nagrania (o tych samych numerach) tworzone po ręcznym resetowaniu licznika w pliku DAT (bez formatowania) sukcesywnie zamieszczę w katalogach from HDD no format, reset counter in DAT 01-03.

    Wpadłem też na pomysł aby przepełnić licznik w pliku DAT i mieć nadzieję, że TV wyrzuci jakiś błąd/zacznie debugować i przy okazji będzie można się zorientować co za soft/Linux siedzi w środku. Niestety też nic z tego – po osiągnięciu wartości FF FF FF FF licznik został wyzerowany przy tworzeniu następnego nagrania i to powstające nagranie zostało dołączone do już istniejącego (czyli do istniejących już plików 0_00.aid, 0_00.vid, 0_00.tts zostały "dotworzone" pliki 0_01.aid, 0_01.vid, 0_01.tts i te dwie osobne grupy plików są odtwarzane jako jedno ciągłe nagranie).

    skynet_2 napisał:

    5. podmienić tts używając pierwszego który został zarchiwizowany
    6. sprawdzić czy TV odtwarza podmienione + udostępnić 2 archiwa tar

    Plikami TTS można żonglować jak się chce, utworzyć/nagrać > przenieść na inny HDD > sformatować HDD TV > znowu nagrać na HDD TV > plik TTS będzie nadal prawidłowo odtwarzany przez TV - oby tylko nie zmieniać nazwy/numeru pliku TTS. Próbę i archiwa o które prosisz oczywiście zrobię, ale raczej w weekend, trochę czasu mi teraz brak.


    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)
    nastepnie przeszukac pod katem identycznej struktury plik vid z Panasonica.
    Jesli sie to uda znalezc to potem bedzie latwiej ustalic wielkosc pakietu i strukture.

    Nagrania planszy testowej w formie jawnej już mam. Pochodzą one z nagrywarki CableTech URZ0083 i umieściłem je w katalogu from CableTech URZ0083. Pliki 000.ts oraz 001.ts to plansza testowa a plik 015.ts to nagranie niestatyczne z Polsat Sport. Strumienie spróbuję z nich wyciągnąć i poszukam tych SEI/VUI – ale też dopiero w weekend.

  • #32 02 Gru 2011 21:18
    dzebrys
    Poziom 11  

    jaco777 napisał:
    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ć.


    szedlem tym tropem, zapytalem na jakims forum w ru i wersje PR* nie maja mozliwosci nagrywania na HDD. stad brak KEY'a.

    swoja droga potrzebuje zawartosc peak eprom z modelu G30. jesli ktos z was bylby uprzejmy nagrac mi go [plik video nagrany telefonem lub podobnie] poprzez hex edytor w service menu to bylbym bardzo wdzieczny. prosze o kontakt na priv. probuje zmodowac S30 na G30. zmiana modelu w w/w flashu powoduje ze tv rozpoznawany jest jako g30, ma dlna, jest isff, ale nagrywanie nie dziala. niby jest dostepne, widzi dysk i mozna wlaczyc nagrywanie ale nie sa tworzone zadne pliki na dysku. powodem jest zapewne brak wygenerowanego klucza. robilem na nowo generacje przez SELF CHECK ale nie chce zadzialac. chcialbym sprawdzic czy flaga do generacji nie jest zapisana w w/w epromie.

    pozdrawiam
    piotr

  • #33 04 Gru 2011 21:45
    jaco777
    Poziom 24  

    Do dzebrys:
    Witam. Jeżeli chodzi o Twój problem, to proponuję dobrze przeszukać Elektrodę czy ktoś już tego nie próbował, a jak nie to załóż lub podepnij się do bardzo podobnego postu - będziesz miał większe szanse na odpowiedź.
    A skoro już tu jesteś to mam do Ciebie pytania:
    - jak dostać się bezpiecznie do edytora HEX, widziałem już go na pewnej stronie ale szczegółów brak ? Do menu serwisowego wiem jak wejść.
    - wiesz już w których komórkach pamięci jest KEY generowany przy SELF CHECK, jesteś w stanie podać nam jego długość (i przykładowy KEY w HEX)?


    skynet_2 napisał:

    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

    Zrobione.
    Ad. 3. Zrobiłem trzy formaty, a pliki umieściłem w katalogach from HDD format od 01 do 03 bez archiwizowania do TAR. Pakowanie plików TTS nie ma sensu, wychodzą jeszcze większe.
    Ad. 6. TV oczywiście odtworzył podmieniony TTS (starszy, przed formatem). Jak się spodziewałem jedynym problemem były pliki AID i VID (nowsze, po formacie) – bieżący licznik czasu pliku TTS wyświetlany przez TV zgłupiał, ale całkowita długość pliku TTS w sekundach była prawidłowo wyświetlana, nie działało przewijanie na podglądzie ale całe nagranie można było obejrzeć jeżeli nie użyło się przewijania. Wnioskuję z tego, że TV całkowitą długość nagrania pobiera (lub jakoś sobie wylicza) bezpośrednio z pliku TTS a pliki AID, VID służą mu tylko do "skakania" do poszczególnych bloków/ramek/klatek w nagraniu (to o czym już wiemy).


    skynet_2 napisał:

    $(date +'%s') - zwraca datę[liczbę sekund od 00:00:00 01.01.1970]

    Spakować się udało, ale zwracana data jest datą powstania archiwum a nie archiwizowanych plików - domyślam się, że o to Ci chodziło (dlatego nie zamieściłem archiwów). Dokładną datę powstania plików można odczytać z bajtów 9-12 w pliku DAT. Czyżbyś myślał o tym samym co ja – TV bierze pod uwagę czas/datę powstania nagrania przy kodowaniu/dekodowaniu ? Tylko musiałby tą wartość zapisywać w samym pliku TTS, bo zmiana czasu/daty w pliku DAT (tego z jawnie np. 4E D1 4C 2F, zapisanym czasem/datą) nie powoduje nieprawidłowego dekodowania pliku TTS. Przejrzałem pliki TTS i nie znalazłem w nich jawnie zapisanego czasu/daty powstania (w postaci czterech bajtów). Może te cztery bajty mają swoją stałą określoną pozycję w TTS i są zapisywane już jakoś przekształcone. Czyli teoretycznie TV przy dekodowaniu bierze pod uwagę numer/nazwę pliku TTS, czas/datę powstania zapisaną gdzieś w samym pliku TTS oraz KEY zapisany w pamięci EEPROM – zaczyna się robić nieciekawie, dwie zmienne które znamy (numer/nazwa pliku TTS, czas/data powstania) oraz jedna stała (KEY w EEPROM) które trzeba podstawić do jakiegoś wzoru.
    Być może trop czasu/daty zawartego w pliku TTS jest fałszywy, ale jeszcze trochę posiedzę nad tym i spróbuję coś znaleźć.


    skynet_2 napisał:

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

    Też miałem taką nadzieję. Niestety nie zauważyłem żadnych podobieństw w plikach TTS o tych samych numerach.


    skynet_2 napisał:

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

    Tak. Startuje od nagrania numer 0_00. Ten sam efekt można osiągną kasując plik last_pos_hdd oraz wszystkie dotychczasowe nagrania.

  • #34 05 Gru 2011 00:57
    skynet_2
    Poziom 26  

    jaco777 napisał:
    Ad. 3. Zrobiłem trzy formaty, a pliki umieściłem w katalogach from HDD format od 01 do 03 bez archiwizowania do TAR. Pakowanie plików TTS nie ma sensu, wychodzą jeszcze większe.
    Wychodzą większe bo tar dorzuca dane o właścicielu pliku, grupy, uprawnieniach, datach utworzenia i zmodyfikowania.
    jaco777 napisał:
    ... ale zwracana data jest datą powstania archiwum ...
    Dzięki temu archiwa tar będą miały różne nazwy i tyle.

    Co do braku plików tar, twój opis jak zachowuje się TV jest wystarczająco dokładny, prawdopodobnie wszystko jest w tts.

    Przejrzę to wszystko komparatorem binarnym jak znajdę chwilę czasu.

  • #35 27 Gru 2011 19:36
    pepe
    Poziom 23  

    W końcu znalazłem jaki system plików jest na dysku Panasonica.
    Mam do Was pytanie - czy jest możliwe podzielenie jednego dysku na UFS i NTFS, tak aby TV część UFS wykorzystywał do nagrań, a część NTFS pozostała dla mnie do odtwarzania innych materiałów. Sam tv bez problemu widzi dwie partycje NTFS jako dwa dyski, ale nie potrafię zrobić tak żeby podobnie widział UFS i NTFS .

  • #36 06 Sty 2012 00:37
    skynet_2
    Poziom 26  

    Sprawdziłem fragmenty plików tts używając operacji xor, delta i zamiany bitów, jak również ich kombinacji i nic to nie dało.

    Możliwe że szyfrowaniu poddawane są całe bloki[np. po 256B], ale liczba możliwych kombinacji jest zbyt duża aby to sprawdzić w rozsądnym przedziale czasu.

  • #37 08 Sty 2012 19:12
    jaco777
    Poziom 24  

    Do pepe:
    Niestety nie mam obecnie wolnego dysku większego niż 160GB aby przeprowadzić taką próbę. Ale z tego co czytałem na innych forach to raczej nic z tego. Będę tego pewien dopóki sam nie spróbuję - jak już będę coś wiedział to oczywiście napiszę.




    Do skynet_2:
    Dzięki za podjęcie się takowej analizy. Ja przez ten czas też nie próżnowałem. Postanowiłem przeprowadzić coś w rodzaju ręcznego ataku brutal force :shocked!: na plik TTS. Najpierw zmieniałem bajt po bajcie i sprawdzałem reakcję TV na tak zmodyfikowany plik. Gdy już miałem jakieś efekty to przyszła pora napisać programik w C który by ten proces usprawnił.

    Efekty mojego ataku w skrócie:
    - ważne jest pierwszych 16 bajtów, nie można ich modyfikować,
    - kolejne 160 bajtów jest nieistotne, można je wyzerować,
    - kolejne 32 bajty są ważne, nie można ich modyfikować,
    - kolejne 160 bajtów jest nieistotne, można je wyzerować,
    - kolejne 32 bajty są ważne, nie można ich modyfikować,
    (...) i tak pewnie do końca pliku.

    Jeszcze jestem w trakcie atakowania :-) pliku TTS. Finalne efekty i wnioski oczywiście zamieszczę.

  • #38 09 Sty 2012 01:01
    skynet_2
    Poziom 26  

    Musiało zająć ci to sporo czasu, takie bieganie z dyskiem od PC do TV :)

    160+32=192 a pandy wspominał o 188 do 208 bajtach na pakiet, być może to strzał na ślepo ale warto to sprawdzić.

    Poza tym 192 to jeden z kilku dzielników całkowitych dla długości plików tts, których wynik jest liczbą całkowitą.

    @jaco777 jak potrzebujesz jakiś program, to opisz co ma on robić, w pythonie napisze to błyskawicznie.

  • #39 23 Sty 2012 20:09
    jaco777
    Poziom 24  

    Witam. Wreszcie udało się przeprowadzić wystarczającą ilość prób i testów abym mógł napisać kolejne wnioski. Tym razem będą one dotyczyć pliku TTS.

    Prawdopodobna struktura pliku wygląda jak poniżej na obrazku:
    - plik zawiera bloki po 192 bajtów każdy, nazwijmy je umownie kompletnym blokiem 192 bajtów,
    - kompletny blok 192 bajtów składa się kolejno z bloku 16 bajtów początkowych, bloku 160 bajtów danych audio/video i bloku 16 bajtów końcowych.

    Panasonic Viera i zdekodowanie/odszyfrowanie nagrań z HDD USB

    Teraz postaram się w miarę zrozumiale opisać co robiłem z poszczególnymi bajtami i blokami bajtów w pliku TTS i jak reagował na to TV.

    1. Zmieniamy wartość któregokolwiek bajtu w bloku 16 bajtów początkowych:
    - efekt : TV nie odtworzy (przerwie odtwarzanie) pliku TTS od miejsca zmiany,
    - wniosek : blok 16 bajtów początkowych jest istotny przy deszyfracji.

    2.1 Zmieniamy wartość któregokolwiek bajtu w bloku 160 bajtów audio/video:
    - efekt : TV odtwarza plik TTS bezproblemowo,
    - wniosek : jest to prawdopodobnie blok z danymi audio/video.

    2.2 Zmieniamy wartość wszystkich bajtów w bloku 160 bajtów audio/video np. na HEX : 00 (lub dowolną inną):
    - efekt : TV odtwarza plik TTS bezproblemowo,
    - wniosek : j/w.

    2.3 Czynność z pkt. 2.2 wykonujemy np. dla 100 000 kolejnych takich bloków w dowolnym miejscu pliku TTS (jak na dole w powyższym obrazku),
    - efekt : TV odtwarza plik TTS bezproblemowo, a w miejscach wyzerowanych bloków mamy czarny obraz i brak dźwięku – nagranie nadal jest odtwarzane, nie działa jedynie przewijanie na podglądzie, nie zmienia się licznik czasu,
    - wniosek : j/w + blok 160 bajtów audio/video występuje zawsze w takim rozmiarze niezależnie od typu nagrania : video SD lub HD, audio stereo lub 2.1 DD,

    3. Zmieniamy wartość któregokolwiek bajtu w bloku 16 bajtów końcowych:
    - efekt : TV nie odtworzy (przerwie odtwarzanie) pliku TTS od miejsca zmiany,
    - wniosek : blok 16 bajtów końcowych jest istotny przy deszyfracji.

    4. Usuwamy całkowicie (nie zerujemy) z pliku TTS którykolwiek z kompletnych bloków 192 bajtowych lub blok 16 bajtów początkowych lub blok 160 bajtów audio/video lub blok 16 bajtów końcowych a także dowolną kombinację/wariację wymienionych bloków i ich wielokrotność,
    - efekt : TV nie odtworzy (przerwie odtwarzanie) pliku TTS od miejsca usunięcia bloku/bloków,
    - wniosek : ciągłość i obecność wszystkich bloków jest konieczna do dalszej deszyfracji, nie można nawet usunąć bloku 160 bajtów audio/video (możemy tylko wyzerować). Możemy usunąć w ten sposób zbędną końcówkę z pliku TTS (np. reklamy po audycji) ale nie możemy usunąć zbędnego początku z pliku TTS.





    5. Zamieniamy miejscami między sobą dwa kompletne bloki 192 bajtów:
    - efekt : TV nie odtworzy (przerwie odtwarzanie) pliku TTS od miejsca zamiany bloków,
    - wniosek : prawidłowa kolejność wszystkich bloków jest konieczna do dalszej deszyfracji.

    Wnioski ogólne (prawdopodobne):
    - do deszyfracji istotne są bloki 16 bajtów początkowych i końcowych (patrz pkt. 1, 3, 4),
    - przy deszyfracji ważna jest kolejność, ciągłość i obecność kompletnych bloków 192 bajtowych (patrz pkt. 4, 5) i wygląda na to, że deszyfracja odbywa się sekwencyjnie blok po bloku, przy czym do prawidłowego deszyfrowania kolejnego kompletnego bloku potrzebny jest kompletny blok go poprzedzający, ale w bloku kompletnym 192 bajtowym nie są istotne wartości z bloku 160 bajtów audio/video (patrz pkt 2.1, 2.2, 2.3), a jedynie wartości z bloków 16 bajtowych początkowych i końcowych (ktoś zrozumiał co miałem na myśli :-) ?),
    - rozmiar kompletnego bloku 192 bajtów jest stały i nie zależy od rozdzielczości materiału video czy ilości ścieżek audio.

    Na obecną chwilę doszedłem do takich wniosków. Jeżeli rzeczywiście coś zagmatwałem i napisałem niezrozumiale to pytajcie. W międzyczasie poczytałem też o dotychczas stosowanym szyfrowaniu strumieni MTS/M2TS i przewija mi się szyfrowanie AES (http://en.wikipedia.org/wiki/Advanced_Access_Content_System) w którym też stosuje się odpowiedni klucz (http://en.wikipedia.org/wiki/Media_Key_Block) do deszyfracji nagrań. W naszym przypadku klucz MKB działał by tylko na danym egzemplarzu telewizora. A samo szyfrowanie AES podobno jest podatne na atak brutal force. Ale to tylko takie luźne przypuszczenie.


    Do pandy:
    Wygląda na to, że potwierdza się to co pisałeś już na samym początku. Próbowałem (prawdopodobnie) rozpracowaną strukturę pliku TTS odnieść do jakiegoś istniejącego standardu strumienia audio/video ale jak na razie bez efektu - w ISO/IEC13818-1 przewidują blok 188 bajtów i budowę bloku z nagłówka i danych. Jest też mowa o bloku 188+4 ("The 188 byte packet size is increased by a 4 byte timestamp to 192 bytes") czyli tak jak u nas 192 bajty na blok. Ale zgadza się tylko ilość 192 bajtów na blok/pakiet - nie pasuje mi struktura w moim TTS 16+160+16. Jeżeli Ty już zauważyłeś jakieś podobieństwo struktury zaszyfrowanego TTS do innego standardu, to oczywiście daj znać.

    Prosiłeś też o to abym wyodrębnił sam strumień z normalnego (jawnego) nagrania: w programie Cypheros TS Doktor v1.1.7 wybieram TOOLS > TS PACKET FILTER > wskazuję plik TS i wybieram do skasowania wszystko (Invalid packet też) oprócz strumienia audio i video. Otrzymuję jawny plik TS o zmniejszonym rozmiarze, którego budowa jest już zbliżona do struktury zaszyfrowanego pliku TTS – umieściłem go tutaj 001_filtered.ts. Zrobiłem to dobrze czy to jednak nie o to Ci chodziło ?
    W otrzymanym pliku występują bloki/pakiety danych o rozmiarze też 192 bajtów i oczywiście każdy z tych bloków/pakietów ma stały nagłówek.

    Panasonic Viera i zdekodowanie/odszyfrowanie nagrań z HDD USB

    Ale mimo sporego podobieństwa, myślę że blok 16 bajtów początkowych i blok 16 bajtów końcowych ma jakąś specyficzną budową założoną przez Panasonica. Być może w bloku 16 bajtów początkowych jest zawarty klucz deszyfrujący a w bloku 16 bajtów końcowych np. CRC. A blok 160 bajtów audio/video to czyste dane audio/video bez jakiegokolwiek nagłówka przewidzianego przez standardy. Należy też pamiętać, że szyfrowanie zależy od nazwy/numeru pliku ale dwa pliki o tej samej nazwie/numerze (utworzone np. po formacie - już pisałem o tym) nie mają takich samym bajtów początkowych - być może Panasonic stosuje dodatkowy element losowy. Czyli na szyfrowanie składałoby się: nazwa pliku, liczba losowa, KEY z EEPROM i ta liczba losowa siedzi gdzieś w bloku 16 bajtów początkowych lub w bloku 16 bajtów końcowych. To kolejne moje luźne przypuszczenia – proszę o Wasze spostrzeżenia.


    Do skynet_2:

    skynet_2 napisał:
    Musiało zająć ci to sporo czasu, takie bieganie z dyskiem od PC do TV :)
    (…)
    @jaco777 jak potrzebujesz jakiś program, to opisz co ma on robić, w pythonie napisze to błyskawicznie.
    Zrobiłem sobie a’la stanowisko testowe przy TV: laptop, kabel USB i TV w zasięgu ręki, na laptopie VirtualBox z odpalonym Knoppix'em, do tego stary Visual C++ w którym na bieżąco modyfikowałem kod programu i wszystko razem jakoś śmigało :-). Fakt: zmodyfikować kod programu, zmodyfikować plik TTS napisanym programem, przepiąć dysk do laptopa, zamontować dysk w Knoppix'ie, nagrać zmodyfikowany TTS, przepiąć dysk do TV, odpalić plik TTS na TV i zanotować efekty i tak w kółko "niezliczoną" ilość razy :-) - ale w końcu jestem głównym prowodyrem całego tego zamieszania i trzeba się poświęcić aby osiągnąć jakieś efekty.
    Dzięki za propozycję wsparcia przy pisaniu programu. Zainteresowałem się tym Python'em i od razu przypomniał mi się Basic z Commodore 64 (pierwszy język w którym programowałem). A sam Python wygląda interesująco i jak znajdę czas to pewnie spróbuje coś w nim napisać. Na razie jakoś sobie radzę w C i przy okazji uczę się na błędach. Jak będę potrzebował pomocy to oczywiście się odezwę.

    A teraz o pliku TTS. Jak myślisz, teraz z tą wiedzą o strukturze zaszyfrowanego TTS, są szanse na dalsze kroki ?



    A na koniec proszę Was wszystkich o ewentualne własne spostrzeżenia i wnioski - może widzicie coś co ja pominąłem. I jeżeli potrzebne będą próba na plikach TTS to je wykonam.


    PS Zabrałem się za softowy generator sygnału DVB-T o którym już wspominałem (http://bellard.org/dvbt/) - może coś z tego wyjdzie.

  • #41 24 Sty 2012 22:57
    skynet_2
    Poziom 26  

    Trochę więcej niż dźwięk :D

    Panasonic Viera i zdekodowanie/odszyfrowanie nagrań z HDD USB

  • #42 24 Sty 2012 23:04
    piotr_go
    Poziom 27  

    U mnie tylko dźwięk :(
    Jaka wersja mplayera?
    Moja to "MPlayer SVN-r33713-4.6.1 (C) 2000-2011 MPlayer Team"


    OK, zauważyłem że jest i mplayer2.
    W mplayer mam tylko dźwięk, w mplayer2 mam tylko obraz.

  • #43 25 Sty 2012 21:03
    jaco777
    Poziom 24  

    Spoko, spoko. Nie rozpędzajcie się tak chłopaki :-).

    Zwróćcie uwagę co napisałem wcześniej:

    Cytat:
    Prosiłeś też o to abym wyodrębnił sam strumień z normalnego (jawnego) nagrania: w programie Cypheros TS Doktor v1.1.7 wybieram TOOLS > TS PACKET FILTER > wskazuję plik TS i wybieram do skasowania wszystko (Invalid packet też) oprócz strumienia audio i video. Otrzymuję jawny plik TS o zmniejszonym rozmiarze, którego budowa jest już zbliżona do struktury zaszyfrowanego pliku TTS -umieściłem go tutaj 001_filtered.ts.

    Może trochę zakręciłem, ale plik 001_filtered.ts powstał z normalnego nagrywania utworzonego za pomocą urządzenia CableTech URZ0083. To nie jest plik z telewizora Panasonic Viera.

    Na innych forach przewija się wątek AES i otrzymałem taką propozycję:
    pasko2 napisał:
    Have you tried to use the contents of the bind.id file as the AES-256 key to decrypt these 16 + 16-byte blocks you mention in your post?. I don't have the skills to program the decyphering routine....

    Niestety obecna moja wiedza i umiejętności kończą się tylko na udanych atakach na WEP (WiFi). A o pliku bind.id już pisałem:
    Cytat:
    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)

    i wątpię aby uczestniczył on w szyfrowaniu. Służy raczej do identyfikacji dysku przez telewizor.

  • #44 31 Sty 2012 22:04
    pasko2
    Poziom 1  

    Sorry for writing in English. I think that bind.id is important. Can you modifiy it and see if everything works? My guess is that it is the key to cypher each tts file in the hard drive, ie: if it is modified none of them will work.

    Regards.

    Edit:
    I was wrong. Tinkering with this file left the disk unusable. Sorry for the disturbance.

  • #45 04 Lut 2012 17:06
    jaco777
    Poziom 24  

    pasko2 napisał:
    Sorry for writing in English. I think that bind.id is important. Can you modifiy it and see if everything works? My guess is that it is the key to cypher each tts file in the hard drive, ie: if it is modified none of them will work.

    Regards.

    Edit:
    I was wrong. Tinkering with this file left the disk unusable. Sorry for the disturbance.

    And I also have done today, trying to file BIND.ID :-). I used two HDD to generate two files BIND.ID. Then I swapped BIND.ID files between drives and playback TTS to work.
    File BIND.ID is only used to recognize the HDD by name (the name given by the Panasonic TV for the first time when it is formatted HDD).

  • Pomocny post
    #46 21 Lut 2012 11:21
    dzebrys
    Poziom 11  

    witam,

    a moze by tak sprobowac ugryz jablko od drugiej strony? moze mniej trudniej [latwiej to zle okreslenie] bedzie dobrac sie do firmware'u i ominac szyfrowanie? firmware jest na am-linuxie, tutaj wiecej informacji o cpu i jadrze. plik SDDL.sec jest rowniez zaszyfrowany ale moze bardziej standardowa technika. z pewnoscia nie wykorzystuje sie do tego unikalnego KEY'a, ktorego jak na razie nie potrafimy zlokalizowac i wyodrebnic. jest jeden szkopol. trzeba plik najpierw odszyfrowac. w podobnych przypadkach przy hackowaniu softu do wdtv po przeskanowaniu pliku binwalk'iem widac bylo ze to obraz cramfs z dodakowym naglowkiem do wyciecia.

    z gory przepraszam za forme "dobrych rad". nie jest moja intencja kogokolwiek z Was obrazac. z racji braku wiedzy i czasu ciezko mi sie zabrac za to samemu. ale trzymam za Was kciuki i mam nadzieje cos sie uda osiagnac.

    aha, to co moge dodac od siebie w temacie, dzieki jednemu z forumowiczow ostalem zrzut peak eprom'a z G30 i przepisalem go do S30. niestety KEY nie jest w nim napisany [ani inna flaga dotyczaca generowania KEY'a] gdyz nie pomoglo to i wciaz mimo poprawnej zmiany modelu, nie jestem w stanie nagrywac na hdd. matka do KEY'a wg serwis manuala jest zapisana na innej plytce [nie na board A] i jest generowany podczas self test'u [np. po wymianie board A].

    sa 3 klucze generowane z matki:

    Code:
    - CI Plus [modul CI, DVB-T]
    
    - DTCP-IP [cos z komunikacja po IP, pewnie do platnych serwisow streamingowych]
    - One-to-One [nagrywanie HDD]

    Code:
    5.1.1. General information:
    
    1. EEPROM (IC8950) for spare parts has the seed of KEY for each.
    2. The final KEY data will be generated by Peaks IC (IC8000) when SELF CHECK was done and are stored in both Peaks IC (IC8000) and EEPROM (IC8950).
    Three KEY are not generated for all models. The necessary KEY are only generated and stored depend on the feature of models.

    5.1.2. Replacement of ICs:
    When Peaks IC (IC8000) is replaced, EEPROM (IC8950) should be also replaced with new one the same time.
    When EEPROM (IC8950) is replaced, Peaks IC (IC8000) is not necessary to be replaced the same time.
    After the replacement of IC, SELF CHECK should be done to generate the final KEY data.
    How to SELF CHECK: While pressing [VOLUME ( - )] button on the main unit, press [MENU] button on the remote control for more
    than 3 seconds.
    TV will be forced to the factory shipment setting after this SELF CHECK.


    jak wymienia sie A-board to trzeba tez wymienic EEPROM z matka klucza, natomiast w druga strone nie ma takiej potrzeby.

    Code:
    5.2.1. General information:
    
    Digital TV programmes can be recorded in USB HDD.
    A One-to-One key generated in A-board by SELF CHECK binds TV and USB-HDD for communication.
    That key is only one key for them. If the key is difference, TV can not access USB-HDD.


    moze jednak plik bind.id ma cos wspolnego z kluczem? dla proby zaladuje pelna zawartosc dysku od Jacka i zobacze czy po przegraniu na moj dysk bede mogl zobaczyc nagrania w mediaplayerze.


    powodzenia

  • #47 23 Lut 2012 21:43
    jaco777
    Poziom 24  

    Do dzebrys:

    Witam ponownie.
    Również próbowałem podejść od strony softu telewizora. Gdyby udało się uzyskać pełny kod źródłowy to jesteśmy w domu i wszystko mamy jak na dłoni – ale jak na razie chyba nikomu się nie udało, nie znalazłem nigdzie udanej próby rozpracowania pliku SDDL.SEC. Przydałby się ktoś kto ma już z tym doświadczenie i nas wspomoże.
    Każda rada związana bezpośrednio z poruszanym problemem jest mile widziana – a nóż ktoś wpadnie na coś genialnego.
    A co do zawartości pamięci w TV – udało mi się dostać do HEX edytora w moim telewizorze i zrobiłem pełny zrzut wszystkich pamięci (EEPROM(Peaks), EEPROM(STBY), Flas(Fake-Eeprom), Flash(Lsi-Data), Flash(module) ) w postaci zdjęć :-) – są tutaj EEPROM

    A plik bind.id służy tylko do identyfikacji sformatowanego HDD. Dowód:
    - zrób format dysku i nazwij go PIES :-) (gdy telewizor zapyta o nazwę po skończeniu formatowania),
    - skopiuj plik bind.id na komputer do katalogu PIES,
    - zrób znowu format dysku i nazwij go KOT,
    - nagraj jakąś audycję telewizyjną,
    - teraz na dysk nagraj plik bind.id z katalogu PIES i zobaczysz, że wszystko działa jak należy, audycja się odtwarza, tylko nazwa dysku zmieniła się na PIES.


    Powracając do prób modyfikacji pliku TTS.
    Wykonywałem w międzyczasie trochę zmian w różnych plikach TTS i wstępnie zauważyłem, że nagrania statyczne (jak plansza testowa) są bardzo wrażliwe na zmiany bajtów w blokach 16 bajtowych początkowych/końcowych, natomiast nagrania niestatyczne (czyli zwykłe audycje) potrafią być całkowicie NIEwrażliwe na zmiany w blokach 16 bajtowych początkowych/końcowych.

  • #48 24 Lut 2012 00:02
    dzebrys
    Poziom 11  

    witam,

    ostatnio odwiedzajac pewien zaklad elektroniczny zauwazylem
    popekany s30. a moze by tak dobrac sie do softu od srodka?
    czyli czytajac go bezposrednio z flash'a? czy jest to mozliwe czy
    tez takie uklady sa zabezpieczone przed czytaniem?


    pozdrawiam
    piotr

  • #49 24 Lut 2012 06:58
    pepe
    Poziom 23  

    Przypuszczalnie (o ile jest w zewnętrznej kości) będzie to flash w obudowie BGA,
    co ostatnio robi się bardzo powszechne, więc łatwo z odczytem nie będzie.
    Druga sprawa czy plik bin znacząco pomoże w stosunku do SDDL.SEC ?
    Wątpię...

  • #50 25 Lut 2012 21:37
    jaco777
    Poziom 24  

    pepe napisał:
    Druga sprawa czy plik bin znacząco pomoże w stosunku do SDDL.SEC ?
    Wątpię...


    Niestety też wątpię czy z "gołej" elektroniki telewizora da się wyciągnąć coś więcej niż z pliku SDDL.SEC.
    Ale gdyby znalazł się jakiś znajomy z serwisu Panasonica :-) to może udałoby się mu zdobyć jakieś informację o sposobie szyfrowania w pliku TTS, długości i lokalizacji KEY'a, itp. Bo sam kod źródłowy oprogramowania TV, to na pewno ściśle strzeżona tajemnica Panasonica do której dostęp mają nieliczni główni programiści tejże firmy.

    Do pepe:
    Jakiś czas temu miałem do dyspozycji przez dwa dni dysk 250GB i oczywiście intensywnie próbowałem zmusić TV to współpracy z dwoma partycjami na tym dysku. Niestety, na upartego widzi tylko jedną z nich, zazwyczaj tą drugą (nie UFS). Nie udało mi się wykonać wszystkich możliwych kombinacji - zdążyłem tylko z partycjami typu UFS i NTFS, oraz różnymi konfiguracjami typu partycje podstawowe, dyski logiczne. Być może klucz leży w kolejności partycji i ich typie.

  • #51 25 Lut 2012 22:24
    pepe
    Poziom 23  

    Ja poległem po jednym intensywnym dniu, wyczerpałem wszystkie swoje pomysły.
    TV widzi dwie partycje jako dwa dyski, ale w NTFS ....
    Założenie partycji UFS poza tv skutkowało brakiem możliwości nagrania.
    Być może w samej tablicy jest coś kluczowego do kodowania/dekodowania nagrań ?

    edit:
    Guzik - przecież kolega przenosił same pliki i dało się odtwarzać na TV :(

  • #52 21 Maj 2012 11:41
    jaco777
    Poziom 24  

    Witam po dłuższej przerwie.

    Temat ucichł i został zamknięty, ale ja nadal się nie poddaję. Wprawdzie wyczerpaliśmy już sporo możliwości, lecz nie powstrzymało mnie to od dokonywania kolejnych prób z modyfikacją poszczególnych bitów w bloku 16 bajtów początkowych. Jak na razie wykonałem zbyt mało prób, ale da się zauważyć, że w określonym bajcie można zmienić tylko jeden bit i strumień będzie prawidłowo zdekodowany - lecz to kolejne przypuszczenie, które muszę potwierdzić wieloma testami (a do tego muszę napisać kolejny program do modyfikacji plików TTS).

    Na innym forum (tutaj link) padła myśl, że pliki TTS zostały zaszyfrowane za pomocą metody DTCP. Szczegóły tutaj:
    http://www.dtcp.com/
    http://drdobbs.com/184407798
    http://en.wikipedia.org/wiki/Digital_Transmission_Content_Protection
    I nawet pasuje: Panasonic przyłożył do tego swoją rękę, też występują klucze do szyfracji, też można uzależnić szyfrowanie od sprzętu (od strony 53 - vol6iss4_art05.pdf). DTCP przewiduje szyfrowanie w M6 oraz AES-128 (Info20050228DtcpV1SbMost1p1.pdf).
    Lecz jeżeli się okaże, że w szyfrowanie plików TTS jest zamieszany AES-128, to chyba mamy pozamiatane. Niby AES można zaatakować metodą Brutal Force, tylko potrzebna do tego będzie kosmiczna moc obliczeniowa i jeszcze więcej czasu.

    Jeżeli temat zostanie otwarty to zapraszam do dyskusji. Przydałby się ktoś jeszcze, kto ma Panasonic'a i dołożyłby swoje pięć groszy. A jeżeli temat nie zostanie otwarty to proszę do mnie pisać na priv.

    PS Ostatnio, w akcie desperacji :-), zacząłem kombinować jakby tu analogowo zgrać zawartość plików TTS z telewizora. Jest światełko w tunelu, szczegóły w nowym temacie tutaj: https://www.elektroda.pl/rtvforum/topic2299668.html

    Dodano dnia 2012-05-28
    Udało mi się uzyskać dostęp do nagrań (oraz Viera Cast) poprzez wyjście EURO, czyli sygnał analogowy (video composite). Szczegóły tutaj : Przełącznik AV CXA2069 (C1AB00003218) - "ręczne" sterowanie I2C.
    Gdyby ktoś był zainteresowany jak to zrobić, to proszę pisać do mnie na PRIV - jeżeli będzie zainteresowanie do napiszę odpowiednią instrukcję.

    Na dowód nagrałem filmik i umieściłem go na Youtube (ze względu na rozmiar i dostępność dla wszystkich). To duże :D to Panasonic Viera a to małe :D po lewej na dole to laptop z grabberem TV.


    Link




    Dodano dnia 8.01.2013
    Ponieważ pojawiają się coraz częstsze zapytanie o instrukcję, to informuję że znajdują się one na moim moim kanale YouTube.

  • #53 15 Paź 2012 08:09
    hojlo1
    Poziom 35  

    Nie chciał by źle 'prorokować", ale dość podobny problem spotkałem w dekoderze Vectry (choć tam nie ma problemu odtwarzania przez różne wyjścia, bo to przecież tylko dekoder).

    Poczytałem zagraniczne fora na temat parowania dekodera z nagraniem (czyli że odtworzysz tylko na nim) i otrzymałem smutne wiadomości.
    Opisali że jakbym nawet dostał się do aplikacji dekodera przed kompilacją (co w praktyce jest niemożliwe) to znowu klucz jest wprowadzany przez inna aplikację.
    I znalezienie takiego klucza (np bruteforce) mija się z celem (programista porównał to do próby łamania długiego WiFi WPA, czyli na domowym sprzęcie...lata)

    Oczywiście sprzęt różny i życzę powodzenia (może coś łatwiej jest)

 Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME