DOS ain't dead

Guti

31.08.2016, 08:23

@ w3a537

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

---
Visit my personal blog at https://www.javiergutierrezchamorro.com

w3a537 Colorado Springs CO USA, 31.08.2016, 20:26 @ Guti	PK Zippers self destruct Post reply
	I am running plain vanilla MSDOS 710. Not malware. Just old software. Funny bug. W3

RayeR

CZ,
02.09.2016, 11:51

@ w3a537

PK Zippers self destruct

Post reply

Do you get any other files corrupted?

---
DOS gives me freedom to unlimited HW access.

w3a537 Colorado Springs CO USA, 03.09.2016, 03:20 @ RayeR	PK Zippers self destruct Post reply
	> Do you get any other files corrupted? None at all Just PKZIP and PKUNZIP. Both self destruct in exactly the same manner in MSDOS 710. But I dealt with it in autoexec.bat Might have to do with the I series processer Doesn't happen on an AMD

w3a537 Colorado Springs CO USA, 03.09.2016, 03:23 @ w3a537	PK Zippers self destruct Post reply
	And it does not happen to them from something else It happens WHEN I RUN THEM but not always.

RayeR

CZ,
03.09.2016, 03:31

@ w3a537

PK Zippers self destruct

Post reply

Strange bug... And did you try to set read-only attibute to it's executable? Sometimes it may prevent overwrite but DOS is not secure as unix/linux where attributes are taken seriously...

---
DOS gives me freedom to unlimited HW access.

Laaca

Czech republic,
03.09.2016, 20:41

@ w3a537

PK Zippers self destruct

Post reply

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 ?

---
DOS-u-akbar!

Rugxulo

Usono,
04.09.2016, 00:56

@ w3a537

PK Zippers self destruct

Post reply

> 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).

tom Germany (West), 03.09.2016, 09:29 @ w3a537	PK Zippers self destruct Post reply
	> 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.

Brian_extended

03.09.2016, 16:41

@ tom

PK Zippers self destruct

Post reply

> > 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?

tom Germany (West), 03.09.2016, 19:21 @ Brian_extended	PK Zippers self destruct Post reply
	> I thought the OP posted how he fixed the problem in Autoexec.bat in his > first post. Did I misread it? my fault, sorry. I referred only to the latest one, and overlooked that thhis trick was mentioned in nthe original post.

Doug

09.09.2016, 06:46

@ w3a537

PK Zippers self destruct

Post reply

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.

- Doug B.

w3a537

Colorado Springs CO USA,
09.09.2016, 07:33

@ Doug

PK Zippers self destruct

Post reply

Precise match with one note
and two exceptions.

It does not bomb if you give it parameters.

It only bombs for me on my I5, not AMD, or Centrino.

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.

I use it because it is small.
How old is it anyway?

C1

w3a537 Colorado Springs CO USA, 09.09.2016, 07:38 @ w3a537	PK Zippers self destruct Post reply
	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. W3

RayeR

CZ,
10.09.2016, 10:37

@ w3a537

PK Zippers self destruct

Post reply

Just try to set read-ony attribute to the executable for completness...

---
DOS gives me freedom to unlimited HW access.

Ninho

10.09.2016, 10:40

@ w3a537

PK Zippers self destruct

Post reply

> 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).

---
Ninho

Arjay

20.09.2016, 19:15

@ w3a537

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

Post reply

> 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.

Arjay

20.09.2016, 19:28

@ Arjay

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

Post reply

> 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.

w3a537 Colorado Springs CO USA, 31.08.2016, 06:23	PK Zippers self destruct (Announce) Post reply
	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 (Announce)

PK Zippers self destruct

PK Zippers self destruct

PK Zippers self destruct

PK Zippers self destruct

PK Zippers self destruct

PK Zippers self destruct

PK Zippers self destruct

PK Zippers self destruct

PK Zippers self destruct

PK Zippers self destruct

PK Zippers self destruct

PK Zippers self destruct

PK Zippers self destruct

PK Zippers self destruct

PK Zippers self destruct

PK Zippers self destruct

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

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