DOS Doom Code Execution

[Redneckerz]

2 hours ago, kgsws said:

Savegame only indeed. But that is only important for snake example. You would want to include your mod in WAD file anyway.

By the way, Doom2 exploit actually runs a few instructions from sector 0. Yes. An executable code in sector data. (you can checkout readme.md on github)

 

I have updated loader to load code from WAD file.

Now i am slowly working on proper example mod. Starting with easy stuff. It won't be that fast for a few days (work) so most of features will be added at weeked.

I can post periodic updates. Or should i rather not spam this thread? Maybe screenshots won't tell much, it looks like any source port :)

 

No, please post periodic updates. Its interesting to read that Doom ACE can work with just a savegame for the Snake example but can also use a WAD for more complexity.

 

I am very curious what you come up with. Some shadow and light trickery? An easy to use way for colored lighting? Or perhaps more UI related things? I am all eyes and ears :)

 

And that screenshot looks fly ;)

[kgsws]

I have a list of features i want to show in my example WAD. Some are easy and fast, others are more complex.

I was fighting with gcc a bit right now, but it's resolved. Here is a quick update for now. Updates will be slower from tomorrow (less time, more complex features).

 

Quote

Nice! I'm also quite curious about how adding looking up/down (Like HERETIC has it.) would work out. However I'm really terrible at programming at the moment, but I could look around how I'd imagine it. I usually play WASD keys so I mount up at 'Q' key and down at 'E' key. As for changing those controls, perhaps adding a menu option like "Other Controls" might work.

Already in. Well, only looking part - no shooting. Shooting requires deeper changes, so later. If there's interest. It works just like mouse look. It replaces original vertical mouse movement.

I have one custom menu planned but nothing complex.

 

1 hour ago, Redneckerz said:

Its interesting to read that Doom ACE can work with just a savegame for the Snake example but can also use a WAD for more complexity.

Most changes can be implemented using savegame only. Even fullscreen status bar i made. But since this is supposed to be API for modding, i kinda expect people to use custom WADs.

I can create fullscreen status bar for savegame only if there's any interest.

 

1 hour ago, Redneckerz said:

Some shadow and light trickery? An easy to use way for colored lighting?

Yes.

 

Just with mouselook and fullscreen status bar it is starting to feel like source port already. I do not know if this is a good or bad thing.

 

By the way, i should focus on Doom 2 v1.9 modding, right? Supporting different versions requires multiple separate compilations right now. And i do not have any easy way to pick which version should be compiled. (My code supports only Doom2 right now.)

[TheNoob_Gamer]

13 minutes ago, kgsws said:

 

So, from what I've seen, this version of Doom ACE supports modifying the status bar more than vanilla but not as flexible as DECORATE?

[THEBaratusII]

1 hour ago, kgsws said:

Holy COW! Can't wait to see it in action on my current Windows 98 rig.

 

Speaking of "current Windows 98 rig" I've finally tested it on a Pentium II 450MHz rig.

 

EDIT : 

1 hour ago, kgsws said:

By the way, i should focus on Doom 2 v1.9 modding, right?

I mean I do see most PWADs I've played use the Doom 2 IWAD, although there are some wads out there that use Ultimate Doom IWAD.

 

My honest answer is that it's really up to you on which version you're targeting, if I was making something myself though, I personally go for Doom 2.

Edited October 5, 2020 by Baratus II

[M_W]

I'd argue Doom 2 v1.9 is the way to go. There are some mods for Ultimate Doom, but the Doom 2 IWAD is by far the most popular for mods.

[NY00123]

It is interesting to see how much can still be discovered about the original executables from the 90s. Congratulations to all contributors!

 

One thing is sure, though: Just in case the idea might be brought up, better don't expect this trick to ever work in Chocolate Doom.

I believe that it's practically impossible, without running a CPU emulator.

[maxmanium]

16 minutes ago, NY00123 said:

One thing is sure, though: Just in case the idea might be brought up, better don't expect this trick to ever work in Chocolate Doom.

I believe that it's practically impossible, without running a CPU emulator.

 

Um... why? I'm aware the source code is not identical, but shouldn't there be a way to implement this?

[holaareola]

14 hours ago, kgsws said:

I have a list of features i want to show in my example WAD. Some are easy and fast, others are more complex.

I was fighting with gcc a bit right now, but it's resolved. Here is a quick update for now. Updates will be slower from tomorrow (less time, more complex features).

 

Already in. Well, only looking part - no shooting. Shooting requires deeper changes, so later. If there's interest. It works just like mouse look. It replaces original vertical mouse movement.

I have one custom menu planned but nothing complex.

 

