für ein vollständiges Log brauchen wir 3 Baudraten, da alles "wichtige" erst nach dem ins7e11 kommt, reicht es ansich auf diese zu gehen, die bekommt man nun durch probieren raus, man weiß ja was man sucht -> Dx 40, Dx54 am Anfang vom paket, oder mit einem Osziloskop...
Damit lässt sich dann das ins7E loggen. Das ins7E sendet ein Byte, welches das TA1-Byte des ATR ersetzt. Damit verändert sich der Wert D und somit auch die Berechnung der Working Baudrate. Hier eine Tabelle, aus der sich der neue Wert ablesen lässt:
Du musst angemeldet sein, um Bilder zu sehen.
Du musst angemeldet sein, um Bilder zu sehen.
Als Beispiel mal das ACL:
- 2-mal wird die Karte bei 6MHz resettet. Daher auch 2-mal ein ATR bei entsprechender Baudrate.
- 1-mal Reset bei 3,579MHz, daher ATR bei 9600bps und ins7E bei entsprechender Working Baudrate.
- ins7E hat den neuen TA1-Wert=0x14=00010100 --> FI=372 --> D=8
- 1-mal Reset bei 4,25MHz. Baudrates mit FI=372 und D=8 berechnen.
Hi,
falls es schlaueren Menschen als mir hilft beim Interpretieren der Logs:
Ich habe mal messtechnisch ermittelt bei welchen Instructions (erste 2 Byte, Class&Code) die Nutzdaten von der Karte gelesen werden (read) und bei welchen sie an die Karte gesendet (write) werden:
Was die Baudrate angeht kann ich zwar nichts zum ACL sagen, aber das CI+ Modul arbeitet bei 4,5MHz was bedeutet:
ATR=12096, Rest=48387
Und ins7E ist dort identisch mit TA1 aus dem ATR, also keine dritte Baudrate.
Ansonsten noch ein Gedanke wegen der Session-Key Sache.
Wäre es eine Idee eine Smartcard zu emulieren um verschlüsselte Instructions zu empfangen&entschlüsseln?
Im Anschluss könnte man diese dann mit eigenen Keys verschlüsselt an eine echte Karte senden um zu sehen was die Karte daraufhin zu sagen hat.
Das könnte man dann wieder der emulierten Karte beibringen usw.
... also keine Ahnung ob das Sinn macht... falls schon wäre das vielleicht eine Ausgangsbasis:
.... ob gelesen oder geschrieben wird, kann man aber auch so "sehen", zumal beim lesen vorher mit gleichem INS abgefragt wird, wieviel Bytes zurückgegeben werden ...
Beispiel:
d0 70 0080 01 -> 70 -> 26 -> 9000
d0 70 0000 26 -> (70) -> [0x26 Daten] -> 9000
Hier wird vorher "gefragt" wieviel Ins70(00,00) an Daten zurückgibt, karte antwortet 0x26
dannach wird gleiches Ins ohne gesetzten Bit in P2 mit 0x26 abgefragt ...
....
Am Smartcard Emulator wirst du bei NDS aufgrund des ZKT scheitern, am Entschlüsseln der Class D3 scheiterst du am unbekannten CardKey vom B4 ... NDS willkommen im Jahr 2016 .... (ok, das ist seit 2007 schon so ...), nicht ohne Grund ist NDS eines der sichersten Systeme, wenn die hier an der Stelle schon schlampen würden, könnte die auch gleich das ROM-Dump rausrücken ...
Programmiert man die Kommunikation aber nach Log selbst nach, sei es mit modifizierten oder originalen Oscam, oder eigenem Programm, kann man D3 entschlüsseln und siehe da, ein CCW erscheint .... .... ... .... .... ... .... ...
Das mit der Längenabfrage hab ich auch inzwischen gesehen und verstanden.
(Allerdings erst nachdem ich die Datenrichtung wusste.)
Und ich glaube ich habe auch manche Lese-Abfragen gesehen ohne dass vorher die Länge abgefragt wurde.
Daher dachte ich die Liste könnte trotzdem nützlich sein...
Also mir ging es nicht darum einen voll funktionsfähigen Emulator zu machen der auch Sender entschlüsseln kann.
Lediglich darum evtl. ein Hilfsmittel zu haben um die per Session-Key verschlüsselte Kommunikation zu verstehen.
Ich hätte gedacht das ist nötig um diese irgendwie nachzuprogrammieren?
(kenne mich zu schlecht aus, sorry falls ich Mist schreibe)
Ja nee, Emulator zum entschlüsseln meine ich auch nicht, das "Problem" ist, das NDS ein ZKT (Zero Knowledge Test) macht Ins4A und Ins5A, da sendet dir der Receiver was, du musst es verrechnen und er vergleicht, ergebniss: du kannst nicht verrechnen, sendest "mist" und Receiver sagt:nö du nix karte, nicht mit mir .... man könnte an der Stelle allerdings ein Routing zu einer echten Karte machen, dann würde es auch wieder gehen ... alles in allem reicht zum verstehen der Oscam Source eigentlich völlig aus, diesen einmal komplett durcharbeiten, mit einem Log (oscam decrypted, log receiver) daneben und man ist im Bilde ... entschlüsseln braucht man die Kommunikation eigentlich nicht, da steht auch nichts neues drin ...
Und ja, es gibt auch Leseabfragen ohne vorher die Länge abzufragen, da manche Ins feste längen haben, guck dir auch mal die Antwort von Ins74 an, dort stehen alle Befehle drin, welche deine Karte kann .... interessant ist ausserdem Ins58 (Kartendaten) und Ins70 (Entitlements), wenn du wissen willst wie's "die ticken" ...
@hansipetii Auf die Smartcard AES Firmware bin ich auch schon gestoßen. Damit kann man auch sehr gut eine Smartcard emulieren, z.B. mit einem Atmega 644. Problem ist jedoch das Timing bei geringer Taktrate. Man müsste bei den benötigten Geschwindigkeiten den Atmega mit einer anderen Clock ausstatten und dann über einen externen Interrupt die Bits lesen. Vorteil dieser Variante ist die richtige Implementierung der Spezifikationen. Viel einfacher ist es allerdings eine vorhandene UART Schnittstelle mit dieser
Sie müssen registriert sein, um Links zu sehen.
zu verwenden. So kann man ziemlich leicht mit einem Arduino oder Ähnlichem eine Smartcard emulieren. Den ZKT gibt es ja nur bei originalen Geräten. Beim ACL könnte man möglicherweise schon die Daten entschlüsseln. Dazu müsste man aber den Schlüsselaustausch genau verstehen.
Ich finde die Möglichkeit interessant einen Smartcard Emulator als Oscam Client zu verwenden.
V14 / F0 / Global antwortet nicht mit plaintext CW, V14 ohne F0 mit "globalem" antwortet ganz "normal" mit CW im bekannten Camcrypt.
Ohne global ebenfalls kein CW.