bypassing load.exe

[llm]

thx yours works perfekt - i forgot to uncompress the files :-)

is the exe fully tested, are there any known problems?

[clvn]

is the exe fully tested, are there any known problems?

as far as my testing goes, there are no problems using the new exe

[llm]

what version of ida do you use - newer version seems to do a much better job in reversing
im currently thinking about buying the latest edition

[clvn]

what version of ida do you use - newer version seems to do a much better job in reversing
im currently thinking about buying the latest edition

i did use the freeware 4.1 version, which is rather old. mostly out of habit. after reading into collabreate, ive installed a newer version and upgraded the .idb, but havent really progressed any further. using the newer version still feels annoying due to some changed hotkeys.

---

to follow up on an earlier post, i was trying to port the disassembly to inline 32-bit assembler in msvc. which is now on hold. fixing the related pointer issues is possible with a well-planned approach (and even trivial with a smaller program), but now its turning into a mess.

so im still considering how to move forward. maybe making an intermediate 16-bit port in turbo c + tasm as the first step... or maybe look for a plugin for ida that helps porting single functions... ideas are most welcome.

[llm]

>i did use the freeware 4.1 version, which is rather old. mostly out of habit.
>after reading into collabreate, ive installed a newer version and upgraded the .idb,
>but havent really progressed any further. using the newer version still
>feels annoying due to some changed hotkeys.

i just saw the differences beween 4.9 and (i think) a recent 5.x version - and it produces a much better and smaller output

>so im still considering how to move forward. maybe making an intermediate 16-bit port in
>turbo c + tasm as the first step

the idea sounds good - got an version of tc/tasm around? maybe you use watcom c or djgpp

[clvn]

i just saw the differences beween 4.9 and (i think) a recent 5.x version - and it produces a much better and smaller output

ok. sounds like its worth further investigation. perhaps even to the point its worth starting almost from scratch again in idapro, but using sane naming conventions etc. at least the existing work could be used as a reference.

>so im still considering how to move forward. maybe making an intermediate 16-bit port in
>turbo c + tasm as the first step

the idea sounds good - got an version of tc/tasm around? maybe you use watcom c or djgpp

tc 2.01 is available from here:
https://downloads.embarcadero.com/free/tc201 ->
http://altd.embarcadero.com/download/museum/tc201.zip

while tasm 5 is no longer officially available, it can be found here:
http://www.phatcode.net/downloads.php?id=280

tried to locate some ancient microsoft c compilers as well (apparently used for the original game), but google wouldnt tell me. tasm+turboc may be just as good, idapros output should be compatible with tasm.


ive done some investigation into the tasm-approach. for example, just passing the entire .asm-file to tasm doesnt work too well; after getting rid of the obvious errors it stops on "out of memory", presumably and hopefully due to a too large code file.

to get past that, it would be obvious to split game.asm into many smaller ones, which can be assembled and linked separately. like one function per file. but, unless the work in idapro is completely done, one would have to backport any new discoveries in idapro back to the separated .asm-files manually.

so to workaround that, its maybe an idea to automate the process of splitting game.asm into smaller pieces. either as a script that parses game.asm and spits out many smaller ones, or finding or writing a plugin for idapro that does the job directly. this would allow testing+porting in tc/tasm and further reverse engineering iteratively. im guessing a script is the most efficient way to split up game.asm anyway.

alas im stuck with other stuff atm, so i wont be able to follow through with any of this in the near future though.

[llm]

im using the borland c++ 3.1 version from

http://vetusware.com/download/Borland%20C%2B%2B%203.1%203.1/?id=5888

the last pure dos version of "turbo" c with tasm

[Cas]

My goodness!

