I am creating a 3d-map for a game (namely: Counterstrike) and I have developed an app that encrypts it with AES. (I want to protect it from outsiders)
The problem is that this game cannot read encrypted maps so I wonder if I could hook the CreateFile function in the game and replace it with a function that would decrypt the encrypted map into memory and let the game load it from there.
It sounds complicated for me, do you think it would be difficult?
I created first a launcher that takes the encryted map file from disk, decrypts it and stores it in the harddisk (unencrypted!) so that the game can load it but it can still be easily obtained by somebody without advanced knowledge.
I know that by loading the encrypted file from disk into memory and decrypting it from there is not a memory-dumper-proof option but it will at least harden attempts to get the map.
Thanks in advance, this is my first post in here and I hope I can help many of you in this wonderful community.
More information: (not required for answer this post but in case you are interested...)
If a friend of mine wants this map, he would have to let me use his computer and execute a program that would retrieve his computer MAC, harddisk ID, etc and would create a sha256 hash of this.
I will give the AES function this HASH as the key to encrypt a unique encrpyed-Map for him in my house. Then I will give my friend the program I want to create + the unique encrypted map.
If my friend gives the map to a third party, this person will not be able to use the map at all because the Hash created by my application would be different than the one required to decrypt it properly.
Thanks a lot, BobS0327. I did a new research based on your answer. I've found that the zwCreateFile is automatically called by the CreateFile function and thus controlling the zwCreateFile seems to be a good way.
I've been monitoring the Half-Life game engine (hl.exe) as it loads the map.
Now I am 100% sure it uses the CreateFile() but the problem is that this function only returns a handle and does not return the content of the file in a variable for the function that calls/invokes it (as I thought.. silly me...)
Also, based on what I read in MSDN:
You cannot use CreateFile to control compression, decompression, or decryption on a file or directory. For more information, see Creating and Opening Files, File Compression and Decompression, and File Encryption.
Now I have to research about these troublesome handles, I am more familiar with pointers than with this.
I am thinking of a DLL that would load the encrypted map, decrypt it and, after it returns a new handle, it will replace (by hooking and patching the IAT of hl.exe) the handle that the game tries to load first with the new one that would point to the decrypted data.
Last edited by sonnyk88; January 18th, 2010 at 02:05 PM.
Silly me, It's not the CreateFile() what I must hook, I must hook ReadFile() which uses the handle returned by CreateFile() to work...
Down here, there's a simple Function which uses CreateFile to find an existing file on disk and returns a handle (hFile). Later this hFile is used by ReadFile() which loads the contents of the selected file in pszFileText. I believe this resembles the functions in Half-Life game (hl.exe).
In this case, I should hook the ReadFile() and make it return a LPSTR which would contain the decrypted data of my map...
You can also do it completely in user mode and only in the process you want.
You can inject the process with a self written dll using the CreateRemoteThread functionality.
Then you can hook the Readfile function with a self written Readfile function by overwriting the jmp address of the readfile function.