Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
kgsws

DOS Doom Code Execution

Recommended Posts

Do not even think about implementing this in source ports. Really. There are only to ways to handle this. Emulator or LE loader. Not source port.

(screenshots are from my LE loader, i am running DOOM2.EXE directly in Linux)

 

1 hour ago, Blzut3 said:

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.

Probably only enhanced dehacked - modifying states, with ability to add actions to any state. But that would still be by running x86 code. So it would not be compatible anyway.

 

Anyway.

I would not call it EXE hack though. Maybe "code hack". Or whatever, even "ace hack" would do.

 

You can't distribute modified EXE file so you have to pack patcher and patch file with your WAD file. My intention was to sidestep this issue. It is not exactly as i imagined but all you have to do is run the game with more parameters (-loadgame) and boom.

 

By the way my example might be delayed a bit. I was implementing more features when i stumbled upon possible code execution using WAD file only. I am gonna investigate this tomorrow.

It would still require additional command line parameter (-warp 33) since it is a map exploit. And i can't tell if this could lead somewhere, yet.

(For anyone interested, this time exploit is in negative thing types in the map.)

Share this post


Link to post

If I could do something with this method, I would rehabilitate the special of the sliding doors, which is also already in the code (or I guess it is in the code). I have to start practicing C (I am really very bad at C right now :v)

Edited by URROVA

Share this post


Link to post

I'm also kinda curious how this ACE exploit would work on network games, I d o remember that loading networked saves are a thing.

7vjq8Sv.png

 

1 hour ago, kgsws said:

By the way my example might be delayed a bit. I was implementing more features when i stumbled upon possible code execution using WAD file only. I am gonna investigate this tomorrow.

It would still require additional command line parameter (-warp 33) since it is a map exploit. And i can't tell if this could lead somewhere, yet.

(For anyone interested, this time exploit is in negative thing types in the map.)

 

The progress just somehow keeps getting better. :D

Share this post


Link to post

Just continue using DOSBox to play this hacked flavour of Doom. It's currently a fully stable emulator. You underestimate its robustness. Instead of trying to adopt this hack into Doom source ports, the larger community's better effort would be spent on keeping DOSBox alive on as many platforms as possible.

Share this post


Link to post

Well, what have I done by mentioning Chocolate Doom...

 

It is true that arbitrary code execution is very far from being a new concept, and also that you can execute any arbitrary code outside of Doom, instead of using a saved game and/or WAD file crafted for a specific task.

 

It's still interesting to see an exploit being used for making a Vanilla Doom gameplay mod after more than 25 years, just by using a saved game.

 

For games which don't or didn't have available source codes (including reverse-engineered sources), modifying the exe is an obvious answer for modding; Not necessarily by distributing such an exe, which can be problematic, but by distributing a patch file that can be used; Either for creating a separate modified exe, or for dynamically modifying a copy of it in memory.

 

I know that the latter approach is being used for Commander Keen mods. Of course, it's practically impossible to properly support all possible patches in a re-implementation (like Commander Genius) or a source port, not without more-or-less running the original exe in an emulator. A small, finite subset of patches can still be supported, of course, but there will obviously be more.

Edited by NY00123

Share this post


Link to post
1 hour ago, NY00123 said:

I know that the latter approach is being used for Commander Keen mods. Of course, it's practically impossible to properly support all possible patches in a re-implementation (like Commander Genius) or a source port, not without more-or-less running the original exe in an emulator. A small, finite subset of patches can still be supported, of course, but there will obviously be more.

 

Binary patches of executables always come with a risk, though, and that's not limited to exploits. Just have a look at Quake 2. Thanks to its DLL interface, any port switching to a different architecture other than 32 bit Windows is left in the cold with many of those old user mods which shipped their own game DLL but didn't bother including the source.

 

Share this post


Link to post
On 10/6/2020 at 2:56 AM, Baratus II said:

