Messages

MD15.DRV "Versions" in several DSI games

Code Select Expand


Game                                   ~Release    Filesize MD5

Stunts 1.0                             11.10.1990  1667     7048D28F2A0FE8C8C09141D5C89706DB <- Part of my Reversed-MT15.DRV Projekt
4D Sports Boxing 1.0                   05.10.1990  1667     7048D28F2A0FE8C8C09141D5C89706DB
Bill Elliotts Nascar Challenge         ~1991       1667     7048D28F2A0FE8C8C09141D5C89706DB
Stunts 1.1                             ~1991       1750     ACC5D03D038F1EF0AFA0CF4DCAD72EF9 <- Part of my Reversed-MT15.DRV Projekt
4D Sports Boxing 1.1                   22.04.1991  1788     B17BBC19ED37C9413DD68E20D4D9848F - Sounds correct with Stunts!
Mission Impossible                     22.04.1991  1788     B17BBC19ED37C9413DD68E20D4D9848F - Sounds correct with Stunts!
World Tour Tennis                      ~1993       1789     53F6BCAEBC097893868C69CE994A3321 - Sounds correct with Stunts!
4D Sports Tennis                       03.03.1992  1789     53F6BCAEBC097893868C69CE994A3321 - Sounds correct with Stunts!
Michael Jordan in Flight               21.12.1992  1813     372ED87FEE4FB0762D2531DC8BB34337 - Sounds correct with Stunts!
The Simpsons: Barts House of Weirdness ~1991       1982     8326A348DCC756EEB77466AD53F742EA - Sounds correct with Stunts!


would be interesting to check:
-what are the additional bytes in the other versions (more Data, more Code?) i thinks mostly timing code differences (primary bug source)

btw: nearly equal size does not mean small differences

as far es i know, we dont even got a unpacker for stunts 1.0 resources, i dont think that the restunts tools ever got tested on 1.0, so its a different beast

In the bypassing load.exe there is mention of a repackaging tool.
http://forum.stunts.hu/index.php?topic=2454.msg55894#msg55894

could be hard work to get it going - some hours/days - because the stunts unpacked files are still part of a bigger exepack packing - i don't know
how to change a single byte in a partial part of an packed exe without breaking the exepack unpacking process

and in the end your'e still struggeling with a exepatch-bug-suffering load.exe which prevent pure DOS use

and i still think you didn't understand the complexity

exepack is like "zip"
stuntspack is like "7zip"
-> both packings are incompatible

zip(original.exe(here is the byte-pos known)) -> chop in 3 parts -> 7zip each part on its own

so even if i 7z-unzip the correct chopped part you still would not find the correct byte in this uncompressed part because it is still part of a bigger zip-file (differently compressed - and not blockwise but complete)

that is super special for this game and nothing typical or usual

I realized that to later. I copied the text of the copy that dreadnaut made of dstien's repository. It is clvn's SVN.

there is no dstiens SVN repo - cvln's the only one (also refered as base on the gitlab page from dreadnaut)

not in a million years - these exes/coms have nothing in common

Ok. I was afraid you would say that.
I kind of expected it to be so as well.

So if I understand correctly. Load.exe creates an executable in memory based on the setup information.
For the reengineering project, only the MCGA/VGA output and the sound blaster/pc speaker were taken.
To create a different version, that process has to be redone with different setup data.

yupp - but the game.exe you've got is exactly the In-Memory version of the exe which load.exe produces if MCGA is selected in config
the sound drv integration is a different project

Then I return to my original idea. Can we change the copy protection bit in the original files?
I would like the copy protection popup to disappear like in the restunts version. Because it's annoying.

The other video modes are useful for creating better car graphics, but are not necessary for reverse engendering, if I understand correctly.

i don't think that is doable because the exe is builded like that game.exe = microsoft.exepack(stunpack(fileX)+stunpack(fileY)+stunpack(fileZ))
think of it as an mathematical expression - you want to change a byte in a stunpack compressed file that is also exepacked with other stunpack files
its not something like a zip-file its the pure binary code attached to get working - there is no way to get to that point without changing the files to a
non original state and we are missing a stunpack implementation that can re-pack the files

