Im 38C1 Hardware EMM. Der Ins7E, alles was da vorn steht ist gleich. Nur die Daten hinten sind anders. Für Generic, den Rest macht doch der zuordner der Karte.
Dachte NDS nutzt eine Art AES light!? ;-)
Aber so oder so ist die Keylänge gleich. Bräuchte man nur noch eine derbe Leistungsstarke Maschine (welche es nicht gibt) und man müsste sich die videoguard2.c auf AES anpassen und natürlich das WebIf für die Bequemlichkeit
Bruteforce schließe ich bei AES aus, auch mit Vereinfachung durch Crypto-Analyse.
Geht denn die grobe Richtung im Moment eher zu 'Hardware-hacken um an die Keys zu kommen' oder zu 'Smartcard austricksen daß sie wieder DES oder gar plain nutzt' ? Dritte Alternative wäre, plain control words in der Hardware abgreifen.
Wenn man sich mal mit den AES Cryptanalysen der letzten 10…20 Jahre befasst, kann man schon den Eindruck bekommen, dass AES mit heutiger Technik “knackbar“ ist.
Mein Tipp ist, z.Z. Plain-CWs aus irgendeiner Hardware.
TAG56 CW Teil:
TAG 56: 56 08 7A 94 E2 C1 99 D6 BD C5 45 03 40 00 80 2B
Die 56 08 sowie die 45 03 40 00 80 2B scheinen immer gleich zu sein, daher die Mitte ist der 2te CW Teil.
Heißt mein "AES crypted CW" lautet B0E9BE3E594211A17A94E2C199D6BDC5.
Ob die 0en im eCW am Ende oder am Anfang sind ist für das AES CW egal, die Reihenfolge dessen ist immer wie im Payload.
1 Teil CW, 2 Teil TAG56.
Dieses "AES crypted CW" entschlüsselt man nun mit dem passenden AES Key (wenn man denn einen hätte).
Und nimmt vom Ergebnis die erste Hälfte um auf sein final gültiges DCW zu kommen.
Man kann sich das auch alles im Oscam Code für den dimeno_magic bzw. Astro Key Prozess anschauen (Kommentare von mir ergänzt).
Edit am 08.01.22:
Fehler im Beispiel behoben, ursprünglich war meine Denke der Tag 56 muss immer mit den 0en im eCW getauscht werden (mal vorne mal hinten), das ist aber falsch, er muss immer ans Ende des eCW.
So wie auch die Reihenfolge im payload ist. Erst das CW dann der Tag56.