Nieuwe AutoUp uit Seca

[Gast]

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