Kabuki g-Knackt!

[Thomas]

Es geht weiter und ich verstehe nichts: http://arcadehacker.blogspot.de/2014...pu-part-2.html

Geht mir ähnlich. Ab dem Punkt hier komm' ich nicht mehr mit :

If Kabuki uses an internal memory for storage then this storage must be of CMOS type, thanks to one of the manufacturer product catalogs (VTI) we already know that the Kabuki Z80 core is a CMOS part.

In theory bits of CMOS memory or registers must default to an specific value after a power loss has occurred. Normally this should be 0, but let's play and get wild by assuming internal inverters are at work and the memory output default value could also be 1.

In either case, and unless the designers of Kabuki randomized ram/register contents as part of a paranoid approach, then we could be in safe grounds when assuming that Kabuki's ram must get back a known state after a power loss has occurred.

Ja, was nützt denn das ? Strom weg, sind auch die Keys weg. Ob die Bits an der Speicherstelle, an der die Keys lagen dann nachdem der Strom wieder da ist nun alle auf Null oder Eins schalten oder gemischt sind nützt doch da nichts ? Ich kann da momentan nicht folgen

[mrdo!]

http://arcadehacker.blogspot.de/2014...pu-part-3.html

Anmerkung: In meinen Augen Stuss.

[Laschek]

Zumindest funktionierts

Grad ausprobiert:

Vorher: pink screen of death

IMG_8858[1].jpg

Auf dem Foto unpink... Batterie war sogar noch auf dem Board Zum Glück nix rausgesuddert.

Danach dann Pang:

IMG_8862[1].jpg

Wieso Stuss?

[mrdo!]

Was der Typ da macht ist bullshit... Er beobachtet das laufende Spiel in Mame und zeichnet die Opcodes auf, die angesprungen werden. Damit Patched er das encrypted ROM.
Nachteil: Wenn er in einen Teil des Programms nicht "reingespielt hat". Wirds auch nicht entschlüsselt. -> Absturz.

So clever waren viele Leute schon vor 10 Jahren.

Das ist also keine vollständige Entschlüsselung. Kann immer passieren, daß ein unbekanntes Codesegment beim spielen auf die Nase fällt.
Die "alte Methode" ist da sicherer...

[BossXxX]

^^^sag ma laschi... spielst du uffn klo? sieht fast danach aus? spülst den mist dann auch gleich runter?

[Laschek]

Das ist also keine vollständige Entschlüsselung. Kann immer passieren, daß ein unbekanntes Codesegment beim spielen auf die Nase fällt.
Die "alte Methode" ist da sicherer...

Ok.

Alles nur Fake, Kulisse, Potemkinsches Dorf, Luftblase?

^^^sag ma laschi... spielst du uffn klo? sieht fast danach aus? spülst den mist dann auch gleich runter?

Das Klo wäre daran zu erkennen dass da die meisten Fliesen runtergerissen sind.
Das hier war mal eine Küche.
Ansonsten: gehe weg!
Du unvollständige Entschlüsselung!

[mrdo!]

Naja, der Typ trägt eben bekannte Sachen zusammen. Er scheint zu glauben, daß es sich um Neuigkeiten handelt.
Das ist aber nicht der Fall.

Wo wir aber gerade beim Pang sind: Wenn man ein bischen mit mame bastelt, kann man sich ein decrypted romset erstellen.
Wenn man das z.B. für PANG macht, sind die entstehenden Roms unter schiedlich zu dem,
was auf der "dead battery society" veröffentlicht wurde!

Mich würde wirklich interessieren woher diese Differenzen kommen, bzw. wie diese Roms gebaut wurden ...

[mikemcbike]

Wie auf meiner Webseite zu lesen ist (http://www.wolfgangrobel.de/arcadereps/pang.htm), hat der Tim von Arcadecollecting einen ganz einfachen Weg gewählt:

weil er sich nicht die Mühe machen wollte, CPU-Befehle (verschlüsselt) von CPU-Daten (unverschlüsselt) zu unterscheiden, hat er einfach alles Bytes entschlüsselt, die EPROMs doppelt so groß gemacht und erst die verschlüsselte, dann die unverschlüsselte Variante darin abgelegt. Der Draht vom Kabuki (Z80-M1-Signal) steuert jetzt über das höchstwertige Adressbit an den Eproms den entsprechenden Datenbereich. Das geht, weil der Z80 bei Zugriff auf Opcodes (CPU-Befehle) das externe M1-Signal automatisch aktiv schaltet.

Das System ist popelig einfach und sicher. Und außerdem hat man ja die entschlüsselten ROMs schon mathematisch unter Verwendung der bekannten Schlüssel und Verschlüsselungsvorschriften erzeugt, siehe MAME-Source Code.

Unser Arcadehacker möchte nun einfach die M1-Steuerung überflüssig machen, indem er die Opcodes selektiv auf Schlüssel 0x00000000 verschlüsselt. Das wird bei Beobachtung eines laufenden Spiels aber immer unvollständig bleiben, weil nicht alle Programmteile abgearbeitet werden.

Ein intelligenter Disassembler könnte das Programm parsen, aber das funktioniert auch nur mit absoluten und relativen Programmsprüngen, wenn man indizierte Programmsprünge hat, also Sprünge auf Adressen, die sich z.B. durch Addition einer Programmadresse mit einem Registerinhalt ergeben, dann funktioniert das so auch nicht. Allerdings weiss ich nicht auswendig, ob der Z80 solche Adressierungen hat...

[mrdo!]

Einfaches Problembeispiel: Eine Tabelle mit Einsprungadressen. Das ist nichts ungewöhnliches. Kann kein "intelligenter Disassembler" jemals finden ...