Listen to this device，而不与GUI交互。
我认为这将是一个简单的注册表项，因此我对此进行了修改。使用RegShot查找密钥：
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Capture\{My-Microphone's-UUID}\Properties
密钥称为
{24dbb0fc-9311-4b3d-9cf0-18ff155639d4},1（在所有计算机上）。以及切换
Listen to this device时的值更改如下：（0更改为f）xxxxxxxxxxxxxxxx0000xxxx
xxxxxxxxxxxxxxxxffffxxxx
但是当我检查GUI时，我看到
Listen to this device复选框已被打勾，但是我可以实际上没有听到我的麦克风发出的任何声音，当我取消勾选时，单击“应用”，重新勾选然后再次应用，我听到了我的麦克风。所以我以为我可能需要DllCall或PostMessage，例如单击apply时发送的消息或调用的dll，但是在Internet上找不到任何内容。我不知道如何让Windows理解此设置已更改。请教我如何使用x64dbg进行反向工程。
#1 楼
AFAIK知道使用什么注册表项并不总是足够的，因为注册表只是存储诸如首选项之类的地方。设置注册表值可能不会立即对设备产生任何影响。设备配置的真实真相是设备本身。根据我的经验，控制面板通常是操作系统托管的轻量级GUI，而执行任何实际工作的过程就是守护程序GUI通过IPC与之对话。
在API Monitor中查看记录的API调用，我们可以看到控制面板将RPC消息发送到AudioSrv服务。在命令提示符中使用
sc queryex，您可以找到承载此服务实例的svchost（服务主机）的PID。从那里在IDA中进行字符串搜索，我们找到字符串“ ListenTo ”被某些AudioSrv代码使用。它可能是用于调试的字符串，但这将是我在IDA中进行一些静态分析或在调试器上设置断点的第一个地方。
有一些工具可以帮助您确定执行某些操作时将运行哪个代码。想到CheatEngine中的Ultimap，您可以在线找到它的教程。您还可以在x64dbg中对进程进行跟踪并查找任何系统调用，这通常很有趣，因为它表明进程正在向内核询问某些内容（例如，控制设备）。
最终，这仅仅为了获得一个hacky解决方案可能需要做很多工作，因此您可以探索替代方案，例如创建虚拟设备驱动程序。
评论
如果我搜索标识的注册表项24dbb0fc-9311-4b3d-9cf0-18ff155639d4，则会得到一些有趣的结果，指向MMDevice API。请参见此处的示例。显然，multimediasoft为.NET提供了一个库（收费）音频录音机，可以“模拟”此功能。
我要做的是：1.查看UI驻留在哪个进程中（使用Spy ++从显示的HWND中获取PID。）我猜想它应该是rundll32 proc之一。 2.然后使用调试器（x64Dbg将起作用）并在该proc中的ntdll.ZwSetValueKey上设置一个断点（在显示该UI之前）。您可能需要在写入注册表值时设置一个有条件的bp来捕获。它将在第二个参数中作为UNICODE_STRING *。 3.运行proc直到bp触发。 4.然后，与调试器一起遍历代码，然后查看它们在做什么。无需猜测。
@ c00000fd +1或仅使用ProcMon（确保配置符号）并在RegSetValue上进行过滤，然后双击该条目并检查调用堆栈，这可能比使用调试器更容易...
我首先想到的是GetSystemMetrics / SystemParametersInfo / WM_SETTINGSCHANGE，但事实证明，这些未用于您想要/需要的东西。我想知道的是，您是否真的对实现该功能感兴趣，或者对您进行逆向工程对您来说是否重要？鉴于我们使用的是RE.SE，我假设它是后者。但是，我想知道，因为我认为在这种情况下，可以用有关Win32编程的知识代替逆向工程。至少以某种方式广播该配置更改是正常的。