Cała aktywność

@trójkowy Przestań już bredzić! Sprzętowe ale ty o trust zone nie masz pojęcia! W trust zone działa pod kontrolą secure os ma aplikacje moduły itd Ty piszesz takie bzdury, że uszy więdną, a ja wiem co piszę! Te brednie nikt nie posiada algorytmów do deskrypcji audio/video! To zwykły AES! Przestań już bredzić bo nie ręczę za siebie. @jacek_kc Dokładnie tak dlatego jak się znajdzie dziurę to się tym nie chwali. A co do STB to tak jeśli to Android. Ale @trójkowyżyje STB z ST. Tam był firmware code do secure procka. Do którego dokumentacji brak. Dużo ciężej zaatakować było ten firmware. A tu masz TA aplikacje dla ARM gdzie masz pełnie dokumentacji pełno narzędzi do dekompilacji disasemblacji. Tak aplikacje TA skompilowane gcc dla architektury ARM, są podpisywane/szyfrowane. Ale wszystko da się złamać. A @trójkowy nie przyswoił nawet tego co w sieci lata. Czyli znane backdoory itd. inna sprawa, że jak to wyszło public to zostało załatane, a certyfikaty trafiły na black listę. Jeszcze te głupoty, że algorytmy nie są znane litości. Przecież są nawet dokumentację do DASH, HLS, smooth streaming. Co więcej mamy już klika aplikacji pod E2 obsługujące DRM, a E2IPLAYER pozwala na pobieranie treści zapieczonych DRM i po pobraniu ma się je plain. A ten dalej takie banialuki pociska... Ile można takie brednie czytać? Jak już wiele razy pisałem ja nie zamierzam się chwalić co mam. @jacek_kcmyślisz, że znalezienie dziury jest tak mega ciężkie tylko, że każdy producent ma pełno dziur. A to mają jakiś interfejs udostępniający interfejs do szyfrowania / deszyfrowania czegoś master key i nawet nie zdają sobie sprawy, że można go użyć do szyfrowania / deszyfrowania innych danych itd. Mają zaimplementowane mechanizmy debug aplikacji TA. Niby wyłączone w release ale tak nie do końca. Łącznie z wypluwaniem certyfikatów plain w logach na serial. No tak logi szyfrowane, ale co z tego jak już wspominałem... Mają mechanizmy debugowe by ładować TA niepodpisane niby nie w sofcie który idzie na produkcję no ale z kodu nie usunięte tylko softwareowo wyłączone. Nie będę tu pisał nic więcej bo sensu to wielkiego nie ma. @jacek_kc A co do tej kompromitacji to ci powiem tak dopóki to nie jest publick, to nawet jak dasz znać producentowi, że coś tam odkryłem to po trzech latach w nowych produktach dziura dalej jest. Jak jest publick i Google banuje całe urządzenia to dopiero producent zaczyna się interesować. Tak to wygląda od strony praktycznej.

Proponuję najpierw rozdzielić pojęcia, bo mieszacie provisioning/attestation z kluczami treści: 1) Certyfikat urządzenia ≠ klucze licencyjne ≠ klucze treści. W Widevine L1 cała wrażliwa kryptografia (unwrapping licencji, klucze sesji) dzieje się w TEE (TrustZone) w ramach zaufanej aplikacji (TA/CDM). Certyfikat urządzenia służy do attestation/provisioningu, a nie do „wyliczania” kluczy treści. 2) Jak trafia certyfikat? Historycznie bywał keybox w fabryce; współcześnie urządzenie generuje parę kluczy wewnątrz TEE, wysyła CSR i dostaje łańcuch certyfikatów podpisany przez Google. To, że payload jest dodatkowo szyfrowany kluczem provisioningu/OEM (związanym z SoC/HUK), dotyczy transportu i składowania, a nie udostępniania „w plain” poza TEE. 3) „Leży w plain” – ale gdzie? „Plain” istnieje tylko w pamięci procesu TA w secure world podczas użycia. REE (normalny świat) nie ma do tego dostępu. Niezależnie od tego, czy RAM secure jest sprzętowo szyfrowany, izolacja TEE + weryfikacja podpisów kodu są głównym mechanizmem bezpieczeństwa. 4) „Jak zhackujesz TA, to masz dostęp do sekretów.” Zgadza się — ale to oznacza kompromitację TEE/TA, czyli wyjście poza zakładany model zagrożeń. Wtedy w grę wchodzą: revokacje certów, aktualizacje TA/TEE, anti-rollback, blacklisty po stronie licencjodawcy. To nie jest to samo co „to wszystko jest w plain i każdy może sobie wziąć”. 5) STB vs Android. Implementacje różnią się szczegółami (key-ladder vendorów, secure video path), ale zasada jest ta sama: sekrety nie opuszczają TEE, a ścieżka obrazu jest zabezpieczona. Publiczne „sample TAs” nie są produkcyjnymi binarkami; bez podpisu OEM/TEE nie uruchomisz ich w secure world. Wniosek: certyfikat urządzenia służy do bezpiecznego provisioningu i attestation, a klucze treści pozostają w TEE. Twierdzenie, że „cert jest plain, więc to bez znaczenia”, jest błędne — „plain” jest dostępny wyłącznie dla zaufanej aplikacji w TEE. Jeśli uważacie inaczej, pokażcie realny model ataku bez kompromitacji TA/TEE i rollbacku — to zupełnie inna klasa problemu.

