Messages

I know little about this subject. But it seems to me that reverse engineering the entire code will not happen anytime soon.

TSR+runtime patching are a complete different story than reversing the entire code - completely unrelated comment

But knowing what we do about the code , we are able to make pretty good TSR's or runtime patches.
It is probably a better choice than changing the half understood source.
It may be a quick and dirty solution but it might increase the playability of the game.

the fixes you install with the TSR can be easier and safe be done in the source itself, the TSR does not help to prevent ANY of the technical problems (anything thats wrong in source-time is also wrong at runtime)
and the changes to the main source should be already separated by IFDEFs to keep it clean

a TSR isn't something that can magical changes the nature of the executable in
a way that modifications are more trival/easier to do, a runtime-approach makes it even more complex
in can do the very same inside of the source but much safer without playing around with non-symbolic offsets to patch etc.

but that is all based on missing knowledge about how assembling or executables work - too much guessing and assuming, it is absolutely clear whats needed and how time consuming it is, for every case we talked about (and porting to C is just one of 8 possible further steps) - but you have currently no chance (but your knowledge is already growing) to take the right decision, because that needs a deeper level of understanding, without trick and trial&error

im telling you the best approach, but you aren't able to understand it, you want to go further, ignoring my tips because they also fail very quick (due to missing konwledge etc. on your side) - as i told you before - reverse engineering is the prime class of development - all problems at one point combined

i hope to find more time in the future to help "finishing" the project

a TSR will not change the problem of moving code around
(which is solveable by link-virus style programming)

it makes not real sense staying away from the source by adding a patch-systems with mods that still can't be created without
decent knowledege about the code and positions

That is where my idea for a replacement main menu came from. We only need to know how it stores global variables (player car, opponent and car, track and graphics settings).
Then we can use the new menu as tsr.
We could add a simple redirect in the code and compile it. It would make further messing with the code unnecessary for menu related changes.

i don't see anything better in using a TSR (when NOT only changing variable values like a game-cheater, which is currently the easiest change in source)
patching the code at runtime is equaly error prone then doing it in source - because there is no difference
as long as you cleanly check what you code-change changes - that goes for the sourc-code as for the TSR changes, a TSR isn't some sort of magical working isolation - and yes im developed some TSRs and runtime patchers - but only because i did not got the source around

That is really interesting to see!  Inline assembly emulation. That would help solve lots of things!

what things do you think about, different than my things?

I had already thought in the past about the possibility of just inserting a call instead of the direct code and putting the main code somewhere else, but what I don't know is if the new segment will end up at the end of the whole program code, because if it's somewhere in the middle, still some program code would be moved done. I don't know much about Turbo Assembler and how it does its thing. If I were sure about it, I could use that.

the order of the re-states segments in the inc file is the order of segments in the executable
new code (with segment-realtions) will change the relocation-table but that isn't a problem

On the other hand, there's another idea I'm having right now which could simplify all this. Instead of inserting new code within the compiled program... this is DOS!  No memory protection, no difference between data and code. And while this is bad for many things, it has its advantages. How about I create a TSR that hooks up a custom interrupt and have Stunts call this interrupt as an API. The hooking would be small and I could do it virus-like, but then, every other bigger mod would just be part of the TSR, not the main program, so nothing would be moved down!  What's more, I could make the TSR be a mod hub where other mods can be plugged in. When I have a moment, I'll start working on that.

a TSR will not change the problem of moving code around
(which is solveable by link-virus style programming)

it makes not real sense staying away from the source by adding a patch-systems with mods that still can't be created without
decent knowledege about the code and positions

from my VS2019 IDE - uncompress is started - the 16bit DOS game Alpha Waves is waiting for the uncompressed data - based on my 32bit C++ code
so i change dosbox in a way that calls inside of the emulated code are hooked and replaced by my own C++ code, this way i can partially replace code

https://imgur.com/a/vwhrMzY (use this link for a larger image)

my current solution for modifying games more or less safe is using dosbox as a backend
for example: im able to hook function calls and overwrite code parts, very good for porting because
you can port a function while the function is in use by the emulated code

for example the data compression routine of the Alpha Waves game
disassembled in IDA then converter to my tiny "emulator" that fakes the minimal
aspects of the x86 code to ease the porting to C

