PK Zippers self destruct

Is this happening even with latest 2.50 versions?
I am myself running them under DOSBox, and no issues.
Maybe a kind of DOS malware?

> I'm not looking for a solution but> both the old PKZIP and PKUNZIP> programs at times self destruct on> my new I5 system.> > When this happens the size of the> program will be found to be 65535> bytes. Yep.> > I placed an extra .SAV copy of each> on my c:\ and in autoexec I copy the> two SAV files over the EXEs which> gets rid of the problem for me.> > Interesting day here.> > W3

PK Zippers self destruct

1) Does it happen with certain parameters or with all (tested) parameters?
Does the behaviour differ with just "pkunzip" and "pkunzip -d samezip.zip"

2) Are you sure that the PKZIP.EXE and PKUNZIP.EXE files are not modified? Are you sure they are not packed with PKLite or with UPX or with similar utility? What are the filesizes of your PKZIP.EXE and PKUNZIP.EXE ?

PK Zippers self destruct

> And it does not happen to them from something else> > It happens WHEN I RUN THEM but not always.

This is probably some local driver bug, unlikely (but still possible) to be some kind of BIOS bug (although you may have to fiddle with some legacy settings).

So unload any TSRs or drivers, and see if the problem persists. That means no USB, no mouse, no soundcard stuff, no software cache, no EMM386, etc.

IIRC, with pkunzip, you can disable automatic detection/use of some things (e.g. DPMI, 386). The cleaner/simpler, the better.

To be quite honest, if you used a FreeDOS-bootable USB, at least then your environment could be verifiable, (re)tested exactly "as is". But all of these little "optimizations" (and buggy drivers) mixed together probably don't do what you think they do.

P.S. Don't forget that you can use Info-Zip as an alternative (different cmdline switches but still works well).

PK Zippers self destruct

> > Both self destruct in exactly the same manner in MSDOS 710.> > > > But I dealt with it in autoexec.bat> > I really LOVE your 'I found a trick to deal with this, but I won't tell> you'> attitude.
"I placed an extra .SAV copy of each
on my c:\ and in autoexec I copy the
two SAV files over the EXEs which
gets rid of the problem for me."

I thought the OP posted how he fixed the problem in Autoexec.bat in his first post. Did I misread it?

PK Zippers self destruct

It might not be a bug! I'm wondering if it might be a security device to prevent "snooping"....

Because i've had this issue as well... but only under a particular condition. Have you (or someone else) unpacked/decompressed the .EXE files? That's when it began happening to me (with both PKZIP and PKUNZIP).

I just tested it again to verify (plain MS-DOS v7.1). Unpack/decompress the binaries (i used IUP or UNPKLITE -- same behavior after either), run the binaries (parameters not required!), and the binary files change datestamp to current, and PKUNZIP changes size as such:
PACKED UNPACKED OVERWRITTEN
------ -------- -----------
PKUNZIP.EXE 34,583 44,562 65,535
PKZIP .EXE 50,663 68,370 68,370

When you next run them, they crash. Examining the binaries reveals that their EXE headers have been overwritten!

Setting the file attribute of the binaries to Read-Only does indeed prevent them from being trashed.

The original (compressed) binaries do not exhibit this issue -- only the decompressed binaries self-destruct.

The version i tested/used was PKZip/PKUnzip 2.50 (03-01-1999). However, i abandoned PK many years ago in favor of the (freeware/open-source) Info-Zip alternatives -- newer and more capable. There are 16-bit and 32-bit DOS versions that have a much-greater memory capacity. And the syntax is easier, in my opinion.

PK Zippers self destruct

Because I am careful never give prams on I5
I am getting away with using it. I now run it via
batch that always provides dummy pram when needed.
And I used Norton to add an extra character to the
file names only available via ALT keypad sequence,
a Japanese YEN.

PK Zippers self destruct

And as I do with every DOS program I have
a batch that uncompresses and recompress
with 5 different compressers, well one
with three sets of options and two others
then I pick the smallest that still works
that still could be the original module.

PK Zippers self destruct

PK Zippers self destruct

> I'm not looking for a solution but> both the old PKZIP and PKUNZIP> programs at times self destruct on> my new I5 system.

> When this happens the size of the> program will be found to be 65535> bytes. Yep.

I don't have access to any of the "problem" CPUs to test my idea,
but as a 1st guess, I would suspect those modern Intel CPUs and supporting
chipsets dropped all support for legacy real-mode 'wrap at 1 Meg', A20-gate
etc, stuff - stuff on which a few DOS programs, /especially/ some packers-
unpackers have been known to rely. You could test my hypothesis by ensuring that DOS load the PK(UN)ZIP program ABOVE 64K. If your DOS version has
a "LOADFIX" command, use that - else you could have to stuff harmless TSRs
or resident data in sufficient quantity to pass above the 64k mark before
starting the PKZIP...

I realise you wrote you ain't looking for a solution, so that was just
my 2 cents of mostly useless advice. If you do the suggested test though,
please report whether loadfix or such seemed to fix the issue, or didn't.

EDITED to add : could also check whether the problem is solved by / sensitive to the / presence/absence of EMM386 (which emulates an A20-gate in software).

PK Zippers self destruct - NOT BUG it checks PSP for PK sig

> I'm not looking for a solution but> both the old PKZIP and PKUNZIP> programs at times self destruct on> my new I5 system.> > When this happens the size of the> program will be found to be 65535> bytes. Yep.

Yes still alive (just)... first post/login in a here in a very long time just to answer this question as I know the exact answer. Phil Katz implemented an anti-hack check to see if the PSP (Program Segment Prefix) contains his initials PK at an offset which his PKLite unpacker adds, if the initials are not present then in the case of PKZIP it runs a bit of code which grabs 64k of from memory which it then uses to overwrite over the top of the EXE before then cleanly exciting.
If I remember correctly Phil also un-readonly's a file as well. I did write my own code to counter this for other situations but if you use Ben Castricum's UNP ( http://unp.bencastricum.nl/ ) as follows: "unp -k+ pkunzip.exe" and "unp -k+ pkzip.exe" then the EXE's will be unpacked which might resolve any other issues and the PKLite fake signature code will be added which will fool Phil's overwriting code.

PK Zippers self destruct - NOT BUG it checks PSP for PK sig

> Phil Katz> implemented an anti-hack check to see if the PSP (Program Segment Prefix)> contains his initials PK at an offset which his PKLite unpacker adds,

Checking Ben's code and reminded myself of when I looked into this about 15 years ago. Phil's PKLite professional code adds PK into 5Ch+5Dh of the loading programs PSP. Those offsets are the first 2 bytes of of a 16 byte array used for Unopened Standard FCB 1. FCB (File Control Blocks) were a C/PM legacy which had already been superseded by file handles by the time PKLite came out.

So basically to stop the anti-hack self destruct code in PKUNZIP/PKZip for DOS you just need to make sure the PK signature is present in some way in the PSP at 5Ch+5Dh when they run. Ben's code -K+ code in http://unp.bencastricum.nl/ is the easiest way.