bypassing load.exe

[clvn]

and it think John Jordan is a good person to ask for the "right" way of doing the port
he creates jjffe - the reverse engeneered version of ffe (frontier first encounters) - from 16bit, dos-extender -> 3dbit win32(directx)

http://jaj22.org.uk/jjffe/jjffefaq.html#q3

as you can read here he used a special version of the ndisasm from the nasm assembler
maybe he could give good avises for doing the port

thats a mad cool project, but apparently the original ffe was written for 32-bit to begin with (borlands dpmi extender to be specific). that simplifies things dramatically from a porting point of view since e.g access to pointer variables and structs containing pointers is basically not a problem. thus most of their disassembly can be copy/pasted without any processing. our case however will require quite a bit of manual fixing to run on 32-bits. that said, i'm still gonna check the output of ndisasm at some point.


btw, ive updated the .idc-script that automates idapro: http://dl.dropbox.com/u/213479/anders.idc

the script spits out an .asm file for each function and an .inc for each segment in the currently open ida-project. still a work in progress. i was able to compile all functions in stunts into separate .obj files using tasm and a few minor adjustments. which is pretty neat, but then linking with tlink failed miserably. i believe the linking issue can be resolved by reorganizing the script a bit to either 1) output an .asm per segment rather than per function, or 2) reduce the number of publics/externs in the asm-files. but i havent found time for it yet.

[llm]

...but apparently the original ffe was written for 32-bit

oh! i forgot to mention this (small evil) difference

i was able to compile all functions in stunts into separate .obj files using tasm...

so your using the borland toolchain - i think that is the best decision - the best 16bit c and asm environment of that time
+ an wonderfull debugger - what version of borland c do you use - the one from the link above?
i think we should share our toolchain enviroment

...and a few minor adjustments...

do we need an transformer-script or something like that
is the adjustment regular enough for automation? what is you prefered language for scripting? python, perl, php...?

as an idea for the seperation: i would use a function prefix (fake namespace) in ida like unknown_, graphics_..., or msqc_ for automated
seperating the functions in different inc/asm and resulting obj files
(then we can start replacing the .obj bases with c derivates - step by step - without loosing the contact to ida)

and i think it would be great to have all the waiting-for-c-translation asm code in inline-assmbler inside an borland c projekt
(makes it much easier to play with the debugger and doing the replacing stuff)

ciao llm

[clvn]

hello!

the project has come to the point where the original game executable is successfully disassembled and recompiled back into a new executable:

http://dl.dropbox.com/u/213479/restunts.exe

could interested people please download this exe, put it in your stunts directory and give it a test run? id like to hear about any problems/crashes/etc. feedback is welcome here or on irc #stunts /efnet

[llm]

a more technical background for the restunts.exe

• the restunts.exe doesn't change anything in your stunts installation - add or remove it anytime you want
• based on the combined and cracked game.exe of the first post in this thread
• it is still a 16bit dos program, based on tasm/tlink - this is just the very first step of the reversing
• the current codebase is around 40 files and about 2.5mb of assembler code - a step by step c port ist planned
• each release needs to be tested very well - there i no way of doing an automated "this is perfect" test
• there will be an source (and tools) release later - the reversed source is still too hot :-)
• feature extention isn't very easy in this stage - its much more than just a decision to do it
• non developer users can currently only help with testing - strange crashes, wrong pictures, ...
• to reach this step, just create the very same exe - was a combination of serveral days hard word and an huge amount of low level detail knowledge - it isn't realy that easy - thanx to clvn
• the command line switch /ssb is needed for soundblaster sound - or just use the attached batch file for starting the restunts.exe

[dstien]

First commit in 18 months.

Finally checked in the remaining decompression functions. Now to focus on some more exciting parts of the code. There are currently some regressions in the ported simulation code that I'll look into.

Current status: http://re.stunts.no/status/2013-02-05.html

[llm]

thx for keeping the project active