Most changes can be implemented using savegame only. Even fullscreen status bar i made. But since this is supposed to be API for modding, i kinda expect people to use custom WADs.

I can create fullscreen status bar for savegame only if there's any interest.

 

Yes.

 

Just with mouselook and fullscreen status bar it is starting to feel like source port already. I do not know if this is a good or bad thing.

 

By the way, i should focus on Doom 2 v1.9 modding, right? Supporting different versions requires multiple separate compilations right now. And i do not have any easy way to pick which version should be compiled. (My code supports only Doom2 right now.)

Can't believe I'm seeing looking down and an overlaid status bar in vanilla doom.  Utterly nuts! Incredible work man.

[GooberMan]

16 minutes ago, maxmanium said:

 

Um... why? I'm aware the source code is not identical, but shouldn't there be a way to implement this?

Tricks like this rely on stack overflows. Code will read more data in to a local variable than it should, end result is that the program executes the loaded data as if it were actually code.

 

Chocolate Doom's save code has been rewritten to avoid this, basically by being explicit about the values it reads/writes with instead of leaving it up to memcpy.

 

You'd need an entirely different attack vector to get it to work.

 

EDIT: Also, depending on compile settings, stack overflows can be detected these days.

Edited October 5, 2020 by GooberMan

[Graf Zahl]

Obvoiusly any port trying to support things like this would have to check for the overflow condition and deal with it on its own terms instead of letting it run amok on the system.

But the real problem lies elsewhere. It would only work on x86 32 bit, but that's not really a future proof platform. So to support it on other architectures you need an emulator - but you not only need an emulator but a code checker that blocks malicious attempts to access functions and system calls that can cause real damage. It also needs total knowledge of where functions start, especially in cases where some jumps into the middle of a function are performed. The amount of work needed can quickly exceed any reasonable effort. So sorry for anyone dreaming of getting this to work with more modern ports: It won't happen.

[DCG Retrowave]

My gaming PC runs MS-DOS 6.22 so this is very epic to me! :)

[Linguica]

14 hours ago, TheNoob_Gamer said:

So, from what I've seen, this version of Doom ACE supports modifying the status bar more than vanilla but not as flexible as DECORATE?

 

ACE stands for Arbitrary Code Execution. Webster's dictionary defines arbitrary as "not restrained or limited". If you want to stick Quake inside Doom, then sure, go ahead.

[Maes]

Well, that will be hard to replicate in Chocolate Doom...

 

1 hour ago, maxmanium said:

 

Um... why? I'm aware the source code is not identical, but shouldn't there be a way to implement this?

Only if everybody agrees to use a controlled subset of the IA-32 instruction set and MS-DOS system calls, which could be easily emulated on every platform and be reasonably safe for execution (e.g. no damaging system calls, no hardware-specific calls etc.). Also, everybody should target specific "known good" locations in Doom's memory layout, which at that point could also be provided as macros/defines for this quirky "Doom Assembler", and even source ports could make some sense of what one was trying to achieve -e.g. write directly to a pixel on the screen?

 

At that point you'd have more of a VM or scripting language though, rather than completely arbitrary code execution.

Edited October 5, 2020 by Maes

[Gez]

11 minutes ago, Maes said:

Well, that will be hard to replicate in Chocolate Doom...

Not just hard, but also completely out of scope.

[Maes]

20 minutes ago, Gez said:

Not just hard, but also completely out of scope.

 

How? Isn't Chocolate Doom's purpose to be "as close as possible to the original executable's experience", going to extra lengths as to include Dehacked support, preserving limitations/bugs and even emulating bugs if need be, for the sake of demo compatibility (albeit not to the extreme extents of prBoom+)?

 

Then maybe we need "Real Chocolate Doom": just like Chocolate Doom, but, you know, really real ;-)

Edited October 5, 2020 by Maes

[Gez]

By definition, arbitrary code execution is not the original executable's experience. It's some arbitrary code's experience instead.

 

Supporting this in a port would include grafting something like PCEM or DOSBox.

[M_W]

Changing Chocolate Doom to support ACE not only seems incredibly out of scope and not worth the effort but, in my opinion, kind of defeats the purpose of what makes this exploit so interesting in the first place. It's a newly discovered exploit for a twenty-six year old compiled DOS application.

Edited October 5, 2020 by M_W

[Noiser]

It would be cool to see that being directly emulated on other ports (maybe on a chocolate doom fork), but I'm totally fine with this being an exclusive feature on DOS. 

As I said tho, convert them to other ports may be a possibility in some cases, especially through ACS\ZScript\Decorate. So if someone want to make a project that runs on both DOS and GZDoom, it's possible depending of what you would like to change.

