AlliedModders - Unrecognized library "libtier0"

AlliedModders (https://forums.alliedmods.net/index.php)

- Coding MM:S Plugins & SM Extensions (https://forums.alliedmods.net/forumdisplay.php?f=75)

- - Unrecognized library "libtier0" (https://forums.alliedmods.net/showthread.php?t=293320)

Unrecognized library "libtier0"

Quote:

"Games"
{
"cstrike"
{
"Signatures"
{
"SpewMessage"
{
"library" "libtier0"
"windows" "\x55\x8B\xEC\x83\xE4\xF8\x83\xEC\x14\x8B\x45 \x08\x53\x56\x57\x8B\xF9"
"linux" "@_ZL12_SpewMessage10SpewType_tPKciPK5ColorS1 _Pc"
"mac" "@_ZL12_SpewMessage10SpewType_tPKciPK5ColorS1 _Pc"
}
}
}
}

When i'm trying to detour this function I get this error:

Quote:

L 01/29/2017 - 14:04:51: [SM] Unrecognized library "libtier0" (gameconf "/home/servers/testlab/cstrike/addons/sourcemod/gamedata/cleaner.games.txt")
Segmentation fault (core dumped)

though there is a library: "bin/libtier0_srv.so"

Re: Unrecognized library "libtier0"

The only supported library values for SM gamedata are "engine" and "server".

Re: Unrecognized library "libtier0"

Have a look here for a solution using the "keys" section in the gamedata and SM's IMemoryUtils interface:

PHP Code:


		
			
void *GetAddressFromKeyValues(void *pBaseAddr, IGameConfig *pGameConfig, const char *key)
{
    const char *value = pGameConfig->GetKeyValue(key);
    if (!value)
        return nullptr;

    // Got a symbol here.
    if (value[0] == '@')
        return memutils->ResolveSymbol(pBaseAddr, &value[1]);

    // Convert hex signature to byte pattern
    unsigned char signature[200];
    size_t real_bytes = UTIL_DecodeHexString(signature, sizeof(signature), value);
    if (real_bytes < 1)
        return nullptr;

#ifdef _LINUX
    // The pointer returned by dlopen is not inside the loaded librarys memory region.
    struct link_map *dlmap = (struct link_map *)pBaseAddr;
    pBaseAddr = (void *)dlmap->l_addr;
#endif

    // Find that pattern in the pointed module.
    return memutils->FindPattern(pBaseAddr, (char *)signature, real_bytes);
}

I added

PHP Code:


		
			
// Keyvalues in gamedata aren't specific to the platform, so we have to distinguish manually.
#ifdef WIN32
# define KEY_SUFFIX "_win"
#else
# define KEY_SUFFIX "_lin"
#endif

to differ between windows and linux gamedata, since the "keys" section doesn't support differentiation there.
You have to open the library you want to hook yourself and get the address using that handle.

PHP Code:


		
			
void *receiveTabAddr = GetAddressFromKeyValues(hDedicated, pGameConfig, "CTextConsole::ReceiveTab" KEY_SUFFIX);

In the keys section you then have somthing like

Code:

    "left4dead2"

    {

        "Keys"

        {

            // Windows

            "CTextConsole::ReceiveTab_win"    "\x55\x8B\xEC\x83\xEC\x18\xA1\x2A\x2A\x2A\x2A\x33\xC5"

            

            // Linux

            "CTextConsole::ReceiveTab_lin"    "@_ZN12CTextConsole10ReceiveTabEv"

        }

}

Re: Unrecognized library "libtier0"

Quote:

Originally Posted by psychonic (Post 2490818)

The only supported library values for SM gamedata are "engine" and "server".

I recently hit that limitation too. Can you explain why only engine and server are allowed? Why don't make it like "free text" and search for the module name inside the srcds process?

Re: Unrecognized library "libtier0"

Quote:

Originally Posted by Chrisber (Post 2491560)

I recently hit that limitation too. Can you explain why only engine and server are allowed? Why don't make it like "free text" and search for the module name inside the srcds process?

I don't know if there's any specific reason that it's like that. The code predates my involvement with SM.

Re: Unrecognized library "libtier0"

Quote:

Originally Posted by psychonic (Post 2491562)

I don't know if there's any specific reason that it's like that. The code predates my involvement with SM.

I think it's because the module names aren't stable, and we translate in core anyways.

Re: Unrecognized library "libtier0"

Quote:

Originally Posted by KyleS (Post 2491570)

I think it's because the module names aren't stable, and we translate in core anyways.

That makes sense. Even back there, then was server, server_i486, server_i686, etc.

We could probably either normalize the common patterns, or just manually add support for all of the common engine bins.