I'm also kinda curious how this ACE exploit would work on network games, I d o remember that loading networked saves are a thing.

It might be possible but not in the way it is coded right now. (it forces you out of the map)

 

 

Quick update. I finished my investigation and this is the result. https://github.com/kgsws/doom_ace/tree/doom2_ace/wad It's a map exploit!

You can run it as any other mod, "-file snake.wad", or you can autostart with "-file snake.wad -warp 1". No savegame needed. By the way try "new game" once you have played SNAKE!.

Since i am quite tired there is no technical description yet, sleep required. I will make one later.

 

However, this brings a problem. Which way is better for custom mods? Exploit in map does not need savegame file anymore, but it replaces one map slot.

For source ports at least, since my loader just invalidates this map once exploit is triggered. Only valid map slots can be used (MAP01 to MAP32), it can be any slot, not just MAP01.

MAP01 can work like autoload but only for "new game" selection. And it would disable source ports. And there are other issues with saved games.

 

What do you think, savegame exploit or map exploit? I could support both ways, but that might be confusing for modders.

Share this post


Link to post
46 minutes ago, kgsws said:

What do you think, savegame exploit or map exploit? I could support both ways, but that might be confusing for modders.

 

I like more the savegame, is like the -deh argument on chocolate doom.

 

This method already is confusing for the most of modders

Spoiler

(me for example, i dont know nor how to compile this thing xD)

, but is very good give vanilla new features :)

Edited by URROVA

Share this post


Link to post
4 hours ago, kgsws said:

What do you think, savegame exploit or map exploit? I could support both ways, but that might be confusing for modders.

I would say the proper answer is both.  If you're going to make a framework for this you should patch the save code to create saves with bootstrap code in them.  I would think this shouldn't be terribly difficult as I would think one could make the bootstrap save a constant and then the patch save loader could seek past the exploit, but you know more than me here.  Then the player doesn't need to concern themselves about the technical details at all.

Share this post


Link to post

The above are very good points!

Also, I think UMAPINFO would be a good way of implementing some sort of MAPINFO in DOS. It was made to be simple to implement(iirc), and is supported in more than just GZDoom, even if it hasn't caught on entirely yet.

Share this post


Link to post
57 minutes ago, insertwackynamehere said:

This means in theory, a library built using this could backport ZDoom features into vanilla. Arguing that the method of doing so should be emulated misses the point.

 

Several posts ago I pointed out that if all mappers/modders/developers agree to use only a limited subset of what is possible -e.g. targeting only specific built-in Doom functions, specific memory regions etc. and even going as far as using standard macros for those, in practice that would reduce the ACE to be almost a standard API/ABI or even scripting language that could be "translated" even in non-native execution contexts -e.g. if you know that accessing some memory region $BASE_ADDRESS + 0x1234 and writing an integer there means affecting the player's health -this could even be understood by looking at compiled code, even from different compilers, as long as the same macros were used.

 

An even more extreme version of this would be to have a scripting engine or specific set of API functions loaded in one of the ACE lumps, and all other "ACE" lumps not being so "ACE" after all, but rather, using the scripting engine or API. Then source ports could implement the scripting engine/API independently, and ignore the actual DOS implementation, while still being able to understand what the other not-so-ACE lumps are meant to do. This would effectively create a unified cross-source port scripting platform.

 

57 minutes ago, insertwackynamehere said:

The exploit simply leading to a standardized patch that supports removing limits, looking up and down, new lumps, etc.


I am not sure how much "limit removing" is actually possible with this exploit -e.g. increasing the number of visplanes is not simply a matter of hacking a single value into memory, but it also requires increasing static storage allocated at the very program's start -the linking/loading phase. Also something very hard to do a-posteriori when everything is loaded, unless you provide different visplane drawing functions that do their own memory allocation etc.

 

OTOH the drawn sprites limit, IIRC is indeed just a single integer value in an "if" or "for" statement somewhere. It really depends on the kind of limit.

Edited by Maes

