08.01.2021, 02:53
(Dieser Beitrag wurde zuletzt bearbeitet: 08.01.2021, 09:59 von siebenstreich.)
Noch was ist mir aufgefallen: An zwei Stellen (Zeile 419 und 466) in der Funktion seg038 steht in BrightEyes der Kommentar "Original-Bug" drin. Es handelt sich zweimal um eine Verzweigung mit der Bedingung
(l_var5 < 0) || (l_var5 > 23) || (l_var4 < 0) || (l_var5 > 23)
Hier wird also "l_var5 > 23" doppelt abgetestet. Beim zweiten Mal sollte es wohl "l_var4 > 23" lauten.
Offenbar bezeichnen l_var5 und l_var4 die x-y-Koordinaten eines Kampffelds.
In Abhängigkeit von der Verzweigung wird später was an die Stelle (25 * l_var5) + l_var4 in CHESSBOARD_CPY reingeschrieben.
Potentiell wird also hinter den Speicherbereich rausgeschrieben bzw. der Inhalt eines anderen Felds überschrieben.
(Seltsamerweise wird l_var5 mit 25 multipliziert wird und nicht wie eigentlich zu erwarten mit 24. Ist l_var nur um eins zu groß (d.h. l_var4 == 24), dann passiert also noch nichts.)
Falls die Stelle durch den Patch noch nicht korrigiert ist, sollte das also gemacht werden.
Mit Glück behebt das den Bug schon, woran ich aber nicht so recht glaube.
(l_var5 < 0) || (l_var5 > 23) || (l_var4 < 0) || (l_var5 > 23)
Hier wird also "l_var5 > 23" doppelt abgetestet. Beim zweiten Mal sollte es wohl "l_var4 > 23" lauten.
Offenbar bezeichnen l_var5 und l_var4 die x-y-Koordinaten eines Kampffelds.
In Abhängigkeit von der Verzweigung wird später was an die Stelle (25 * l_var5) + l_var4 in CHESSBOARD_CPY reingeschrieben.
Potentiell wird also hinter den Speicherbereich rausgeschrieben bzw. der Inhalt eines anderen Felds überschrieben.
(Seltsamerweise wird l_var5 mit 25 multipliziert wird und nicht wie eigentlich zu erwarten mit 24. Ist l_var nur um eins zu groß (d.h. l_var4 == 24), dann passiert also noch nichts.)
Falls die Stelle durch den Patch noch nicht korrigiert ist, sollte das also gemacht werden.
Mit Glück behebt das den Bug schon, woran ich aber nicht so recht glaube.