Some Guy wrote:
Paul wrote:

When you unpack the above GHOST_BOOTx.zip file, are
you finding it corrupted ? There seems to be a problem
unpacking the second floppy image. The file might have
been truncated.

The page where I got the ghost link from is this:

http://www.dslreports.com/forum/r562...ppy-for-BootCD

The first post gives a direct link to the file. If you click on the
link and download it, you get a file with 1,340,942 bytes and it will
have the current (real-time) date and time.

The direct link is this (this is what I posted earlier in this thread):

http://www.dslreports.com/r0/downloa...HOST_BOOTx.zip


I now see that if you try to download this file using wget, or by
directly entering it into a browser, you get a file with 1,339,806
bytes, and it has a date of 1/11/2004 (at least that's what I'm seeing).
And it won't unpack.

It might be that the dslreports server is not giving the entire file
unless your http file request includes this as the referrer url:

http://www.dslreports.com/forum/r562...ppy-for-BootCD

wget won't give any referrer URL (unless you specifiy one on the command
line, assuming wget has that ability).

So in other words, you need to access this page using any browser:

http://www.dslreports.com/forum/r562...ppy-for-BootCD

And then click on the ghost download link in the first post.

In this example, there's no referer, and the correct size results.
An attempt to do this with WGET on the same platform, gives
the "smaller" (1,339,806 bytes) file.

paul@mint ~ $ http GET http://www.dslreports.com/r0/downloa...HOST_BOOTx.zip --output out.zip
paul@mint ~ $ ls -al
total 1320
-rw-r--r-- 1 paul paul 1340942 Nov 12 01:53 out.zip
paul@mint ~ $

I compared the two files, and there is a weirdness at
around every ~32KB of data in the ZIP. Almost as if
maybe the file was being re-encoded on the fly
by the NGINX server.

And logically, even though the files are different
sizes, when unpacked, they have the same GHOST_BOOTx.exe
(1,397,111 bytes) inside the ZIP file. Whatever horrid
mutilation is happening, it hasn't affected the payload.
Other than that, I haven't been able to figure out
what the crap at the beginning and the end of the file
means. It's an encapsulation, but what is it ?

*******

Using either the proper sized or the smaller ZIP,
you can extract the EXE inside it.

The 1,397,111 byte GHOST_BOOTx.exe is a self extracting ZIP.

At hex offset 0x2121C of that EXE, you will find
50 4B 03 04 (PK/3/4). Which is the start of the archive.
That means everything before that address, is the SFX
program for self-extraction (on run).

Near the end of the EXE file, in the "trailer" area, at
0x155142 you will find that address value in reverse
order "1C 12 02".

OK, now if you remove the SFX portion, the executable
at the beginning of the file, it's still a ZIP. What
I did, was remove everything from 0x0 up to 0x2121C.
The result is a file that now starts with 50 4B 03 04 (PK/3/4).
You want to have the PK from 0x2121C kept in the file.

In the trailer area, where it says "1C 12 02",
replace that with "00 00 00". That's because, with
the SFX removed from the beginning, the archive
now starts at zero, instead of starting at
0x2121C. If you don't correct the offset stored in
the trailer, that causes another error.

Save the file. Now, when you feed that to a modern
ZIP utility, it sees *one* IMA file (floppy diskette)
inside, with good CRC.

paul@mint ~ $ unzip -t snip3.bin
Archive: snip3.bin
testing: GHOST_BOOTx.IMA OK
No errors detected in compressed data of snip3.bin.
paul@mint ~ $ file snip3.bin
snip3.bin: Zip archive data, at least v1.0 to extract
paul@mint ~ $

The same file from 7ZIP in Windows, shows only one IMA
and no header errors.

L:\snip3.bin\
size packed modified CRC
GHOST_BOOTx.IMA 1474560 1261251 2003-01-10 22:06 5D725E63

And that CRC value, you can see it in reverse order
down near the end of the file. Before the trailer starts.

*******

As for the floppy itself, it doesn't have a copy of Ghost on it.

But, a puzzle for you. When you "winimage" something, it works
at the sector level. Notice that the floppy must have been
filled with relatively random data, because the compressed
archive saved hardly any space at all. That means there
*could* be deleted files, sitting on the floppy. A good
technician, would have zeroed the white space on the floppy,
before winimaging, as this would make the archive significantly
smaller. By winimaging the raw floppy, without doing any
hygiene, means there could be "interesting things" on there.
And maybe, that's what the person who posted that, had in
mind :-) You never know. I've had enough fun for now.

Paul