[Main] [Docs] [Installs] [Search] [Team] [Guestbook] [Links]

Benutzung von resload_Protect#?

Theorie

Es gibt viele Situationen, bei denen es sehr hilfreich wäre informiert zu werden, wenn das installierte Programm auf bestimmte Speicherzellen zugreift. Mithilfe der resload_Protect#? Funktionen ist es möglich, bestimmte Speicherbereiche vor dem Lesen und/oder Schreiben durch den Prozessor zu schützen. Schützen meint dabei, dass jeder Zugriff auf ein solcherart markierten Bereich eine "Access Fault" Exception auslöst, die in einem Fehlerrequester von WHDLoad angezeigt wird. Wenn ein Speicherbereich durch resload_Protect#? geschützt wird, verändert WHDLoad die entsprechenden Kachel-Descriptoren im MMU-Übersetzungsbaum. Dadurch generiert jeder Zugriff auf eine geschützte Kachel durch den Prozessor eine "Access Fault" Exception. Der Exception-Handler im WHDLoad prüft den Grund für jede Exception. Wenn der Grund ein Zugriff auf eine geschützte Kache l war, aber die zugegriffene Adresse nicht in einem geschützten Bereich lag, wird der Zugriff emuliert und die normale Programmausführung fortgesetzt. Ansonsten wird das installierte Programm mit einem entsprechendem Fehlerrequester beendet. Zugriffe des Instruction-Stream (d.h. Zugriffe bei denen Prozessorcode geladen wird) werden immer emuliert, oder mit anderen Worten: die resload_Protect#? Funktionen überwachen nur das Schreiben und Lesen von Daten.
Dadurch, dass jeder Zugriff auf eine geschützte Kachel (Kachelgröße gegenwärtig 4096 Byte) ein "Access Fault" generiert auch wenn der geschützte Bereich nur eine Größe von einem Byte hat, bedingt eine starke Verlangsamung der Ablaufgeschwindigkeit des installierten Programmes. Insbesondere wenn sich Programmcode auf derselben Kachel befindet. Wenn das installierte Programm sehr von seiner Ausführungsgeschwindigkeit abhängt, können sich Unterschiede in der Ausführung ergeben. Es kann auch sein, dass einige Programme deshalb nicht mit resload_Protect zusammen arbeiten.

Beispiel: Codeprüfsummen

Wenn ein Spiel mit WHDLoad installiert werden soll, muss die original Laderoutine so verändert werden, dass sie nun WHDLoad nutzt um die Spieldaten zu laden. Einige Spiele verwenden Prüfsummen über Codebereiche um festzustellen, ob der ursprüngliche Code verändert worden ist. Solche Prüfsummenroutinen sind manchmal nicht leicht zu finden. Unter Verwendung der resload_Protect#? Funktionen in WHDLoad ist dies aber ganz einfach! Alles was man tun sollte, ist die veränderten Bytes mit Leseschutz zu versehen. Dadurch erzeugt jede Routine, die versucht eine Prüfsumme zu berechnen indem sie die geänderten Bytes liest, eine "Access Fault" Exception. Womit die entsprechende Routine identifiziert ist.

Einschränkungen

Die Kachel, auf den der SSP zeigt, darf nicht geschützt werden. Falls dies doch getan wird und eine Exception auftritt, führt dies zu einem "Double Bus Fault", weil der Prozessor nicht in der Lage ist das Exception Stackframe zu schreiben. Nach einem "Double Bus Fault" ist nur noch ein Hardwarereset möglich. WHDLoad prüft beim Setzen des geschützten Bereiches ob dieser sich mit dem aktuellen SSP überdeckt. Wenn dies der Fall ist, beendet es sich mit einer entsprechenden Fehlermeldung. Das hilft aber natürlich nicht wenn sich der SSP später ändert.

Weitere Einschränkungen und zusätzliche Informationen sind unter den entsprechenden resload_Protect-Funktionen in den Autodocs dokumentiert:

[Main] [Docs] [Installs] [Search] [Team] [Guestbook] [Links]