[Sacred 2 Loka-ID reverse engineering tool]

Nice that there is such a tool now.  I lack the time to go test it, but I think people who will use it will know what they do. Legally (at lest here) it is not reverse engineering but finding the addresses of items.

Yes, sadly hashes need brute force and intelligence, human or artificial, to 'decipher'. Czevak and me had a discussion 11!!! years back.

Quote

czevak 56

Started conversation: February 10, 2011 · IP

Hi Chattius,

 

soso die Patentante war mal Serienschauspielerin? Lindenstraße?

 

Der eigentliche Grund meiner PN ist ein kleines (oder großes) Mathe Problem. Wir haben die global.res von Sacred 2 ja geknackt und können neue texte einfügen. Soweit so gut. Jede Textzeile in der global wird über eine eindeutige Nummer aufgerufen (hash). Diese Nummer berechnet sich aus der entsprechenden LokaID. Wir wissen wie man aus der LokaID den Hash berechnet. Umgekehrt ist das leider schwierig. Wenn ich also wissen will wie z.B. die Bonusbezeichnungen auf die Waffen kommen, muss ich zurückrechnen können wie die LokaID ungefähr aussieht.

 

Bei vielen LokaIDs wie z.B. Waffen- oder Setnamen ist das einfach wie BLUEPRINT_%s oder SET_%s (%s steht für irgendeine Zahl). Bei den boni ist das nicht so einfach zu erraten.

 

zur eigentlichen Formel wie sich die Hashes berechnen:

 

Die Buchstaben der LokaID gehen mit ihren ascii Werten ein (egal ob groß oder kleinbuchstaben). Daraus ergibt sich z.B. für a der Wert 65, b=66 ... z=90. Die Zahlen 0-9 haben die Werte 48-57. Das Spiel berechnet den Hash folgendermaßen:

 

(Wert 1. Zeichen) * 113 + (Wert 2. Zeichen)

 

Kommen danach noch weitere Zeichen wird das Endergebnis immer zuerst mit 113 multipliziert und dann der Wert des kommenden Zeichens addiert.

 

Jetzt kommt das fatale daran: Die speichervariable hat nur 32Bit. Wann immer das Ergebnis 4294967296 übersteigt, wird nur noch mit dem Rest der darüberliegt weitergerechnet.

 

Ich hab schon probiert durch beispielreihen wieder auf die unglaublich großen ursprünglichen Hashes (Realhash) ohne wegfallen der vielfachen von 4294967296 zurückzurechnen, damit ich dann einfach die rechenoperationen umdrehen kann, aber das ist immer eine Formel mit zwei variablen:

 

Realhash = X * 4294967296 + Sichtbarer Hash.

 

Ich kenne weder den Realhash, noch X genau. X ist sicher irgendwie von der Zeichenfolge der LokaID abhängig, aber wie genau verschließt sich mir.

 

Bei LokaIDs mit 5 Zeichen kann X schon 2 oder 3 sein. Bei 6 Zeichen schon alles zwischen ca. 281 und 389. Darüber wird's schnell unübersichtlich.

 

Ein paar Hashes zum üben und nachdenken:

 

aa: 7410

ab: 7411

abcde: 10694172943

UI_BONUS_123: 2435574601

BLUEPRINT_3458: 1245813544 (Realhash=32659581183857795897455909672!)

 

Vllt. findest du ja irgendeine Möglichkeit. Ich bin mit meinem Latein jdflls. am Ende.

 

Liebe Grüße,

Mario.

----

Quote

chattius 1,887

Replied: February 14, 2011 · IP

Die Schwierigkeit ist dass Hash-Funktionen verschiedene ursprüngliche Strings auf die gleiche Zahl abbilden können. So dass du nicht explizit zurückrechnen kannst. Vielleicht kann die NSA oder der BND helfen, aber ich sehe nur eine Chance wenn du den Definitionsbereich stark einschränken kannst und dann eine Brute-Force-Attacke fährst.

 

Wo taucht denn das Problem auf? Das Spiel verwendet den Hash-Wert um in einer Tabelle nachzuschlagen welcher Bonus verwendet wird? Und ihr kennt nur den Hashwert? Kommt der 'gehashte' Text in der Tabelle vor?

 

Wenn du zum Beispiel die Vermutung hast, dass der Text BLUEPRINT_xxx ist, dann kann man das schnell verifizieren. Richtig vermuteter Textanfang und bis zu 4 folgende Zufallszeichen traue ich mir zu zu knacken.

 

Wenn x1 bis xn die Zeichen sind, dann wird der Hashcode rekursive berechnet:

 

H1 = x1

H2 = (H1*113 +x2)mod216

H3 = (H2*113 +x3)mod216

=(x1*1132 + x2*1131+x3*1130)mod216

 

Du kannst also die Modul-Rechnung ganz am Ende machen. Wenn du jetzt den Anfang richtig rätst machst du eine Fallunterscheidung, dass nur noch ein, zwei, drei oder vier Zeichen folgen.

 

Annahme es wären 3 Zeichen, du setzt in einer ersten Hash-Berechnung für diese drei Zeichen den Wert 0 ein(nicht das Zeichen 0!). Damit hast du eine Konstante für den geratenen Text.

 

Nun nimmst du den angezeigten Hashwert und ziehst die Konstante davon ab. Was übrig bleibt ist xn+xn-1*113+xn-2*1132 und sollte eindeutig sein wenn keine ASCII-Zeichen grösser 113 vorkommen.

 

113<27 und ein Zeichen höchsten 8 Bit lang, sodass das Ergebnis bei 4 Zeichen maximal 3*7 +8 Bits lang sein sollt. 29 bits sind kleiner 32 . Bei 5 Zeichen wären es schon mehr wie 32Bit.

 

Ich sehe deshalb für mich nur Chancen wenn man schon ziemlich genau weis was der Ursprung war.

 

P.S.: Wenn meine Kleine in 5 Wochen aus dem Krankenhaus kommt - habt ihr schon an den Pferdenkampfkünsten gebastelt?

 

...

[Community Patch]

Never touch the optionsDefault.txt or options.txt. If you want to change options.txt it is best to CREATE a file named optionsCustom.txt and add your changes there. It will overwrite other options files.