Well, if you're interested...
As a hacker, I like looking into files in general. It was nothing serious to find out that those PAK files are actually ZIP archives. When I wanted to see what's inside, I got the dialog box, asking for the password... DAMN!
A few minutes later, it became apparent that the complete Info-ZIP (
http://www.info-zip.org ) code for 32-bit Windows is compiled into the EXE as there are strings which make no sense in the game: e.g. "Password incorrect--reenter:" is what Info-unZIP, a console program to be run in a DOS box, prints when the previously typed password proves to be incorrect.
Yes, my first try was looking in the EXE, trying to find "strange" strings. However, this is a Russian game so I expected the authors to be smart enough to know some hacker tricks and NOT leave the password unencrypted.

Also, the password may be expected to be long and/or complicated enough so that Advanced Archive/ZIP Password Recovery wouldn't find it (in this millennium

).
I easily found the place where the string mentioned above is used. The check for the validity of the password, thus a _use_ of the password, must be very near. After some trial & error and comparison of the code with that of the original Info-unZIP program, I thought I found which "variable" (read: memory area; there are no variables as such in a machine code executable!) is supposed to hold the password. (It can be expected that the password is passed unencrypted from the game itself to the unzip component.) I couldn't debug the program because, as far as I remember, loading it into W32DASM made it crash long before any access to the PAK files.
So, I had to find a way to have the password printed somewhere. As I can't add even as few functionality as a message box to the program easily, because of the lack of space _and_ the lack of Windows API knowledge,

I voted for generating a General Protection Fault on purpose.

Then there's an error message displayed in a dialog box by the game (not Windows!), as I already found out. I changed the exception handler to display a string from a different memory location than the original "Stack Frame:" string. (The "Stack Frame:" string is in a read-only data segment, trying to overwrite it caused a GPF _before_ anything useful could be done...)
Then I changed the unzip code to place the first four bytes (a double word) of the password to that memory location and then try to read from memory location 0xFFFFFFFF (no segment is supposed to be 4 Gigs long

). I got the program crashed and display an error message with some garbage. Again, after some trial & error, I managed to make it display four English letters. Hmmm! Then I changed the unzip code to have the second four characters displayed. That was again four letters. Then I knew I was in the right direction...
A small intellectual satisfaction for the day!
Joe