EXE hacking

[OpenRift]

1 hour ago, xttl said:

 

Sure, but it is also a bit more complex to add than anything that has been already implemented so far, at least if done right (=with direct saving to disk file added, unfortunately game exe doesn't already include normally unused code for that like Heretic & Hexen do). Same reason longtics isn't in yet, it needs more extensive game asm code patching which is annoying to do on the fly (the previous hacks which included it statically patch it into the exe on disk, this hack tries to keep almost all patching in memory except for short "loader" that is patched into normally unused space added for padding code section to 4kB page size). I have been implementing the simplest features first.

So all your raised limits change dynamically? Am I getting this right?

[xttl]

 

Download (includes patched source for Borland C++ 3.1):

see newer post

 

I might finally put a website up again or register into that newfangled github to host this. I wonder should I also make a new thread? Needs testing though, I've only tested a couple of patches and there are still some values in the tables which might not be correct...

 

edit: to clarify, this is a modified version of DHE based on released v3.0a source code that should support both Final Doom versions (and everything else v3.0a did, from 1.666 to Ultimate 1.9!)

 

edit2: I've tested this a bit now.

 

Working patches:

  dmarmy3.deh (DHE 3.x example) warnings from dosbox on some maps
  fun_2.deh (DHE 3.x example)
  sample.deh (DHE 3.x example)
  suprwep8.deh (DHE 3.x example)
  turbo.deh (DHE 3.x example)
  pl2.deh (Plutonia 2)

 

Not working:

  sample.deh (DHE 3.x example)

  vsmooth.deh (vanilla smooth weapons)

 

sample.deh does not work with the original binary-only DHE v3.1 either when applied to Final Doom r1 (sprite name "TROO" is supposed to change to "SHTG" but it changes to ":%p " or other such garbage instead). vsmooth.deh however works with DHE v3.1 & Final Doom r1 exe. So more investigation is still required.

Edited November 2, 2020 by xttl

[taufan99]

This DeHackEd for Final Doom seems very useful enough to warrant a new thread. Also, all your work definitely needs to be preserved on Github.

[Redneckerz]

On 10/30/2020 at 7:47 PM, xttl said:

udoomhack_r3.zip

Brilliant. If you may, since you mentioned that UDoomHack supports different -parms now, could you make an updated list of features this supports?

Besides that, i am sorry to hear you are facing some hurdles in life. If there is anything i can do to help, let me know.

On 10/30/2020 at 9:04 PM, OpenRift said:

Well the #1 example that comes to mind is Plutonia 2. The only need for increased limits as far as I know is the usual savegame overflow nonsense. Otherwise it works perfectly fine with v1.

 

https://www.doomworld.com/idgames/levels/doom2/megawads/pl2

 

PL2 did have an illegally modified Doom executable to enable support, i believe. it was made by some russians.

 

2 hours ago, xttl said:

 

Download (includes patched source for Borland C++ 3.1):

dhe_special.zip

 

I might finally put a website up again or register into that newfangled github to host this. I wonder should I also make a new thread? Needs testing though, I've only tested a couple of patches and there are still some values in the tables which might not be correct...

 

edit: to clarify, this is a modified version of DHE based on released v3.0a source code that should support both Final Doom versions (and everything else v3.0a did, from 1.666 to Ultimate 1.9!)

This is beyond incredible. A DeHacked modification that supports every single version of Doom including Final Doom/Anthology? This should be on/idgames.

 

@Doomkid take note! As Vanilla Vigiliante, this will be of service to you.

@JadingTsunami This might also be highly useful for VULD, since it uses DeHacked anyway. With this update, VULD could also handle Final Doom/Anthology things.

 

By the way: If you need help hosting some of your old work on that Github page - I have most of your older stuff saved up, so it could be hosted there.

[Doomkid]

Thanks for the mention, this is awesome! Since I've always only modded Doom 1 and Doom 2, I wasn't even aware of any issues with any Final Doom versions until very recently, so this is great to see.

[JadingTsunami]

Oh, this is fantastic news. Thanks @Redneckerz for the mention. And @xttl this is excellent; something that many have said would be useful but no one has developed until now.

 

I will look into this more soon; I agree it would make a great addition to the VULD bundle.

[OpenRift]

Jesus Christ man, I was all like dude, making a whole new version of dehacked for anthology FDoom is gonna be a pain in the ass to make, and what does he do? Churns a whole test version out 48ish hours later. @xttl, you sir are a legend. I completely agree with @Redneckerz, this should definitely be archived ASAP on github or idgames or something.

 

EDIT: Just did some testing with a custom deh file for URANIA.WAD and it works 100% with the anthology exe. Fucking kick-ass.

Edited November 1, 2020 by OpenRift

[OpenRift]

@xttl back to udoomhack though, any plans on adding mp3 WAD/CD music support for stuff like SIGIL_SHREDS.WAD?

[xttl]

Well before you get too excited, let's see if I can get it to reliably work with ALL DeHackEd patches. I wonder what would be good, complex patches to test besides vsmooth.deh? HacX? Batman Doom? Btw. even if a particular patch SEEMS to work without crashing, watch the DOSBox console status window for messages. eg. dmarmy3 doesn't crash but warping to certain levels you start to get warnings. Most likely frame/codepointer changes for certain monsters' frames doesn't work as it should but I'll investigate more...

 

before I do that, I wasted some time on a new color scheme tho:

 

 

(can be disabled from dehacked.ini if you don't like it)

 

Also removed Greg Lewis' email address from the startup info box because it almost certainly doesn't work anymore, heh.

 

17 hours ago, OpenRift said:

back to udoomhack though, any plans on adding mp3 WAD/CD music support for stuff like SIGIL_SHREDS.WAD?

 

No. MP3 is too complex to patch in (though maybe that could change with kgsws' new patching tools which allow use of compiled code), and output quality would be limited (less than 44.1kHz and less than 16-bit) anyway except on certain soundcards. CDDA is more realistic but then you'd always have to burn CDs or generate CD images with audio tracks for DOSBox from your mp3/ogg/flac files.

 

update: Ahh yeah, code pointer editing uses another table of hardcoded wtf is this shit values in data.h. I copied the values for Final Doom r1 from DHE 3.1 exe into DHE SE and vsmooth.deh works now (in Final r1). Well except barrel explosions still crash the game for some reason. Still need to figure out the codepoff[] values for Final Doom r2.

Edited November 2, 2020 by xttl

[xttl]

Okay, I figured out how to calculate the values. vsmooth.deh works with Anthology exe now. Though there are still random stability issues (with both Final Doom exes). :(

 

updated version:

see new thread

 

edit: Hey an idea just popped into my mind: what about adding support for Doom95 and maybe the even more crappy win3.1 windoom exes? Though let's get both Final Dooms working 100% first. Also, might be too complicated due to different executable format (and honestly I don't even like working with the DHE codebase much because it seems messy and depends on Borland C)

Edited November 2, 2020 by xttl

[xttl]

Figured out what was causing (at least some of) the crashes: magic value (oh god the program is full of these) 5855 in dehacked.cpp:Loaddoom must be bigger for Final Doom exes! 6000 is the value used in DHE 3.1. The value is the # of bytes read from LE fixup records tables (for frame table code pointers' fixups).

 

I changed it to 8192, vsmooth.deh now works perfectly in both Final Doom versions. I think I can make a new thread for this program at this point. :)

 

sample.deh still doesn't work tho I'm not sure if it's even supposed to... perhaps not. (causes game to I_Error out when spawning things due to changing sergeant's doomednum without assigning it to another thing)

Edited November 2, 2020 by xttl

[Redneckerz]

@xttlI have replied in the seperate thread already with far more useful links than this post will, but nevertheless, ill say it here aswell:

A heartfelt thank you from my end for all the effort you have put into not only DHE Special, but also UDoomHack, the seperate executables for No Rest for the Living, Ravmouse and Sig_Exe alongside other things.

[SaladBadger]

I dunno if anyone's too interested in hacking the 0.2 and 0.3 alphas, but I've found a brute-force way to generate a flat executable that can be loaded into a disassembler. I've tried Ghidra, but it should hopefully work with IDA

 

1. Locate the start of the code section (I dunno, I think it's a code section). this has the signature EB 0E 64 62 67 6F 74 6F 20 3D 6D 61 69 6E (ë dbgoto =main in ansi)
2. Nuke every byte in the binary before the EB
3. Add more bytes at the end for the data. How much? I dunno, there's probably a field somewhere in the header that says. I padded my executable to one meg to be safe.
4. Load that mess up in Ghidra as a flat binary. Can specify x86, 32 bit, GCC and it seems to work just fine.
5. Stare at that mess in the code browser.

This seems to work. Mostly (I've only tested it with 0.2 atm, since that has extensive debugging symbols). The compiler and linker used for Doom 0.2 and 0.3 is weird (does anyone know for certain which compiler was used to begin with?) and seems to group string and other literals by input file with its functions, and starting the flat binary at the start at the segment seems to align accesses to these literals properly. I wanted to figure out more about the executable format itself, which would probably be vital for any extensive hacks, but I honestly couldn't make heads and tails of the dos extender binary involved. It's pretty tiny, especially compared to DOS4GW, but still beyond my scope.

 

There are some problems I've observed with this. Some functions don't seem to get called right, and the main function isn't properly detected so it needs to be added manually, but unless I could figure out what sort of relocation data is present, this is the only way I've been able to make anything work.

[xttl]

I looked a bit into 0.2 and 0.3 some years ago but it seems I've lost the notes. ;__;

 

So let's look at it again:

 

If you calculate the size of the regular DOS MZ executable from the header fields (numpages*512 + lastpagesize) it is 61360 bytes for Doom 0.2 exe and 63280 bytes for Doom 0.3. In both cases, if you look at the exe in those locations, there's something which very much looks like it could be another executable header (just as expected) beginning with magic bytes "MT". IIRC I eventually found out some info about this format, but now I cannot remember what I typed into Google anymore. :( Obviously "MT" by itself is not very useful as a search term. probably confusing this with the formats used in Japanese PC98 Doom&Wolf

 

These strings can be found in the executables:

 

"Code Builder(TM) Kit 80387 Emulator Installation Module   $CBVersion: NPXEMUL V1.1A$Copyright 1992 Intel Corporation." (0.2)

"Code Builder(TM) Kit 80387 Emulator Installation Module   $CBVersion: NPXEMUL X00E              $Intel Corporation Proprietary Software" (0.3)

 

Code Builder seems to be have been the name of Intel's C compiler at some point in time, so that might have been what the game was built with before switching to Watcom.

 

edit: well, I found a download for Code Builder 1.0, but trying to compile&link a 32-bit printf("hello") with it fails due to missing file BIN\XMVM.

If you look at strings in the Doom binaries, there's a reference to "XMVM" in there. "XMLOD" is also referenced, and this copy of Code Builder does have a BIN\XMLOD file. I guess xmlod might be the protected mode binary loader and xmvm is the extender.

 

Building with icc /xnovm actually works, "xmvm" seems to be something that is only required if you want virtual memory support for your program. There is a "MQ" header directly following the MZ part though, not "MT". The compiler/linker also makes a "hello.rex" file as an intermediate step, see how the old Doom binaries have strings "XMDBG.REX" and "XMVM.REX" in there (these strings are actually part of XMLOD). The REX file begins with a "MQ" header.

 

I think 0.2 and 0.3 were compiled using the Intel compiler and the DOS extender is called "XMLOD" (or maybe just "XM"?). Too bad 1.0 seems to be the only version easily available on the Internets (it is older than what was used for Doom) and even that is an incomplete copy... unless XMVM was sold separately or something.

 

edit2: looking at Doom 0.3 exe my current guess is that the actual game executable (in "MT" format) begins at offset 88323 (0x15903) and in 0.2 at 86273 (0x15101), this is assuming the compiler just switched from the "MQ" to "MT" format at some point after 1.0. (the first executable after XMLOD should only be the self-contained 80387 emulator in any case, at least it works that way when I build programs with FPU emulation enabled in 1.0, it copies the whole LIB\EMUL387 "MQ" binary between XMLOD and my own program from the .REX "MQ" file)

 

edit3: the total size of MT executables can be found at offset of "MT" header + 50 bytes. take a look at doom 0.3, go to 0xF762 and you see 0x61D3 there in little endian which is the size of that version of EMUL387 header included. otherwise I have no idea about the header format yet. :(

 

edit4: I wonder if the real beginning of the code section (relative to start of MT) is the first 4-byte value in the header right after the magic "MT"? (0x12CC in 0.2, 0x2EB0 in 0.3). That points a little bit before the jump opcode + "dbgoto" thing though.

 

edit5: last or second to last field in header (14th 32-bit value after magic) is the size of debug info tail, it is zero in v0.3 and exactly matches size of debug data (109557 bytes) included in v0.2 after the end of actual MT.

 

also, seems REX stands for "relocatable executable" in some contexts so there may be a fixup table, though these "MT"/"MQ" exes don't look like any PharLap format I've found documentation for.

 

seems MQ might be a PharLap format after all: link

problem is, I still cannot find any documentation for the MT variant (assuming it is an updated form of MQ) and Open Watcom's wdump doesn't know anything about it :(

 

edit6:

 

If we assume the MT header consists of just a bunch of 32-bit values after the magic "MT" bytes, it would look like this for Doom v0.3:

unknown1...: 0x00002eb0 (11952)
unknown2...: 0x00002e76 (11894)
unknown3...: 0x0004d54b (316747)
unknown4...: 0x0006d54c (447820)
unknown5...: 0x00000000 (0)
unknown6...: 0x003a0000 (3801088)
unknown7...: 0x00020000 (131072)
unknown8...: 0x00000000 (0)
unknown9...: 0x00000000 (0)
unknown10..: 0x0001eded (126445)
unknown11..: 0x00000000 (0)
unknown12..: 0x00000000 (0)
mtsize.....: 0x00021c9d (138397)
debugsize..: 0x00000000 (0)
unknown13..: 0x000002f1 (753)

I thought unknown7 might be the stack size (since it's exactly 128kB) but changing it to very low values or even 0 seems to have no effect on the program in DOSBox. It's not even generating any warnings in the console. :(

 

I also tried removing the 387 emulator binary completely from in between XMLOD and the main game MT because I thought what if the emulator sets up the stack anyway. Well, it still doesn't crash. :(

 

Game runs fine without the emu in DOSBox tho, as I expected because DOSBox already emulates a FPU anyway. (does the game even use it? I recall the press beta documentation mentioned something about some "floating point traps" still being in there while final game will run w/o FPU...)

 

Most annoying thing about this is that the extender and format probably have been documented somewhere, but I just don't know how to search for it, or it's not on the web sitting in an old book somewhere.

 

btw. XMLOD from Code Builder v1.0 cannot load the Doom MTs, but if I rip out XMLOD from either Doom exe and combine it with my MQ hello.rex compiled with Code Builder it works. So I guess the older XMLOD version does not support the MT format, but the newer ones included with Doom can do both MT and MQ, and possibly also a third format: MR.

 

yet another update: downloaded some old PharLap 386|DOS Extender tools, mapexe.exe recognizes MQ binaries but not MT binaries. :( also, not much documentation was included as text files and I have yet to find manual scans on the net.

Edited November 17, 2020 by xttl

[SaladBadger]

this is some good sleuthing, but it is frustrating there's very little documentation. My own searches turned up the potential phar lap connection, but also got caught up in a red herring in the form of an obscure gcc port that also used the "xm" prefix and had a dos extender named "xm" with similarly named modules like "xmdos", but the dates on all of the files I found are from 1990, so it's too early. Phar Lap does come up a lot seeing as it's one of the earliest DOS extenders, but I don't think I've ever seen any DOS binary use it or any actual documentation on using it, so that's annoying.

 

ed: re: floating point usage: The only floating point use I have found so far is creating the sine LUT. I haven't turned up anything that occurs in the game logic.

Edited November 17, 2020 by SaladBadger

[xttl]

Viewing with the DOSBox debugger, it seems Doom v0.2 gets loaded at 0x2000010:

0038:02000000 CD 21 61 C3 00 00 00 00 00 00 00 00 00 00 00 00  .!a.............
0038:02000010 EB 0E 64 62 67 6F 74 6F 20 3D 6D 61 69 6E 00 00  ..dbgoto =main..
0038:02000020 FC 60 DB E3 BE 68 D9 00 02 66 C7 06 5A 5A DD 3E  .`...h...f..ZZ.>
0038:02000030 80 3E 00 75 1E D9 3E 66 8B 06 66 25 3F 10 66 83  .>.u..>f..f%?.f.
0038:02000040 F8 3F 75 0F C7 05 6E D9 00 02 01 00 00 00 E8 F1  .?u...n.........
0038:02000050 8E 00 00 61 E8 D3 8D 00 00 E8 DE 8E 00 00 E8 2D  ...a...........-
0038:02000060 00 00 00 E8 84 88 00 00 0B C0 74 06 50 E8 02 8F  ..........t.P...
0038:02000070 00 00 FF 35 E0 D5 03 02 FF 35 F8 D3 03 02 FF 35  ...5.....5.....5

...at least with my DOSBox memory settings and version/build; if it works like DOS4GW and LEs then the load address can change depending on those.

 

Also there are some bytes before it that are *not* coming from the exe file (well, at least not the main MT part) which translate to: int 0x21, popad, ret. There are not enough zero bytes before the jump in the exe for that pad to 16 bytes either.

 

Can also confirm pointers change in memory vs. on disk (the thing that comes after the main MT header always looked like it's a fixup table anyway, this just confirms it is indeed rebased on load).

 

(I calculated that base address by breaking into debugger and then finding the bytes at EIP on disk, and before you ask: under 0x2000000 there is just a lot of zero fill, CS,DS,ES,SS,GS,FS all point to the same memory as usual)

 

just checked: Doom v0.3 is loaded at the same address and changing xms,ems&umb from true to false has no effect on load address.

 

btw. header value #10 (126445 bytes for v0.3, 58535 bytes for v0.2) is always very close to size of what you get if you cut everything from the MT before the first jump or at the offset the first header value specifies (and also all the debug info from v0.2), but neither matches it exactly. Cutting at the point specified by value #1 is only off by one byte though... or I am cutting wrong :P

 

I wonder what is value #6, it is the same large number on both (0x3a0000 = 3801088), I thought it could be the amount of memory to reserve (the version of the Intel compiler I have defaults to 3MB and that number would be close at 3,625MB) but changing it even by one in either direction causes the programs to crash DOSBox.

 

update: if you cut everything before the offset given by the first value in the header, you'll get a chunk that is the same size as in MT header value #10 (58535 bytes in v0.2, 126445 in v0.3). I think the first 12 bytes (so 3x 32-bit values) in that chunk before the jump + string are some kind of further header values. The second and third values are 1 and 0 respectively in both alpha exes. The first value seems to be a further offset, if you use the value to jump to a position inside this chunk you get to some very similar looking content in both exes (beginning with 5D C3 00 0D ...).

 

Based on some strings further down it might mark the start of library code, but why would they want or need to demarcate it like that? (it is not a code/data split either).

 

I noticed in a DOSBox memory dump that some of the stuff near the end of the MT does not appear where you'd expect it to, so the loader probably does something with that value... but what and why?

Edited November 17, 2020 by xttl

[xttl]

On 11/17/2020 at 10:24 AM, SaladBadger said:

this is some good sleuthing, but it is frustrating there's very little documentation.

 

I bet the documentation does exist, but only in an old book somewhere. :( Or possibly in a hard drive that is holding files from somebody's old BBS system that never made it into the Internet age.

 

On 11/17/2020 at 10:24 AM, SaladBadger said:

but also got caught up in a red herring in the form of an obscure gcc port that also used the "xm" prefix and had a dos extender named "xm" with similarly named modules like "xmdos"

 

That's interesting, never heard of that one. DJGPP is the only port of GCC to DOS I knew about...

 

On 11/17/2020 at 10:24 AM, SaladBadger said:

Phar Lap does come up a lot seeing as it's one of the earliest DOS extenders, but I don't think I've ever seen any DOS binary use it or any actual documentation on using it, so that's annoying. 

 

My understanding is that Phar Lap extenders were relatively pricey to license back in the day, and so they mostly only got used in expensive professional software like AutoCAD for DOS. I wouldn't be surprised if there simply aren't any games out there that use a Phar Lap extender. Still, the same formats seem to have been used by extenders from other companies (such as here by Intel).

 

I think Watcom actually used to generate protected mode binaries only for Phar Lap until DOS4G and others came along, even Open Watcom still supports some Phar Lap formats in addition to DOS4G. Btw. the last generation of Phar Lap's DOS extender (TNT) actually used the same executable format as Windows NT (including all current versions) uses: PE. It even provided at least some subset of the Win32 API under DOS, including threads and stuff, in 1993. Nowadays there are some free extenders that also do this (see HX DOS Extender), people have got things like media players written for Windows to run in DOS that way.

 

The Japanese Doom and Wolf binaries are in Phar Lap formats too: Doom & Doom 2 use "MP", and Wolf uses "P3". You can actually find some information about these on the 'net. MP seems very simple, not many fields in the header. I wonder if it's related to MQ/MR/MT which all have very short headers, like the version preceding MQ?

 

It's too bad all the Japanese id games were built without relocation tables for some reason even though the formats can do it, maybe their weird Japan only(?) DX DOS extender doesn't support rebasing? That makes it hard to add support for them into LE Loader because it isn't possible to control at what (virtual) addresses you get memory buffers from the OS. :( Well, actually you *can* ask VirtualAlloc on Windows or mmap on Linux/Unix for memory at a certain virtual address, but you aren't guaranteed to get it. I've tested this with asking for memory at 0xA0000 so that a game which uses standard no-frills VGA mode 0x13 could run without any patching or trapping of the graphics code, and it does often work but unfortunately not always (not even when ASLR is disabled from the program header). However, the Japanese binaries must be loaded at very low addresses which makes the required allocations unlikely to succeed in any environment. I would have loved to support at least Wolf3D since it's the only official 32-bit port of the original PC version. :(

 

^{well, maybe I could go through the binary and try to build a relocation table for it myself but that'd be a LOT of effort...}

 

I was going to save this long post until I have some more substantial info about MT, but it's not happening today and probably not tomorrow either. :P

 

Only things I can add right now are that none of the originally zero header fields seem to control the entrypoint. Thought one of them would be it, MQs have an entrypoint field which however is zero by default in REX files built with Code Builder 1.0. Perhaps they removed that option from MT and just always start execution at the beginning... Also, in the main header, the value at 0x18 is definitely a 16-bit word (XMLOD code reads it as 16 bits with movzx), not a 32-bit doubleword. That probably makes the one before it 16-bit too (but you could split the preceding fields in different ways, needs more analysis of XMLOD to be sure). I also finally confirmed that the size of a few other fields is 32 bits.

Current guess at header format looks like this:

Spoiler

 

$ mtread doom.exe 1

size of MZ: 61360 (0xefb0) bytes
size of 387 emulator MT: 24913 (0x6151) bytes

game MT at 0x15101 (86273), header info:

002 dword02.....: 0x000012cc (4812)
006 dword06.....: 0x00001292 (4754)
00a dword0A.....: 0x0003e573 (255347)
00e unknown4....: 0x0003fdac (261548)
012 unknown5....: 0x00000000 (0)
016 word16......: 0x0000 (0)
018 word18......: 0x003a (58)
01a unknown8....: 0x00001838 (6200)
01e unknown9....: 0x00000000 (0)
022 dword22.....: 0x00000000 (0)
026 dwcodesize..: 0x0000e4a7 (58535)
02a unknown12...: 0x00000000 (0)
02e unknown13...: 0x00000000 (0)
032 dwmtsize....: 0x0000f773 (63347)
036 dwdbgsize...: 0x0001abf5 (109557)
03a unknown16...: 0x000004ad (1197)

  subheader:
   000 0x00008d39 (36153)
   004 0x00000001 (1)
   008 0x00000000 (0)

 

(Doom v0.2)

 

 

Edited November 19, 2020 by xttl

[OpenRift]

Hey, so I was curious, would there be any way that someone could make a patch for Ultimate Doom's EXE that would increase the zone memory, similar to how Doom32 does? Or perhaps a better question, has anyone found how to do that with Ultimate Doom's EXE?

[Redneckerz]

21 hours ago, OpenRift said:

Hey, so I was curious, would there be any way that someone could make a patch for Ultimate Doom's EXE that would increase the zone memory, similar to how Doom32 does? Or perhaps a better question, has anyone found how to do that with Ultimate Doom's EXE?

I'd assume its the same thing as applied to Doom32. Good ole Myk uploaded a seperate Heapsize.CRK file in the past which can be applied using Cracker.exe

 

But Ultimate Doom v1.9 is, i believe, the same executable as Doom 2 v1.9 anyway.

[OpenRift]

14 minutes ago, Redneckerz said:

I'd assume its the same thing as applied to Doom32. Good ole Myk uploaded a seperate Heapsize.CRK file in the past which can be applied using Cracker.exe

 

But Ultimate Doom v1.9 is, i believe, the same executable as Doom 2 v1.9 anyway.

Unfortunately not. Doom 2 1.9 is the same as Doom 1.9, pre Ultimate Doom. so unfortunately the patch doesn't work. :/ that is a good link to have tho.

[Redneckerz]

44 minutes ago, OpenRift said:

Unfortunately not. Doom 2 1.9 is the same as Doom 1.9, pre Ultimate Doom. so unfortunately the patch doesn't work. :/ that is a good link to have tho.

You are right, i stand corrected.

 

I do know of a patched up Ultimate Doom that was released as Final Doom-plus. However, it isn't based off the actual Final Doom but rather just regular Doom-plus 1.92.2. It was finally retrieved in October 2020.

 

It might be a starting point. Perhaps you can patch the heapsize crack to that and then thus establish some kind of FDoom32?

Ofcourse, Xttl's Ultimate Hack would be the definitive vanilla modification, but sadly he has been in absentia for a few months.

[OpenRift]

4 minutes ago, Redneckerz said:

You are right, i stand corrected.

 

I do know of a patched up Ultimate Doom that was released as Final Doom-plus. However, it isn't based off the actual Final Doom but rather just regular Doom-plus 1.92.2. It was finally retrieved in October 2020.

 

It might be a starting point. Perhaps you can patch the heapsize crack to that and then thus establish some kind of FDoom32?

Ofcourse, Xttl's Ultimate Hack would be the definitive vanilla modification, but sadly he has been in absentia for a few months.

I tried that, and cracker.exe still says failed. I'm gonna try my luck with IDA again. 

[OpenRift]

@Redneckerz I didn't do the heapsize thing yet, but I did manage to figure out something else. I finally figured out how to increase the savegame limit in Final Doom (rev2). Tested with TNT Reevilution Map04 and Plutonia 2 Map03. No crashes. 

FDOOMSP.zip

 

I'm actually shocked by how easy it was. Though it was more just my personal brand of copy-pasting hex values from existing cracks. I'd essentially just find the same sequence of values in UltraEdit and make the changes. I'm honestly surprised it worked. 

 

Today is a good day.

[OpenRift]

Oh yeah, I also should've posted my .crk file. Perhaps @xttl may find it useful. :)

fdoomsav.zip

[Dark Pulse]

1 hour ago, OpenRift said:

Oh yeah, I also should've posted my .crk file. Perhaps @xttl may find it useful. :)

fdoomsav.zip

He hasn't been around in about three months, so it might be awhile...

[OpenRift]

1 minute ago, Dark Pulse said:

He hasn't been around in about three months, so it might be awhile...

It's more just a message for when he comes back.

[axdoomer]

On 3/23/2021 at 5:16 PM, OpenRift said:

@Redneckerz I didn't do the heapsize thing yet, but I did manage to figure out something else. I finally figured out how to increase the savegame limit in Final Doom (rev2). Tested with TNT Reevilution Map04 and Plutonia 2 Map03. No crashes. 

FDOOMSP.zip

 

I'm actually shocked by how easy it was. Though it was more just my personal brand of copy-pasting hex values from existing cracks. I'd essentially just find the same sequence of values in UltraEdit and make the changes. I'm honestly surprised it worked. 

 

Today is a good day.

 

For the heapsize, if you can't find the same sequence of bytes, I suggest using the BinDiff plugin for IDA Pro or Ghidra(+LX loader).

 

It allows you to match functions which are not the same at the byte level, but have the same control flow. Sometimes the functions are the same, but two instructions gets swapped or different registers are used, which will change the functions at the byte level.

 

BinDiff helps solve this problem. It looks like this:

[OpenRift]

Just now, axdoomer said:

 

For the heapsize, if you can't find the same sequence of bytes, I suggest using the BinDiff plugin for IDA Pro or Ghidra(+LX loader).

 

It allows you to match functions which are not the same at the byte level, but have the same control flow. Sometimes the functions are the same, but two instructions gets swapped or different registers are used, which will change the functions at the byte level.

 

BinDiff helps solve this problem. It looks like this:

Forgot to mention, I did figure out the heapsize thing for Doom 1, but I ended up discarding it because it proved useless in solving the issue that E4M7 from No End in Sight always seems to have. Something about that level is causing a venetian blinds crash and I have absolutely no idea how to fix it. It's such a strange enigma and such a shame because NEIS is such a great WAD.

[SaladBadger]

so I've been trying to complete xttl's work on the Alpha 0.2 and 0.3 format since I'd like to complete RE of them, but my crude way of mapping them wasn't working out well. I feel like I'm close, so freaking close, but it's not 100% falling in place. Here's my estimate of the header right now:

002 dwcodestart.: 0x000012cc (4812) //this value is dwrelocsize + wheadersize
006 dwrelocsize.: 0x00001292 (4754) 
00a dwdatasize..: 0x0003e573 (255347) //in memory
00e dwstackptr..: 0x0003fdac (261548) //this value is dwdatasize + dwstacksize + 1. Extremely wild guess atm. Doesn't 100% make sense
012 unknown5....: 0x00000000 (0)
016 word16......: 0x0000 (0)
018 wheadersize.: 0x003a (58) //3a in both Doom 0.2 and Doom 0.3
01a dwstacksize.: 0x00001838 (6200) //131072 in Doom 0.3
01e unknown9....: 0x00000000 (0)
022 dword22.....: 0x00000000 (0)
026 dwcodesize..: 0x0000e4a7 (58535)
02a unknown12...: 0x00000000 (0)
02e unknown13...: 0x00000000 (0)
032 dwmtsize....: 0x0000f773 (63347)
036 dwdbgsize...: 0x0001abf5 (109557)
03a unknown16...: 0x000004ad (1197)

From the bits of data I've extracted so far, I can throw my program at the Doom 0.2 or Doom 0.3 executables and correctly locate the code section and work through that. The code section starts with a small sub-header of 3 dwords. The second is always 1, and the third is always 0, and then there's the db goto =main jump. The most convincing value is the first one, which is nearly 3 times larger in 0.3, because Doom 0.3 has significantly more code than 0.2, but it's not quite enough to get to the data section, and the amount it's not enough varies across the two executables.

 

This is frustrating because I poked at the data section, and I can see how it's assigning default values of memory to the program's address space, but I can't get that final piece of the puzzle, what actually locates it to work, and that's frustrating. I can hardcode it and get the 0-based flat executables I want, but I want to understand damnit. Would also like to be able to understand the relocation data. I have to assume the relocation data is sandwiched between the header and the code section.

 

EDIT: AGH, why's this always happen right after I make the post explaining how I can't figure it out? I figured it out. I think. There is no separation between "code sections" and "data sections", so far as I can tell so far. Instead, there's one big unified block that puts bytes into memory. From the start of the code section up to the end of the MT file, a number of blocks are stored. The blocks have a simple format:

int blocksize; //size of the block
int unknown; //always 1 to the best of my knowledge, unknown purpose
int address; //where in the 0-based address space the bytes will be placed
uint8_t data[blocksize]; //the data to read into memory

This should resolve every lingering problem I've had so far. Fingers crossed...

Edited April 9, 2021 by SaladBadger

[OpenRift]

13 hours ago, SaladBadger said:

so I've been trying to complete xttl's work on the Alpha 0.2 and 0.3 format since I'd like to complete RE of them, but my crude way of mapping them wasn't working out well. I feel like I'm close, so freaking close, but it's not 100% falling in place. Here's my estimate of the header right now:

002 dwcodestart.: 0x000012cc (4812) //this value is dwrelocsize + wheadersize
006 dwrelocsize.: 0x00001292 (4754) 
00a dwdatasize..: 0x0003e573 (255347) //in memory
00e dwstackptr..: 0x0003fdac (261548) //this value is dwdatasize + dwstacksize + 1. Extremely wild guess atm. Doesn't 100% make sense
012 unknown5....: 0x00000000 (0)
016 word16......: 0x0000 (0)
018 wheadersize.: 0x003a (58) //3a in both Doom 0.2 and Doom 0.3
01a dwstacksize.: 0x00001838 (6200) //131072 in Doom 0.3
01e unknown9....: 0x00000000 (0)
022 dword22.....: 0x00000000 (0)
026 dwcodesize..: 0x0000e4a7 (58535)
02a unknown12...: 0x00000000 (0)
02e unknown13...: 0x00000000 (0)
032 dwmtsize....: 0x0000f773 (63347)
036 dwdbgsize...: 0x0001abf5 (109557)
03a unknown16...: 0x000004ad (1197)

From the bits of data I've extracted so far, I can throw my program at the Doom 0.2 or Doom 0.3 executables and correctly locate the code section and work through that. The code section starts with a small sub-header of 3 dwords. The second is always 1, and the third is always 0, and then there's the db goto =main jump. The most convincing value is the first one, which is nearly 3 times larger in 0.3, because Doom 0.3 has significantly more code than 0.2, but it's not quite enough to get to the data section, and the amount it's not enough varies across the two executables.

 

This is frustrating because I poked at the data section, and I can see how it's assigning default values of memory to the program's address space, but I can't get that final piece of the puzzle, what actually locates it to work, and that's frustrating. I can hardcode it and get the 0-based flat executables I want, but I want to understand damnit. Would also like to be able to understand the relocation data. I have to assume the relocation data is sandwiched between the header and the code section.

 

EDIT: AGH, why's this always happen right after I make the post explaining how I can't figure it out? I figured it out. I think. There is no separation between "code sections" and "data sections", so far as I can tell so far. Instead, there's one big unified block that puts bytes into memory. From the start of the code section up to the end of the MT file, a number of blocks are stored. The blocks have a simple format:

int blocksize; //size of the block
int unknown; //always 1 to the best of my knowledge, unknown purpose
int address; //where in the 0-based address space the bytes will be placed
uint8_t data[blocksize]; //the data to read into memory

This should resolve every lingering problem I've had so far. Fingers crossed...

Any luck on finding a way to implement the higher savegame buffer?