Ludzie posiadaja klucze L1 jak i PR3K, przeciez to widac po materialach ktore sa dostepne , ale czasami z dobrym "mod-em" mozna sie pogubic (pluginy pod E2) (publiczna dyskusja, wiec nie mozna inaczej). Narazie Adas

@szumacher nie rozumie wciąż że L1 to rozwiązanie sprzętowe dokładny algorytm nie jest znany a do dekrypcji strumienia audio-vizualnego potrzebne są sprzętowe klucze z TEE i tego że wszystkie rozwiązania do ochrony treści są sprzętowe od przeszło 15 lat. Z ciekawości zapytałem oto prosta odpowiedz sztucznej inteligencji: Widevine L1 jest rozwiązaniem sprzętowym (hardware-based) i to kluczowa cecha odróżniająca je od niższych poziomów zabezpieczeń. Oto szczegółowe wyjaśnienie: Czym jest Widevine? Widevine to technologia DRM (Digital Rights Management) należąca do Google, używana do ochrony treści wideo przed nielegalnym kopiowaniem. Jest stosowana m.in. przez Netflixa, YouTube Premium, Disney+ i innych dostawców treści. Poziomy Widevine: L1, L2, L3 Widevine ma trzy poziomy zabezpieczeń, gdzie L1 jest najwyższy (i najbezpieczniejszy): Widevine L1 (Hardware-backed): Deszyfrowanie i przetwarzanie wideo odbywa się w sprzętowym bezpiecznym środowisku (TEE - Trusted Execution Environment). TEE to izolowany obszar procesora/układu SoC, niedostępny dla systemu operacyjnego ani aplikacji. Klucze szyfrujące i operacje kryptograficzne są tam chronione. Wymagany do odtwarzania treści w ultra HD (4K) i HDR. Widevine L2/L3 (Software-based): L3: Deszyfrowanie odbywa się całkowicie w oprogramowaniu (bez izolacji sprzętowej). Klucze są łatwiejsze do wycieku. L2: Mieszane (częściowo sprzętowe, ale słabsze niż L1). Treści są często ograniczone do rozdzielczości HD (1080p) lub niższej. Dlaczego L1 jest sprzętowe? Bezpieczne środowisko (TEE): Procesor musi mieć dedykowany hardware (np. TrustZone w ARM) do izolacji krytycznych operacji. Certyfikacja: Producent urządzenia (np. telefonu, telewizora) musi uzyskać certyfikat od Google potwierdzający poprawną implementację TEE. Klucze sprzętowe: Klucze szyfrujące są powiązane z konkretnym urządzeniem i przechowywane w TEE. Jak to działa w praktyce? Aplikacja (np. Netflix) żąda odtworzenia treści. System Widevine sprawdza poziom zabezpieczeń urządzenia. Dla L1: Klucz deszyfrujący jest przesyłany do TEE. TEE deszyfruje strumień wideo i renderuje go bez udostępniania danych do głównego systemu. Ekran musi być chroniony przed przechwytywaniem (HDCP). Skąd wiesz, jaki poziom ma twoje urządzenie? Na Androidzie: Ustawienia > Informacje o telefonie > Widevine DRM. Aplikacje typu DRM Info pokazują szczegóły. Podsumowanie: L1 = Sprzętowe zabezpieczenia (TEE) + najwyższa jakość wideo (4K/HDR). L3 = Programowe zabezpieczenia (brak izolacji sprzętowej) + ograniczenia jakości. L1 wymaga certyfikowanego hardware'u, więc nie da się go "dodać" softwarem na starszym urządzeniu. Ja > Czy L1 wykorzystuje jakies klucze sprzetowe do dekrypcji strumienia audio video ? Odp: Tak, Widevine L1 bezpośrednio wykorzystuje sprzętowe klucze kryptograficzne do dekrypcji strumienia audio-wideo. Jest to kluczowy element jego architektury zabezpieczeń. Poniżej znajduje się szczegółowe wyjaśnienie: Rola kluczy sprzętowych w Widevine L1: Trusted Execution Environment (TEE): Widevine L1 działa w sprzętowo izolowanym środowisku (TEE), które jest oddzielone od głównego systemu operacyjnego. TEE ma własny procesor, pamięć i zasoby kryptograficzne, niedostępne dla zewnętrznego oprogramowania. Klucze urządzenia (Device Keys): Każde urządzenie z Widevine L1 posiada unikalne klucze sprzętowe (np. zapisane w bezpiecznej pamięci SoC lub modułu TPM). Klucze te są trwale powiązane z hardware’em i nie można ich wyodrębnić ani zmodyfikować. Proces dekrypcji: Serwer DRM (np. Netflix) dostarcza zaszyfrowany klucz treści (Content Key), który jest używany do odszyfrowania strumienia wideo. Klucz treści jest odszyfrowywany wewnątrz TEE za pomocą kluczy sprzętowych urządzenia. Odszyfrowany strumień wideo jest renderowany bezpośrednio w TEE, a dane nigdy nie trafiają do pamięci systemowej w formie niezaszyfrowanej. Dlaczego to jest bezpieczne? Izolacja sprzętowa: TEE uniemożliwia aplikacjom lub systemowi OS dostęp do kluczy lub odszyfrowanych danych. Certyfikacja sprzętu: Producent urządzenia musi spełnić rygorystyczne wymogi Google dotyczące implementacji TEE i przechowywania kluczy. Atesty hardware’u: Klucze są chronione przed fizycznymi atakami (np. side-channel attacks) dzięki specjalistycznym układom kryptograficznym. Analogia: Wyobraź sobie sejf (TEE) wbudowany w ścianę (urządzenie). Tylko sejf ma klucz (klucz sprzętowy) do otwarcia zaszyfrowanej paczki (klucz treści). Paczka jest otwierana wewnątrz sejfu, a jej zawartość (wideo) jest przekazywana bezpośrednio do ekranu, bez wystawienia jej na zewnątrz. Różnica między L1 a L3: Widevine L3 używa kluczy przechowywanych w software’cie (np. w pamięci systemowej), które są podatne na ekstrakcję przez zhakowanie systemu. Widevine L1 uniemożliwia to dzięki sprzętowej izolacji. Podsumowanie: Widevine L1 opiera się na kluczach sprzętowych i TEE do ochrony zarówno kluczy treści, jak i samego strumienia multimedialnego. Jest to standard wymagany do odtwarzania treści 4K/HDR w serwisach takich jak Netflix czy Disney+. Znając analogie i strukture zabezpieczeń stosowanych przez producentów stwierdziłem już na początku że to rozwiązanie sprzętowe. Twierdzę również iż nikt nie posiada sprzętowego algorytmu i kluczy do dekrypcji strumienia audio-video a zwykły pirat prędzej wykorzysta port HDMI odbiornika zamiast zawracać sobie głowę jakimś kluczykiem L1 w 2025r. Parcie na klucze pojawi się w przyszłości gdy uruchomią długo oczekiwane parowanie sprzętowe pomiędzy telewizorami a urządzeniami z portem HDMI takie rozwiązania są wdrażane od wielu lat w dzisiejszych telewizorach tylko do dziś nie zostały jeszcze uruchomione. Nie twierdzę również że klucze sprzętowe są nie do odczytu a algorytmy nie do poznania jednak w ostatnich latach poziom zabezpieczeń z EAL5 wzrósł sprzętowe moduły kryptograficzne w procesorach są projektowane przez AI na zlecenie producentów i pomimo iż procesory te nie posiadają wysokich poziomów zabezpieczeń jak te występujące w dzisiejszych kartach inteligentnych e-dowodach e-paszportach to wciąż przy niskim budżecie jest ciężko rozpracować ich zabezpieczenia.

