-
Content count
174 -
Joined
-
Last visited
About kgsws
-
Rank
Junior Member
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
a reminder to everyone please do a virus check and tell everyone if you wad is safe to download
kgsws replied to Paulkdragon's topic in WAD Discussion
In fact, they did not. At least not every bug present in vanilla. Yes. Bugs that lead to code execution in vanilla are still present in some modern source ports. That is true. It would be difficult, or maybe even impossible, to create a single WAD with code execution for multiple source ports. And if you account for different version of each source port, it is even less likely. -
kgsws changed their profile photo
-
OK, for custom implementations it would not. Either way, code execution path is gone. That's one way to do this. I would use one structure with unsigned values and do something like this for old maps when parsing: if(vanilla_format && loadsubsec->firstseg >= numsegs) I_Error("Invalid subsector!") Because, technically, this check should be done anyway at some point. You would have to count segs first, of course. Of course range checking everywhere is better.
-
With fixed Z_Malloc, allocating this much memory would simply fail. My point is that when doom was coded, they clearly did not care about signed vs unsigned values. There are no assumptions about negative vs positive values. Therefore, keeping signed values vs using unsigned values does not really matter if you don't also add other checks. Both cases are broken in some way. (except in a few places where they use negative values to convey special meaning) Anyway, if you want to fix width / height / patch range properly, you should also check for some kind of top limit. You could also check, as you have mentioned, for negative values. I'm gonna mention "negative check" in my original post.
-
Well, places i have mentioned should be safe to change into unsigned. No existing and valid data should contain negative values on places i have mentioned. Plus, some overflow bugs are true even for too high signed values. Well, Z_Malloc combined with signed values with various negative values in texture data leads to code execution when you load the WAD. Even before graphics mode starts. That's what ACE Engine uses. Actually there are overflow bugs like that, yeah. I should add those.
-
Since i have found multiple code execution paths in original Doom source code, and this source code is base for many source ports, here's a list of possible code execution paths. With all modern OS protections, i can't tell if any of these bugs lead to code execution. But it's trivial to fix these anyway. Function FindResponseFile in d_main.c. https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/d_main.c#L722C6-L722C22 This function is supposed to load command line arguments from a file. This function allocates fixed amount of 100 arguments, you can overflow it by providing more in load file. This function is pretty much useless, just remove it. Many modern ports did just that. Function PIT_CheckLine in p_map.c. https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/p_map.c#L242 Spechit overflow. This could overwrite some global variables. Just add numspechit check. if(ld->special && numspechit < MAXSPECIALCROSS) Function PIT_AddLineIntercepts and PIT_AddThingIntercepts in p_maputl.c. https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/p_maputl.c#L606 https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/p_maputl.c#L616 Intercept overflow. This could overwrite some global variables. Some modern source ports emulate this for "all ghosts" bug. Just add intercept_p check. if(intercept_p < intercepts + MAXINTERCEPTS) File r_data.c. Various structures with signed variables which should not get negative. https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/r_data.c#L73 https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/r_data.c#L88 https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/r_data.c#L106 And maybe more ... Using unsigned types is a quick but incomplete fix. If you want to fix width / height / patch range properly, you should also check for some kind of MAX limit. Everywhere you load these structures from lumps. Function M_LoadDefaults in m_misc.c. https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/m_misc.c#L373 This function loads configuration entries from the file. Configuration text has space for 100 characters but format string for parsing "%79s %[^\n]\n" does not have any limit. This can lead to stack overflow. Modern source ports fixed this issue by replacing original format string with this one: "%79s %99[^\n]\n". This will limit configuration text size to 100 bytes. This function also has issue with string vs integer handling. You can provide integer in place of string. Which would likely lead to a crash, since it is only a pointer read access to bad memory address. However, in original game, strings are only used for chat macros. Just keep this in mind if you intend to extend original config file with new entries. Function P_SpawnMapThing in p_mobj.c. https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/p_mobj.c#L732 It is possible to create things with negative doomednums. These will be interpreted as "negative" player starts. Every player start is stored in playerstarts array, which leads to negative indexing of array. With careful selection of negative player start to avoid player-in-game check here, it is possible to overwrite any global variable, that happens to exist at specific negative index, with contents of this map thing. This is, indeed, confirmed to allow code execution in DOS EXE. To fix this, update mapthing_t structure with unsigned short type;. This will also allow using doomednums >= 32768. Alternatively, some source ports simply return from P_SpawnMapThing if mthing->type <= 0. Function Z_Malloc in z_zone.c. https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/z_zone.c#L185 This function accepts negative size. There are ways to sneak in negative value for allocation in specially crafted lumps in WAD file. Negative allocation passes and, as a side effect, next free heap block entry will be positioned before current one. This heap block entry will overwrite previously allocated data. Furthermore, any new allocation will provide pointer to already used memory, allowing you to overwrite even more existing data, including existing heap block entry pointers. This is, indeed, confirmed to allow code execution in DOS EXE. To fix this, change every integer to unsigned integer. Including memblock_t structure. Alternatively, call I_Error when size < 0. (this fix is easier) File p_saveg.c functions P_UnArchivePlayers and P_UnArchiveThinkers. https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/p_saveg.c#L104 https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/p_saveg.c#L302 This allows loading out of bounds states. Are out of bounds states useful? Maybe! In DOS EXE: 1) It is possible to use state index which points to array of player_t structures. This is also loaded from save game file. Therefore, it is possible to create arbitrary state, including code action pointer! 2) It is possible to find state index where state action pointer overlaps with pointer to allocated sectors, which you can control from save game file. Therefore, it is possible to hide executable code in sectors. Basicaly, any location where you read state index could be an entry point. To fix this, do not blindly accept state index from save game file. Always check if it's in allowed range. Now. This is not a full listing of all existing exploitable bugs in Doom code, these are only some i know about and, most importatnly, some are even present in existing source ports. Also remember that these bugs might apply to other idtech 1 games - heretic, hexen, strife ... (here's confirmed code execution in Hexen ACS)
-
Pretty cool video. Very nice look at features of my demo WAD. * Yes, almost every location and scripted event is inspired by other game or other doom mod. (Even green-fog rooms are. Can you guess which Doom mod inspired those?) * Arch-viles can't resurrect gibbed enemies. Yes, they can resurrect each other. But not if you gib them - that is my counter-balance. Plus, you can gib corpses! * Interesting point about ammo balance. I did design ammo placement and respawn to be "just enough". But maybe "just enough" only for me since i know where everything is. (And there's a secret ammo stash at "The Unseen" map.) * Many weapons have alt-fire. Sometimes useful. You can load up to 4 rockets in rocket launcher and fire all at once. Or you can make plasma ball explode for much more splash damage. * Grenades are extremely powerful. * Enemies drop "demon essence" that powers all weapons at slot 8. All these weapons use no ammo and are extremely buffed when you pick up invulnerability. * Force field generator item could be useful. It blocks hitscan and reflects projectiles. * Super-Secret-Puzzle sequence is my idea. And to prevent "solution sharing" it is not randomized at the start of the map, but a bit later. Solution is shared in my youtube video. * MAP30, the last level, has different game play. You can't use rockets to win. * One commander keen is replaced with another ... game reference ... and it gives you a secret weapon.
-
I have not seen this animated yet. This is related to https://doomwiki.org/wiki/Picture_format It also shows how doom does not store transparent pixels at all.
-
It does not. But you can do limited, but still way more powerful than boom conveyor belts, scripting using DECORATE. Check demo wad, it uses that a lot.
-
UnknDoomer's corner of ultra silence - Short WAD Reviews / Longplays / Hints
kgsws replied to UnknDoomer's topic in WAD Discussion
What makes it even more funny or confusing is that i have actually released something with almost the same name ages ago. https://doomwiki.org/wiki/KGZDoom -
No. UDMF as a format is one thing but various features are other thing. It is possible. At one point i had UDMF loader working. But it still only supported features of Hexen map format. So at that point UDMF was ... pointless ... and slower to load. Oh, and collisions were not working as UDMF does not provide BLOCKMAP. But yeah, no UDMF in ACE Engine.
-
That is GZdoom bug. This should work in ACE engine. ACE Engine does not support UDMF. It only supports Hexen and original Doom format. Visplane limit can be raised in WAD config lump. Yeah, that is not supported in ACE Engine. Hexen map format does not allow it. That's a bit tricky as it depends on what you actually want to do. You could start by using config lump from demo i released. It even has render limits risen.
-
I'm not sure what part are you referring to. Yes, software renderer in GZDoom is broken when 3D floors are used. I did not really see anything extreme that is not possible in ACE Engine already. Maybe i was not looking well. Can you post screenshot of the issue?
-
Eventually yes, i guess. It kinda seems to be a low priority thing since how many players are gonna try to "collect" negative frags. Once i can detect negative numbers, it does not really matter if i use minus sign or change colors. So, minus sign is a better choice.
-
Another bugfix release https://github.com/kgsws/doom_ace/releases/tag/v4 Yeah, sorry. I totally forgot about that. Now it works, but it can't show negative frags ... due to other changes i did in the past. Again, fixed. The issue was that if you used text without any space, last letter would get removed. Now i hope that's all. But still, report anything you find out broken. It is. But it is not gonna be as quick as these bugfixes. I might add this in the future though.
-
Ok, netgame bugfix is done: https://github.com/kgsws/doom_ace/releases/tag/v3 Done Done. You have type message as "cheat" and it will be sent as a message. There is no new "chat" key, there is only "cheat" key. If you want cheats in multiplayer (useful for testing), use ! as a first character. Also one extra thing. I have added support for colored player background to intermission. Original background is too dark though. If you are making a custom WAD, i recommend you to change patch STPB0 to something brighter. Just remember, it has to use player base color (green in default). (Now that i think about it, it's not exactly the best solution. It will break if you use more player classes with different base color.)