DOS Doom Code Execution

[rustygizzard]

9 hours ago, TheOnlyTrueFenix said:

I'm playing this on dosbox and it looks like i'm the only one with this problem.

what the hell? are you sure you're running the original doom2.exe without any addons or mods besides the ACE exploit? it looks like your textures are extremely filtered so that's something that might mess it up.

[JadingTsunami]

12 minutes ago, rustygizzard said:

what the hell? are you sure you're running the original doom2.exe without any addons or mods besides the ACE exploit? it looks like your textures are extremely filtered so that's something that might mess it up.

 

I saw the same thing on my machine with a stock, unmodified Doom 2 v1.9. MD5sums all match the values in the wiki.

 

DOSBOX also shows errors related to illegal memory access, which I imagine is part of it.

 

I found out it only happens if you have a screen size with a border (that is, smaller than fullscreen-1).

[Wagi]

Judging how the muzzle flash is correct, I'm going to assume that the light tables used for column drawing got jacked up somewhere. Probably related to the colored lighting effects.

[Redneckerz]

@termrork and @Baratus II thank you for your helpful videos! Looks amazing on real hardware.

I tried testing this in DosBox, but using the same Doom2 exe i used to playtest VULD, it just hangs, doing everything correctly. I reckon its part of what Jading is saying.

 

Nevertheless, fantastic demonstrator of subtle and not-so-subtle effects. Ofcourse, the big winners for me are Mouselook and the custom toggable colored lighting steps with fog. There is a lot you can do there, color puzzles for instance, but also pulsating lights that change in intervals (or can blend in an animation).

 

And the brilliance of it all is that it totally fits the Vanilla limitations in 320x200. It enhances visuals without looking out-of-place or completely impossible.

 

Whether its a pseudo-port calling a Vanilla executable or a Vanilla executable running illegal code, it does not matter. The result is equally the same and one hell of an argument to consider Vanilla or even DOSBox again with all its limits, if this is what is needed to achieve these kinds of features.

[URROVA]

For me the big winners are the linedefs with arguments, the things with specials, Z Axis and translations, the colored lighting is very cool! And i saw some fuzzy wall here right?

Edited October 14, 2020 by URROVA

[kgsws]

23 hours ago, URROVA said:

Ehhh... WTF vanilla running an HEXEN FORMAT MAP, with thing specials and all xD

Coming soon: ACS on vanilla.

That could be done. We will see.

 

50 minutes ago, URROVA said:

For me the big winners are the linedefs with arguments, the things with specials, Z Axis and translations, the colored lighting is very cool! And i saw some fuzzy wall here right?

Keep in mind this is just a proof of concept, i have coded only a limited set of line specials. Someone would have to implement all ZDoom line specials. That is not hard but very time consuming.

 

 

Everyone having issues with texture colors: I might have fixed that, please download demo.wad again. I did not have this issue but i am quite sure i know why it happens. Let me know it that helps. It should also fix mouselook when changing screen size.

https://github.com/kgsws/doom_ace/tree/doom2_ace/wad

 

I am investigating new potential exploit. I need help from someone with real hardware. Both windows and DOS.

Please run "doomsav4.dsg" from here https://github.com/kgsws/doom_ace/tree/doom2/savegame.

It will just cause error, but i need to know those 3 values it will print. Thanks.

[THEBaratusII]

1 hour ago, kgsws said:

I am investigating new potential exploit. I need help from someone with real hardware. Both windows and DOS.

Please run "doomsav4.dsg" from here https://github.com/kgsws/doom_ace/tree/doom2/savegame.

It will just cause error, but i need to know those 3 values it will print. Thanks.

 

I currently tested your doomsav4.dsg on my Pentium II 300MHz PC.

 

Windows 95

CODE: 0x82DAE000

DATA: 0x82DF3000

ZONE: 0x82E79024

 

MS-DOS Mode (MS-DOS 7.0)

CODE : 0x00159000

DATA : 0x001A0000

ZONE : 0x0022F024

[xvertigox]

This is cool as fuck and it's so sweet seeing people test it on actual hardware. I love seeing the updates in this thread.

[kgsws]

On 10/14/2020 at 11:57 PM, Baratus II said:

MS-DOS Mode (MS-DOS 7.0)

CODE : 0x00159000

DATA : 0x001A0000

ZONE : 0x0022F024

Very nice. That will work.

On 10/14/2020 at 11:57 PM, Baratus II said:

Windows 95

CODE: 0x82DAE000

DATA: 0x82DF3000

ZONE: 0x82E79024

That's unfortunate. Won't work.

 

Thanks for testing.

 

So, i have beatifull WAD exploit that will only work in DOS / DosBox / FreeDOS. Not windows.

I have managed to test win XP, won't work either.