@trójkowy Naprawdę masz nikłe pojęcie o widevine. W trust zone masz uruchomiony serwis i tak certyfikat jest plain rozumiesz? On leży i owszem zaszyfrowany paniec RAM jest szyfrowana ale jak masz z hackowaną aplikacje działająca w trust zone to ona ma dostęp do plain. I proszę nie pisz już głupot bo ta domyślna przykładowa implementacja TA lata po sieci. Tkwisz w STB w jednym rozwiązaniu i piszesz BZDURY! Google jak dostarcza certyfikat widevine to go dostarcza zaszyfrowanego innym kluczem z którym urządzenie wychodzi z fabryki. I ten klucz i owszem leży zaszyfrowany kluczem chipsetu. Ale to nie ma nic wspólnego z wyliczaniem. Nawet wszystkiego co napisałeś nie chce mi się czytać bo jesteś w takich malinach, że to się w głowie nie mieści. Stek bzdur. Nie mam nic do ciebie i nie chcę cię obrażać ale ty nawet nie zapoznałeś się z ogólnie dostępnymi informacjami odnośnie DRM widevine.

@cezar07 Oni nie mają niczego płacą za rozwiązania off the shelf czyli takie min. wygrzebane stare dekodery operatorskie z sti7111 7105 których już dawno nie ma w systemie a ktoś dopisał i aktywował za dopłatą , stary caid irdeto który nie został nigdy wyłączony nagle otrzymał uprawnienia do kart których oficjalnie już nie ma to takie które działały bez żadnego parowania u operatora nova. Forever może conajwyżej płacić za certyfikat drm lub token który ktoś wylicza prywatnym kluczem tym kimś może być organizacja i tak to działa o ile wogóle działa nie słyszałem. Oczywiście ktoś mógł rozpracować zabezpieczenia w starym procesorze z jakiegoś starego telefonu który obsługuje drm tak mógł jednak to nie jest robota na rok czasu i mało prawdopodobne jest to że gdzieś występuje jakiś błąd który umożliwił odczyt klucza prywatnego z TEE w gre wchodzą conajwyżej drogie ataki sprzętowe. Takiego czegoś już od dawna nie ma tu są na rynku dekodery z aktywnym dostępem do kernela z ARM nikt z nich niczego do dzisiaj nie odczytał a minęło już przeszło 4 lata poświęcanie czasu na to jest nieopłacalne. Skoro twierdzisz że to musi działać to zapytam może o najprostszą rzecz gdzie macie waszego magika od wifiboxa ?! przecież to takie proste musi działać nawet najprostszego rozwiązania nikt nie może wam zrobić a gdzie jakieś klucze drmy broadcomy i reszta bo w iks forever wszystko działa tzn. że złamane ? ja bym tego nie nazwał złamanym.

