how to getasynkkeystate with pcileech on windows 11?

[ufrisk]

Microsoft have changed how the gafAsyncKeyState works on the most recent Windows 11 22H2.

I haven't looked into how it's done now. I've kinda been hoping someone else would reverse how it's working now since I've been quite busy. I see that the export itself is gone from win32kbase.sys though and that it's been replaced with some C++ mangled name ?gafAsyncKeyState@@3V?$SGDKEYBOARDgafAsyncKeyState@PEAE@@A. But it's probably not the same.

Also there is another export _GetAsyncKeyState that looks interesting, but it's probably a function.

But as I mentioned I haven't looked into this. Please let me know if you should solve it somehow.

[fortnitebott]

I found it:

win32ksdg.sys!gSessionGlobalSlots

UINT64 Session1_UserSessionState = Read(Read(Read(gSessionGlobalSlots)));

UINT64 gafAsyncKeyState = Session1_UserSessionState + 0x3690;

but how to get and read this with pcileech?

[ufrisk]

This would require you to have the the DLLs for microsoft debug symbols alongside vmm.dll. dbghelp.dll and symsrv.dll.

ULONG64 va_win32ksdg = 0xfff...;
ULONG64 va_gSessionGlobalSlots = 0;
CHAR szModuleName[MAX_PATH] = { 0 };
BOOL fLoadOK = VMMDLL_PdbLoad(hVMM, 4, va_win32ksdg, szModuleName);
BOOL fSymbolOK = VMMDLL_PdbSymbolAddress(hVMM, szModuleName, "gSessionGlobalSlots", &va_gSessionGlobalSlots );

I'm not completely sure PID 4 will work all the way though, it may be that you'd need to use a CSRSS PID instead.

I should add an example about how to use the debug symbols.

Please let me know how it goes.

[ufrisk]

And it looks like quite a convoluted way of doing it, but if it works it's all ok I guess.

If I follow the pointers (I might have missed something) in your example I see that the Session1_UserSessionState points to a big pool allocation with pool header 'Sgaa'. If this is correct it might be easier to retrieve it that way. I have two on my test system so it's probably correct that it's the UserSessionState.

[fortnitebott]

[ufrisk]

is fLoadOK TRUE (i.e. did the load succeed or not)?

for extra debug info add startup-parameters "-loglevel", "symbol:7" when initializing vmm.dll.

you would need to have the supporting dll files dbghelp.dll and symsrv.dll in the same folder as vmm.dll, also you'd need to answer YES to the Microsoft popup question the first time (or place an empty file named symsrv.yes to accept their eula) in the vmm.dll folder also. Also this requires the PC to have an internet connection the first time so it's able to download the symbols from microsoft.

or if you're on Linux this will be a bit different with regards to the dll files, but it should still work.

[fortnitebott]

[ufrisk]

There is something not working with the debug symbol load. Does it print any on the console if you add the startup-parameters: "-printf", "-loglevel", "symbol:7"

---

An alternative that may be easier in your case would be to follow the example for the pool map:

https://github.com/ufrisk/MemProcFS/blob/4c5626a6939a6d868db9b69f346f0b9fd42bba11/vmm_example/vmmdll_example.c#L1265

Just search for pool header: Sgaa instead of pool header: TcpE in the example. In my win11 test machine there seems to be two Sgaa objects in the big pool (probably one per session) this would correspond with your large memory allocation where you use the offset in.

[fortnitebott]

I use startup-parameters. They don't write anything to the console. Can you send pool map code for this?

[ufrisk]

You may also try "-loglevel", "f:symbol:7", "-logfile", "c:\temp\logfile_symbol.txt" this should print some info to the log file. Note that you may have to call VMMDLL_Close(hVMM); to flush the file to disk.

About the pool example, just copy the example code I have in the example project and change 0x45706354 (i.e. TcpE) to 0x61616753 (Sgaa). In my test I got two hits.

[ufrisk]

How did it go with this issue, did you have any success?

[ufrisk]

Since I haven't gotten any answers I'm assuming this issue was resolved so I'm closing the issue. If it's not resolved let me know.