For other ports it would be trickier, but simple stuff regarding monster\weapon behavior can be simulated (partially or not) via dehacked, visual tricks or bug exploits. Crispy\Boom would be a better option for that though, as you can use extended dehacked formats and match features that are already built in these ports (like being able to look up and down). Again, that's up to what you would like to change and how you can use your creativity to adapt these changes on other environments (or you can focus on DOS and not care about any of that, which can be even better).

Edited October 5, 2020 by Noiser

[Graf Zahl]

3 hours ago, Maes said:

 

How? Isn't Chocolate Doom's purpose to be "as close as possible to the original executable's experience", going to extra lengths as to include Dehacked support, preserving limitations/bugs and even emulating bugs if need be, for the sake of demo compatibility (albeit not to the extreme extents of prBoom+)?

 

Then maybe we need "Real Chocolate Doom": just like Chocolate Doom, but, you know, really real ;-)

 

 

It's more a question of feasibility. The way this thing works you need to create machine code that's hardwired to the DOS EXEs intricacies. Trying to execute that code in a different context will be a gargantuan effort that'd only be worth it if there was a genuine gain. And a handful of projects isn't really it. My guess is that the scope of these changes will be on a scale where it is easier to reverse engineer them to source code (unless provided directly, of course) and integrate that code directly into the port or script it in a port capable of instead of trying to run the actual machine code.

 

 

 

 

 

Edited October 5, 2020 by Graf Zahl

[JadingTsunami]

Cross-compatibility will depend, I think, on the API definition. If the interface is defined to abstract the Doom EXE function calls through indirection I think other ports would at least be capable of implementing the API if they chose to do so.

 

This is a non-trivial amount of work, and it does add a lot of necessary boilerplate to every modded savegame data blob. But I think it is doable.

[Redneckerz]

22 hours ago, kgsws said:

Already in. Well, only looking part - no shooting. Shooting requires deeper changes, so later. If there's interest. It works just like mouse look. It replaces original vertical mouse movement.

I have one custom menu planned but nothing complex.

Seeing Snake and a custom status bar is already amazing enough. At this point, stuff like up and down seems almost trivial.

Quote

Most changes can be implemented using savegame only. Even fullscreen status bar i made. But since this is supposed to be API for modding, i kinda expect people to use custom WADs.

Hopefully you agree with me that the differences between the two and what they encompass should be explained very clearly. If most is possible with just Savegame hacks, then the function of the custom WAD has to be explained, and also - How one can craft such a WAD.

Quote

Yes.

 

Just with mouselook and fullscreen status bar it is starting to feel like source port already. I do not know if this is a good or bad thing.

Now that shadow/light trickery i have to see in action. Though, i have little to doubt this given the examples already given. And yes, its a good thing that it looks and feels like a source port.

 

As for your other question - Yes, definitely stick to Doom 2 v.1.9 modding, Ultimate Doom is only something extra as not too many WADS rely on it (But some do, hence the extra). The vast majority is Doom 2 1.9.

 

8 hours ago, maxmanium said:

 

Um... why? I'm aware the source code is not identical, but shouldn't there be a way to implement this?

This only works with either a simulator afaik or low level Higan-like emulation - both are insanely expensive to do in terms of processing power required. Given the limited niche of Vanilla, this may not be worthwhile.
 

Spoiler

Personally i would go for it given that you can implement new renderer effects aswell, but fact is, Vanilla modding is a niche. Boom + ZDoom modding is far more expansive and omnipresent.

 

6 hours ago, Maes said:

 

How? Isn't Chocolate Doom's purpose to be "as close as possible to the original executable's experience", going to extra lengths as to include Dehacked support, preserving limitations/bugs and even emulating bugs if need be, for the sake of demo compatibility (albeit not to the extreme extents of prBoom+)?

 

Then maybe we need "Real Chocolate Doom": just like Chocolate Doom, but, you know, really real ;-)

It would require a very different design philosophy than what Chocolate Doom is for. Doom ACE isn't technically doing anything with the vanilla limits - It fully bypasses them by running custom unsigned x86 code. To replicate that, you need far more than an emulator: You need something that actively simulates every possible quirk that can happen in a real DOS system. That's far beyond the scope of Chocolate Doom.

 

Chocolate Doom ACE could be a side-project however, but it would be independent from the main Choco codebase. And it would only be usable for those mods that actively abuse ACE. Given how long Choco Doom has been around and how long it usually takes to simulate a DOS system, this would be cost of effort/cost of effectivity issue here.

 

One thing to spark additional interest is by more examples of its possibilities, mind you...