Ale jacy są nie odstępni ? jakieś odpady co i tak nikt nie ogląda a tak praktycznie wszystko jest .... Ja to bym ci radził zainteresować się takim forever i jak masz wiedze to się rozkiwaniem tego ich boxa. Nie to ze maja tam cs to iptv oraz takie ich netflixa co sie jakos podobnie nazywa gdzie praktycznie wszystko jest z vod. Pewnie te klucze maja dawno bo po co maja garbować jak mogą mieć czysty sygnał.

Nie uwierzę na słowo. Od czasów wprowadzenia parowania sprzętowego z kartami wszystkie rozwiązania chroniące kontent to rozwiązania wyłącznie sprzętowe dotyczy każdego drm i całej reszty. Do generowania certyfikatów i pozostałych danych potrzebny jest prywatny klucz sprzętowy wpisany w trusted zone enviroment blokować mogą poszczególne dane dlatego że do wyliczania tych danych używany jest numer seryjny procesora wraz z kluczem zapisanym w otp tee. Klucza nie da się zczytać zczytywarką. Nikogo to już nie interesuje tu się liczy prosty zysk niewielkim kosztem gdyby miało być inaczej to wszyscy operatorzy pay-tv byliby wciąż dostępni w sharingu bo tam jest lepsza jakość nikt nie zawracałby sobie głowy jakimś transkodowanym iptv.