Basically, difference between ZONE and CODE must be exactly 0xD6024 for it to work.

(Or to be extra correct, it can work with your win95 values, but then it won't work in DOS.)

 

This exploit won't need any extra parameters at all. Just "doom2 -file mod.wad" and thats it.

Anyone interested or should i stick with MAP / savegame exploit?

Edited October 15, 2020 by kgsws

[URROVA]

3 minutes ago, kgsws said:

Anyone interested or should i stick with MAP / savegame exploit?

I should say go for map exploit. 

[kgsws]

Actually, just a quick idea. I might get it to work on both win95 and DOS. But certainly not winXP. I would however need more confirmations.

Can you try it once again on win95 just to see if those numbers are the same? Or maybe even (if possible at all) run doom twice at the same time. First normal game and in second game load this savegame.

Anyone can test this on Win98?

 

Would be really cool to make this work.

[THEBaratusII]

17 hours ago, kgsws said:

Actually, just a quick idea. I might get it to work on both win95 and DOS. But certainly not winXP. I would however need more confirmations.

Can you try it once again on win95 just to see if those numbers are the same? Or maybe even (if possible at all) run doom twice at the same time. First normal game and in second game load this savegame.

Anyone can test this on Win98?

 

Would be really cool to make this work.

 

I really don't see the need in running it via Windows XP's NTVDM since it has issues, I still remember having keyboard delay while playing Doom on a Pentium III running XP a long time ago. But I might look into checking it again on Windows 95 just to see. Now as for Windows 98 though, I'll have to grab another IDE hard drive in order to do so as I'm happy with Windows 95 at the moment.

 

And I could perhaps find another drive to put Windows Me (The highly-criticized one) on it for multiple OS testing purposes.

 

UPDATE: I've tested it again, here are the results, but I feel there was a difference and I believe it was caused from resetting the machine but I,ll double check if that's the case.

 

Old :

CODE: 0x82DAE000

DATA: 0x82DF3000

ZONE: 0x82E79024

 

New #1 - Load from savegame
CODE : 0x833BD000
DATA : 0x83402000
ZONE : 0x83488024
 

New #2 - Start normal then load savegame
CODE : 0x833BD000
DATA : 0x83402000
ZONE : 0x83488024

 

UPDATE 2 : I've rebooted the machine again and I was probably right on the cause of the difference.

CODE : 0x829E0000
DATA : 0x82A25000
ZONE : 0x82AAB024

Edited October 16, 2020 by Baratus II

[kgsws]

6 hours ago, Baratus II said:

UPDATE: I've tested it again, here are the results, but I feel there was a difference and I believe it was caused from resetting the machine but I,ll double check if that's the case.

This is great. While values are not the same, what i need is that ZONE - CODE difference is the same. Which it is. Nice.

 

So i have quick testing WAD for this kind of exploit. While it is not a snake, it will tell you it's working (it will also exit the game). However, notice when it happens.

https://github.com/kgsws/doom_ace/tree/doom2_ace/wad Download nice.wad.

By the way, do not even try to edit the WAD. It's "not valid".

 

@Randy87 Is this it? While it's not as universal (won't work in WinXP) as my previous MAP exploit, it is likely as soon as any WAD code execution can happen.

[URROVA]

I tried nice.wad on dosbox, is nice that doesnt need the -warp 32 cmd argument to work :)

But i noticed that the startup became a bit slow... How it works? It needs making slow the startup to work?

Edited October 17, 2020 by URROVA

[Randy87]

2 hours ago, kgsws said:

@Randy87 Is this it? While it's not as universal (won't work in WinXP) as my previous MAP exploit, it is likely as soon as any WAD code execution can happen.

 

Of course, ace from a wad file. I suppose in my mind I was thinking of something that would be innocuous and could contain malicious/joke code. I'm not sure why that was my thinking, but this obviously covers that.
The only other consideration that comes to mind is code that can run as early as possible or avoids using a map slot.

 

There has been some discussion in this thread about the usefulness of this for Doom modding.
I haven't really read any of it (just skimmed), though I can guess what all was said.
Certainly some standard community derailing of any vanilla hacking fun.
Just thought I'd throw my 2 cents in, even if it's already been previously stated.

 

This is really cool and I'm quite pleased that you took the time to work on this project.
Feels like checking something important off a list.
However, I'm not sure why anyone would want ace for modding.
The idea was (in my mind) to surreptitiously run code with the player being none the wiser and then be surprised by the results. It's just a wad file right? Nope.
But that's it.
While you can do it with ace and it has been done, why? Outside of proving it can be done, which it has.
It would make more sense to extend the original engine using a patched exe or a loader.
Not to mention that we already have a compilable DMX supported DOS source port these days.
It might even have dehacked support.
So, once again, really cool stuff, but an odd roundabout way to mod Doom.

