Nieuwe AutoUp uit Seca

5 december 2000

Zie bijlagGääähnn.....Tschuldigung, ich hatte eine lange Nachtschicht betreffend Goldwafer :-). Ich habe mich hingesetzt und das Goldwafer Autoupdate File neu bearbeitet. Ich will eine Einheitliche Norm fürs EEPROM schaffen. Nun ist es geschafft. Die Non Publik Version von meinem ATMEL Autoupdate SECA File hat den gleichen EEPROM Inhalt wie die Publik Goldwafer Autoupdate Version. Es läuft wunderbar. Jedoch ist nun das Problem mit unseren lieben Spaniern :-). Die Jungs tun alles um uns bei Laune zu halten. Nach einer 8 Stündigen Log Season konnte ich nun einige Strings auswerten. Ja, sie senden Fake Keys. Mit anderen Worten für die, die nicht soviel Ahnung haben. Bei Autoupdate und Taquila kommt ein Bild und verschwindet wieder :-) um es mal ganz einfach auszudrücken. Ich habe die beiden INST 40 Kommandos mal Decryptet und Leserlich zusammen gestellt. Hier mal die Inhalte vom Guten String und dem Fake String:// Fake String //32 BIT Providermatrix crypted 5d 16 42 37 F0 18 EC 3C 08 10 12 24 C0 03 24 F0 8B 0E 3C 3B 95 08 E8 58 6E 22 44 0D BD 2A 86 9F22 15 5F // Prüft datum des Abonenten 21 15 9F // setzt Datum 90 5D A0 25 38 B9 76 1A ED 8D // Schreibt Key 0D 90 5C B0 B0 6B 0C 88 D8 EC BF // Schreibt Key 0C 90 5E A3 8A B3 2C 9C F5 EC 84 // Schreibt Key 0E 82 BF 7B B8 4D D2 7D 22 B5 // 8Byte Signatur//Good String //32 BIT Providermatrix crypted ba f5 b2 ae 3E 88 6B 7F E5 0A 59 5F 4F 7D 48 EF 43 9C 54 F6 DA E3 B9 86 75 32 29 75 BA 82 9C 3F22 15 7E // Prüft datum des Abonenten 21 16 3F // setzt Datum 90 5C AE 50 D2 BF 91 8A 4A D7 // Schreibt Key 0C 90 5D 4D 18 7A 74 86 3E 1E 9F // Schreibt Key 0D 90 5E 5A 1D B3 DD 48 22 12 31 // Schreibt Key 0E 82 56 D6 51 41 38 4E 7A B7 // 8Byte SignaturNun wollen wir mal mit unserer Goldwafer eine neue Gegenwehr dafür Basteln. Welche Möglichkeiten haben wir ? Zum einem können wir einfach die PPUA raus nehmen, jedoch ist dann unsere Karte nicht mehr Autoupdatefähig. Also vergessen wir das. Dann kann man noch die Providermatrix zu hilfe nehmen. Ich habe diese nun nicht entschlüsselt, aber man sieht, dass nicht alle Karten mit dem Fake String angesprochen werden. Also bleibt uns die Möglichkeit eine 'CB20' Auswertung in die Goldwafer mit einzubauen. Damit währe sichergestellt das auch das letzte byte der PPUA ausgewertet wird und nur dann die Keys geschrieben werden, wenn unsere vollständige PPUA angesprochen wird. Dies währe eine sehr gute Lösung. Jedoch verbraucht diese variante sehr viel Programmspeicher im PIC. Dann gibt es noch die Möglichkeit, die Reihenfolge der gesendeten Keys auszuwerten. Wir sehen im Fake String ja, das die Reihenfolge 0D,0C,0E beträgt. In allen anderen Strings von div. Anbietern ist immer die Reihenfolge 0C,0D,0E. Auch ein guter Punkt um dort anzusetzen. Jedoch würden die Spanier dann vieleicht im Fake String die Reihenfolge auch ändern. Also nicht 100%ig das ganze. Aber für eine vorrübergehende Lösung das einfachste. Dann ist noch die Sache mit dem Date. Zwar weiss ich nicht was die Jungs da genau Auswerten, jedoch könnte man dort auch ansetzen. Immerhin sind die Date angaben vom Fake String anders als die vom Guten String. Leider fehlt mir ein 2. String vom Vormonat um genau zu sehen wie sie damit arbeiten. Aber diesen Punkt könnte man mal festhalten. Und zum guten Schluss bleibt noch die Sache mit der 8 Byte Signatur. Wir könnten eine Signaturüberprüfung machen, jedoch würde das in diesem Fall nichts bringen, da die Signatur in beiden Fällen i.O. ist. Warum nun MOSC Karten nicht darauf anspringen liegt wahrscheinlich mit dem Date zusammen. Nun haben wir alle endlich wieder mal was zu Basteln. Mal sehen wie ich mein Autoupdate File umschreiben werde. Ich glaube ich nehme die Reihenfolge der Keys zuerst..... Ihr seht nun das ich wieder Hände voll zu tun habe, deshalb kann ich nicht so oft im Netz präsent sein. Auf gehts........

Inloggen

Nieuwe AutoUp uit Seca

Aanbevolen berichten

Gast

Wie is er online 0 leden

Overig

Activiteit