• Please review our updated Terms and Rules here

Decompression PKLite Executables

H

hackerb9

Experienced Member
Joined
Jul 14, 2015
Messages
74
Location
Earth, currently.
I was trying to disassemble a program (3C5X9CFG.EXE) that turned out to be compressed with PKlite. I couldn't find any generic program for such decompression, but I did find a project that had routines that worked for a couple program (Keen Dreams and The Elder Scrolls Arena). So, I wrote up a little command line wrapper for those routines to make it easier for anyone in the future who needs to do this for disassembling or just searching for strings.

https://github.com/hackerb9/depklite

Note that I didn't make it create a full DOS executable since I didn't need that. It just generates a file with all the decompressed data (plus some header garbage). You don't need to specify any arguments (other than the .EXE file). If you wish, you can also change the byte offset of where the compressed data is (if you don't want the header garbage) or try turning on decryption (if it all looks like garbage). I wrote it for GNU/Linux, but I expect it will work anywhere that has gcc.
 
Version 2 dates from 1992: Docs here Before that, PKLITE could do the job just as well, and that goes back to what, 1988? PKUNLITE was developed for those files with hacked headers.

Moral: Always check SIMTEL20 if you're looking for a DOS utility. Chances are that someone wrote just what you need 30 years ago. :)
 
like a billion pklite unpackers. i wrote several :) You also have to understand there are about 10+ official versions (registered, unregistered) then there are the 100 hacked versions of the pklite envelope. I believe the final versions are a bit different from early versions but all mostly the same.

also be aware some versions apply a marker in memory 'PK' at 0x5C when they decompress so internally the app knows if it has been bypassed (that was the theory, its basically useless).

(straight from the pklite docs)
Code: 
The extra compression option now writes the characters 'PK'
(50, 4B hex) into the psp at offset 5C hex. The user program
can check for this signature and abort if it isn't found. This
way the user program will not run if the PKLITE compression is
removed. This check may look something like the following in
Microsoft or Borland C:

if (*(unsigned int far *)MK_FP(_psp, 0x5C) != 0x4B50)
exit(1);
 
Thanks for all the helpful hints! It's interesting that I'm not the only one who didn't find any of these tools. This has lead to folks re-coding the wheel. In some ways they've done it better by creating reverse-engineered documentation that is easy to Google, but it's clear the old tools are much more capable.

Were there documents that went with any of these old programs that described the file formats? It'd be nice if there was a portable program that could do what they did. So far, the only one I've seen that even had source code was UNP. (And I'm not hopeful for the portability of the source code as the author of UNP states it's not supported as he can't compile it anymore).
 
To the best of my recollection, any file format documents were published separately. File formats changed often--I discovered that after coding my own LHA tiny expander. Did not work with later LHARC archives. Still, it was a pretty neat trick getting an expander into less than 4KB. One of the reasons that LHARC fell out of favor was that the algorithm for compression had been patented, but the patent not initially enforced--but then picked up by a third party of "sue 'em all" lawyers (champerty should be illegal).

Phil Katz ran into the same thing with SEA suing him for creating PKARC/PKXARC.
 
The patents should have expired by now (14 years, I think) but I bet the copyright would be enforceable (70 years after death of author).

I had thought the OpenTESArena project was being overly cautious by having a clean room approach to PKLite (the person who documents the format isn't the one who implements it). I guess I was wrong.

So, are there still people who know the old formats who can document them for others to implement?
 
Dunno--hasn't Phil Katz been gone since 2000 or so (reportedly the victim of Demon Rum)? Given that the zip format is available as open source in several Linux archivers, I don't see how the idea of clean room approaches would matter.
 
unp isnt portable. its all asm written in tasm, and compiles just fine. i dont know any runtime packer (lzexe,pklite,propak,etc) that document the data/fileformat (outside upx since it comes with source).
 
In the modern world of VMs, I'm not sure how important it is to know what the format is to expand it, since the expansion code is included. For .COM files, start decompressing in an emu and then set a stop condition when CS:IP = CS:0100 a second time, and you've just uncompressed any compressed .COM file (although the expanded .COM will always be 64K since you can't know what the size is from that operation).
 
Chuck(G) said:
Given that the zip format is available as open source in several Linux archivers, I don't see how the idea of clean room approaches would matter.
Click to expand...

I had thought PKLITE was different from PKZIP. No? I tried using an open source pkunzip on a .EXE I had and it didn't work.

Trixter said:
In the modern world of VMs, I'm not sure how important it is to know what the format is to expand it, since the expansion code is included. For .COM files, start decompressing in an emu and then set a stop condition when CS:IP = CS:0100 a second time, and you've just uncompressed any compressed .COM file (although the expanded .COM will always be 64K since you can't know what the size is from that operation).
Click to expand...

You are right, of course, it is not extremely important.

I mention it because it seems like at this point in time, while we have very little documentation, we might still have people with knowledge who could jot it down. Otherwise, future generations who are curious about these systems will have to either rely on VMs without understanding or rediscover what was previously known, as happened with the documentation of PKLITE 1.12 by dozayon.

Does it matter if this knowledge is lost and has to be rediscovered? Perhaps not. While I would love to see documentation for EXE compression like PKLITE, it's really a question for the people with the knowledge (if any are left) to decide.
 
You must log in or register to reply here.
Back
Top