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.

Loggen einer Sky-Karte mit dem Season Logger

Die Baudrate bei der das ATR gesendet wird ist NICHT immer 9600. Dies hängt von der Clock ab. Nachzulesen in ISO7816-3.
 
stimmt, aber bei 3.57 Mhz sind wir nahe an 9600bps dran:

>The initial etu is 372/fi s where fi is in Hertz.

sind zwar dann 4% abweichung, bis 3% ist aber bei UART erlaubt, somit gehts halt "einfach"

wenn jetzt der TDS866 wirklich mit 5mhz rangeht, sind wir "höher", mein TDS865 allerdings geht mit 3.57mhz ran ...

Bleiben wir trotzdem dabei, wie Fun7 sagt:

Init-Baudrate->Working Baudrate->"Ins7e11 Baudrate"

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...
 
Auch da muss man nicht herumexperimentieren. Die ersten beiden Baudrates lassen sich wie folgt berechnen:

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 dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!
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.
 
Zuletzt bearbeitet von einem Moderator:
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:

Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

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:
Du musst dich Anmelden oder Registrieren um diesen link zusehen!
 
.... 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 .... .... ... .... .... ... .... ...
 
@dtrm

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" ...
 
Ok, danke für die Aufklärung.
Ins74 mit der Cmd Table verstehe ich nun auch schonmal.
Wobei ich übrigens im Log vom CI+ Modul kein Ins4A finden kann.
 
@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
Du musst dich Anmelden oder Registrieren um diesen link zusehen!
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.
 
Das ganze wird durch asymm. Verschlüsselungen effizient unterbunden
 
Was mich interessieren würde wie antwortet eine V14 mit F0 und globalen und eine V14 ohne f0 und globalen müsste ja was anderes Antworten.



Grüße jens
 
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.
 
Es gibt aber altaktivierte V14 mit F0, welche ganz normale DCWs ausspucken
 
Die haben auch nem anderen Payload wie die ausgefallenen
 
Für die Nutzung dieser Website sind Cookies erforderlich. Du musst diese akzeptieren, um die Website weiter nutzen zu können. Erfahre mehr…