Single Status Update
Previously I've mentioned that I had a blackout because of losing one of my winchesters.
Now I could restore it but sadly, it didn't have any datas on it anymore. I stored my games on it, which is not a big loss - but all my WADs, with more than 3 GBs, that I've selected by hand during 4 years, and also all my Doom projects...
...well, they are.
So I'd like to ask your help! Is there anyone who owns any versions of my megaWAD projects (Somewhere in Time) which has unfinished map? I really need at least MAP04 and MAP11, those are the maps in which I put the most effort.
- Show previous comments 20 more
That hopefully means you've found some wads, if the bytes that immediately follow don't contain plain text. What you need now is a crash course in calculating relative offsets in Hexadecimal to determine where the start of the wad's directory should be. I'll post some more info later after I've had a play with HxD, haven't tried using it to recover files before now.
EDIT - HxD doesn't support saving blocks of data as files (which is a pest), while those blocks can be copy/pasted into another editor for saving there's a 2 Meg clipboard limit (which is also a pest) so my first attempt at extracting a 19 Meg wad that way was an abject failure. I'm currently trialing another freeware editor called wxHex Editor which looks to be better suited for our purposes (saved that 19 Meg wad with ease), though I had to go back one version to get it running on WinXP. I'll type up a few notes after dinner.
EDIT #2 - I'm happy with the wxHex Editor works and will post some notes ofter I've finished taking and editing screenshots - and getting some sleep. If you don't have a Hex calculator I'd recommend Hexit, which is more freeware.
If most of the wads in your collection are zipped or otherwise archived, those search results are hopefully wads you've been editing. If you decide to have a poke around with the disk editor, leave the file mode at "Read Only".
Back again, hopefully with a solution. Suppose I should start with the "your mileage may vary" disclaimer bit, since this data extraction method assumes a few conditions are met in order to work.
- The ascii string "PWAD" is at the start of a disk sector
- There are no lumps after the wad's internal directory - that doesn't make extraction impossible, just more difficult
- The file isn't fragmented, which is more likely to be an issue with larger wads
- The data hasn't been partially overwritten by a newer file, which would suggest the data's from an older version or a deleted file and probably not worth saving
Step 1: Open your disk partition (which isn't necessarily E:, that just happens to be my first data partition).
Step 2: Start your search.
Step 3: You have a search result (highlighted in blue) and this is where it starts to get interesting. The red lines are sector boundaries and with our highlighted text at the start of a sector we can be fairly sure it's the start of a wad file. The other highlights I've edited in, the lump count in yellow and the offset to the start of the wad directory in green.
Both of those values are in hexadecimal and Little Endian,so to make sense of them you need to read each set of bytes from right to left when entering them into the calculator, so the offset in that screenshot would be entered as 00 07 2A D0 (without spaces, they're just for readability and you can skip the leading zeros). Make a note of both values as shown and the address from the left-hand column with the big arrow pointing to it - 00039CC000 in this example. The lowercase "h" indicates hexadecimal, the program defaults to decimal but you can cycle through 4 number-bases by right-clicking on that column.
Step 4: Left-click on the first highlighted character (the start of our file) then right-click and select "Set Selection Block Start".
Step 5: Here's where you'll need a calculator, since we're about to calculate where the file ends - actually one byte past the end. Using the values in Screenshot 3 as an example - we enter the offset to directory (72AD0) and add to that the lump count multiplied by 16, which in hexadecimal is done by adding a zero. The reason for multiplying is because each lump entry in the directory occupies 16 bytes, 8 of which are reserved for the lump name, the others for size and offset. In this example, the hex value of 30 becomes 300, adding that to the offset gives us a result of 72DD0.
Step 6: Enter the calculated result into the "Go to Offset" requester, hit Go! and hope for the best.
Step 7: It looks like we're there (I've highlighted the byte, something the program doesn't do). It might look like we've gone a couple of bytes too far in this case, but those two null bytes have to be considered part of the 8 byte lump name.
Step 8: Go back one byte to where the directory and file ends, right-click and select "Set Selection Block End".
Step 9: Save your dump - preferably to another drive. Last thing you want to do is risk overwriting data you're hoping to extract. The block size you're saving (circled in red) should equal the calculator's decimal result.
Step 10: Return to Step 2.
Apart from your work-in-progress wads, you're also likely to salvage backups created by map/wad editors and possibly gl wads (.gwa files) created by glBSP, which is what my example wad is.
Hope this helps. If you get lost, post questions (and values noted down at Step 3) and I'll do what I can to help.