[Redneckerz]

DOOM_Ace was covered in this month's issue of the Wadazine. :)

[THEBaratusII]

1 hour ago, Redneckerz said:

DOOM_Ace was covered in this month's issue of the Wadazine. :)

Nice! I just downloaded the PDF to take a look.

 

17 hours ago, kgsws said:

So i have quick testing WAD for this kind of exploit. While it is not a snake, it will tell you it's working (it will also exit the game). However, notice when it happens.

https://github.com/kgsws/doom_ace/tree/doom2_ace/wad Download nice.wad.

By the way, do not even try to edit the WAD. It's "not valid".

I might test this on both emulated and real hardware, and also curious on how the WAD became non-editable though.

Edited October 17, 2020 by Baratus II

[kgsws]

18 hours ago, URROVA said:

I tried nice.wad on dosbox, is nice that doesnt need the -warp 32 cmd argument to work :)

But i noticed that the startup became a bit slow... How it works? It needs making slow the startup to work?

It is trying to read almost 4GiB from the WAD file (yes, giga). This of course is not possible, especially when read offset is set behind the ending of the file.

While request to read 4GiB from file can end up just reading 0 bytes in total, some underlying driver (my guess is dos4gw) is trying to split those 4GiB into smaller, probably 64kiB chunks. And this would take a while, even if it is not reading anything.

Anyway, that is just my guess though.

 

3 hours ago, Baratus II said:

I might test this on both emulated and real hardware, and also curious on how the WAD became non-editable though.

One entry in WAD file has negative size. ... Or very large positive size. Depending on how you look at it. (signed / unsigned)

I am very curious how is gonna Win95 filesystem driver deal with it. It should probably work. It works in FreeDos too.

 

 

Actual bug is in Z_Malloc, it is possible to request negative size. This allocation will be successful. Next allocation, however, will give you pointer to memory offset by previous negative allocation.

My WAD file contains two entries. TEXTURE1, which has negative size. This prepares next allocation pointer. Negative size is chosen so it will point into the code. And specifically code that is executed after reading from WAD file (I_EndRead).

Then TEXTURE2 is normal entry (64k in size) but when it is read it will inevitably overwrite large portion of original game. As i mentioned, function I_EndRead is called every time something was just read from the WAD (it removes disk icon in right corner). Just this time it was overwritten by my code.

By the way, if you look closely, 64k of code is mostly filled with NOPs (0x90). This is chosen so small variations in relative position of CODE and ZONE segments are covered. In other words, this large area of "do nothing" is there to support DOS and Win95 with single WAD file.

Spoiler

 

R_Init: Init DOOM refresh daemon -

Z_Malloc(3756, 1, 0x570357DC)
read from file 3:0x3081F8 size 3756 to 0x0024E05C; EIP 0x001B8985
Z_Malloc(-767348, 1, 0x57037FE0)
read from file 4:0x1000000 size 4294199948 to 0x0024E05C; EIP 0x001B8985
Z_Malloc(65536, 1, 0x57037FDC)
read from file 4:0x002C size 65536 to 0x00192B00; EIP 0x001B8985

 

Notice how 0x00192B00 address is very close to EIP 0x001B8985. This read will overwrite the code.

 

 

 

5 hours ago, Redneckerz said:

DOOM_Ace was covered in this month's issue of the Wadazine. :)

Interesting. I am still not entirely convinced if there is enough audience for this.

 

18 hours ago, Randy87 said:

Not to mention that we already have a compilable DMX supported DOS source port these days.

It might even have dehacked support.
So, once again, really cool stuff, but an odd roundabout way to mod Doom.

Yep, that is what i was basically asking for.

I am able to create non-source port with many features that would be bundled in WAD file with mods and run trough original game. But would it have more success than existing DOS source ports? I guess you can call it "vanilla compatible", but that is a long stretch.

 

 

I am gonna have to think about it. I have quite a few other (far, far away from Doom) projects. And now i am not sure where my priorities are.

Edited October 17, 2020 by kgsws

[Linguica]

A proof of concept WAD, with supporting documentation / code, is perfectly fine as a milestone to hit. It's possible that there could be a use for this sort of thing (something for checking demo compatibility? Coding a TASbot demo for GDQ?) but no one has thought of it yet.

[Telemassacre]

Add some zeroes.

 

Edited October 17, 2020 by Telemassacre

[Redneckerz]

On 10/17/2020 at 8:49 PM, kgsws said:

Interesting. I am still not entirely convinced if there is enough audience for this.

What else do you really need to be convinced? This thread and the responses it garners should give you a clear picture.

 

On 10/17/2020 at 9:59 PM, Telemassacre said:

Add some zeroes.