Po tym co napisałeś stwierdzam, że nie masz wiedzy. Dany certyfikat można zablokować. Co więcej można zablokować, albo ograniczyć dostęp do treści dla urządzeń w których wykryto luke pozwalająca na wyłuskanie certyfikatów. Co więcej teraz urządzenia nie wychodzą z gotowym certyfikatem L1. Przy pierwszym requeście ten certyfikat per-device jest generowany przez serwery google. Piszesz o tej arm'owej trust zone jakby to było nie wiadomo co tymczasem w jego ramach uruchamiany jest soft dziurawy jak każdy. Pisanie, że nikt nie ma jest niepoważne. Takimi rzeczami po prostu nie warto się chwalić. Co do HDMI no to przecież było po to wprowadzane HDMI 2.x z nowa matrycą kluczy. Druga sprawa jak można walczyć z grabowaniem po HDMI to fingers prints. Ale grabowanie po HDMI ich bardzo nie boli, bo drogi panie musisz zrobić re-encoding i już jakość gorsza, a druga sprawa to możesz "pobierać" VOD tylko w czasie rzeczywistym. Wiec to trwa bardzo długo.

Chyba tam miało być canal+

Kolega nie rozumie wciąż istoty problemu klucz prywatny i certyfikat od widevine to rozwiązanie sprzętowe poza kernelem z telewizora czy odtwarzacza z androidem kontent z L1 jest dekodowany w arm trust zone sprzętowo i to tylko wtedy gdy odpowie na certyfikat ale ty wciąż możesz piracić ten kontent bo posiadasz dostęp do portu hdmi z odtwarzacza z androidem który to dekoduje możesz wpiąć to pod transkoder i udostępnić w internecie live lub możesz to zgrać z hdmi i wgrać do internetu to odnośnie pay-tv obecnie pracują nad tym aby zabezpieczyć również hdmi te zabezpieczenia są od dawna instalowane w procesorach od telewizorów ale nie zostały jeszcze do dziś aktywowane i jeśli to zrobią będziesz musiał posiadać klucze sprzętowe albo od keyladdera hdmi lub z keyladdera z TEE (trusted enviroment) do zdeszyfrowania kontentu z DRM w tym wszystkim najgorsze jest to że nawet same nośniki fizyczne z najnowszymi produkcjami mają zostać upchane do internetu w przyszłości i dostępne wyłącznie w usługach online jeśli tak zrobią od odbioru tv czy najnowszych produkcji filmowych będą potrzebne te klucze na dziś dzień to jest tematyka sci-fi ponieważ kanał pay-tv który jest dostępny wyłącznie w usługach online nie ma go na satelicie zostanie przetranskodowany i dosłany w strumieniu pirackim z portu HDMI i też go odbierzesz żaden pirat nie będzie sobie głowy zawracał jakimś kluczem sprzętowym z certyfikatem tak to wygląda w 2025r. Problem tkwi w dostępie jeśli coś zostaje zablokowane od wewnątrz działą wciąż z zewnątrz.

Tutaj macie dumpy z telewizorów i narzędzia. Reszte sobie ułóżcie https://postimg.cc/6TW68g7c

Zly "requests" prowadzi do uwalenia danych rowniez jak i "key api" (zmienilem oznaczenie). W Polsce tylko anal+ ma wyzsze wymagania, nikt inny Narazie Adas

Nikt tego nie posiada lub posiadają obecnie tylko organizacje. To rozwiązanie sprzętowe i nie jest to coś co zostało opisane przez firmę security explorations konkretne zainteresowanie może się pojawić w przyszłości w momencie kiedy wyłączą dostęp przez tokeny u wielu lub wszystkich operatorów ze względu na to że wyliczone dane są uniwersalne prędzej kupi je jakaś większa firma w zabezpieczony sposób zainstaluje w swoim sprzęcie aby ten się lepiej sprzedawał. Te zabezpieczenie nie dotyczy tylko pay-tv ale w przyszłości wraz z DRM dotyczyć będzie również zabezpieczenia filmów które są zgrywane i udostępniane w publicznym internecie min. poprzez zabezpieczenie L1 od wewnatrz i DRM na zewnątrz z HDMI. Właśnie główny problem dla copyright trolli stanowi to że dane pozyskane z nawet najstarszego i najbardziej dziurawego procesora będą wciąż kompatybilne z każdym przekazem który wymaga takiej ochrony.

