Multi-client support

[Xyene]

BnS Buddy (at least) implements multi-client support by adding Evengard's anti-GameGuard bypass into clients, since even though GameGuard is no longer being used, it still has the functionality of preventing clients from detecting each other. Evengard never shipped source, and I would like to not ship mystery binaries (or run them as admin myself, for that matter) if at all possible.

A quick analysis of the bnsnogg binaries show that it's a winmm.dll proxy generated through Dll_Wrapper_Gen. I expect the majority of the binary deals with spoofing GameGuard, but they mention IAT hooking in their thread so I suppose that's what's being employed here.

If I'm right, the functions being hooked are GetCurrentProcessId, CreateFileW, and CreateMutexW... I'm not immediately sure what GetCurrentProcessId would be useful for, but the CreateFileW hook I suspect is for redirecting config lookups to get past the launcher verification, which leaves CreateMutexW for bypassing the client check -- which makes sense, since named mutexes would be a good fit for this task.

So, I think that stripping the name from all mutexes as they're being created would prevent the clients from looking themselves up. Something like:

HANDLE WINAPI MyCreateMutex(
	_In_opt_ LPSECURITY_ATTRIBUTES lpMutexAttributes,
	_In_     BOOL                  bInitialOwner,
	_In_opt_ LPCTSTR               lpName
) {
	return CreateMutex(lpMutexAttributes, bInitialOwner, NULL);
}

However, a test using Dll_Wrapper_Gen proxying version.dll and the IAT patching from agent.c did not yield anything promising... the DLL got loaded, but received no CreateMutexW calls. Perhaps I'm doing something wrong.

[Xyene]

Mutex appears to be what's going on here. Client.exe creates a named mutex "BnSGameClient", and if you create with the same name before the client starts, the client refuses to continue.

from win32event import CreateMutex
CreateMutex(None, True, "BnSGameClient")

Closing this handle in Process Explorer allows a second instance of the game to get past the instance check and attempt to load, but it crashes with a dialog regarding corrupt game files, and prompts a reinstall. Using my 🔮 I guessed that the first client was keeping open handles to xml.dat/config.dat, and closed those handles too. The second game client loaded.

So, multi-client support boils down to making named mutexes where the name is "BnSGameClient" unnamed, and switching CreateFile's dwShareMode to FILE_SHARE_DELETE on xml.dat and config.dat.

This is kind of tricky, since it requires the 32-bit launcher agent to inject a potentially 64-bit client process... which can't work. I'm thinking a 64-bit helper inject.exe that takes an agent DLL path and an executable name / arguments and injects the target executable. Then a 32-bit agent DLL could be used to inject NCLauncherR.exe for verification bypassing, and 2 DLLs for Client.exe multiboxing (which would be injected by the NCLauncherR.exe agent.

In my current iteration of betterbns that I've been working privately on, the only thing I needed to hook was CreateMutexW and CreateFileW, they look like this:

HANDLE WINAPI BCH_CreateMutexW(LPSECURITY_ATTRIBUTES lpMutexAttributes,
        BOOL bInitialOwner,
        LPCWSTR lpName)
{
        return g_pfnCreateMutexW(lpMutexAttributes,
                bInitialOwner,
                (lpName && !wcscmp(lpName, L"BnSGameClient")) ? NULL : lpName);
}

HANDLE WINAPI BCH_CreateFileW(LPCWSTR lpFileName,
        DWORD dwDesiredAccess,
        DWORD dwShareMode,
        LPSECURITY_ATTRIBUTES lpSecurityAttributes,
        DWORD dwCreationDisposition,
        DWORD dwFlagsAndAttributes,
        HANDLE hTemplateFile)
{
        return g_pfnCreateFileW(lpFileName,
                dwDesiredAccess,
                dwShareMode ? dwShareMode : FILE_SHARE_READ,
                lpSecurityAttributes,
                dwCreationDisposition,
                dwFlagsAndAttributes,
                hTemplateFile);
}

IAT hooking doesn't work on the client in my experience though, because the exe is packed with Themida, so it resolves all of its imports at run time and are called through its VM. So you need to use an inline hooking library such as Detours or minhook to accomplish this.

I have other stuff I can share too btw, if you were interested in collaborating on this. I still have you on Steam or you can hop in my discord if that is more convenient. https://discord.gg/S894KAZ

[Xyene]

Haha, nice to see that we came to the same conclusion regarding the multiclient check. I didn't know that about Themida, but that would definitely explain why IAT redirects were mysteriously not working (actually I should probably have looked up what Themida really was when it blocked procmon :theenk:).

Probably minhook would be the easiest here, since the client is also 64-bit. I'll be joining your Discord 😄

[Xyene]

This is functional 👍