3 hours ago, Graf Zahl said:

It's more a question of feasibility. The way this thing works you need to create machine code that's hardwired to the DOS EXEs intricacies. Trying to execute that code in a different context will be a gargantuan effort that'd only be worth the effort if there was a genuine gain.

Considering the kinds of things shown off (Status bar, snake game) and what else is possible (New light/shadow effects) the gain is obvious.

 

The gargantuan effort you speak of is replicating it on anything outside Real DOS, because DOSBOX may work ever so slightly (But so far has seemed to do deal with it relatively well).

What's needed is either:

• Higan like Low Level Emulation that emulates these things at the microlevel
• A DOS simulator that actively simulates a real DOS PC, including its idiosyncrazies (literally) to make ACE possible.

Both options are indeed a gargantuan effort as described, the latter even more so. It would also be prohibitively expensive in CPU power.

 

But, it is a possiblity. Perhaps using FPGA's? In the short term, improving DOSBOX or an existing DOS simulator (if any) is beneficial to achieving new hacks. So far, DOSBOX seems to do well here.

Edited October 5, 2020 by Redneckerz
I annoy people with words. Now i am correcting them.

[Dragonfly]

56 minutes ago, Redneckerz said:

Chocolate Doom ACE could be a side-project however, but it would be independent from the main Choco codebase. And it would only be usable for those mods that actively abuse ACE. Given how long Choco Doom has been around and how long it usually takes to simulate a DOS system, this would be cost of effort/cost of effectivity issue here.

To add to this, anyone tasked with making such a thing possible will tell you to go away and mod the source code yourself to include whatever arbitrary extras you want. :P

Edited October 5, 2020 by Dragonfly

[Blzut3]

1 hour ago, Redneckerz said:

and what is supposely possible

I guess it hasn't been spelled out clearly enough yet: An ACE is effectively the same as just running another executable except for the fact that Doom will already have been loaded into memory.  It's not "supposedly possible," it is possible, since this can do literally anything that can be done with the hardware.  There is no fundamental difference between using the ACE and compiling the whole game from source except for the novelty of live patching the vanilla binary blob.

 

I'm not entirely familiar with how the control API works or the Doom network drivers work, but these modular pieces of Doom could probably also be used to attach arbitrary code to a running instance of Doom.  It loses some cool factor since it's not using an exploit, but it would still be taking advantage of the fact that DOS has no memory protections.

 

This is why this kind of thing would be out of scope for Chocolate Doom, as while yes you could make a version of DOSBox that only runs Doom to emulate it, this effectively blows the scope of the project to PC emulator.  And I do mean PC emulator since there's nothing stopping you from making calls to Windows 9x, or booting Linux from a Doom save game.

 

Now if you want to have fun with this particular method of injecting code, by all means go right ahead.  I've personally thought about playing around with the theoretical ACE in Hexen's ACS code (which would be an in my opinion cooler exploit since it could be buried in an ACS0 compatibility stub allowing the mod to be EE (if it had Hexen support), Vavoom, ZDoom, and seemingly "vanilla compatible" just by starting up the game).  But make no mistake, this is just a round about way of making a new source port.

 

With all that said, if you all are going to actually use this to create things, I would strongly encourage people to refrain from calling the result a "vanilla mod" or something with that implication.  I say this as the developer of ECWolf and having to put up with articulating what is compatible with ECWolf in a landscape where creating custom source ports is very common and the results are called "DOS mods" and "Wolf4SDL mods" leaving no distinction for things actually compatible with unmodified code.  Now I don't expect this to get super popular in this community since we don't have a culture of creating custom source ports for mods (although there have been a handful), but if it does at least I can say I warned you all to avoid making things confusing for new players.

Edited October 5, 2020 by Blzut3

[M_W]

Expecting Chocolate Doom to run this exploit is the equivalent of expecting a port of Splinter Cell to support Xbox soft mod exploits.

[Redneckerz]

27 minutes ago, Blzut3 said:

I guess it hasn't been spelled out clearly enough yet: An ACE is effectively the same as just running another executable except for the fact that Doom will already have been loaded into memory.  It's not "supposedly possible," it is possible, since this can do literally anything that can be done with the hardware.  There is no fundamental difference between using the ACE and compiling the whole game from source except for the novelty of live patching the vanilla binary blob.

I am aware.

 

I willl remove any and all hints as to any doubts regarding ACE's since its clear that putting in unwarranted disclaimers such as from myself trickles you into writing a clarification and getting likes on it because this clarification is needed.

 

And it should not be needed anyway so this annoys me enough to just outright remove it. You didn't need to clarify it, and its my own damn fault that you felt heckled enough to do so.

