Update zum Updater
Durch die Arbeit am BTS_Wrapper ist mir jetzt noch eine bessere Lösung eingefallen um die Kollision der Threads beim Redraw zu verhindern. Ich halte den Hauptthread von Civ4 kurz an. (Keine Macht den MutexenZitat von Ramkhamhaeng
)
Im Allgemeinen eine gefährliche Idee, aber hier geht es wunderbar.
Ich dachte wir hatten die pitboss server exe dazu schonmal gepatcht. Ich habe zumindest ziemlich lange im IDA zugebracht um dann ein paar Instruktionen mit NOPs zu ueberschreiben.
Achtung Spoiler:
Und ich bin dir für den Patch immer noch sehr dankbar
Und ich frage mich ob dieses Ladeproblem auch unter Windows auftreten kann. Damals hatte ich ja das Problem dass sich bestimmte Spielstände nicht auf deinem Server, oder lokal bei mir, aber auf einem Windows-Rechner laden ließen.
Jetzt habe ich Spielstände, die ich auf keinem System laden kann obwohl sie valide aussehen (Ich müsste allerdings noch probieren diese Spielstände aber noch mit der Zulan-Exe zu laden. Dann würde sich die Theorie bestätigen oder kann verworfen werden.)
Etwas anderes. Man wird nach den Jahren immer noch überrascht. Der folgende Code erstellt nur eine Liste von Einträgen, einer pro Spieler, die auf der letzten Seite im PB-Spielerstellungs-Wizard angezeigt werden. Interessanterweise braucht es (Edit: Auf meinem Laptop) rund 15 Sekunden bis diese Schleife durchlaufen ist
Achtung Spoiler:
Das irgendwie zu beschleunigen ist mir nicht gelungen, aber zumindest konnte ich den Aufruf der Schleife vom Programmstart entkoppeln. Denn normalerweise will man ja einen Spielstand laden und dann braucht man das ja gar nicht...
Geändert von Ramkhamhaeng (26. Juli 2018 um 19:15 Uhr)
Ah, jetzt verstehe ich glaube ich. Die Pruefsumme ist im Save gespeichert und du vermutest die wird beim Speichern falsch berechnet - darum klappt das laden in keinem Client? Ich fuerchte es ist deutlich schwerer die Berechnung beim Speichern zu beheben als das Laden einfach blind zu erlauben - zumindest solange wir keine Ahung haben warum das berechnen beim schreiben fehlschlaegt. Hast du ne Ahnung was das fuer ne Pruefsumme ist und auf welche Repraesentation der Daten die angewendet wird?Und ich bin dir für den Patch immer noch sehr dankbar
Und ich frage mich ob dieses Ladeproblem auch unter Windows auftreten kann. Damals hatte ich ja das Problem dass sich bestimmte Spielstände nicht auf deinem Server, oder lokal bei mir, aber auf einem Windows-Rechner laden ließen.
Jetzt habe ich Spielstände, die ich auf keinem System laden kann obwohl sie valide aussehen (Ich müsste allerdings noch probieren diese Spielstände aber noch mit der Zulan-Exe zu laden. Dann würde sich die Theorie bestätigen oder kann verworfen werden.)
Da sind halt ne Menge calls drin in denen irgendne furchtbar ineffiziente Implementierung schlummern koennte. Normalerweise muesste man halt nen profile machen, aber ich weiss nicht ob das in dem Kontext so einfach ist.Etwas anderes. Man wird nach den Jahren immer noch überrascht. Der folgende Code erstellt nur eine Liste von Einträgen, einer pro Spieler, die auf der letzten Seite im PB-Spielerstellungs-Wizard angezeigt werden. Interessanterweise braucht es rund 15 Sekunden bis diese Schleife durchlaufen ist
Achtung Spoiler:
Das irgendwie zu beschleunigen ist mir nicht gelungen, aber zumindest konnte ich den Aufruf der Schleife vom Programmstart entkoppeln. Denn normalerweise will man ja einen Spielstand laden und dann braucht man das ja gar nicht...
Achtung Spoiler:
Ja, genau das wollte ich ausdrücken. Im PAE_PB brauchen die Spieler teilweise drei Loginversuche. Es gibt zwar von den Spielern auch die Vermutung, dass es am BTS_Wrapper liegt, aber ich habe so ein kritisches Save überprüft. Da ist Client-Save = Server-Save und ich kann es manuell auch nicht laden. Daher glaube ich nicht daran, dass es daran liegt.
Die Prüfsumme sind die letzten 32 Bytes (String der Zahl). Da sie viel mit MD5 gearbeitet haben sollte sie auch mit MD5 erstellt worden sein. Es gibt aber zwei Probleme.
1. Meiner Meinung nach fließen die ersten Bytes des Saves, die beispielsweise den Mod-Namen enthalten, nicht in die Prüfsumme.
Müsste man noch mal testen, aber WIMRE kann man den Modnamen anpassen ohne die Ladbarkeit zu verlieren.
2. Ich habe schon mal md5(SAVE[A:B]) mit der Prüfsumme verglichen und kein Match gehabt.
D.h. ich habe entweder die Prüfsummen-Bytes nicht korrekt interpretiert (BigEndian, LittleEndian, ?!?) oder es geht noch ein Seed, z.B. aus DLL/Python-Code-Prüfsumme, ein.
Wegen 2. war es mir bisher nicht möglich Saves mit der richtigen Prüfsumme zu versehen.
Dadurch sind sie immer nur durch deine Pitboss-Exe ladbar. Eines der letzten Rätsel
Edit: Zur Sicherheit erwähne ich diesen Fakt noch:
Der Vergleich mit der DLL/Python-Prüfsumme ist eigentlich eine separate Baustelle. Wenn man die Mod-Daten ändert meldet er sich ja mit der Fehlermeldung „Mod-Daten“ wurden geändert.
Bei Änderungen am Save erhält man dagegen die Meldung a la „Save konnte nicht geladen werden“.
Spricht eigentlich gegen die Vermutung, dass diese zwei Prüfsummen zusätzlich auch noch in die Checksumme des Saves eingehen.
Geändert von Ramkhamhaeng (26. Juli 2018 um 19:43 Uhr)
Im save ist ein zlib-komprimierter Teil drin. Ich vermute der wird erst entpackt, weil wenn man da rumschreibt gibt es erstmal einen decompression error. Der teil ist aber auch nicht direkt der input zum md5. Kann durchaus sein, dass die da was "geheimes" davor packen. Schwierig ist, dass wirklich wahnsinnig viel md5 gemacht wird - die Konstanten dazu sind leicht zu finden, stehen aber an 11 Stellen im code - hab noch nicht gefunden was da genau rein geht.Ja, genau das wollte ich ausdrücken. Im PAE_PB brauchen die Spieler teilweise drei Loginversuche. Es gibt zwar von den Spielern auch die Vermutung, dass es am BTS_Wrapper liegt, aber ich habe so ein kritisches Save überprüft. Da ist Client-Save = Server-Save und ich kann es manuell auch nicht laden. Daher glaube ich nicht daran, dass es daran liegt.
Die Prüfsumme sind die letzten 32 Bytes (String der Zahl). Da sie viel mit MD5 gearbeitet haben sollte sie auch mit MD5 erstellt worden sein. Es gibt aber zwei Probleme.
1. Meiner Meinung nach fließen die ersten Bytes des Saves, die beispielsweise den Mod-Namen enthalten, nicht in die Prüfsumme.
Müsste man noch mal testen, aber WIMRE kann man den Modnamen anpassen ohne die Ladbarkeit zu verlieren.
2. Ich habe schon mal md5(SAVE[A:B]) mit der Prüfsumme verglichen und kein Match gehabt.
D.h. ich habe entweder die Prüfsummen-Bytes nicht korrekt interpretiert (BigEndian, LittleEndian, ?!?) oder es geht noch ein Seed, z.B. aus DLL/Python-Code-Prüfsumme, ein.
Wegen 2. war es mir bisher nicht möglich Saves mit der richtigen Prüfsumme zu versehen.
Dadurch sind sie immer nur durch deine Pitboss-Exe ladbar. Eines der letzten Rätsel
Edit: Zur Sicherheit erwähne ich diesen Fakt noch:
Der Vergleich mit der DLL/Python-Prüfsumme ist eigentlich eine separate Baustelle. Wenn man die Mod-Daten ändert meldet er sich ja mit der Fehlermeldung „Mod-Daten“ wurden geändert.
Bei Änderungen am Save erhält man dagegen die Meldung a la „Save konnte nicht geladen werden“.
Spricht eigentlich gegen die Vermutung, dass diese zwei Prüfsummen zusätzlich auch noch in die Checksumme des Saves eingehen.
FYI
Code:import zlib import hashlib with open('./test.CivBeyondSwordSave', 'rb') as f: data = f.read() for i in range(len(data) - 1): if data[i] == 0x78 and data[i + 1] == 0x9c: z_begin = i break z_begin for z_end in range(len(data), z_begin, -1): if (data[z_end-4] == 0x00 and data[z_end-4] == 0x00 and data[z_end-2] == 0xFF and data[z_end-1] == 0xFF): break print(z_end) decomp_obj = zlib.decompressobj() udata = decomp_obj.decompress(data[z_begin:z_end]) print(len(uncomp_data))
Achtung Spoiler:
Das mit dem Zlib-Teil ist neu für mich.
Die Bedeutung der Prüfsummen am Beginn des Saves habe ich früher schon mal ermittelt. Auf 11 Stellen bin ich nicht gekommen, aber in der Nummer sind bei deinem Testsave vielleicht die md5-Werte der Spielerpasswörter enthalten.
1. Hash = ?
2.-5. Hash = DLL-, Python-, XML-Prüfsummen plus vierte in mir gerade unbekannter Reihenfolge. (Edit: Vierte vielleicht ein Wert, welcher der Civ-Exe zugeordnet ist.)
6. Hash = Adminpassword (als wchar)
Danach Spieler-Infos und danach die Spielerpasswörter (als wchar). Etwas genauer kommentiert in z.B. ~/ramk/FindRound.py
Ist das Spiel nicht passwortgeschützt fallen die 6. Hashs weg bzw. enthält das Save Verweise auf Strings der Länge 0
Geändert von Ramkhamhaeng (27. Juli 2018 um 00:49 Uhr)
Der gezippte Teil nimmt fast das gesamte Save ein und wird aus den Spieledaten bestehenAllerdings wundert mich die hohe Kompressionsrate da es binäre Daten sind. Allerdings kann die Rate durch viele Nullen in Arrays erklärt werden.
> python dein_code.py
Z_Begin: 3780
Z_end: 17926
Len data: 14146
Len data uncompressed: 1744511
>~/Civ4$ du -b Example_v8.CivBeyondSwordSave
18012 Example_v8.CivBeyondSwordSave
@Zulan
Bei den Civfanatics hat DarkLunaPhantom darauf hingewiesen, dass unserer derzeitiges Parsing des Date-Strings nicht vollständig ist. Es gibt bestimmte Einstellungen bei denen nicht nur Jahreszahlen und die Monate Januar und Juni im String vorkommen.
Das auf weitere Monate zu erweitern ist kein Problem, aber Civ4 bietet auch noch weitere Kalendertypen (CALENDAR_WEEKS, CALENDAR_SEASONS, …) und Mods können theoretisch noch ganz andere Typen definieren.
Da wird es schwierig das mit einer Zahl, derzeit Jahr + 10000*Monat, abzuspeichern.
Außerdem wurde ich dadurch nochmal auf den Fakt gestoßen, dass wir die Eingabewerte für „Game name“ und „Mod name“ gar nicht ausreichend parsen. XSS-Attack incoming
Ich würde vorschlagen die beiden String-Eingabefelder werden durch eine Djangofunktion zum Entfernen von Tags gejagt.
Aber was machen wir mit der Date-Angabe. Feld auch in einen String umwandeln oder den Parser der Eingabe verfeinern?
Ist das (1. / 2.) ein theoretisches oder praktisches Problem?
Das wird beim ausgeben automatisch gestripptAußerdem wurde ich dadurch nochmal auf den Fakt gestoßen, dass wir die Eingabewerte für „Game name“ und „Mod name“ gar nicht ausreichend parsen. XSS-Attack incoming
Ich würde vorschlagen die beiden String-Eingabefelder werden durch eine Djangofunktion zum Entfernen von Tags gejagt.
Aber was machen wir mit der Date-Angabe. Feld auch in einen String umwandeln oder den Parser der Eingabe verfeinern?
https://docs.djangoproject.com/en/2.1/topics/security/
Achtung Spoiler:
Zumindest bei den Monatsnamen war es ein praktisches Problem. Werde den Filter vermutlich einfach nur etwas erweitern.
Ist das (1. / 2.) ein theoretisches oder praktisches Problem?
Automatisch wird leider an der Stelle nichts gefiltert. In http://civ.zulan.net/pbspy/game/1/#game_log habe ich z.B. jetzt einen Link mit alert-Popup eingefügt.Das wird beim ausgeben automatisch gestrippt
https://docs.djangoproject.com/en/2.1/topics/security/
Die Eingabe kommt ja vom PB-Server und nicht von Formular-Eingabefeldern, etc von der Seite.
Das ist halt die eine Stelle mit autoescape
Fuer die Listenformatierung und so, ist halt doof wenn man die Formatierung nicht im Template macht...Code:{% autoescape off %} <td class="colEvent">{{ logentry.message }}</td> {% endautoescape %}
Achtung Spoiler:
Ich hab das jetzt gefixt, auch bei der victory condition. Sind jetzt noch exakt listen und Bilder erlaubt.
Achtung Spoiler:
Danke, schneller als ich und sicher auch eine elegantere Lösung
Bei der Änderung in .gitignore sind, glaube sowohl meine Variante als auch deine Variante nicht korrekt.
- ./static filtert nix
- static filtert alle static-Ordner/Dateien
- /static filtert nur auf dem Top-Level
Bei Variante zwei wird auch das Unterverzeichnis pbspy/static ignoriert.
Fixed :-)Danke, schneller als ich und sicher auch eine elegantere Lösung
Bei der Änderung in .gitignore sind, glaube sowohl meine Variante als auch deine Variante nicht korrekt.
- ./static filtert nix
- static filtert alle static-Ordner/Dateien
- /static filtert nur auf dem Top-Level
Bei Variante zwei wird auch das Unterverzeichnis pbspy/static ignoriert.
Was uebrigens nervig ist: Django 1.11 (die aktuelle LTS) supported kein python 3.7. Da gibt es eine Stelle mit einem one-liner Fix aber die wollen den nicht backporten weil 1.11 ja nur security fixes bekommt. Ich muss jetzt immer beim Django update (auf eine neue 1.11.x) den Patch manuell einspielen. Auf 2.1 updaten wollte ich aber auch nicht, dann eigentlich erst 2.2 (wieder LTS).
Achtung Spoiler:
Berechtigungen
Zitieren
