LoadLibrary() fails - invalid PE header?

[Zapeth]

Hello, so before I begin to explain my problem I'd like to ask this question first:

Is there any way to figure out where/why exactly LoadLibrary() fails to load a dll?
I already read about "show loader snaps" (http://msdn.microsoft.com/en-us/library/windows/hardware/ff556886%28v=vs.85%29.aspx ) but that didn't really help much, I'm still clueless why he fails to load the dll.

Anyway, so the dll in question was actually originally encrypted and can be decrypted using the tool from here -> http://aluigi.altervista.org/papers.htm#hl (direkt link -> http://aluigi.altervista.org/papers/hldlldec.zip ) which also adds the PE header to the decrypted dll.

However the resulting PE information seems to be wrong since a LoadLibrary() call to the resulting dll fails (GetLastError returns 193, ERROR_BAD_EXE_FORMAT).

Though after looking at the values and addresses in the PE header myself I couldn't really spot any problems, thats why I was wondering if its possible to figure out what part of the library loading function causes this trouble.

The dll in question is the client.dll from Counter-Strike 1.5 which is for example publicly available here -> http://www.moddb.com/mods/counter-strike/downloads/counter-strike-15 (since you would have to extract it from the setup first I could also post a link to the original and decrypted dll here if needed)

[kbw]

That doesn't make much sense to me.

Compressing a DLL has nothing to do with PE Header damage/replacement,

[Computergeek01]

Anyway, so the dll in question was actually originally encrypted...

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 swear on my right arm that at least one of them has made whatever mistake you have made and that person knows precisely how to resolve it. Compression is what we call broken encryption algorithms.

[modoran]

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.

[Zapeth]

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.