Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the board
Thread view  Mix view  Order
w3a537(R)

E-mail

Colorado Springs CO USA,
31.08.2016, 06:23
 

PK Zippers self destruct (Announce)

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

Guti(R)

Homepage

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 http://www.javiergutierrezchamorro.com

w3a537(R)

E-mail

Colorado Springs CO USA,
31.08.2016, 20:26

@ Guti

PK Zippers self destruct

I am running plain vanilla MSDOS 710.

Not malware.

Just old software.

Funny bug.

W3

RayeR(R)

Homepage

CZ,
02.09.2016, 11:51

@ w3a537

PK Zippers self destruct

Do you get any other files corrupted?

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

w3a537(R)

E-mail

Colorado Springs CO USA,
03.09.2016, 03:20

@ RayeR

PK Zippers self destruct

> 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(R)

E-mail

Colorado Springs CO USA,
03.09.2016, 03:23

@ w3a537

PK Zippers self destruct

And it does not happen to them from something else

It happens WHEN I RUN THEM but not always.

RayeR(R)

Homepage

CZ,
03.09.2016, 03:31

@ w3a537

PK Zippers self destruct

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.

tom(R)

Homepage

Germany,
03.09.2016, 09:29

@ w3a537

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.

Brian_extended(R)

03.09.2016, 16:41

@ tom

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?

tom(R)

Homepage

Germany,
03.09.2016, 19:21

@ Brian_extended

PK Zippers self destruct

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

Laaca(R)

Homepage

Czech republic,
03.09.2016, 20:41

@ w3a537

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 ?

---
DOS-u-akbar!

Rugxulo(R)

Homepage

Usono,
04.09.2016, 00:56

@ w3a537

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

Doug(R)

E-mail

09.09.2016, 06:46

@ w3a537

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.

- Doug B.

w3a537(R)

E-mail

Colorado Springs CO USA,
09.09.2016, 07:33

@ Doug

PK Zippers self destruct

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(R)

E-mail

Colorado Springs CO USA,
09.09.2016, 07:38

@ w3a537

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.

W3

RayeR(R)

Homepage

CZ,
10.09.2016, 10:37

@ w3a537

PK Zippers self destruct

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

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

Ninho(R)

E-mail

10.09.2016, 10:40

@ w3a537

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

---
Ninho

Arjay(R)

20.09.2016, 19:15

@ w3a537

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.

Arjay(R)

20.09.2016, 19:28

@ Arjay

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.

Back to the board
Thread view  Mix view  Order
15111 Postings in 1359 Threads, 247 registered users, 14 users online (0 registered, 14 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum