Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache copy of library on first symbol/signature lookup #1642

Merged
merged 1 commit into from
Nov 18, 2021

Conversation

peace-maker
Copy link
Member

Always perform signature searches on an unaltered copy of the binary. This avoids signature mismatches if the same function is detoured twice and thus the first bytes of the function were replaced by the detour. It is implemented by creating a copy of the current (hopefully unaltered) state of the library on first symbol or signature lookup through IMemoryUtils and using that copy to find matching signatures.

Now you're able to find signatures even if something else already messed with the bytes. Before this patch, code like this would fail to locate the signature again after the memory was altered (assuming both gamedata files are identical).

public void OnPluginStart() {
    GameData gd = new GameData("test1.games");
    Address testfunc = gd.GetMemSig("testfunc");
    PrintToServer("Found sig: %x", testfunc);
    delete gd;

    StoreToAddress(testfunc, 0xff, NumberType_Int32);

    gd = new GameData("test2.games");
    testfunc = gd.GetMemSig("testfunc");
    PrintToServer("Found sig again: %x", testfunc);
    delete gd;
}

So it's not necessary to wildcard the first 6 bytes of a signature to still find it even if the function was detoured by something else. This is only true for SourceMod and its extensions or rather anything using the IMemoryUtils to find a signature in memory. It'd be desired to have such an interface exposed in MetaMod:Source for all other server plugins to use in the future.

Always perform signature searches on an unaltered copy of the binary. This avoids signature mismatches if the same function is detoured twice and thus the first bytes of the function were replaced by the detour.
Copy link
Member

@asherkin asherkin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dragokas
Copy link
Contributor

dragokas commented Nov 18, 2021

This is the genial and demanded thing.

Cache copy of library on first symbol/signature lookup

When does the first symbol/signature lookup happens by default (except GetMemSig e.t.c.)?

I mean, if e.g. I manually detour some function (not via dhooks) from the plugin context, does the most common libs like server/engine had already been precached?

@dragokas
Copy link
Contributor

Ok, I see. It only preserves a single symbol by FindPattern request.

@peace-maker
Copy link
Member Author

The current state of the whole library in memory will be preserved whenever the first call to IMemoryUtils::FindPattern or IMemoryUtils::ResolveSymbol happens on it. If there were other modifications on the library beforehand where the address wasn't looked up through one of the two functions that modification is preserved as well, but that only applies to other metamod plugins or Valve Server Plugins not using IMemoryUtils.

So this isn't linked to dhooks at all, but only to the address lookup process. You can assume that SourceMod itself already performed some lookup and triggered the caching before the first sourcepawn plugin code runs, yes.

@peace-maker peace-maker merged commit 1c30b88 into master Nov 18, 2021
@peace-maker peace-maker deleted the sigscan_cache branch November 18, 2021 16:55
dvander pushed a commit that referenced this pull request Dec 10, 2021
Always perform signature searches on an unaltered copy of the binary. This avoids signature mismatches if the same function is detoured twice and thus the first bytes of the function were replaced by the detour.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants