Dies ist eine mobil optimierte Seite, die schnell lädt. Wenn Sie die Seite ohne Optimierung laden möchten, dann klicken Sie auf diesen Text.

Pace TDS865NSD Fakten zusammen tragen, rooten etc

Kurze Zwischenfrage: Das Ziel besteht darin, aus der CPU zur Laufzeit einen Key zu entnehmen, wofür eine modifizierte Soft notwendig ist bzw. per Root-Zugriff abgefragt werden kann, richtig?
Liesse sich der Key auch über andere Bestandteile wie z.B. einer .rodata Datei ableiten? Bei MerIin schlummern ja dort die MODs drin.
THX
 
Zuletzt bearbeitet:
Oh man was bringt es euch ihr kommt bei der cpu högstens bist icam anfang das wars das icam spricht mit cpu direkt mit einen bvm log würdet ihr sehen was das icam in die cpu gibt doch dan ist entgültig schlus cpu spricht nach aussen uber k5 ein 256bit rsa key auch mem2mem genannt das schlimste jst wur wissen nicht ob sha1 oder revers es könnte auch genauso wie bei php ein hash sein ich tippe eh schon lang auf sha1 mac hash den überlegt mal cpu massen ware software bei allen gleich somit mus irgend was in jeder hardware anders sein die lan mac eventuell mann sollte schauen wo man die geräte sn wiederfindet den die will sky habe ändert mal 2 zahlen und gebt die bei sky falsch bekannt bleibt das bild dunkel irgend wo muss die sn sein als hexx ich tippe auf bootloader den da kommen wir nicht ran um ein printenv zu machen sonnst könnte man die nac mal ändern und es bleibt dunkel wetten
 
Zuletzt bearbeitet:
Ich vermute eher, dass bei der Produktion online eine CA-ID und die dazu passenden Keys abgerufen werden und die dann in den BSP OTP-Storage geschrieben werden und danach die Fuse geschrieben wird.
 
Eher unwarscheinlich da dieses gerät auch für die franzosen und italiener genutzt wurden die werden nicht jedes gerät mochmal angeschlossen haben um zu programieren ich denke eher das es so ist der bootloader macht beim 1 einschalten eine verbindung und lädt vom nds transponder was runter und fläsht es ins otp
Man sollte den Nds transponder mal mitloggen und schauen was da so gesendet wird
 
Foxconn personalisiert aber genau so die Smartphones für Apple, Nokia & Co.
 
Leuts, wie schon mal erwähnt spiel ich dat alles zur Zeit theoretisch durch

Mein letzter danke war beide wege zu verbinden, so könnte man eventuell das eine für das andere finden, bzw infos sammeln...!!!???
Mir fehlt momentan einfach die Zeit alles aufzubauen und rums zuspielen
 
Zuletzt bearbeitet:
Natürlich wurde jede CPU angeschossen und programmiert :joycat: und das passiert sicherlich nicht über irgendeinen unsichecheren Kana via DVB Transponder im Nachhinein.
Dafür gibt es extra Schritte in den Chip Produktionslinien, da ist nen entsprechender Sockel mit Roboter Pick and Place, die CPU kommt rein und das ganze Provisioning und Fuses werden geschrieben, Daten kommen von customized Geräten vom CA Vendor.
 
Wie sich das mit dem im SOC verbauten Key verhält, steht doch in der KLAD-SPEC. Dazu kommt noch der Vendor Key, und schon ist das Rätsel gelöst.

Nur mal so ne Anekdote: ich habe vor Jahren mal 50 OTP-Token (Schlüsselanhänger) bei nem Händler gekauft. Systemfrei (TOTP) Dabei war eine Liste mit Seriennummern (die standen hinten auf den Dingern drauf, mit Barcode) und dazugehörigen Seed Vektoren für das OTP. In unserer Anwendung musste man dann nur noch die Seriennummer eingeben und konnte das Token dann zum Login verwenden. Den dazugehörigen Key hat unser System aus einer internen Datenbank geholt. Der Rest ist öffentlich standarisiert.

Das wird bei Set Top Boxen nicht anders gemacht, nur daß der Vendor Key noch mit reinspielt ;-)
 
Das bildet vielleicht das grobe Schema ab, aber nicht die reale Implementierung, und vor allem nicht auf Low-Level Ebene.
Jeder Hersteller gibt heute sein Süppchen dazu wenn ein SoC designed und für ein CA zertifiziert wird. Aber das würde einfach viel zu weit führen an der Stelle und es wird eh kaum einer die Dokumentation einer Realimplementierung gesehen haben um jetzt zu sagen ist so oder nicht.
 
Zuletzt bearbeitet:
Ich werde was zitieren:

The compliant chipset shall receive the Vendor ID, Ek3(K2), and a 128-bit nonce via the driver API
interface.

Da(nonce) shall be returned as the response to the CPU via the driver API interface.

The selection of which cipher to use will be controlled by the driver API interface. Only AES-128 or TDES will be used
for a root key to CW derivation chain. However, the chipset does not need to enforce this.

The drivers executing within the main CPU of the sink device are not specified in the present document because they
are platform and industry-specific. The specific driver API may be obtained from the Trusted Authority upon request.

Cau Adas
 
Schöne Doku. Kann so sein, muss nicht so sein.

Von einem DES-Quirk der V13 bzw. unterschiedlichen Modi (81, 83) ist dort auch kein Sterbenswörtchen zu finden.
 
Was sagt uns Broadcom Nexus?

Cau Adas
 
Für die Nutzung dieser Website sind Cookies erforderlich. Du musst diese akzeptieren, um die Website weiter nutzen zu können. Erfahre mehr…