Everytime I'm busy for a few weeks, I come back and there's magic going on!  I would be very happy to help!  Time ago, I had been thinking of a method for decompiling the whole Stunts code (mainly LOAD.EXE). I had already UNPacked the EXE and noticed the structure of the HDR, COD and DRV files. Note that the DRV files are the sound libraries, each of them is supposed to be loaded at the beginning of a segment (offset zero) and starts with a series of jumps to each of the sound functions. I am currently working on a project for FreeDOS that should provide a sound API for DOS and enable some old games to have sound again. Stunts is one of my examples of how this can be accomplished, by replacing the DRV files (specially the AdLib one) with patches that redirect the functions to the new API, called CPOS/NSS.
But back to the decompiling... I am willing to help, but would suggest the following:
1- Do not abandon the game support for pure DOS!  This is an opportunity to support the FreeDOS project. Stunts was born a DOS application and it can still be improved with 32bit code without necessarily having to separate from DOS. Make sure any new code can also be compiled to run under pure DOS. I can dedicate to that myself.
2- MASM and TASM are not very comfortable to receive decompiled code because of the way they structure the sources (ASM files)... having lots of required directives. I strongly suggest Flat Assembler: http://flatassembler.net
3- What do you need help with?

[clvn]

hello!

still busy at work here, but havent completely forgotten about this.

so far i've probed into automating idapro with .idc-scripts. i really like the idea of automating idapro to generate a compilable and extendable project.  such a script would have to do something like this:

Code Select Expand

- for each segment, generate segN.inc containing extrns to all symbols in that segment (procs, locs and data)
- for each function, generate functionname.asm file with:
- include all seg0..segN.inc, EXCEPT for the segment where the function belongs
- extrns for all symbols in the same segment EXCEPT the current function and data
- public definitions of data and procs
- the implementation of the function and related data
- also, the datasegment must be split into at least two files, since the source code is too big for tasm
- some .bat or project file that assembles and links everything

if this turns out to work, we will have a working exe compiled from the disassembly and the possibility to start porting to C. further reverse engineering can still take place in idapro. e.g when a new variable is discovered and properly renamed, the source files can simply be re-generated from scratch by executing the idc. already-ported c functions may still need to have symbol names back-ported manually, but i still believe this approach would be more convenient than porting everything by hand.

there might turn up some interesting issues related to optimizations made by the original compiler. and lateron the script needs some features related to porting, e.g generate c headers and ignore already ported functions.

here's my attempt at an idc so far. its not usable for anything, but i learnt a great deal when writing it. it was left like this a few days ago, some parts are commented out after testing the built-in method to generate the assembly:

http://dl.dropbox.com/u/213479/anders.idc

1- Do not abandon the game support for pure DOS!  This is an opportunity to support the FreeDOS project. Stunts was born a DOS application and it can still be improved with 32bit code without necessarily having to separate from DOS. Make sure any new code can also be compiled to run under pure DOS. I can dedicate to that myself.

agreed. dos support would be nice.

2- MASM and TASM are not very comfortable to receive decompiled code because of the way they structure the sources (ASM files)... having lots of required directives. I strongly suggest Flat Assembler: http://flatassembler.net

in regards to prefered compilers, assemblers etc, i dont really care. in the beforementioned approach the output can presumably be formatted to suit any assembler. if fasm can compile ida's output with less hassle, then im all for it. the ultimate end-result wouldn't depend on any assembler anyway, so i propose whoever makes (and shares) an idb+idc that produces a compilable project gets to decide on the assembler.

3- What do you need help with? Smiley

i need help with "everything". i'll likely resume coding on the idc whenever time permits, unless somebody does it before me. or comes up with a better approach where i can participate. im open for good suggestions.


everybody are also welcome to join on irc in #stunts/efnet. im still alone in there, hardcore idling

[Cas]

Great!  Well, I'll tell you what I'm good and bad with, what I have at hand and what I need to know to be able to help.

- I have always been part of the... uh... "resistance", he, he, against Windows, so I have all these years kept on working for DOS. I'm pretty comfortable to it, although I really like and use Linux as well (I have Ubuntu), but I'm still not as good at it as I am with DOS.
- For real-mode high-level, I've worked with Turbo Pascal, Borland C++ and QuickBASIC. I'm specially comfortable with the last two. For low-level, I understand any assembler, but for writing I'm much faster with FASM. For protected-mode high-level, I've been working with FreeBASIC and I've tried it under Ubuntu too. I would like to improve there as well.
- I know very little about network and internet stuff, so I don't even remember how to use an IRC, but I'm willing to participate there if you tell me how.
- I have (some times intentionally) avoided using object-oriented programming, so I am not familiar with languages that develop exclusively in that area. I am used to programming graphic routines low-level and I know how to access old SoundBlaster cards through ports too. I am used to doing that myself, so I don't know about libraries and I'm inexperienced about loading third-party modules in my code.
- I understand the structure of DOS EXE files and know about opcodes
- I am weak about low-level protected-mode programming

