Die Zwingfeste in Thorwal

[siebenstreich]

Mit etwas Verspätung habe ich mir das ganze jetzt angeschaut und endlich verstanden. Vielen Dank für die Erklärung! Bisher hatte ich nicht gesehen, wo es einen Unterschied macht, dass es der unmittelbar nächste Schleifendurchlauf ist, an dem das Feld wieder betreten wird. Die entscheidende Beobachtung ist: Der Dungeon-Handler wird in jedem Schleifendurchlauf aufgerufen, und unter normalen Umständen (wenn nicht sofort wieder Pfeil-nach-oben gedrückt wurde) wird dabei die falsch gesetzte Variable gs_dng_handled_po  korrigiert.

gs_dng_handled_pos sollte nur dann auf pos gesetzt werden, wenn pos nach der Eventbehandlung auch wirklich der aktuellen Gruppenposition entspricht.

Ich glaube es gibt auch Dungeon-Felder B, wo man durch den Event-Handler zu einem dritten Feld C (also nicht das Ausgangsfeld A) geschickt wird. Bei denen wäre dann gs_dng_handled_pos (hab ich in meinem Fork jetzt in gs_dng_pos_bak umbenannt) entsprechend der Grundlogik falsch gesetzt, nämlich auf das vorletzte Feld A anstelle des letzten Feldes B. Da immer nur target_pos != handled_pos verglichen wird, ist damit vermutlich trotzdem alles stimmig. Aber 100%ig sicher bin ich mir nicht. Es muss bedacht werden, dass sich die Gruppe immer auch mit einem Transversalis bewegen kann, beispielsweise auch von C nach B.

Ich verstehe aktuell noch nicht vollständig, warum „Vorwärts (↑) gedrückt halten“ nur manchmal zuverlässig greift (bei niedrigen Cycles oft konsistenter, bei hohen teils gar nicht).

Ich kenne mich mit hardwarenahen Sachen nicht gut aus, aber es ist (bzw. war zu MS-DOS Zeiten) doch wohl irgendwie so:

Beim Gedrückthalten einer Taste produziert der hardwareseitige Tastatur-Controller den Tastenanschlag dieser Taste immer wieder, mit einer gewissen Frequenz: Zwischen erstem und zweitem Anschlag mit ~1/2 Sekunde delay, danach mit einer repeat rate von ~10 Zeichen pro Sekunde oder auch etwas mehr.

Deswegen klingt es für mich durchaus plausibel, dass die Tastatur das Anschlagsignal nur manchmal schon so früh erzeugt, dass der Exploit greift. Senkt man die cycle-Rate der dosbox, so läuft das Programm langsamer, bei gleich bleibender repeat rate der Tastatur. Damit vergrößert sich das Zeitfenster, innerhalb dessen der Tastananschlag eintreffen muss. Die Folge ist eine erhöhte Chance für das Eintreten des Exploits. Bei ausreichend kleiner cycle-Rate ist das Zeitfenster länger als ein ganzer repeat-Zyklus der Tastatur. Der Exploit funktioniert dann zu 100%.

Es gibt ja auch einen BIOS-seitigen Puffer für nicht abgearbeitete Tastenanschläge. Man müsste nach einer Möglichkeit suchen, den Puffer vorab entsprechend zu befüllen, so dass die Aktionen "erstes Betreten des Felds", "Auswahl der Antwort auf die Textbox", "zweites Betreten des Felds" komplett durch vorgepufferte Tastenanschläge ausgelöst werden. Dann sollte der Exploit meinem Verständnis nach zuverlässig funktionieren.

Insgesamt bauen wir hier natürlich auch darauf, dass die Dosbox Hardware und BIOS von damaligen Rechnern exakt simuliert. Im Prinzip müsste man den Exploit an einem originalen 386er mit MS-DOS testen (und nicht nur in der Dosbox), um sicher zu sein.