Nie przesadzaj z tym oglądaniem świata z za okna, bo raczej większość się pogodzi z tym że nie może oglądać na tunerze z E2 i będzie oglądało na tv, czy innym boksie z certyfikatem. Podejrzewam że tylko starej gwardii tak zależy na tym aby to działało z poziomu tunera E2, bo to nasza pasja od lat, swego rodzaju szajba.

Nie wiem , bo nie jestem użytkownikiem Twojej wtyczki , więc nie znam tej historii. Ale ja osobiście , nie mając doświadczenia w temacie , zamiast błądzić jak ,, dziecko we mgle'' , wolał bym zapłacić jakieś rozsądne pieniądze . W tym momencie temat rozsądnych pieniędzy uważam za zakończony.

Jak sie "januszowi" wszystko serwuje jak tylko tupnie nozka, wtedy masz tak jak sobie zyczyles. @lokopoko zwykly Reseller, nic nie wie tylko popycha dalej. ------ L3 i PR2k dziecko by sobie poradzilo (nawet bez HW, czyste EMU). Narazie Adas

Nie poradzi sobie. Dowód daliście sobie sami przy pierwszej wersji e2kodi, kiedy trzeba było wygenerować własny L3, którego tworzenie jest opisane publicznie "jak dla trupa". Gdyby nie azman, który "dał" wam swój i nieruchawość google które olewa l3 - oglądalibyście tylko świat za oknem.

jakieś info można sprawdzić tutaj GitHub - devine-dl/pywidevine: Python implementation of Google's Widevine DRM CDM (Content Decryption Module) a z innego źródła aby wyciągnąć Widevine L3/L1 potrzeba Android Studio Android Studio - Download mnie ciekawi czy i jak da się wyciągnąć te dane z TV z Andkiem na pokładzie ps. a wg. info wtajemniczonych taki certyfikat w sieci kosztuje kilkaset €

I to tez by był niezły pomysł z tym " Szukam magika do wyciągnięcia certyfikatu L1 '' myślę ze pewnie sa tacy co sie znają i na tym ale czy ktoś będzie chciał wyciągać takie dane to nie mam pojęcia. Kolega Tolek7 w innym wątku pytał o tego boxa Android Box 4k od Canal+ to samo wejście do niego czyli root to zajmie trochę bo to wszystko jest podobne do wejścia w inny box i szukanie kluczy dla oscam . To są boxy certyfikowane wiec producent daje jakiś poziom zabezpieczeń i to nie jest tak ze wejdziesz sobie po robocie o i tu leży klucz to go podniosę i mam.

Zaczynac masz od ROOT, pozniej L3 / PR 2k, sam zobaczysz jak daleko zajdziesz. Narazie Adas

Wszystko pięknie , tylko to ma się nijak do tematu. Skoro faktycznie jest to na tyle skomplikowane dla zwykłego ,,śmiertelnika'' i tylko nieliczni sobie z tym poradzą , to równie dobrze można założyć temat ,, Szukam magika do wyciągnięcia certyfikatu L1 '' Bo poza banały że jest to możliwe , da się , i tak dalej, nic więcej z tego nie wyniknie.

Na 90% nie; ludzie maja problem z cfg oscama a ty myślisz ze ktoś wejdzie w soft znajdzie gdzie jest takowy certikat potem pewnie rozkoduje go bo na tyle głupi nie byli ze jest podali na tacy. Czy ktoś tutaj zajął się wyciąganiem kluczy do oscam z tych pace i równie starych boxow; mamy teraz 1 rodzynka co cos walczy .

Kowal-ski zawsze sobie dawal rady Narazie Adas

@adas13 To jest oczywiste chyba dla każdego , że takich rzeczy nie wystawia się publicznie , bo było by to niczym innym jak tylko głupotą. Chodzi tu raczej o to czy przysłowiowy ,,Kowalski''sobie z tym poradzi