it changes the result that much that is isn't original anymore and only for keeping the setup-tool alive

i don't know what you mean by "better car graphics" CGA/EGA/TANDY are older technologies and got much less colors then VGA (4 or 16 colors, i don't know TANDY)

/nb - parsed, but unused
/ssb - use soundblaster (ad15.drv) instead of pc speaker
/sXY - use driver XY15.drv instead of pc speaker (e.g /sad for soundblaster)

But these are all sound related.

because only the sound drivers are loaded dynamical by stunts

Are the video parameters accepted as well?

no - the real executable is constructed (in RAM) based on the setup-selected code-file-parts - the sound driver get loaded by stunts itself

In other words. If I would rename that executable to load.exe. would it load correctly with the setup.dat information if I run the game with stunts.com??

not in a million years - these exes/coms have nothing in common

that is the reason why i sometimes talk about decent game.exes for CGA, EGA, MCGA and TANDY

all the non loader.exe programs (stunts.com, stuntsk.com etc...) are not part of the original package and not needed at all

So the whole deal with load.exe was intended as an elaborate way to hide the actual executable so the game would be difficult to crack?

that or maybe some extreme size constraints with release floppies that demand such splitting (but i don't think that was a problem at that time)

and also takes the load.exe process some more RAM - so its definitily not a RAM saving strategy

btw: the combine tool should also work with the CGA,EGA and TANDY Version - but i think never tested before

so in the End we've got a CGA,EGA,TANDY and MCGA exe - the Sound-Driver get loaded dynamically

my drvcombine tool just disables the dynamic loading of the sound drivers by directly integrating a driver (but that is only to ease the reverse engineering - then the disssembler can see also into the sound driver code - that was NOT in any way part of the original DSI release/packaging-process)

here is the full exe combine code - even for non programmers small enough to someway understand was happening

https://github.com/xor2003/restunts/blob/master/src/execombiner/main.cpp

the input files in https://github.com/xor2003/restunts/tree/master/src/execombiner/assets
are alreay unpacked with dstiens stunpack

after the combine run the resulting exe-file is manually unpacked with UNP (or other Microsoft EXEPACK capable unpacker)

and then the byte is changed to disable copy protection (which prevents a jump to exit or something like that)

Just found the adapter to connect them to USB. This shall be the work for my next evenings. Will let you know if I found anything (or not).

The force is strong in you, young Mark Nailwood

I think they produced normal game.exes with the compiler with mapfiles, containing start/end of all the functions inside, packed the exe with exepack from microsoft, splitted the exe afterwards at multiple points in the base code and grafix code, packed the splitted parts with stunts own packing format and wrote load.exe to reverse this process at startup time

As learned form dstien's restunts SVN repository the copy protection can be permanently disabled by setting a 0 to a 1 on two locations.
Why then are the cracks so elaborate?

First of all, its clvn's SVN, he started the restunts project

The cracks did not go the route to analyse the process of unpacking multiple files and combining them in ram before run, and reverted that process, what load.exe does but hooked themself at the end of this process and then do their thing, typical for most of these times crack programs

the original exe is like what clvn's unpacker creates with the restunts game.exe, but the dsi guys want it further processed, maybe for protection reason, most of the combined code file parts are afterwards packed with stunts own resource packing algorithm and the complete resulting executable is another time "packed" with exepack from microsoft, that is very special and not a typical way of distributing a executable

In the resulting executable what load.exe combines in memory to the game.exe is a pure uncompressed exe image that just contains a trivial password check that is easy to disabled by patching the result of a is-correct-password-result to always success

@Daniel3D which versions are these?

I know of this one:
http://stunts.kalpen.de/stunts.htm

See attachment

what is the source of the floppy image? (i've already got all the available downloads - for years)

Code Select Expand

What I found:

i talke about floppy binary images - not pictures of the floppies

i've downloaded everything i've found - kalpen, abandonia etc. years ago - but no clean floppy images

the floppy images here seem to be only the same version n times with different names
https://archive.org/search.php?query=stunts%20floppy%20image