AW: Technische Details einer verheirateten NDS V14
Ha hab das Thema gefunden
Was passiert ei Pairing genau... weiss eigentlich keiner , ich auch nicht.
Aber ein wenig kann ich dazu sagen.
2 Chipsätze haben ein extra Magic eine Crypto Core ähnlich wie bei den alten Smartcards At90SCXXXXC. Diese ist im Receiver IC verbaut.
Beispiel die Serie STi71XXX oder Broadcom 73XX. In dem extra ist auch ein 8x8 Register in denen magische Dinge hinterleg sind.
Das ist soweit aus dem Conax Hack bekannt.
Die adressierung des magics hat eine Lücke bei STi IC´s, im Linux Treiber XXX.KO file sind die Adressen gespeichert.
Das Pairing ist kein neues Wunder, es kam schon bei Betacrypt zum Einsatz (Betacrypt = Ableger Irdeto). Das Bluecam wurde verheiratet.
Mit einem Class 01/05 wurde ein 64Byte Block generiert vom Modul und weitergegeben an die Karte. Bei nicht Z Karten wurden die ersten 8 byte benutzt und man hatte kein Pairing.
Beim Z Algo benutze man alle 64 Byte die ein Block Cipher RSA sind. (Einweg).
64 Byte = 512 Bit RSA
In diesem Block sind Kommandos um einen AES/3DES Key auszuhandeln. Ich habe jetzt nicht geschaut was die NDS Karte macht es kann aber sein, das der Block größer ist und 768 Bit RSA hat.
Das ist das neue Wunder... Camkey(Camcrypt) Weiter wird die Uniqe Kartenkennung auf die Box übertragen und anders der Boxkey in die Karte.
Was ich generell sagen kann ist, das es verschiedene Level des Pairings gibt, nicht nur das Software Pairing & Hardware Pairing.
Level 0 = low security ( Nur RSA/AES Daten )
Level 1 = Software Pairing
Level 2 = Hardware Pairing
Bis Level unbekannt..... in den jeweiligen Leveln ergibt sich auch ein andere Algo mit spielerein wie XOR ect.
Das ist das Generelle vom Pairing....
Welches cmd für NDS oder andere ist... entzieht sich momentan meiner Kenntniss.
Das heisst wenn jemand die RSA bricht, gibt es wieder klare Kommandos zu sehen bis zum Punkt wo die Karte AES ausgehandelt hat.
Das man AES nicht brechen kann sollte jedem klar sein... Es wäre sinnlos bei DES wären es 18 Billionen Schlüssel und bei AES ein vielfaches mehr.
Es bringt aber auch nicht wirklich viel, einen Receiver zu Jtagen oder mittel RS232 einen Dump anzufertigen.
Anders wäre ein ständiger RAM dump von Vorteil. Es gibt schon Lösungen bei verschiedenen Providern die Cw´s abzufischen, das Resultat ist aber nicht tauglich, da das CW viel zu spät
beim "Client" ankommen würde.
Wenn jemand ei OTA abgreifen könnte wäre ich echt dankbar... auch wenn im binary fast nichts zu holen ist... aber interessant ist es.
Wichtig ist auch zu sammeln, welche Chipsätze in den Original Receivern verbaut sind. Vieleicht sind diese nicht wirklich tauglich und können nur ein
Software Pairing.
PS: Es gibt Firmen wo das CAS selbst noch nicht drauf ist und ein Update des Casés gemacht werden muss das sie
HD+ tauglich werden...
vieleicht ja auch bei den NDS Receivern.
Eventuell mal auf die Seite von Colibri sehen, der sich mit den Humax Geräten auseinander gesetzt hat.
odd key = DOK
even key = DEK
key length = DKL
Dann gibt es noch die ChannelID = C
und die verschlüsselte Transport Session <-- die auch eine eigene ID hat.
Der EVEN Protect Key L0_EK
Der ODD Protect Key L0_OK
Das heisst... es wird die Channel ID abgefragt und schon so gefragt um welchen Sender es sich handelt...
Channel ID 20 -> AES ALGO->>>>>>> CW->>> protect ->>>> BILD
Kommen jetzt noch 10 anfragen aus z.B. einem Share... wird gecounted... maximal X CW´s in der und der Zeit.
Kommen andere Anfragen wie 3 verschiedene ID´s 10 , 55, 25 Zählt man und sagt nope...keine CW Berechnung und Ausgabe..
Nennt man ja auch Surflock
So damit sind mal die Schwachmaten mit ihren Payservern raus
HAHA und an diese eine Persöhnliche Nachricht: FUCK YOU nannananananana
Wenn alle die Pairing machen Klug sind... wird es bald mehr CI Module geben, die lizensiert sind für alternative Receiver....
Das Sky Modul für NDS ist ja schon mal was.... CI+ aber es rennt im TV und STB.
