Hallo miteinander. Ich habe im Anhang eine Datei hochgeladen welche etwa 133 verschiedene 8-Bit BMP Dateien enthalten müsste. Diese Datein sind alle Grayscale. Nun habe ich versucht jede Datein über den Hex Editor herauszukopieren. Leider sind die Dateien danach von keinem Bildprogramm mehr lesbar. Habt ihr evtl eine Theorie wo der Fehler liegen könnte? Im Hex-Code finde ich den Header "424D" mehrfach vor. Keiner der Dateien sollte größer als 20~40KB sein. Leider kann ich aus diesen Header-Informationen keine für mich verwertbaren Informationen herausziehen: 424D7F8BCCCC7F8B7F8B33537F8B7F8B1111B29F7F8B11127F8B7F8BCCCC7F8BBB7C8B44 0C4812997C8B729E11122788443989A40C9444A21F08000A9F11122227444778AB22AFA9 02133011079E20101111772224A30CCAAAA7994442B3FF11117210412343717AA70B059D 110301777987 Ich hoffe ihr habt davon mehr Ahnung als ich :)
Hmmm ... die Signatur ist "BM", dezimal 19778, hex 4D 42 ... ist da bei dir evtl. ein Little-Endian-Problem (LoByte/HiByte vertauscht)? http://de.wikipedia.org/wiki/Windows_Bitmap
Hallo und danke für deine Antwort. Leider kann ich nicht zu 100% auschließen das sich die Datei unkomprimiert in der Datei befinden. Ein Datei-Signatur-Scan hatte mich auch nicht weiter gebracht, daher habe ich mir einfach eine 8-Bit BMP erstellt und mit dem HEX-Editor den Header kopiert. Gibt es da mittel und Wege um genauere Informationen aus der Datei zu bekommen?
Plastefuchs schrieb: > Gibt es da mittel und Wege um genauere Informationen aus > der Datei zu bekommen? du must doch am besten wissen, was für Daten du erwartest? wo kommen sie her, welche Auflösung, welche farbauflösung aber unkomprimierte Bilddaten scheint das nicht zu enthalten. Wenn man im Gimp mit Rohdaten öffnen spielt, könnte man sonst wenigstens ansatzweise irgendwo struktur erkennen, wenn man ein wenig mit dem Breitenregler spielt-
Also die Situation ist folgende: Die Daten enthalten 8-Bit Bilder in Graustufen. Diese entstammen einem 12 Jahre altem Spiel. Die Entwicklerfirma existiert schon lange nichtmehr daher habe ich mich mit verschiedenen Herstellern in Verbindung gesetzt weil ich den Quellcode kaufen wollte. Den richtigen Ansprechpartner habe ich zwar ausfindig gemacht, aber leider war der originale Quellcode nichtmehr auffindbar. Man hat mir allerdings gestattet mir die Ressourcen aus dem Originalspiel zu verwenden. Das ist alles was mir über diese Datei bekannt ist.
Kann es sein, dass die Datei eine einzige Bitmap, mit mehreren Kacheln, enthält? Dann würde sich nur ein Header in der Datei befinden. Dies wiederum würde das "manuelle" Kopieren verhindern. Such dazu einfach nach der Sequenz: 42 4D. Aber Vorsicht, die Byte-folge kann aber auch regulär innerhalb eines Bildes vorkommen.
Plastefuchs schrieb: > Die Daten enthalten 8-Bit Bilder in > Graustufen. Diese entstammen einem 12 Jahre altem Spiel. Name des Spiels, Größe der Grafiken, Farbauflösung (4, 8, 16,... Graustufen in einem Bild), Screenshot?
Angehängte Dateien:
-
225512aaa.jpg
270 KB
Hallo, @ Vlad Tepesch Das Spiel nennt sich "KKnD: Krossfire". Die Farbauflösung liegt bei 256 Farben, diese werden aber nicht in der Bitmap selbst gespeichert sondern über eine Farbpalette direkt vom Spiel in die korrekte Farbe gezeichnet. Wie groß die Grafiken sind ist schwer zu sagen die einen sind etwas kleiner andere etwas größer, alle aber kleiner als 50x50 denke ich. @amateur Es ist gut möglich das die Datein in einer großen Datei zusammengefasst wurden sind. Den Bitmap Header konnte ich allerdings an mehreren Stellen der Datei ausfindig machen, daher ging ich davon aus das es sich hierbei um einzelne Bilder handelt.
Probiers mal damit ist ein altes DOS-Tool, also ohne Gewähr. Das Programm erwartet vermutlich als Übergabeparameter den Namen der zu durchsuchenden Datei. gk
Die genaue Beschreibung der Bitmapheader gibt's bei KleinWeich. Früher enthielt denen C-Compiler auch eine passende Strukturdefinition, zusammen mit einer Beschreibung der Datentypen. Da drinnen steht auch ob 1,4,8 u.s.w. Bit pro Pixel verwendet werden und wie groß die Farbtabelle ist. Um grob festzustellen, ob jedes Bild einen eigenen Header hat, wüste ich nur die Suchfunktion. Die Anfangskombination müsste mindestens 133-mal vorkommen. Sollte sie als Grau-Wert innerhalb eines Bildes auftauchen, so ist es oft so, dass mehrere Signaturen in sehr geringem Abstand auftauchen.
kknd sagt mir was, ich glaub das hab ich auch mal gespielt. wo hast du denn den dump her? kann man nicht vielleicht direkt in den Spieldateien nach den Grafikdaten suchen? um welche Grafiken geht es dir denn? notfalls halt per screen shot der dump enthält auf jeden fall keine gültigen BMP-Header. und wie gesagt, er enthält höchstwahrscheinlich auch keine unkomprimierten grafikdaten. zu not könnte man noch versuchen, ob man zur Programmlaufzeit an die Daten kommt. da werden sie höchstwahrscheinlich irgendwo im Ram liegen oder ist deine datei ein ram dump?
amateur schrieb: > Früher enthielt denen C-Compiler auch eine passende Strukturdefinition, > zusammen mit einer Beschreibung der Datentypen. Das tut der jetzt natürlich auch noch.
Hallo, Den Dump hat ich aus ner Memory Dump rausgeschnitten weil ich gehofft habe das die Datein dort ggf. unverschlüsselt drin liegen könnten. Die Originaldatei ist bei /levels/german/gamesprt.lpk zu finden. Ich wollte es vermeiden jede einzelne Einheit von Hand aus der Datei zu rippen da auch viele Animationen vorhanden sind und das einfach sehr lange dauern würde dies für jede Farbe seperat zu tun. Ich möchte nach möglichkeit alle Grafiken haben die zu finden sind. Da der Quellcode nichtmehr auffindbar ist und der Assemblercode mehr als aufwendig umzuprogrammieren ist, wollen wir die moderne Technik nutzen wie z.b. die XNA Umgebung von Mikrosoft und das Spiel nachprogrammieren. Das dürfte mit den heutigen Mitteln nicht mehr ganz so komplex sein.
Plastefuchs schrieb: > Ich habe im Anhang eine Datei hochgeladen welche etwa 133 verschiedene > 8-Bit BMP Dateien enthalten müsste. Diese Datein sind alle Grayscale. Meine erste Vermutung: Die Anzahl der Bytes im dump (6142650) ist durch 150 teilbar. 6142650 / 150 = 40951 Meine Anfangsvermutung: Es handelt sich um einzelne 150 Bilddateien mit identischer Größe von je 40951 Bytes. Also würde ich den dump erstmal in 150 einzelne Dateien splitten und dann nachsehen, was man da herausholen kann. Und ich würde mich von der Vorstellung freimachen, dass mit BMP zwangsläufig eine "Windows BMP" Datei gemeint sein muß. Das Kürzel BMP kann durchaus einfach für "Bitmap" stehen, also irgendein Format bei dem jeweils dieselbe Anzahl von Bits für je einen Bildpunkt stehen. Wie oft kommt denn die "BM"-Zeichenfolge im dump vor, die auf ein Windows-BMP Format hindeuten würde? Ist diese magische "BM" Folge jeweils am Anfang der Datei zu finden, wenn man den dump in 150 gleichgroße Dateien aufteilt?
Plastefuchs schrieb: > Ich wollte es vermeiden jede einzelne Einheit von Hand > aus der Datei zu rippen Und deshalb "rippst" du lieber ein Memory-Dump?? Wenn man einmal das Format raus hat kann man sich doch ein kleines Programm schreiben welches die Daten konvertiert, Programmerfahrung sollte ja wohl hoffentlich vorhanden sein wenn du das nach programmieren willst.
Was mir gerade noch einfällt: Ist das vielleicht aus einem Windows-Programm? Vielleicht sogar aus einem Windows-Programm, das mit einem Microsoft-Compiler entsprechend der Microsoft-Programmierrichtlinien programmiert wurde? Wenn die Entwickler beim fertigen Programm keine speziellen Kompimierungs- oder Verschlüsselungsmaßnahmen vorgesehen haben, dann ist es unter Umständen möglich, direkt aus der .EXE oder .DLL Datei die Bilder wieder herauszubekommen. Poste bitte mal statt des dumps lieber diejenige EXE oder DLL Datei oder sende mir mal einen Link zum Downloaden, in der die Bilder enthalten sind, dann versuche ich mal was.
Plastefuchs schrieb: > Die > Originaldatei ist bei /levels/german/gamesprt.lpk das: Jürgen S. schrieb: > Poste bitte mal statt des dumps lieber diejenige EXE oder DLL Datei oder > sende mir mal einen Link zum Downloaden, in der die Bilder enthalten > sind, dann versuche ich mal was. ist also nicht notwendig wobei mird er Ort levels komisch vorkommt und ich eher vermuten würde, dass dort missionsgedöhns drinsteckt. Sprites werden schließlich selten lokalisiert und levelabhängig werden die Sprites auch nicht sein. Ich würde versuchen bei den Spieledateien anzusetzen. Zur Not versuchen mit einem Debugger/Dissassembler (zB ollydbg) herauszubekommen, was mit den Dateien gemacht wird.
Hallo nochmal, Ich arbeite mit Assembler momentan an der Originalen exe-Datei. Ich selber kann zwar nur sehr wenig Assembler Programmieren, jedoch kann ich diesen einigermaßen gut lesen. Die Sprites für das Spiel sind ohne jeden Zweifel in dieser Datei enthalten. In einer anderen Routine werden die Sprites zur Laufzeit über 3x *.pal Dateien eingefärbt. Dies ist zu 95% sicher. Leider kann ich aus der Debugger-Routine nicht zu 100% schließen wie genau die Dateien nun eigentlich entpackt werden. Sicher ist nur das diese nicht im Arbeitsspeicher oder auf der Festplatte zwischengespeichert werden. Ich habe im Anhang die von mir manipulierte exe hochgeladen. Die Änderungen sind unter anderem: - Verschlüsselung der exe entfernt - NoCD Patch - Videos / Hintergrundmusik wird absofort nichtmehr von CD geladen sondern Lokal - Auflösung auf Widescreen angepasst (fehlerhaft) - IsDebuggerPresent gepatcht - CreateFileA gepatcht - Checksumming gepatcht Der Code ist durch diese Maßnahmen von jedem beliebigen Debugger lesbar.
Ich nochmal, ich habe euch für Testzwecke auf die schnelle eine lauffähige "minimal" version gebastelt. Ich habe alle Videos, alle Musikdaten, SP und MP-Missionen entfernt. Daraus ergibt sich die Dateigröße von 10MB. Wenn man im Singleplayer eine beliebige Mission startet, sieht man eindeutig wie er die Sprites aus der gamesprt.lpk extrahiert. Vielen Dank nochmal. Ein Copyright verstoß besteht im übrigen nicht, da ich eine Erlaubnis habe :)
Plastefuchs schrieb: > Ich arbeite mit Assembler momentan an der Originalen exe-Datei. Aus der EXE-Datei kann ich nur drei winzig kleine 32x32 Bitmaps rausziehen, die entweder als Icons oder als Mauscursor verwendet werden können, darunter das unter Windows angezeigte Programm-Icon der Datei. Weitere Bilder sind da erstmal so direkt ersichtlich nicht enthalten. Weiter oben schriebst Du etwas von der Datei "gamesprt.lpk", in der die Bilder enthalten sein sollen. Der von Dir angegebene Speicherort existiert natürlich nur in einer vollständigen Installation des Spiels auf der Festplatte, die ich nicht habe. Diese Datei gamesprt.lpk könnte eine umbenannte DLL-Datei sein. In dem Fall würde irgendwo kurz nach dem Anfang der Datei einmal die Zeichenfolge "PE" als PE-Header auftauchen. Wenn das der Fall ist und die Datei genau so wenig verschlüsselt und komprimiert ist wie die EXE-Datei, und dort die Bilder entsprechend den üblichen Microsoft-Standards enthalten sind, kann man sie dort eventuell auch herausziehen. Die im letzten Posting gepostete EXE-Datei enthält jedenfalls keine für mich dort ersichtlichen BMPs, nur drei kleine Icons. Jedenfalls könnte man die Bilder nur aus derjenigen Datei rausziehen, in der sie tatsächlich enthalten sind. Und die EXE-Datei ist es nicht.
Hallo, In der von mir oben angehängten Datei befindet sich sehr wohl die gamesprt.lpk. Wenn die rar-Datei geöffnet (www.winrar.de) wurde, findest du den Ordner "LEVELS" vor. Wenn du dann in den Ordner "german" navigierst findest du die Datei. Es handelt sich hierbei nicht um eine PE Datei :)
Plastefuchs schrieb: > Wenn man im Singleplayer eine beliebige Mission startet, sieht man > eindeutig wie er die Sprites aus der gamesprt.lpk extrahiert. Tja, leider hat die gamesprt.lpk Datei keinen PE-Header und es handelt sich nicht einfach um eine umbenannte DLL-Datei. Oben schriebst Du was von "Verschlüsselung der exe entfernt". Könnte es vielleicht sein, dass die "gamesprt.lpk" eine auf dieselbe Weise verschlüsselte Datei ist? Also dass man ggf. mit demselben Entschlüsselungstool, das zum Entschlüsseln der EXE verwendet wurde, ggf. eine unverschlüsselte gamesprt.lpk erhalten kann, ggf. nachdem gamesprt.lpk nach gamesprt.dll oder gamesprt.exe umbenannt wurde? Andere Idee: Ob es wohl herauszubekommen ist, mit welchem Toolkit die .lpk Datei erstellt wurde, wenn sie nicht mit einem Microsoft-Compiler kompiliert wurde? Vielleicht mit einem Game-Construction-Kit oder einen bestimmten Grafik-Tool?
Hallo, Ich glaub ich muss das nochmal klarstellen mit den Dateien, da gab es scheinbar ein missverständnis. Die exe wurde durch PE-Verschiebung manuell verschlüsselt. Da die Datei allerdings schon >14 Jahre alt ist, war es mit heutigen Mitteln nichtmehr so schwer diese zu "korrigieren". Der Rest war dann nurnoch Assembler-Code. Bei der "gamesprt.lpk" handelt es sich nach wie vor um Bilddatein. Es handelt sich hierbei weder um eine DLL noch um ene EXE. Die exe liest während des Ladevorganges eines Levels die Sprites aus der Datei aus. Dabei sind 133 Lesevorgänge laut Procmon festzustellen. Jede Datei ist 20-40KB groß. Sämtliche Bilddatein die darin enthalten sind, wurden in Grayscale - also Graustufen gespeichert. Die Datein enthalten demnach keine Farben. Die Farben werden zur laufzeit über die .pal-Files eingfärbt. Der Hex-Editor an mehreren Stellen eine Bitmap Signatur sichtbar. Das Spiel läuft auf 256 Farben.
Plastefuchs schrieb: > Der Hex-Editor an mehreren Stellen eine Bitmap Signatur sichtbar. Zwar taucht die Kennung "BM" auf, aber im BMP-Dateiformat folgt nach der "BM" Signatur ein 4-Byte Wert im Little Endian Format, der die Dateigröße der BMP-Datei vorgibt. Falls die Bilddateien nicht größer als 64 KB sind, müßten das dritte und vierte Byte hinter BM immer 0 und 0 sein. Dezimal: B M . . 0 0 Hexadezimal 42 4D .. .. 00 00 Und das kommt bei der Datei nicht hin, weil das dritte und vierte Byte nach "BM" eben nicht "0" und "0" sind. Da stellt sich dann für mich schon die Frage, was es sein kann und wie das ggf. ein ein Greyscale-Bitmap zu konvertieren ist, wenn es keine hintereinander in eine Datei kopierte Windows-Bitmaps sind.
Ggf. sind die Bytes im ein paar Stellen verschoben und im Arbeitsspeicher werden sie zurück verschoben? Irgentwo in dem ASM Code muss ja der Code drinstehen. :)
in dem File sind definitiv keine Bitmap header, das schrieb ich weiter oben schon. die kennung BM ist da zufällig drin. die datei ist 6MB groß, Bei angenommener Gleichverteilung aller Zeichen würde man ~90 vorkommen von BM vermuten. Es sind zwar mit 144 ein paar mehr, aber das ist wohl im Rahmen der Schätzung. Auf jeden Fall müssten es deutlich mehr sein, wenn da auch noch 130 BMP-Header drin sein sollten. Ich hab grad mal versucht das Programm mit einem Debugger auszuführen und mir die stelle anzuschauen, wo er den "gamesprt"-String referenziert. Ein paar Befehle drunter ist eine string-Referenz auf eine Fehlermeldung, dass das Laden fehlgeschlagen ist. Meine Hoffnung ist, dass man dort, wo er es einliest heruasfinden kann (zum beispiel an Parameter von Funktionsaufrufen in bekannte APIs), was für ein Format das zeug hat.
Die Idee hatte ich auch schon aber leider bin ich bisher gescheitert. Wenn du allerdings etwas herausfinden solltest würde ich mich sehr freuen wenn du es mir mitteilst :) Danke schonmal
Darf man fragen wozu Du die Bitmaps verwenden willst? Ich hab übrigens auch mal ein paar RAW-Experimente mit den Files gemacht und konnte keine Strukturen erkennen - Bist Du sicher das es unkomprimierte Bitmaps sind?
Plastefuchs schrieb: > Da der Quellcode nichtmehr > auffindbar ist und der Assemblercode mehr als aufwendig > umzuprogrammieren ist, wollen wir die moderne Technik nutzen wie z.b. > die XNA Umgebung von Mikrosoft und das Spiel nachprogrammieren. Das > dürfte mit den heutigen Mitteln nicht mehr ganz so komplex sein. Ich bin leider nicht zu 100% sicher ob die komprimiert sind. Aber nachdem was ich bisher gehört habe gehe ich davon aus das dies der Fall ist.
Dis Struktur der Datei wird etwas klarer, wenn man sich die Lesezugriffe anschaut. zuerst wird ein Header gelesen. in den letzten 4 Byte steht die größe des nächsten Blocks. Der nächste Lesezugriff beträgt Größe plus zusätzliche 8 Byte, in deren letzten 4 Byte wieder die Größe des nächsten blockes steht.
1 | 21:07:09,9187666 Kknd2.exe 20552 ReadFile fmv_surv.lpk SUCCESS Offset: 0, Length: 24 |
2 | 21:07:09,9190928 Kknd2.exe 20552 ReadFile fmv_surv.lpk SUCCESS Offset: 24, Length: 38.341 |
3 | 21:07:09,9198371 Kknd2.exe 20552 ReadFile fmv_surv.lpk SUCCESS Offset: 38.365, Length: 31.377 |
4 | 21:07:09,9204622 Kknd2.exe 20552 ReadFile fmv_surv.lpk SUCCESS Offset: 69.742, Length: 51.155 |
5 | 21:07:09,9211565 Kknd2.exe 20552 ReadFile fmv_surv.lpk SUCCESS Offset: 120.897, Length: 44.682 |
6 | 21:07:09,9218406 Kknd2.exe 20552 ReadFile fmv_surv.lpk SUCCESS Offset: 165.579, Length: 727 |
7 | 21:07:09,9218825 Kknd2.exe 20552 ReadFile fmv_surv.lpk SUCCESS Offset: 166.306, Length: 8 |
8 | 21:07:09,9219066 Kknd2.exe 20552 ReadFile fmv_surv.lpk SUCCESS Offset: 166.314, Length: 247 |
9 | 21:07:09,9220842 Kknd2.exe 20552 CloseFile fmv_surv.lpk SUCCESS |
Ich möchte wetten, dass das jeweils ein Objekt ist. Da die Blöcke alle unterschiedlich groß sind, obwohl man annehmen sollte, dass zumindest wenigstens einige Bilder ein gleiches Format haben, liegt die Vermutung nahe, dass sie komprimiert sind. Die Kompression ist auf jeden fall nicht sehr fortgeschritten, da die Bytewerte nicht allzugut verteilt sind. auffällig ist, dass alle Dateien ziemlich am Ende einen leeren Block haben. Der letzte Block wird auch immer genau mit der definierten Größe eingelesen.
falls es irgendwie hilft: hier der Code zum splitten der großen Datei in Eintelteile. Ich komm nich weiter. Da du geschrieben hast, dass du Asm sehr gut lesen kannst, könntest du versuchen festzustellen, wo die Bilddaten am ende landen. Meine Vermutung war, dass irgendwo eine WinApi oder DirectX-Funktion gerufen wird, der die Daten übergeben werden. An der stelle hätte man gewonnen, da dieser Funktion ja irgendwie das Format bekannt sein muss. Leider konnte ich in den importierten Funktionen nix finden, was mit grafiken zu tun haben könnte. Vielleicht ist die Liste der Importierten Routinen aber auch irgendwelchen Verschlüsselungs- oder Obfuscating-Aktionen zum Opfer gefallen. Vielleicht kennt jemand ein Tool, mit dem man sämtliche Calls zu externen Modulen mitloggen kann? Processmonitor überwacht scheinbar nur eine Auswahl an IO-Operationen kannst du vielleicht mal noch so viel dateien posten, dass man das spiel auf einer kleinen einfachen Karte richtig starten kann, um sich mal den kompletten Ram anzuschauen? Ansonsten hab ich auch keine Ideen mehr, außer dem quasi hoffnungslosen Durchprobieren von Dekompressionsmethoden auf den Daten. Da es aber sicher zig simple Bildkompressionen gibt (alleine RLE gibts mehrere Varianten) und dann unklar ist, ob in den einzelnen Blöcken der Anfang ein Header ist, den man auslassen muss, scheint mir das unmöglich.
Vlad Tepesch schrieb: > Vielleicht kennt jemand ein Tool, mit dem man sämtliche Calls zu > externen Modulen mitloggen kann? > Processmonitor überwacht scheinbar nur eine Auswahl an IO-Operationen API Monitor (http://www.rohitab.com/apimonitor) scheint das zu können. aber auch hierfür wäre es wichtig mal das Spiel im laufenden Zustand zu monitoren
Hallo Zuerst vielen Dank für deine bisherige Hilfe! Dieser De-Compiler sieht ja sehr interessant aus. Darf man fragen mit welchem Programm der erstellt wurde? Ich hatte in der vergangenheit schonmal nach etwas ähnlichem gesucht aber leider ohne Erfolg. Ich habe dir im Anhang 3 Multiplayer-Karten hochgeladen. Diese müssten in das Verzeichnis \KKND Krossfire\LEVELS\Multi\ Im Spiel kannst du sie dann Laden indem du auf "Multiplayer"-"keine Mitspieler" gehst. Einen CPU Gegner fügst du hinzu indem du auf eins der schwwarzen Kästchen der Spieler-Liste klickst. Ich habe die Multiplayer-Karte aus dem Grund hochgeladen, da im Singleplayer-Modus noch ein Anti-Crack-Schutz greift, der prüft ob die CD-Check Variante geändert wurde. Dies führt dazu das im Singleplayer alle Einheiten Selbstmord begehen. Ich habe noch nicht herausgefunden woran das liegt. In den LPM-Datein sind die Tiles sowie die Attribute, die MIN-Datei enthält nur die Minimap.
Plastefuchs schrieb: > Zuerst vielen Dank für deine bisherige Hilfe! Spieltrieb und sportlicher Ehrgeiz wie es ausschaut, werden die lpm files nach dem gleichen Muster eingelesen, wie die lpk files. villeicht gibt es einen Maperditor oder ein grafik converterprogramm was bmp->kknd-map grafiken umwandelt. zumindest gibt es ja leute die eigene tilesets erstellt haben. kannst du die multiplayerkarten in einem Mapeditor öffnen? Am vielversprechendsten scheinen mir die MinMaps zu sein. Da passieren 3 4-Bytelesezugriffe und dann ein Block. Meine Vermutung ist, dass die 2. und 3. Lesezugriff die Größe sind. kennst du die Größe der Karten? hier die werte aus den dateien: 1: 212x212 2: 192x192 3: 246x244 und: http://www.youtube.com/watch?v=s0QOAFTwxQ4 Ach so: Plastefuchs schrieb: > Dieser De-Compiler sieht ja sehr interessant aus das ist kein decompiler, das tool logt nur alle aufrrufe in externe moodule mit.
Angehängte Dateien:
-
mlti_01.png
30 KB
did mim dateien scheinen ausnahmsweise unkomprimierte rohdaten zu sein. bei Breite 212 oder noch eher bei 424 lässt sich eine Karte erahnen allerdings gehören scheinbar immer 2 Byte zu einem Pixel RGB565 ist es aber auch nicht. (im anhang mal 3 fach vergrößert) ich konnte auf der Spielerstllungsseite aber irgendwie nicht die Karte aktivieren um es zu vergleichen. Nach ein paar schritten stürzt das spiel bei mir aber auch ab.
Das hatte ich vergessen dir zu sagen, ich hatte die Auflösung auf 1920x1080 gepatcht, das Spiel verkraftet das nicht so gut. Immer wenn man die Maus ausserhalb des 4:3 Fensters bewegt gibts einen Crash. Du musst einfach die options.cfg mit Notepad öffnen und den Screenmode von 2 auf 0 ändern. Dann läuft es wieder 1024x768. Die MIM Datein liegen unkomprimiert vor. Ein "Minimap Viewer" wird sogar auf der Seite angeboten. Wie dieser Karteneditor den du dort beschreibst entstanden ist, ist mir wohl bekannt. Diverse Mapper haben Wochenlang die einzelnen Tilesets aus dem Spiel herausgerippt. Die "Tiles" befinden sich für gewöhnlich in den den Desert.kp-Datein. Dort sind diese in 16x16 Blöcken unverschlüsselt. In den Map Files müssten sie allerdings Verschlüsselt sein.
das heißt doch diese Leute müssten auch das Format kennen, in dem die Daten komprimiert vorliegen
Die Entwickler sprechen leider nur Chinesisch und Google Englisch. Aber wie bereits erwähnt sind die Tiles unkomprimiert, während die Sprites verschlüsselt sind.
und http://www.sleipnirstuff.com/forum/viewtopic.php?f=83&t=15158 kennst du? evtl. kannst du den ja mal anschreiben ob er weitergekommen ist?
Mit dem hab ich mich schon öfter unterhalten. Er arbeitet zwar dran, hat aber noch nichts erreichen können.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.