Today we will focus on mapping the functions found. They all reside in the AudioSes.dll, so this will be our primary target.
Interfaces and IAT
The problem with the IAudioClient and IAudioRenderClient interfaces is, like with all other interfaces, they don’t have their functions exported in the DLL, but are called using their VTables. So you don’t get their functions mapped nicely into your IAT, but have to dig a little deeper. If you are unfamilar with VTables and/or IAT, I suggest you to at least look up the Virtual function tables concept before contiuning to read. I will briefly explain it though.
Virtual functions tables in MSVC
In MSVC classes with virtual functions have their VTable pointer placed at +0x0 in memory. So the very first field contains the pointer to a table where all virtual functions are stored. You can imagine the table being an array of function pointers, each 4 bytes (on x86) in size. During compilation, the compiler replaces a call to object->SomeInterfaceMethod with its index in the virtual function table which could look like this: object->VFT[index].
Mapping addresses from VFT to DLL
In order to find the implementation of the interface functions in our audio DLL, one can simply check the implementation of the interfaces in Audioclient.h. You could also simply call the functions and check the asm output, which will call the function like this:
mov eax, pAudioClient mov eax, [eax+index*4] call eax
You can then retrieve the actual location using something like this:
DWORD vTable = *(DWORD*)pAudioClient; DWORD getCurrentPaddingOffset = *(DWORD*)(vTable + 0x18);
Then calculating the offset is easy: getCurrentPaddingOffset – Audioses base. For Windows 8 (32) bit, GetCurrentPadding would be at 10018D7D (VTable index is 0x18).
So now we know where the interfaces functions are stored in the DLL.
Hooking the functions
Hooking the functions is no different than normal hooking. We could either use the static offsets we gathered or dynamically resolve the addresses from the VTable and use them. The latter is version independent so it’s preferable.