So I hope I can be helpful here. It's very good to have somebody else also trying to unwrap all this code. I've been working on analysing Stunts internal variables to block replay handling and I partially succeeded, except that I found some stuff to be system-dependent. Now that car-editing is already possible, the next step (apart from replay-handling control) would be enhancement of track edition, by allowing variable-size maps and more track objects. We need to isolate the (kind of crazy) pseudo-Newtonian force/collision engine, the track/replay file analysis code and the sound and graphics hook-points. About the sound, I've already been working on that. OK... please let me know how we can get in touch. I can pass you my e-mail and Skype IDs and will be glad to participate in the IRC

[clvn]

please let me know how we can get in touch. I can pass you my e-mail and Skype IDs and will be glad to participate in the IRC

irc is an ancient yet popular way to chat in real time. you need an irc client such as irssi on linux or mirc on windows, connect it to irc.efnet.org and join the channel #stunts. we're two people in there right now

[Cas]

Thank you... I'm installing RSSI.... I'll try to figure out how it works. I once used IRC through a web-based interface, but I don't remember where it was.

I've been researching the memory structure of Stunts as it loads and I found the following data. Many of this, you probably have already figured out, but other stuff might be useful:

- Stunts has HDR, DIF and COD files for MCGA, TDY (Tandy) and CGA, but the DIF file is replaced by a CMN file for EGA. All COD files for some reason are about 64K long (though never exactly), DIF files are about 16K and the CMN file is about 128K. This cannot be just a coincidence!  HDR files are unmistakenly EXE headers. They are 30 bytes long, but nevertheless correspond to EXE files whose code starts at byte 512. The space in between does not contain any code update, though. COD, DIF and CMN files are slightly compressed with a procedure that looks like a very basic kind of Huffman. This is exactly the same procedure used for 3D shapes compression, so it is already known, as cars are already being edited!!  The actual sizes of decompressed codes are specified at the second byte of these files and do not match with the size estimate contained in the headers, which is much bigger.
- STUNTS_K.EXE, the crack, is lightly encrypted. The encryption system can easily be removed with UNP. The unpacker will ask for a passcode. First thing I thought worked: it's just "stunts_k". The resulting file is smaller than the encrypted one.
- STUNTS_K.EXE is loaded, keeping its environment MCB and code MCB. On top of it, STUNTS.COM runs, which also preserves its environment, reads the configuration file and loads LOAD.EXE into memory half-manually, apparently upgrading the code depending on the graphics card selected. LOAD.EXE runs. Environment is preserved again. LOAD.EXE reserves a lot of heap and no dynamic memory is allocated for variables. Only one extra MCB is allocated, but it is used to store only the sound driver, which starts at byte zero. If no sound card is selected, PC-Speaker driver is loaded anyway, but is not used. This last MCB takes up all the rest of the available conventional memory, even though it is not necessary.
- I have verified that the data contained in MCGA.COD and MCGA.DIF is not found in memory while Stunts is running. This is a confirmation that the information is compressed.
- Some variables are stored at positions that seem to be also variable respect to LOAD.EXE's starting code offset, even though they are within the same MCB. This is still a kind of mistery to me

Hope it's useful

[llm]

>Hope it's useful

its informative - but a little bit outdated due to the fact that clvn already created an
combined version of the load.exe + hdr, dif, cmn and cod files - only the .drv file is still loaded at runtime
and this version is also cracked (no need for the "unoffical" stunts.com or stunts_k.exe anymore)

just use his version for further investigation (you can then delete load.exe/*.hdr/*.cmn/*.cod/*.dif and stunts.com, stunts_k.exe)

http://dl.dropbox.com/u/213479/execombiner.zip

[llm]

@clvn

i ask a friend of mine to diff the output of ida 4.9 freeware with a recent ida version - the differences for the
game_cracked.exe is marginal only some dos interrupts and std c library calls are better recognised

so is seems to be fully ok to go with the 4.9 version

[llm]

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