emu_t just got some registers, memory and methods that look like the original
asm and behave like the original asm code - but its just C/C++ code

this function gets called by dosbox when the emulated code actually wanted to call the original
16bit code, i can debug, step through it, log data, write unit-tests etc.

this is my third try to port that function properbly - before just in assembler and 16bit C
but subtile micro difference seemed to work but my port was until now only working with 95%
of the data

Code Select Expand

void UNCOMPRESS_sub_1BAE7(emu_t &e)
{
start:
e.push(e.es);
e.push(e.di);
e.cx = 0x80;
e.ax = e.ds;
e.es = e.ax;
e.di = 0x301;
e.xor(e.ax, e.ax);
e.rep_stosw();
e.pop(e.di);
e.pop(e.es);
e.sub(e.di, *e.word_ptr(e.cs, 0xBAA2));
e.ax = e.di;
e.shr(e.ax, 1);
e.shr(e.ax, 1);
e.shr(e.ax, 1);
e.shr(e.ax, 1);
e.cx = e.es;
e.add(e.cx, e.ax);
e.es = e.cx;
e.and (e.di, 0x0F);
e.add(e.di, *e.word_ptr(e.cs, 0xBAA2));
e.push(e.ds);
e.push(e.es);
e.push(e.si);
e.push(e.di);
e.cx = 4;
e.di = 0xBA9A; // offset byte_1BA9A; ???
e.ax = e.cs;   // seg seg000 // cs register; ???
e.es = e.ax;
e.lds(e.si, *e.dword_ptr(e.cs, 0xBAA4));
e.ax = e.si;
e.shr(e.ax, 1);
e.shr(e.ax, 1);
e.shr(e.ax, 1);
e.shr(e.ax, 1);
e.dx = e.ds;
e.add(e.ax, e.dx);
e.ds = e.ax;
e.and (e.si, 0x0F);
*e.word_ptr(e.cs, 0xBAA4) = e.si;
*e.word_ptr(e.cs, 0xBAA4 + 2) = e.ds;
e.add(*e.word_ptr(e.cs, 0xBAA4), e.cx);
e.rep_movsb();
e.pop(e.di);
e.pop(e.si);
e.pop(e.es);
e.pop(e.ds);
e.dx = *e.word_ptr(e.cs, 0xBA9C);
e.inc(e.dx);
e.cmp(*e.byte_ptr(e.cs, 0xBA9A), 0);
if (e.jnz())
goto loc_1BB63;
goto loc_1BC52;
// ---------------------------------------------------------------------------

loc_1BB63:
e.push(e.ds);
e.push(e.es);
e.push(e.di);
e.xor (e.ch, e.ch);
e.cl = *e.byte_ptr(e.cs, 0xBA9A);
e.di = 0x201;
e.ax = e.ds;
e.es = e.ax;
e.ds = *e.word_ptr(e.cs, 0xBAA4 + 2);
e.si = *e.word_ptr(e.cs, 0xBAA4);
e.add(*e.word_ptr(e.cs, 0xBAA4), e.cx);
e.rep_movsb();
e.cl = *e.byte_ptr(e.cs, 0xBA9A);
e.xor (e.ch, e.ch);
e.di = 1;
e.add(*e.word_ptr(e.cs, 0xBAA4), e.cx);
e.rep_movsb();
e.cl = *e.byte_ptr(e.cs, 0xBA9A);
e.di = 0x101;
e.add(*e.word_ptr(e.cs, 0xBAA4), e.cx);
e.rep_movsb();
e.pop(e.di);
e.pop(e.es);
e.pop(e.ds);
e.xor (e.ch, e.ch);
e.cl = *e.byte_ptr(e.cs, 0xBA9A);
e.xor (e.ah, e.ah);
e.bx = 1;
loc_1BBB4:
e.al = *e.byte_ptr(e.ds, e.bx + 0x200);
e.si = e.ax;
e.dl = *e.byte_ptr(e.ds, e.si + 0x301);
*e.byte_ptr(e.ds, e.bx + 0x402) = e.dl;
*e.byte_ptr(e.ds, e.si + 0x301) = e.bl;
e.inc(e.bx);
if (e.loop())
goto loc_1BBB4;
e.dx = *e.word_ptr(e.cs, 0xBA9C);
e.inc(e.dx);
e.cx = 1;
loc_1BBD2:
e.dec(e.dx);
if (e.jnz())
goto loc_1BBE1;
loc_1BBD5:
e.cmp(*e.byte_ptr(e.cs, 0xBA9B), 0);
if (e.jz())
goto locret_1BBE0;
goto start;
// ---------------------------------------------------------------------------

locret_1BBE0:
return;
// ---------------------------------------------------------------------------

loc_1BBE1:
e.push(e.ds);
e.si = *e.word_ptr(e.cs, 0xBAA4 + 2);
e.ds = e.si;
e.si = *e.word_ptr(e.cs, 0xBAA4);
e.lodsb();
*e.word_ptr(e.cs, 0xBAA4) = e.si;
e.pop(e.ds);
e.bx = e.ax;
e.cmp(*e.byte_ptr(e.ds, e.bx + 0x301), 0);
if (e.jnz())
goto loc_1BC01;
e.stosb();
goto loc_1BBD2;
// ---------------------------------------------------------------------------

loc_1BC01:
e.bl = *e.byte_ptr(e.ds, e.bx + 0x301);
e.xor (e.ax, e.ax);
e.push(e.ax);
goto loc_1BC35;
// ---------------------------------------------------------------------------

loop_x:
e.bp = e.ax;
e.cmp(*e.byte_ptr(e.ds, e.bp + 0x301), 0);
if (e.jz())
goto loc_1BC44;
e.cmp(e.bl, *e.byte_ptr(e.ds, e.bp + 0x301));
if (e.ja())
goto loc_1BC30;
e.al = e.bl;
e.bl = *e.byte_ptr(e.ds, e.bp + 0x301);
loc_1BC22:
e.bl = *e.byte_ptr(e.ds, e.bx + 0x402);
e.or (e.bl, e.bl);
if (e.jz())
goto loc_1BC42;
e.cmp(e.bl, e.al);
if (e.jb())
goto loc_1BC35;
goto loc_1BC22;
// ---------------------------------------------------------------------------

loc_1BC30:
e.bl = *e.byte_ptr(e.ds, e.bp + 0x301);

loc_1BC35:
e.al = *e.byte_ptr(e.ds, e.bx + 0x100);
e.ah = e.bl;
e.push(e.ax);
e.xor (e.ah, e.ah);
e.al = *e.byte_ptr(e.ds, e.bx);
goto loop_x;
// ---------------------------------------------------------------------------

loc_1BC42:
e.ax = e.bp;
loc_1BC44:
e.stosb();
e.pop(e.ax);
e.or (e.ax, e.ax);
if (e.jnz())
goto loc_1BC4C;
goto loc_1BBD2;
// ---------------------------------------------------------------------------

loc_1BC4C:
e.bl = e.ah;
e.xor (e.ah, e.ah);
goto loop_x;
// ---------------------------------------------------------------------------

loc_1BC52:
e.push(e.ds);
e.push(e.es);
e.cx = *e.word_ptr(e.cs, 0xBA9C);
e.push(e.cx);
e.ds = *e.word_ptr(e.cs, 0xBAA4 + 2);
e.si = *e.word_ptr(e.cs, 0xBAA4);
e.add(*e.word_ptr(e.cs, 0xBAA4), e.cx);
e.rep_movsb();
e.pop(e.cx);
e.pop(e.es);
e.pop(e.ds);
goto loc_1BBD5;
}


