XP/FLHook/GetFLName Problems

Cannon

We’ve run into a problem while reinstalling FLHook-Plugin 1.5.9 onto a XP Pro SP3 machine. I’ve also replicated the same problem on a second machine.

The problem is that any hook command that accesses HkGetCharFileName or HkGetAccountDirName fails with “Unknown Error”.

I’ve checked a few things and found that the call to GetFLName returns 0 on the problematic machines - on working machines it returns some sort of non-zero number.

Here’s where the function is called.

HK_ERROR HkGetCharFileName(wstring wscCharname, wstring &wscFilename)
....
	_GetFLName GetFLName = (_GetFLName)((char*)hModServer + 0x66370);
	char szBuf[1024] = "";
	if(!GetFLName(szBuf, wscCharname.c_str()))
		return HKE_UNKNOWN_ERROR;
....

On inspection GetFLName always returns a valid account name/charfile name in the szBuf - even when the return code from the function is 0.

I patched FLHook to ignore the return code then everything seems to work okay but I really need to understand what the real problem is.

We have installed other XP machines without this problem so I feel like this is a dll/library or installation issue.

Have done a few other things:

Clean FL installation.
Removed all plugins.
Checked file permissions.
Rebooted machine (a few times!)
Moved stuff randomly (desperation)
Checked every log file could think of - nothing interesting found

Has anybody run into this sort of problem before? any suggestions on how to fix it?

EDIT: Updated to reflect majkp’s post & this poster had the same problem
http://flhook.drachennest200x.de/forum/viewtopic.php?p=1097&highlight=&sid=472f35a4edb1d434dc91becbe62cd743#1097

majkp

Just a small update, it’s not Server2003 but Windows XP Professional 32bit with SP3.

We also have a beta-testing server which runs with XP Pro SP2 and it works there.

From this point of view it might be related to the XP3.

EDIT: Not related to SP3, runs fine on another PC with SP3.

w0dk4

I once had the same problem I think, not sure… but cannot remember the solution.

1.1 patch is installed?

How does server.dll look like around
0x66370
?

Cannon

Yeah, I’ve got 1.1 installed.

I’ve spent a little bit of time poking around 0x66370 (0x6d46370 in server.dll disassembly). This function is more or less composed of the following steps:

1. Take the provided wszID duplicate it using wcsdup and convert it to lower case sing wcslwr
2. Hash the ID into a filename/dirname, using lots of bit shifting and rotating and stuff.
3. Copy of the hash into the buffer szBuf using sprintf
4. Release the memory allocated by wcsdup by calling __imp_free()

The function prototype in hook indicates that the function returns an int; the IDA disassembly indicates the same thing.

int __cdecl GetFLName(char *szBuf, const wchar_t *wszID);

The FLHook code expects the return code in eax, but as far as I can tell the GetFLName function is not explicitly setting eax, instead eax is changed as a side effect of calling __imp_free(). I’m guessing that depending on the particular msvcrt library version you are linking to, the __imp_free() behaviour will vary. On most systems eax gets a non-zero number and HkGetCharFileName works…on some it doesn’t.

To save you looking it up, here’s the last few lines of the GetFLName() function…

.text:06D464CD         mov   edx, [esp+14h+arg_0]
.text:06D464D1         push  edi
.text:06D464D2         push  ecx
.text:06D464D3         push  offset a02x08x ; "%02x-%08x"
.text:06D464D8         push  edx       ; char *
.text:06D464D9         call  ds:sprintf
.text:06D464DF         push  ebp       ; void *
.text:06D464E0         call  ds:__imp_free ; <---- I muck up eax
.text:06D464E6         add   esp, 14h
.text:06D464E9         pop   edi
.text:06D464EA         pop   esi
.text:06D464EB         pop   ebp
.text:06D464EC         pop   ebx
.text:06D464ED         pop   ecx
.text:06D464EE         retn

Does this look possible or am I completely wrong. Any thoughts appreciated…

I haven’t checked msvcrt library versioning yet (not really sure how to do this but will figure it out)

w0dk4

When you made the post I looked it up myself and came to the same conclusion.
But this really bugs me because I thought I had the same problem once but back then it was some stupid mistake, like not having installed 1.1 (thus the code at position 0x66370 of server.dll was something completely different)

Anyways, Im just trying to understand why exactly horst relied on the return value… because it doesnt make any sense.
Other functions that call this function do not rely on eax either, so I think its safe to ignore it.

Will change it in the next version.

w0dk4

I forgot to include it in the changelog, but this is fixed in the 1.6.0 version (fixed == ignoring returnvalue)