Share this post


Link to post
14 hours ago, Blzut3 said:

I would say the proper answer is both.  If you're going to make a framework for this you should patch the save code to create saves with bootstrap code in them.  I would think this shouldn't be terribly difficult as I would think one could make the bootstrap save a constant and then the patch save loader could seek past the exploit, but you know more than me here.  Then the player doesn't need to concern themselves about the technical details at all.

Yes, this is one way i was thinking of. Mod loading would be transparent to the user. But i would rather change save/load so different mods would have custom file names and would not collide with each other. And prepare for the future where it might even work like it does in Hexen or Strife.

So, i kinda throw this idea out of the window ... (but maybe if it's requested a lot)

 

7 hours ago, insertwackynamehere said:

All the discussion of source ports supporting this seems misguided for the reasons listed. A cooler thing to imagine is, this ACE stuff leading to a standardized framework which loads MAPINFO, DECORATE, ACS, etc. Basically, the arbitrary code execution part is to get these things to work in vanilla; it is not something to emulate in its own right. The established mapping extensions that already exist could be loaded and processed using this exploit. This means in theory, a library built using this could backport ZDoom features into vanilla. Arguing that the method of doing so should be emulated misses the point.

I think this is the direction it will all go.

But probably instead of adding text parsing into the DOS Doom i would rather have all generated and compiled into single binary.

So, something like MAPINFO / DECORATE / ANIMDEFS to C converter. And then compile all using makefile.

 

7 hours ago, Alper002 said:

The above are very good points!

Also, I think UMAPINFO would be a good way of implementing some sort of MAPINFO in DOS. It was made to be simple to implement(iirc), and is supported in more than just GZDoom, even if it hasn't caught on entirely yet.

Seems simple enough. Though i would support any map name, not just MAPxx.

 

6 hours ago, Maes said:

I am not sure how much "limit removing" is actually possible with this exploit -e.g. increasing the number of visplanes is not simply a matter of hacking a single value into memory, but it also requires increasing static storage allocated at the very program's start -the linking/loading phase. Also something very hard to do a-posteriori when everything is loaded, unless you provide different visplane drawing functions that do their own memory allocation etc.

It's almost the same. You have to modify some instructions when modifying EXE anyway. Doing this already in the game is about just also modifying instructions that reference specific static area so it would use newly allocated one.

 

19 hours ago, URROVA said:

I like more the savegame, is like the -deh argument on chocolate doom.

But you can do that with MAP exploit too. "-file snake.wad -warp 1"

 

 

I am gonna continue with my example mod, but this loading "issue" has to be resolved. Any map slot that would be used for the exploit is unusable on source ports.

However, savegame exploit requires you to include another file with your mod. Which could be a mess if you have more custom mods with incompatible ACE loaders.

 

There is another method where savegame exploit itself would load additional WAD(s). This would let you skip the "game is modified" message.

However, savegame can be referenced only by a single character ("-loadgame H" for "doomsavH.dsg") so first 7 letters are always "doomsav".

 

I like MAP exploit since everything is contained and clearly named. It supports "autoboot" too. It just eats up one map slot for source ports. But that might not be an issue with UMAPINFO.

Share this post


Link to post

Having a self contained ACE inside a WAD is very appealing especially if it can be finagled to "just work" under source ports as well. Putting it inside a DSG however makes it more "obvious" that it is a special DOS-payload. Both are worthwhile avenues to explore.

 

On 10/4/2020 at 10:49 AM, kgsws said:

I was looking for early execution exploits in WAD but no luck so far. Of course there is R_RenderBSPNode, but that would just mess up everything. If usable at all.

 

?? Potential ACE inside the BSP tree? What is the theory behind this?

Share this post


Link to post
41 minutes ago, kgsws said:

But probably instead of adding text parsing into the DOS Doom i would rather have all generated and compiled into single binary.

So, something like MAPINFO / DECORATE / ANIMDEFS to C converter. And then compile all using makefile.

I absolutely would rather prefer actual text parsing be added into DOS Doom; I don't think Hexen had serious performance issues with its DOS-based ACS VM. Compiling MAPINFO also wouldn't make any sense. And I think DECORATE can be done if a JIT-based approach can be used for compiling it into native code.

Share this post


Link to post
2 hours ago, kgsws said:

Any map slot that would be used for the exploit is unusable on source ports.

Couldn't we use a map slot like map33 that is hardly ever occupied?  I created a little test wad a second ago and -warp 33 worked for me in Dosbox'd doom2.exe, GZDoom and Crispy.

Share this post


Link to post

Ideally something like MAP00 or MAP99 would be used, if attempting to load it in vanilla is possible and does not crash before activating the payload.

Share this post


Link to post
2 hours ago, Cacodemon345 said:

I absolutely would rather prefer actual text parsing be added into DOS Doom; I don't think Hexen had serious performance issues with its DOS-based ACS VM. Compiling MAPINFO also wouldn't make any sense. And I think DECORATE can be done if a JIT-based approach can be used for compiling it into native code.

If you restrict DECORATE to just the subset that vanilla can support without modification, there's zero overhead once processed.  The core of DECORATE just generates static tables that Doom already has.

 

Now if you want to support more than basically unrestricted DeHackEd then yeah one needs an expression evaluator and stuff like that.  Overall though I think the concerns of performance on doing text parsing are being overstated.  I'm not entirely sure why kgsws would prefer to go the compiled route besides it being neater and it could be done.  (Or possibly because a tool to convert DECORATE code to C kind of already exists.)  From my point of view text processing would be more widely used since then one can just grab pre-made binaries and slap them in the WAD.

3 hours ago, kgsws said:

Any map slot that would be used for the exploit is unusable on source ports.

The way I see it is if the exploit is being done to do anything important then either the code has to be executed, or the port is advanced enough that it can be instructed to skip the map.  It might bother some people that the game starts on MAP02 instead of MAP01 but so what?

3 hours ago, kgsws said:

But i would rather change save/load so different mods would have custom file names and would not collide with each other.

While I see why you would think to go down this road, I do wonder if it would be of any practical use.  How often do people play enough mods simultaneously that they run out of save slots in such a way that they couldn't just back up and restore the files as needed?  Users don't read anything, so I would personally say being transparent to the user is more important, but that's just me.

Share this post


Link to post
7 hours ago, Blzut3 said:

 Users don't read anything, so I would personally say being transparent to the user is more important, but that's just me. 

I don't think that this kind of user will ever use DosBox and Doom.exe to begin with - they'd probably settle on something easier to handle...

 

Share this post


Link to post
3 hours ago, Graf Zahl said:

 they'd probably settle on something easier to handle...

I'm not sure in this case, but playing on DOSBox can be as easy as pressing a single button as long as you provide an interface for them.

Edited by Noiser

Share this post


Link to post

No. My guess is that most regular people who want to play Doom on a modern system will Google for "Play Doom on Windows/Mac/Linux" and be guided to some tutorial to set up a source port - or use the Unity version right away if they do not own the game yet.

 

DosBox is arcane for those who grew up on modern computers and have no interest in technical solutions. They may unknowingly use it if they get a predefined setup, but they most likely won't be able to create one themselves.

 

But even if you gave one to them, the first question you are likely to get is "How can I set this to a higher resolution?" and they either stop right there or look for a better solution (read: Look for a source port that best matches their interest.) since the answer is "You can't".

 

Share this post


Link to post

Still, it's as easy as it gets. What they will choose after that is not my business.

Edited by Noiser

Share this post


Link to post

So... this was an interesting thread.

Personally, I have no interest in the old DOS executable. As much as I feel a certain nostalgia for the old days at times, I really prefer convenience plus trying to play something fast in low resolution these days makes my eyes hate me before too long. However, this is definitely interesting and certainly extremely creative. Go hard, and ignore any naysayers. If you are getting something out of doing this, that is all that matters.

Share this post


Link to post

Still battling over semantics and the likes I see.

 

Look, if someone makes a mod worth playing, I guess it's on the mod-maker to also provide ample instructions on how to play the mod, no? You don't let map authors release a wad for, idk, EDGE, and go on to never tell you how to play the mod in the first place, right?

 

If the wad/mod is worth playing, people can and will go the extra mile to set up the environment to play it, provided there's clear / easy enouh instructions to follow.

 

I have had this ACE exploit in the back of my mind the last couple of days, I don't have the know-how nor free time right now but I'd be very interested in a wad which, for the most part, behaves like a normal doom experience, but through ACE exploits begins to act like it's a sentient computer, gradually corrupting the game step by step and essentially breaking the 4th wall. Think lilith but with less reason for some people to get angry about it and a more 'game-like' approach.

 

Other ideas I've had that are less... "Doomy", shall we say? By comparison they are wholly experiments / "a waste of time" in the eyes of many.

  • a file manager in doom where your actions serve to manage the files, be it renaming, moving, deleting, etc.
  • the oft-discussed idea of backporting features from boom, zdoom, whatever, but intended to make 'compatability patches' for modern releases, stretching the meaning of "vanilla compatible".
  • A rogue-like doom experience, where the ACE generates or manipulates maps and monsters on the fly to create a different experience on each playthrough. I realise this idea is the most irrelevant of the ones I've pitched simply due to being quite possible in GZDoom et al already.

Share this post


Link to post

no one is looking to replace source ports with DOS, it's just cool to see what can be done that we never knew could be done prior. i mean the possibilities range from playing snake in the menu to adding gameplay enhancements (i.e. minimized hud, looking up and down), which in vanilla doom, is pretty damn cool. as for the accessibility of it, it took me about 5 minutes to install dos and jump into the loadgame. it's not the ideal way to play doom, but it's not as hard as everyone is making it out to be unless you're using the preconfigured version that comes with the steam release. in my opinion we should just have fun with what's being discovered instead of writing it off with the source port argument.

Share this post


Link to post
1 hour ago, Dragonfly said:

I have had this ACE exploit in the back of my mind the last couple of days, I don't have the know-how nor free time right now but I'd be very interested in a wad which, for the most part, behaves like a normal doom experience, but through ACE exploits begins to act like it's a sentient computer, gradually corrupting the game step by step and essentially breaking the 4th wall. Think lilith but with less reason for some people to get angry about it and a more 'game-like' approach.


I think someone could start a simillar trend to the "every copy of SM64 is personalized" thing. Something like "every copy of Doom shareware is personalized", "This save file came from an alternate reality", "Savestates from Hell". But I dunno. Maybe the magic is already lost as the trick is known, but at least it's not just an edited video, PWAD nor custom source port.

Share this post


Link to post
2 hours ago, Dragonfly said:

If the wad/mod is worth playing, people can and will go the extra mile to set up the environment to play it, provided there's clear / easy enouh instructions to follow.

 

I doubt it. The last time this happened for me was Caverns of Darkness. I thankfully declined when faced to play this with the semi-broken DOS EXE it came with. Fortunately I was able to come up with an alternative solution.

Now what would a techically less knowledgeable user do if faced with a setup they do not like? Not even the best mod in the world would help if the obstacles are too high - and that's totally a subjective assessment.

 

Share this post


Link to post

One thing I've thought about that I can't spot being mentioned on prior pages at least: Would such abuse be usable to add some sort of ACE header to an otherwise normal vanilla save such that you can circumvent the save game buffer overflow? It'd be an incredibly involved setup for pretty minimal gain but it could be a neat workaround.

Either way my imagination is rather lacking here, compared to the incredibly impressive work already done. Great job on this, kgsws! How hard is it to write an individual ACE savegame, anyway?

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×