Yet, we had to do it that way because there was no other in this case, but a full rewrite of the game to C or a recreation with a new engine are the only options if we want a stable modded game

its still possible but you need to be very carefull - don't add code in between that moves code, always try
to be binary equal or not equal in very small well known parts

for example - adding only code by link-virus behavior, add a new segment, ignore relocation table changes, patch calls into the code (save the original code) - recover original code after running the new code - this way you can add large amounts of code without changing too much

or search the code for non-symbolic offsets and fix them to symbolic ones, then your able to change everything without problems - but that could be time consuming

but this is all in all very "tinker"

i had little time so i did an all or nothing approach.
Changing all files creates a near copy, but there are many bit differences, and it does not run,.

expected result

Yes and no.
After fixing a typo I did it again and although it still doesn't work, i did get a clear error message.
I forgot to write it down but it was something along the line of that it failed to read the contents of sdmain. Vsh..
So maybe..

Te correct version is already in the post above, just didn't go into details because I had no time for it at that moment.

you will get random problems when not beeing binary equal - and you will not be able to test all effects (its impossible) - to not create a binary compatible version (which is easy and clear what to do) is like asking for random trouble somewhere over the complete code - anytime in the future - the 100% binary equal version is by design correct

there is no "it seems to work" partially - every move of code is just wrong (what does not mean in any form that the game will crash - but still its wrong, for example subtile errors in the physic engine, speed, while drawing etc., unlimited amount of silly invisble bugs)

