HFS files, I have the asm

Here's the asm that supposedly decompresses shit from the HFS

ASM (NASM) | sub_1001F440 proc near ; CODE XRE

I'm not familiar with zlib at all, and I only know a little asm, so could someone lend a hand?

That function simply inflates a buffer with zlib calls, you need to go up a couple calls, and you'll find the actual algorithm.

I'll save you the trouble and post my work:
- HFS files are a modified ZIP format
- the contents are compressed when the file name has ".comp" as the extension
- in most of the archives, there is a simple XOR obfuscation applied to the name/data (although the xor table is large and somewhat obfuscated in memory)
- in a recent patch they added a 4 byte xor to some files (EndOfCentralDirectory.CentralDirOffset * EndOfCentralDirectory.CentralDirSize)

There is however a 4 byte checksum (likely CRC32) on the extra obfuscated files, but I can't figure out how it's used, and so I can't completely repack the extra obfuscated archives.

Have you tried loading FileSystem_stdio.dll and using functions from it?

The CreateInterface func inside it returns a pointer to a instance of the IFileSystem class, when I tried mine, I was using source 2007, instad of 2006, and am too lazy to correct my error right now. I'm pretty sure it loads the hfs files by defining them as a search path

Edit: oh, do you have a unpacked filesystem_stdio that I could use, the unpacking tutorial I got unpacked the code, but didn't give me a usable dll.

Edit: about that 4-byte checksum, ida FindCrypt v2 only showed SHA-1 consts in filesystem, but there are CRC32 consts in engine.dll

Edit: Whoa, you joined just to post that?

I don't have a proper unpacked version of the DLL, not that it would be much use. The IFileSystem pointer mostly matches what's in the 2006 SDK, except there are a couple changes to the ISteamFileSystem vtable, or whatever it's called. I don't remember the exact offsets, but they use the AllocOptimalReadBuffer and friends functions.

Thanks for the hint about SHA-1, it seem rather unlikely, but it's worth a shot.

the addr of the SHA-1 consts in my dll were: 10022FBE and 10023016

Edit: oh and, does AzuiSIeet == AzuiSLeet?

Edit: the use of the unpacked dll would being able to hit F9/F10/F11 in VS2010 instead of adding a bunch of debug outputs and running it directly

no outside links... unless it was approved b a mod

HFS files, I have the asm

Post a Reply

Tags for this Thread