I'm not saying you're wrong, just that it's not what you seem to think it is. GameOverlayRenderer.dll hooks LoadLibraryA in a process so it can monitor when D3D/OGL get loaded (has done this for a long time!), the PB stuff is for compatibility (if PB is loaded, it sets a special flag). SetLastError is so it can restore the error code that the real LoadLibraryA set. This appears to be a genuine crash in GameOverlayRenderer, as I said, because it's passing off an invalid pointer to stricmp.
I speak as someone who has previously RE'd GameOverlayRenderer to debug a crash due to race condition with nVidia drivers and OpenGameBroadcaster, I don't see anything outwardly strange here.
[Edited by gibbed, 7/9/2013 6:39:05 PM]
this assessment may be the closest to the cause of the issue. No idea what the actual valve coding error is/was, but it seemed to not like trainers, memory searchers, or just about ANY .dll being injected into the game process..
thanks again gibbed..
btw, similar technique is used by multiplayer trainers to use d3d to do their dirty work.
I was not aware that software routinely hooks system api's. keep in mind that our trainers (ironically) we try desperately not to manipulate anything other than the game code, and will avoid that too if possible.
we won't be messing around with any steam .dll's. our solution was to remove the hook to the kernel32.dll api that steam created to begin with. likely this won't be necessary as valve themselves acknowledged a bug with unintended consequences and this will be fixed by steam soon.
best,
Cal
[Edited by Caliber, 7/9/2013 7:32:17 PM]
Okay, I need to retract my earlier suggestion, and explain what the crash is being caused by. It's a legitimate bug in GameOverlayRenderer and nothing to do with anti-cheat.
Whenever LoadLibraryA is called, GameOverlayRenderer does something like this:
HMODULE WINAPI LoadLibraryAHook(LPCSTR lpFileName)
{
if (strlen( lpFileName ) <= 9 || stricmp( &lpFileName[lengthOfSteamDLL - 10], "steam.dll" ))
{
...
lengthOfSteamDLL is 9. See the bug?
Hint: Spoiler:
we allocate extra byte already..
Size = Len(DllFileName$)+1
derp!
best,
Cal
Okay, I need to retract my earlier suggestion, and explain what the crash is being caused by. It's a legitimate bug in GameOverlayRenderer and nothing to do with anti-cheat.
Whenever LoadLibraryA is called, GameOverlayRenderer does something like this:
HMODULE WINAPI LoadLibraryAHook(LPCSTR lpFileName)
{
if (strlen( lpFileName ) <= 9 || stricmp( &lpFileName[lengthOfSteamDLL - 10], "steam.dll" ))
{
...
lengthOfSteamDLL is 9. See the bug?
Hint: Spoiler:
we allocate extra byte already..
Size = Len(DllFileName$)+1
derp!
best,
Cal
That looks like an extra byte for the trailing NULL in the string? What I was suggesting was adding an extra byte on top of that and writing your path and then passing allocated_memory+1 rather than allocated_memory+0 to your RemoteLoadLibraryA(). The crash occurs because it tries to pass &DllFileName[-1] to stricmp, which is not always a valid memory address.
Likely this bug will be fixed in the next Steam update that pushes a new GameOverlayRenderer build, so you can probably just bide your time and ignore this problem until it is.
[Edited by gibbed, 7/9/2013 7:41:00 PM]