You know, you can always visit /dev/null to find a cabinet of programming jokes there.

[Obsidian Plague]

On 10/25/2020 at 7:02 AM, Redneckerz said:

You know, you can always visit /dev/null to find a cabinet of programming jokes there.

just a heads up that wasn't what he originally posted, he edited it to that to cover up what he said

[Redneckerz]

44 minutes ago, Obsidian Plague said:

just a heads up that wasn't what he originally posted, he edited it to that to cover up what he said

I fear that the original comment was even worse.

[URROVA]

On 10/27/2020 at 7:58 AM, Redneckerz said:

I fear that the original comment was even worse.

[redacted]

Edited September 15, 2021 by URROVA

[kgsws]

Ok. I did some testing, i got a break from doom, then i did more testing ... And i have decided to go with MAP exploit.

While WAD exploit would start very early and did not need any arguments, it has not-so-great drawbacks.

 

I made some required progress with new initialization code (loading textures, sprites ...). Original doom code had too many limitations for modding.

(and as a bonus you can make your own fancy loading screen)

 

You can get small demo here, download "engine.wad". Start with command "doom2 -file engine.wad -warp 1".

https://github.com/kgsws/doom_ace/tree/doom2_ace/wad

This is only a basic demo. It does not even run my previous demo map, yet. You can at least check and comment on new loading screen and how hard/easy it can be modified.

 

Also, i started to call this "ACE ENGINE".

If this ever gets finished there is something that other source ports would have to do in order to co-exist with ace engine:

Ignore every single lump between ACE_CODE and ACE_END lumps. Some of these are part of exploit, some are hacks to start the game faster. These, however, use legit Doom lump names and that will only confuse source ports.

(my code replaces first character of every lump name with 0xCC)

But it might be too early to think about this right now. Let's see how far i can make it.

 

[URROVA]

nice loading screen :)

 

This still can read hexen format maps or its only for more free graphic loading?

 

 

Edit: Tried to rename MAP33 to MAP02, and not :(

Edited October 28, 2020 by URROVA

[kgsws]

22 hours ago, URROVA said:

This still can read hexen format maps or its only for more free graphic loading?

Slowly making progress.

 

https://github.com/kgsws/doom_ace/tree/doom2_ace/wad

You can download "demo.wad" again, i just updated it.

There is nothing new though. Actually, mouselook is missing.

It is still full of demo-specific hacks. I will make slow transition to proper implementation. (hopefully with source port compatibility)

 

I still do not know how to handle many features so it could work everywhere, if needed. Like, should i create new specification for COLORMAPs or should i rather go with something already existing, which might need complicated implementation?

 

EDIT: For anyone interested, source code for my demo is always available. https://github.com/kgsws/doom_ace/tree/doom2_ace/ace_code

Edited October 29, 2020 by kgsws

[termrork]

cute loading screen :)!

 

about specifications and conventions I personally would go for the easier implementation

[inkoalawetrust]

I wonder if someone will eventually use this to reimplement the scrapped secret Asteroids minigame that was supposed to be accessible in the automap but was scrapped ? It definitely would be interesting to see. Maybe it could even be made as a demo of what this exploit can do if it wouldn't be too to add in. Though it's probably unnecesary since you've already made a snake game demo, and the demo.wad you've released already arguably has even more impressive features such as freelook, jumping, colored lighting, the ability to change sprite colors, fog etc .

[kgsws]

3 hours ago, inkoalawetrust said:

I wonder if someone will eventually use this to reimplement the scrapped secret Asteroids minigame that was supposed to be accessible in the automap but was scrapped ?

I was actually thinking about this some time ago. It would be fun easter egg.

 

 

Anyway, got a "small" update.

https://github.com/kgsws/doom_ace/tree/doom2_ace/wad

You can download "demo.wad" ... again.

 

Map is not really changed, but engine is.

* Fixed many bugs with new loading.

* Added "missing flat" and "missing texture" graphics. No more error-exit to DOS.

* First original doom bugfix: semi-fixed medusa effect. It works correctly with solid textures. (All without rewriting texture or rendering code. Just binary patches and hooks.)

* Floor textures can be used on walls (but not the other way around). Wall texture like this is generated internally as 64x128. This uses more RAM. Also, floor texture still uses its own RAM. So single texture like that can use 3x original memory. This resolution (64x128) is chosen since original doom renders every single texture 128 pixels high. This also makes it somewhat incompatible with zdoom if flat texture is used as a mid texture.

 

New code takes about 17kiB of memory right now. This is way less than TITLEPIC.

I was testing quite a few hexen format maps i got for zdoom, fun stuff. It crashes in very special ways. Clearly, new maps are way too big for original DOS doom.

Keep in mind that almost all line specials are not implemented. So you can't play those maps anyway.