Freedos usb stick?

[Cas]

Hey, guys... It's late and I'm super sleepy, so excuse me for not reading all recent messages in detail. After giving a quick look, I'm thinking of these things:

- As I understood it before and I think it's the same as stated now, stunts.com reads the config and calls load.exe with the command line corresponding to the configuration. Then, load.exe runs and unpacks itself. Once unpacked, depending on the command line, selects a graphics driver and writes the driver file on top of itself at some part in memory to modify the game's code so that it works for that adapter. After that, the game continues without significant modification of the code segment. Am I right?

- If I'm right about the previous thing, then unpacking load.exe and precombining it with the MCGA driver, which is the only graphics driver we really use and then running that final executable file, without needing to recompress it, would yield a normal EXE file that would not do weird things in memory. Can that be done?  I really haven't read restunts in much detail. Maye all this is already thought of.

- Finally, stunts_k is a TSR that works by waiting for Stunts to be in memory, unpacked an all, and then checks a certain region of memory in order to crack the "security system". If it fails to find this region, it does nothing, potentially making the game unstable. Modifying the executable has a chance of interfering with stunts_k. I've confirmed in the past that loading other TSRs before stunts_k does often interfere too. I think if we have the keys, it's "healthier" to just avoid stunts_k, but we can continue to use it whenever things work well.

[llm]

Thx, i forgott that the combined result is also exepacked, makes it even harder to reach just C
(more then 10 years since ive worked on the load.exe analyzation...)

load.exe combines stuntspacked files which results in a in memory game executable that itself is exepacked, its easy to patch the protection in the end result, but very hard in the starting components

[llm]

If im right about the previous thing, then unpacking load.exe and precombining it with the MCGA driver, which is the only graphics driver we really use and then running that final executable file, without needing to recompress it, would yield a normal EXE file that would not do weird things in memory. Can that be done?  I really haven't read restunts in much detail. Maye all this is already thought of.

Thought out and working for the last decade that is what the execombiner from the restunts project does, that is the base for all reverse engineering analysis

svn://anders-e.com/restunts/trunk/restunts/src/execombiner (uses https://github.com/dstien/gameformats/tree/master/stunts/stunpack)
other implementation: https://github.com/w4kfu/Stunts/tree/master/makegame

the drvcombiner goes even further and integrates a selected sound driver into the exe
svn://anders-e.com/restunts/trunk/restunts/src/drvcombiner

an svn client is needed for the svn:// repos - like subversion on command line or for example TortoiseSvn

all that is done to ease the analyze process with IDA or Ghidra - something that is very hard using this high dynamical behaving load.exe

[Daniel3D]

So, if i understand correctly it is very difficult to remove the copy protection from the original file without using execombiner to make a new executable.
Not that i'm opposed to the idea. But it would have been nice to have a ' Freeware ' edition with only original files and working setup..

[llm]

So, if i understand correctly it is very difficult to remove the copy protection from the original file without using execombiner to make a new executable.

correct

the freeware edition would have changes in serveral files and setup is then dead

we could have serveral executables and our own stunts.com (using setup.dat for configuration calling the correct game executable with correct parameters) - but then is maybe more like an "extended" edition

[Daniel3D]

That's sounds reasonable. We could update the version number to 1.2 or something so it is clearly something new.

