4

I'm writing an Autohotkey script to toggle Listen to this device for my microphone, without interacting with a GUI.

listen to this device

I thought it would be a simple registry key being modified so I used RegShot to find the key:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Capture\{My-Microphone's-UUID}\Properties

The key is called {24dbb0fc-9311-4b3d-9cf0-18ff155639d4},1 (On all computers).

And the value when toggling the Listen to this device changes like this: (The 0's change to f's)

xxxxxxxxxxxxxxxx0000xxxx
xxxxxxxxxxxxxxxxffffxxxx

But when I check the GUI, I see that the Listen to this device tick-box has been ticked but I can't actually hear anything from my mic, when I un-tick it, click apply, re-tick it and apply again, I hear my mic. So I thought I might need DllCall or PostMessage here, like what message was sent or what dll was called when I click apply but I couldn't find anything on it on the Internet. I don't know how to make Windows understand that this setting has changed.

Please teach me how to reverse engineer this with x64dbg.

Improve this question
18
  • 1
    If I search for the identified registry key 24dbb0fc-9311-4b3d-9cf0-18ff155639d4 I am getting some interesting results pointing to the MMDevice API. See for example here.
    – Robert
    Mar 17, 2020 at 8:53
  • 1
    Apparently multimediasoft offers a library (paid) Audio Sound Recorder for .NET which "emulates" this feature.
    – 0xec
    Mar 17, 2020 at 9:53
  • 3
    What I would do is this: 1. See what process that UI resides in (use Spy++ for that to get PID from the HWND you showed.) I'd guess that it'd be one of rundll32 procs. 2. Then use a debugger (x64Dbg would work) and set a breakpoint on ntdll.ZwSetValueKey in that proc (before that UI is shown). You may want to make a conditional bp to catch when your registry value is written. It will be in a 2nd parameter as UNICODE_STRING*. 3. Run the proc until bp triggers. 4. After then just walk thru the code with your debugger and see what they are doing there. No guesswork needed.
    – c00000fd
    Mar 18, 2020 at 21:32
  • 1
    @c00000fd +1 or alternatively just use ProcMon (be sure to configure symbols) and filter on RegSetValue then doubleclick the entry and inspect the callstack which might be easier than using a debugger...
    – Remko
    Mar 21, 2020 at 21:53
  • 1
    I first thought of GetSystemMetrics/SystemParametersInfo/WM_SETTINGSCHANGE, but it turns out those are not used for what you want/need. What I am wondering is whether you are actually interested in achieving that functionality or whether it's important to you how to reverse engineer such stuff?! Given we're on RE.SE I'd assume it's the latter, but I'd like to know as I think that in this case it might be possible to substitute reverse engineering with knowledge about Win32 programming. It would be normal, at least, for that configuration change to be broadcast somehow.
    – 0xC0000022L ♦
    May 6, 2020 at 13:30

1 Answer 1

Reset to default
2

AFAIK, knowing what registry keys are used is not always enough, because the registry is just a place to store things like preferences. Setting a registry value may not have any immediate effect on a device. The real source of truth of how a device is configured is the device itself.

From my experience control panels tend to be lightweight GUIs hosted by the OS, and the process that does any real work is the daemon that the GUI talks to over IPC.

Looking over the recorded API calls in API Monitor we can see that the control panel sends RPC messages to the AudioSrv service. Using sc queryex in Command Prompt, you can find the PID of the svchost (service host) that's hosting the instance of this service.

From there, doing a string search in IDA, we find the string "ListenTo" being used by some of the AudioSrv code. It could be a string used for debugging, but that would be my first place to do some static analysis in IDA or set a breakpoint on with my debugger.

There are some tools that can help with figuring out which code is run when you perform some action. Ultimap in CheatEngine comes to mind, you can find tutorials for it online. You can also perform tracing of the process in x64dbg and look for any syscalls, which is generally interesting because it indicates that the process is asking the kernel for something (e.g. control a device).

Ultimately, this is probably a lot of work just to get to a hacky solution, so you might explore alternatives e.g. creating a virtual device driver.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.