im still working on my 16-bit-opcode to c code converter/emulator in my very very limited spare time...
(btw: a nice and very small (due to real-mode-only) emulator able to run stunts is fake86 http://sourceforge.net/projects/fake86/)

[RacerBG]

I don't know what I can do but if you wish I can help.

For sure I can't code at all.

[AureliusR]

My god, I read through the whole thread thinking to myself, nobody will have replied in years, and then I got to the end and to my disbelief, people are still playing and reverse engineering this childhood gem of mine that nobody I've ever known has heard of or played!!

I'm not sure what I can contribute to this reverse engineering as my programming skills are limited to C++, PHP&MySQL and a bit of Visual Basic... :S however I'm sure I can help somehow, whether it be computing power or logic skills, or something. Please keep me in the loop as I'm extremely interested in this project!

I'll even start learning relevant languages if needed. BTW it may be irrelevant but I use Ubuntu, Fedora and Windows so my OS skills are sharp, at least. And what llm said: DOSBox is an excellent emulator that does Stunts perfectly on my x86-64 computer (to my surprise) if you hadn't already heard of it.

[w4kfu]

Hello,
I started reverse enginerring also this game for fun and profit.
I have already coded an unpacker for EXEPACK, and a decompressor for their file format using huffman binary tree, I'm going to code a compressor too.
I'm on irc "irc.efnet.org" #stunts, is it the official channel ?

[BonzaiJoe]

Hello,
I started reverse enginerring also this game for fun and profit.
I have already coded an unpacker for EXEPACK, and a decompressor for their file format using huffman binary tree, I'm going to code a compressor too.
I'm on irc "irc.efnet.org" #stunts, is it the official channel ?

Hey AureliusR and w4kfu, and welcome. Great to hear about your work and your love for Stunts.
#stunts on EFNet is the official Stunts channel, but we don't really use IRC anymore. There is a chat room in connection with this forum, which is sometimes used, but generally the forum is the main channel for communication.

Apart from the people in this thread, Duplode also plays with the code.
Do you wanna play the game also? The competition is happening as we speak at "http://stunts.hu/zak"
Happy reverse engineering! :-)

[CTG]

who are these mysterious hackers...

[Friker]

who are these mysterious hackers...

your ghosts?

[w4kfu]

Tonigh, I found some times to work on my compressor, I'm now able to edit for example "MISC.PRE" after uncompressing it, change some strings, recompress it, and the game prints the strings I edited.
If you are interested to see the code you can find it on my github : https://github.com/w4kfu/Stunts/

[Duplode]

Hello w4kfu, and hello AureliusR!

Tonigh, I found some times to work on my compressor, I'm now able to edit for example "MISC.PRE" after uncompressing it, change some strings, recompress it, and the game prints the strings I edited.
If you are interested to see the code you can find it on my github : https://github.com/w4kfu/Stunts/

We already had a decompressor for packed resource files, namely dstien's stunpack, though no one had written a compressor yet stunpack is at the core of stressed, which is the tool we use for creating custom graphics. You can find it at: http://code.google.com/p/stuntstools/

The Stunts Wiki gives a good overview of what we already know about the data files. http://wiki.stunts.hu/index.php/Resource_file_format is a decent starting point if you want to read on that. In addition, there was reasonable progress towards reading and porting disassembled code, though these efforts are currently under-documented (not to say under-publicized). For information beyond what is hinted in this thread, the best person to ask at this point would be dstien (I am too much of a dilettante in that field to be able to give a sensible overview  ). I should also mention the replay logging thread, which reports a very recent attempt to leverage some of that knowledge.

[w4kfu]

We already had a decompressor for packed resource files, namely dstien's stunpack, though no one had written a compressor yet stunpack is at the core of stressed, which is the tool we use for creating custom graphics. You can find it at: http://code.google.com/p/stuntstools/

I'm actullay still studying how load.exe works (especially for .COD, .DIF, .HDR, .CMN), and stuntstools handle badly these files, because it checks if the uncompressed file size is present at the first byte of the uncompressed data, see : http://code.google.com/p/stuntstools/source/browse/src/app/resource.cpp#126
But for these files, this information is not present, that's why I rewrote my own implementation (using Huffman tree implementation, despite huffman tree-less in stuntstools), and beeing able to understand well how load.exe deal with these files.