27 minutes ago, Blzut3 said:

This is why this kind of thing would be out of scope for Chocolate Doom, as while yes you could make a version of DOSBox that only runs Doom to emulate it, this effectively blows the scope of the project to PC emulator.  And I do mean PC emulator since there's nothing stopping you from making calls to Windows 9x, or booting Linux from a Doom save game.

A custom DOSBox build that solely runs Doom would be interesting and out of itself by integrating the various DOSBox options that forks have, like specialized filters and such.

27 minutes ago, Blzut3 said:

With all that said, if you all are going to actually use this to create things, I would strongly encourage people to refrain from calling the result a "vanilla mod" or something with that implication.  I say this as the developer of ECWolf and having to put up with articulating what is compatible with ECWolf in a landscape where creating custom source ports is very common and the results are called "DOS mods" and "Wolf4SDL mods" leaving no distinction for things actually compatible with unmodified code.  Now I don't expect this to get super popular in this community since we don't have a culture of creating custom source ports for mods (although there have been a handful), but if it does at least I can say I warned you all to avoid making things confusing for new players.

I have no idea yet how to properly define it as-is beyond being an ACE and able to run custom code.

 

Calling it a Exe hack in the DoomWiki defined sense would mean it would actively tamper with Doom's internal works. Doom-ACE does not really do that to begin with: It exploits a flaw, but it does not actively change anything within Doom's internals.
 

1 minute ago, M_W said:

Expecting Chocolate Doom to run this exploit is the equivalent of expecting a port of Splinter Cell to support Xbox soft mod exploits.

Which is funny since Splinter Cell Xbox has a hex-edit mod that allows it to run at 720p on said Xbox. Probably needs a memory upgrade, but it works.

[M_W]

Yeah, I don't mean to come off as negative, but the griping about this not being implemented in chocolate doom is, I think, a really stupid distraction from the discussion of a very cool project.

[Blzut3]

3 minutes ago, Redneckerz said:

Calling it a Exe hack in the DoomWiki defined sense would mean it would actively tamper with Doom's internal works. Doom-ACE does not really do that to begin with: It exploits a flaw, but it does not actively change anything within Doom's internals.

I do think, if not "Exe hack," something involving the word "hack" would be suitable.  While you are correct that an ACE doesn't have to change anything with the Doom internals, I don't know how realistic it would be to do anything interesting without live patching some piece of existing code (kgsws would the one to comment here).  One of those things where while there's technically a chance the term is wrong, so is the way we use the term "source port" but it makes sense to everyone.

[rustygizzard]

you've gotta be shitting me. mouselook and an overlaid status bar? this is crazy. i don't even give a shit if this runs on any ports, fuck it, just show me what else can be done on vanilla doom. 

[Graf Zahl]

30 minutes ago, Redneckerz said:

Calling it a Exe hack in the DoomWiki defined sense would mean it would actively tamper with Doom's internal works. Doom-ACE does not really do that to begin with: It exploits a flaw, but it does not actively change anything within Doom's internals.
 

 

If it didn't "change any of Doom's internals" it would not work. The entire purpose is to do that! And in this regard it is completely irrelevant whether you apply it statically to the .EXE file or through an exploit at run time.

Seriously, the only new thing here is the delivery method. Patching an executable to do thiings it was never made for is an ancient concept - remember Entryway's limit epanding modified EXE?

[Redneckerz]

28 minutes ago, Graf Zahl said:

 

If it didn't "change any of Doom's internals" it would not work. The entire purpose is to do that! And in this regard it is completely irrelevant whether you apply it statically to the .EXE file or through an exploit at run time.

Well, yes. That's why i lean mostly to calling it a exe hack in the first place - But given this is the first of its kind, some reiteration is in order.

28 minutes ago, Graf Zahl said:

Seriously, the only new thing here is the delivery method. Patching an executable to do thiings it was never made for is an ancient concept - remember Entryway's limit epanding modified EXE?

Given i chronicled the entire history of that thing, yeah i remember.
 

50 minutes ago, Blzut3 said:

I do think, if not "Exe hack," something involving the word "hack" would be suitable.  While you are correct that an ACE doesn't have to change anything with the Doom internals, I don't know how realistic it would be to do anything interesting without live patching some piece of existing code (kgsws would the one to comment here).  One of those things where while there's technically a chance the term is wrong, so is the way we use the term "source port" but it makes sense to everyone.

Basically what i am thinking of is describing both methods as an exe hack - Going forward with the delivery method that Graf mentioned.

 

Though the changeability of this hack is much more far fetching, ofcourse.