I've spent a few days on my own trying to work out my problem by poking around with the search here and other places online, and I've come across a few people having the same issue as me but haven't come across any public solution. If I've missed something really dumb then don't be shy telling me. Also I'm new here and don't know if I'm posting in the right place etc. I'm more than happy to be schooled if I'm being a noob!!
I bought a DVD copy of Half-Life 2 the other day from a thrift store, as I was intrigued by the idea of having an early copy of the game physically in my collection. I knew the history of it being "the first game to require Steam" so I did a bit of Googling whilst I was in the store to see if it was possible to play the contents of the disc, and I bought it when I saw a few guides showing how to.
I managed to extract all my CABs and then from there the contents of all the various .gcf files into one folder. But no combination of launch arguments or Steam emulators seem to be able to get me past the error "Unable to load filesystem_stdio.dll". Troublingly, when browsing my bin directory in the folder holding all the extracted game files, there is no filesystem_stdio.dll to speak of. Neither is it there in any of the .gcf files when browsing them with GCFScape, leading me to ruminate on whether or not the build on my disc even came with all the files needed to run the game, or if some were destined to be delivered via Steam upon installation and setup.
It's worth noting that my disc is not the GOTY edition that the tutorial I was following was aimed at, but an earlier edition (all the CAB files on my disc are dated Oct 8th 2004, not sure what build that would make it)
I've tried this on both Windows XP and Windows 10. Same result - missing filesystem_stdio.dll - in both cases.
If there's any information I've left out, apologies & please let me know. š
After watching many YouTube videos about older computer hardware, YouTube began recommending videos about trains - are they trying to tell me something?
Actually i have iso of HL2 Collector edition, build 2153. This version doesnt requires connection to online servers. So after installing Steam client, it starts to install hl2. Tested on Windows XP many times. Works like charm.
Yup. Someone actually mentions my issue there, and another individual says that it may be to do with the game trying to load the file from a .gcf file and just to extract them all, which I already did.
The culprit .DLL is missing from both within the .gcf's and when they're all extracted too. That's why I'm worried my build is missing files that were meant to be retrieved from the Internet back in the day.
Also make sure you are using the correct switches as well as a the correct steam emu for the older ver of HL2 and OS. I use revemu for the older builds. <5153
It's worth noting that my disc is not the GOTY edition that the tutorial I was following was aimed at, but an earlier edition (all the CAB files on my disc are dated Oct 8th 2004, not sure what build that would make it)
I've tried this on both Windows XP and Windows 10. Same result - missing filesystem_stdio.dll - in both cases.
So I followed the instructions in the first post using my 2004 eur retail disc, but it turns out the gcf files are encrypted on this version. I had to use GCFExplorer instead to unpack the gcf files, each one requires entering the correct "Half-Life 2 GCF encryption key" before unpacking. Then as I'm on Win 98 I did need KernelEx to get revemu to work.
After posting this, out of interest I went out and bought a GOTY edition disc for a few pounds, and the files on that disc are indeed not encrypted, making it one less step to get going. I didn't want to download a GOTY or Collectors edition iso, as they had all seem to have been tampered with. The GOTY disc is dated 2005.
Attached is a photo of the disc boxes. Left is my Eur retail disc, original release. Files need to be unpacked and decrypted.
Right is the Eur retail GOTY edition disc. Files are unencrypted. Only unpacking is needed.
So my disk looks exactly like the one on the left (non-GOTY) but GCFscape can see all the files and extract them, doesn't ask me for an encryption key at any point.
PS: sorry for the delay and thanks for the responses all, been busy with Lifeā¢
Install like normal, then0 use the crack from the pirate version. That's what I do. Site rules don't allow to share it so you'll have to find it on your own.
I wasn't decrypting my GCFs, and I came to believe that I didn't need to, because GCFscape never asked for my decryption key which another poster led me to believe it would. As GCFscape never asked for any kind of key to extract my GCFs, I just assumed it was unnecessary. Until I opened some files that should have been plain-text readable and just found pure gibberish. One decryption session with hlunp.exe later and wouldn't you know, all my missing files/corrupt files issues I've had over the last few weeks mysteriously vanished. Apologies for wasting y'alls time, but thank you everyone for being so generous with it. š
Hi everyone! Now that I'm on holiday I've been looking into old Source Engine versions (I have the same retail DVD from October 2004 displayed by Spark a few posts above), and I remembered that hlunp.exe is known to have a bug that causes a small number of files to be incorrectly decrypted. Most of them are sounds, which are innocuous (just small popping noises), but others are models and scripts, that cause crashes on some places of the game.
This is a shame, cause hlunp.exe is a very nice command line tool that can be easily automated in scripts. The only other tool capable of decrypting GCFs that I'm aware of, GCFExplorer, is GUI only so it cannot be scripted.
So I decided to have a look at it, and after a while I found the cause of the issue and I managed to patch it. The patched executable is attached at the end of this post, just in case it is of someone's interest.
To find the issue, I firstly read some documentation on how the files are encrypted inside GCF files. The files can be stored in three ways:
In plaintext.
Encrypted with AES-128-CFB, in 32KB chunks.
Compressed with zlib deflate and then encrypted with AES-128-CFB, also in 32KB chunks.
Plaintext files and compressed + encrypted files are correctly extracted. The problematic files are the very few that are encrypted but no compressed. Comparing an incorrectly decrypted file by hlunp with the same file correctly decrypted by GCFExplorer instantly reveals the issue. Hlunp is decrypting the file as only one big block, but for getting the correct result it should be decrypted in 32KB chunks. The files generated by hlunp have the first 16 bytes of every 32KB chunk corrupted (except the first one), cause the incorrect IV is used for the first block of every chunk.
As there is no source code to work with, a bit of reverse engineering at assembly level is required. Using x64dbg I traced the code until I found a function with a loop that calculates the 16 bytes XOR for every CFB block, and then calls another function that encrypts the previous encrypted block using the specified key. When this function is called, the following can be observed:
The total size of the file in bytes is at ss:[esp+0x00].
The remaining number of bytes to decrypt is at ebp register.
At ss:[esp+0x6c] there is a pointer that points to a 16 bytes vector that contains the previous encrypted block, that is going to be encrypted by calling the function.
To fix the issue, for every 32768 processed bytes, the 16 bytes vector that contains the data to be encrypted by the function must be changed to all zeros (the correct value of the IV). To do this I made a code injection by modifying the call instruction to jump to an empty part of the executable. I placed the injected code at 0x400300, and it is the following:
It pushes the eax register to the stack, cause it is going to be used by this block. First the number of processed bytes is calculated by subtracting the total size of the file and the remaining bytes. Then, the modulo between this number and 32768 is calculated (as this number is a power of two it can be calculated just with an AND instruction). If the modulo is zero then the mentioned 16 bytes vector is cleared. Finally the eax register is restored and the code jumps to the real address of the function.
I compared all the files extracted from the DVD (Spanish version) with this patched hlunp and with GCFExplorer, and they are all identical. With the original bugged hlunp there were 71 corrupted files.
UPDATE: I also patched a bug that prevents the program to extract directories that contains invalid characters in the name (some GCFs have directories inside the reslists folder that contains ":" character). Now the invalid characters are removed from the name before the directory is created, like others programs as GCFScape or GCFExplorer do.
