PDA

View Full Version : Anyone know much about 1992 Packing/Unpacking executables?



comradesean
February 11th, 2016, 09:32 AM
I've got a retail release of the software "Out of the World" and a Scene release TimeStamped two+ days earlier. I'd like to compare the two executables and see if there were any differences (and figure out if it was a legitimate early release), but the scene group repacked their copy with PKLITE and it no longer matches the retail release.

The retail executable has the following in the header

4D 5A 44 01 2A 00 00 00 02 00 B5 14 FF FF E8 0A MZD.*.......
00 08 00 00 0D 00 21 05 1C 00 00 00 44 49 45 54 ......!.....DIET

It looks like it was packed using DIET if you look at 0x1C - 0x1F, but I've tried every version available and none of them will unpack it. Further, DIET actually tags files with a lowercase "diet" in that exact position.

I've also tried CyberWare Universal Unpacker without any luck and "The Executable's Unpacker" which appeared to unpack it, but the executable came out scrambled and inoperable. I can locate readable ASCII though that matches the scene release so it might just be missing some sort of header or footer code.

Trixter
February 11th, 2016, 01:27 PM
Have you tried UNP? My copy shows: "UNP 4.11 Executable file restore utility, written by Ben Castricum, 05/30/95"
However, if it was modified then CUPS is probably your only choice. You usually have to run CUPS' more advanced modes on a real system as it's v86 stuff chokes many emulators.

comradesean
February 12th, 2016, 07:21 PM
Have you tried UNP? My copy shows: "UNP 4.11 Executable file restore utility, written by Ben Castricum, 05/30/95"
However, if it was modified then CUPS is probably your only choice. You usually have to run CUPS' more advanced modes on a real system as it's v86 stuff chokes many emulators.

I did try UNP, but it stops after listing EXE part sizes. I'm guessing that's where it gives up if it can't determine pack method?

I'm trying to run CUPS with /3 right now on a pII, but I can't tell if it's hanging or not. (no keyboard with leds)

Trixter
February 12th, 2016, 08:37 PM
It was common to change ASCII signatures to confuse things. If you change DIET to LZ91, it appears to match an lzexe file. Do that, then try UNP with it.

Failing that, try all three CUPs modes on a system that is booted to real mode without any EMM/QEMM so that you can use the v86 mode.

comradesean
February 12th, 2016, 10:25 PM
It was common to change ASCII signatures to confuse things. If you change DIET to LZ91, it appears to match an lzexe file. Do that, then try UNP with it.

Failing that, try all three CUPs modes on a system that is booted to real mode without any EMM/QEMM so that you can use the v86 mode.

No luck yet, but ran into something strange. Running mode 7 resulted in an output that was nearly the same size as the original packed executable, only 30 bytes bigger or so. The header was actually corrected to that of LZ91 with the last four bits coming out as ?? ?? ?? ??. When I switched that with LZ91, it unpacked but the result was still unrunnable and scrambled, however it did contain some readable ASCII from the game.

Just switching the header to LZ91 without running CUP results in UNLZEXE hanging. I also packed several DIET executables and compared their headers to figure out the common bits, but putting those into the retail executable did no good either.

I've been trying to run v86 mode, but it's either hanging or very, very slow. Will leave system on over night and see what's up in the morning.

george
February 13th, 2016, 12:52 AM
Can you post a link to an archive with this packed executable and the accompanying files needed to run it?

comradesean
February 13th, 2016, 07:09 PM
PM'd you

george
February 14th, 2016, 03:26 AM
Here you have it unpacked and working (attached to this message).

comradesean
February 14th, 2016, 04:02 PM
Here you have it unpacked and working (attached to this message).

Thanks george!

Okay, so I'm not the most knowledgeable on the subject but I'm 99% sure this is a different release. Ignoring the header, 0x20 through 0x5BCC are similar, but not quite. After that, allowing for an offset of 0x29 between the two, the executables the identical. I'm assuming that would be embedded resources since this is where I'm finding the in-game text?

Strange thing is there's a configuration file "CONFIG.DAT" timestamped 04/15/92 that is included (this is created by the user). So that would mean that they would have had to have access to the release on that date.

Nothing conclusive from what I can see to determine legitimacy and Google Groups is polluted with misinformation due to the earlier European release and imports. It wouldn't be the first time, though, and these groups getting early beta releases was actually quite rare. I'll just have to keep trying my luck on eBay.

Chuck(G)
February 14th, 2016, 09:49 PM
There was also a virus IIRC that borrowed some of the DIET code. Not saying that this is your case, but just a possibility.

george
February 15th, 2016, 02:20 AM
There was also a virus IIRC that borrowed some of the DIET code. Not saying that this is your case, but just a possibility.
Not his case. One executable can be unpacked to thousand different valid files so simple byte comparison is not enough to make serious conclusions.

Chuck(G)
February 15th, 2016, 08:57 AM
Not his case. One executable can be unpacked to thousand different valid files so simple byte comparison is not enough to make serious conclusions.

I don't follow you at all. Care to elucidate?

As I recall, a virus using code from 1.45f (not the actual program) would infect an executable file by compressing it and adding a payload. Thus, the resulting infected file would be of the same length as the original. If you don't think that it's possible, I can probably find a cite for you.

This caused the virus scanner included with DOS 5 retail to falsely trigger on good files that had been processed with DIET.

george
February 15th, 2016, 03:31 PM
I don't follow you at all. Care to elucidate?

As I recall, a virus using code from 1.45f (not the actual program) would infect an executable file by compressing it and adding a payload. Thus, the resulting infected file would be of the same length as the original. If you don't think that it's possible, I can probably find a cite for you.

This caused the virus scanner included with DOS 5 retail to falsely trigger on good files that had been processed with DIET.

There is no virus in his file.