(I've done that in my testing copy.  just because I can )

[llm]

That's sounds reasonable. We could update the version number to 1.2 or something so it is clearly something new.

ok - will take a look what is needed

(I've done that in my testing copy.  just because I can )

"Once you start down the dark path, forever will it dominate your destiny, consume you it will."

[Daniel3D]

But how am I to know the good side from the bad?

Some way to distinguish the alternate version would be sensible. If only for support reason's

[Cas]

It'd be great if that were fully solved and we were all just using the simplified version. So that's the idea behind Restunts, ha, ha. This has happened to me many times: I watch somebody else's code or read a book about something... I understand nothing. Then I sit down to think alone and I come up with the same ideas that were there. My programming is very much lone-wolf-styled   I've programmed this way since 1991 or so.

[llm]

It'd be great if that were fully solved and we were all just using the simplified version. So that's the idea behind Restunts, ha, ha.

Restunts is splitted in three parts:

First: the delevopment of tools that remove cracking or any dynamic loading to ease it for reengineering tools: DONE around 2009: so working for the last 11 years
--> that is the game.exe i attached here for Daniel3D

Second: Reverse the game to assembler that assembles to the very same (100%) original exe: DONE around late 2009: so also for the last 11 years
--> that was the first restunts.exe that is sometimes attached in forum post around the "Reverse Engineering" Topic

Third: Porting function by function to C code and link that to the remaining assembler code (producing the restunts.exe): the creation/function overloading is fully scripted and working for the last 11 years - but the function porting (~800 Functions, 2.5MB of assembler) is not easy an takes much much time - maybe 50-60% done in 2009-2012... i think
--> that are restunts.exe that is are attached in following forum post around the "Reverse Engineering" Topic
--> also the rpldump tool is based on that code

there are no technical obstacles - just much much of manual asm to c porting work and much much reverse engineering understanding of the asm code
everything is public available, buildable from source and nearly working right out of the box

[Cas]

Oh, then it's much more advanced than I thought!   One thing is coming to my mind.... What if the code were translated as-is to native assembly, plus C for modern systems?  That is, replacing DOS function calls with their "equivalents" for each system, and so on. This could be done pretty fast and would allow to compile and run the game immediately and then, continue analysing the code and turning assembly into C, but we wouldn't have to wait until it's fully completed to use it.

[llm]

Oh, then it's much more advanced than I thought!   One thing is coming to my mind.... What if the code were translated as-is to native assembly, plus C for modern systems?  That is, replacing DOS function calls with their "equivalents" for each system, and so on. This could be done pretty fast and would allow to compile and run the game immediately and then, continue analysing the code and turning assembly into C, but we wouldn't have to wait until it's fully completed to use it.

Stunts is 16 bit segment/offset real mode code that means you can only run in 16bit emulation mode under Windows - without ability to call even 32bit APIs, direct graphics and sound programming is also a big problem - most games that are reversed like that are already 32bit flat-mode code with dos-extender (for example Syndicate Wars) - converting the 2.5MB/~300KLOC 16bit asm to 32bit asm is nearly impossible and can't be done in small steps

i've always thought about converting the 16bit asm to functional equivalent C-code (like https://github.com/xor2003/masm2c does) but its still a huge challenge to come to the same behaving code, xor2003 startet to write a new asm parser/generator right now for stunts - but that will still take some time

another idea was to use DosBox as an environment like Bright-Eyes (https://github.com/Henne/Bright-Eyes, process-description: https://github.com/Henne/Bright-Eyes/issues/49) does intercept the function calling and routes that to real real C functions interacting with the emulated environment - thats why i played with some sort of emulation and changed the simple x86 emulator Fake86 to become a StuntsVM (which is only and direct capable to run stunts - also available here in the Forum) - but its all very time consuming

the current restunts function were ported under DOS with simple debuggers etc. very time consuming etc.

[Cas]

Yes, I imagine   It's too much assembly code!

Of course, translating assembly manually would take just as long as translating C, perhaps, so there's no point, but I was hoping it'd be possible to "automatically" convert assembly. Like... the code is separated in its functions and then each call to each function is transformed into a 32bit call to a 32bit memory region instead of 16bit segment:offset. Non-flow instructions are translated to their equivalents in 32bit, sometimes an instruction would turn into two or vice-versa. Calls to code outside Stunts, such as DOS interrupts are recognised and turned into calls to home made system functions that are analogous to DOS ones. Calls to sound functions are redirected to null functions temporarily. Once the whole thing works, the 32bit assembly program is converted to a C based inline assembler and the functions that have already been translated to C are replaced and the program recompiled in C with inline assembly. Of course, all this work will fail if Stunts does any weird thing like writing on its own code. Data memory regions would also have to be accounted for. A memory map has to be created before making the program to perform this huge operation. Yes, it's tons of work and harder, but maybe, in the end, faster. Still, I understand you... just thinking of it makes me feel like ditching the idea, ha, ha.

[llm]

but I was hoping it'd be possible to "automatically" convert assembly.

thats the only way it could be done without introducing to many errors
problem with that is: currently not every offset is a symbol - sometimes only ax+0834 or something, it could happen that
the different 32bit code size changes the offsets etc.

the rest is more or less the ideas that are aorund - but its just a spare time thing

Of course, all this work will fail if Stunts does any weird thing like writing on its own code.

as far is i know - no self modifying code in stunts

i've attached the lastest asm-source (that gets you to a nearly 100% identical version of the original exe) so you can have a look how complex/time consuming it could be
the big problem are also 16bit offsets as function parameters that then get combined with some segements to form a real address - hard to follow that automaticly without semantic knowledge

[Daniel3D]

Side question...

Since I don't have any problems with memory with the game.exe.
Does game.exe still load in real mode memory? Or secretly in extended?

I don't know how to check that..