i had little time so i did an all or nothing approach.
Changing all files creates a near copy, but there are many bit differences, and it does not run,.

expected result

Oh, it's great that you've kept your C and assembly polished throughout the years.

im working in this business - would be sad if i would stop polishing it

As you know, I've been wanting to start working more in C, but the lack of native graphics (native to the compiler, that is) has been stopping me.

ever tried Allegro? https://liballeg.org
Version 4.2 supports DOS (Allegro 4.4+ removed the support) https://liballeg.org/readme.html 

Allegro 4
Allegro 4 is the classic library, whose API is backwards compatible all the way back to Allegro 2.0 for DOS/DJGPP (1996). It is no longer actively developed, but we still apply patches sent to us by contributors, mainly to fix minor bugs. Every so often we will make new releases.

Allegro 4.4 supports the following platforms:

Unix/Linux
Windows (MSVC, MinGW, Cygwin)
MacOS X
Haiku/BeOS
PSP (currently in git repository only)
The older Allegro 4.2 branch additionally supports:

Windows (Borland)
QNX
DOS (DJGPP, Watcom)

i don't know if its worth to invest time in this area to come up with your own solution
just wrap the stuff in you graphs.h/c and replace it later when everything is working - the best
pixel drawing routine is for nothing if its not called for doing something magical

did it work to change the segment alignment to para?

It is possible to have zero-length code... in a way. This is what many viruses do. You analyse the original code, then make it shorter by either using more space-efficient code or dropping things that are not being used. Finally, use the newly available space to introduce new code.

im well aware of that and using it activly in some of my reversing projects
im in the assembler,C/C++, reversing, disassembling area more or less full time per day for the last 15 years - there is nearly nothing i haven't touched in that time

Cas and I used asmorig in all cases. Also checked the executable against game.exe (the execombined executable)

im mean the unchanged asmorig - just to prevent other problems with your extensions
(it a clean test that do not need to happen in a already changed source)

Al changes in the code are local and besides a offset with the last modification there are no differences besides what is to be expected as far as I can tell.

your changes must move code and offsets - because new code can't be of size 0 (or did Cas magic?)

We didn't touch the version with c code substitution because that brings extra uncertainty to the mix.
We kept it as close to unmodified original as possible.
Now we know more we could try the same thing with c code. See what effect that has and if that works better or not.

its very possible to only use c code for your extensions - adding a new segment for example and some patching, the other c ports are not needed to use c code for your stuff

Do they need to be changed in the ASM file and the INC file simultaneously for each segment?

yes all segment names/definitions need to be equal

AND you should base on the original asm - i have no idea if you and Cas checked if the exe changed with your extension in an unwanted way (what does not mean in any way that it would crash, could be that it just works but still wrong)

[very last]

But that's relative easy to do i guess .

more or less - one need to change (starting with the very last segment, going up) to change "byte" to "para" - assemble and check if anything in the exe changed, then the next segment, one by one - producing as many exes as segments available

Code Select Expand

seg041.asm
dseg.asm
seg039.asm
seg038.asm
...
seg000.asm

from last to first because then its easier to see in a hex-editor what parts changes down, if you start with seg000 everything will change because the segments are orderd seg000, ... ,seg039, dseg, seg041 (segment 40 is the dseg (data segment))

it will mostly result in some bytes more (or less) around segment ends/begins then in the previous exe - which needs to be removed(added) in the assembler source

we can't tell if something starts at a location because the previous block was padded with extra bytes or because it just ended there, so we just align to the byte

one need to check if removing these bytes + segment align=para works - it should, but that isn't just replacing byte with para - every segment needs to be checked in the resulting exe to prove that it works - because you said it need to be aligned and para was were common in that days