|Compressing a DLL has nothing to do with PE Header damage/replacement, |
Well I'm not sure how to explain it since I don't know how the original encrypted dll gets loaded by the application.
The guy who wrote the decryption tool reverse engineered the process himself, but it was for a different "game" (Half-Life) so there might be a difference, its still the same "type" of dll though.
|I know that it feels like a brush off, but the most productive advice you will ever get is to go back to the distributor of the encryption algorithm.|
I'm not sure what you mean by "distributor of the encryption algorithm", if you are talking about the people who created the dll, thats a game company (Valve) so its very unlikely that they give out any information about that.
If you are talking about the guy who wrote the decryption tool, that might be worth a shot but it seems he is not active anymore so not sure if he can help me (I'll try to contact him anyway though).
|First try to load the DLL in depedency Walker or Dumpbin and see what happens.|
It could be a wrong manifest or a X86/X64 mismatch.
Dependency Walker seems to be able to load the dll, as well as dumpbin (not sure how I can tell for the latter though).
In case you want to investigate the dll yourself, I uploaded it here -> https://www.mediafire.com/?bq5o6ht57018aud
(vgui.dll is a dependency for the client.dll, the _orig one is the encrypted file and the other one the not-working decrypted dll).
I forgot to mention you can also take a look into the decryption tool's source code (which is included in the link I posted in the first post), the PE header gets assembled in there.
And if you don't think messing around with these dlls is a good idea to begin with, I'd at least like to know if there is a way to tell where or why LoadLibrary() fails to load the dll (for example if he expects there to be an additional section header or if some address points to an invalid location) since the pieces of the header I looked at seem fine to me.