全文详细地址：

假如您试着从运作CylancePROTECT的设备上转储lsass.exe过程运行内存得话，您便会发觉，它是一件十分艰难的事儿。

在本试验中，大家将为阅读者演试怎样成功转储过程的运行内存并绕开Cylance（或一切别的病毒防护/节点检验和回应解决 *** ），后面一种应用客户态API hooking来明确程序在实行全过程中是不是有故意个人行为。

事实上，Hooking是一种历史悠久的技术性，我以前早有了解，但从来没有机遇使用过，直至我偶然发现Hoang Bui的一篇文章——该文章内容详细介绍了EDR的unhooking解决，详细地址为

尽管本试验演试的API Unhooking技术性是在MiniDumpWriteDump API前后文中开展的，可是该技术性一样适用别的一切已hooked的API。

事实上，我们可以将API hooking与 *** 服务器开展对比：您的运用程序开展的全部API调用（包含其主要参数），比如CreateFile、ReadFile、OpenProcess等均会被AV/EDR阻拦并开展相对的查验，随后由AV/EDR判决程序的实际操作/用意是不是故意的。

针对EDR生产商而言，她们对客户态API的hook方式是：被劫持/改动Windows DLL（如kernel32/kernelbase和ntdll）中的函数界定（API）。

一般来说，函数界定是根据在其开始 *** 一个jmp命令来开展改动的。这种jmp命令将更改程序的实行步骤——程序将被跳转到EDR的查验控制模块，该控制模块将分辨程序是不是主要表现出一切异常的个人行为，从总体上，他们是根据剖析传送给EDR已经hooking/监控的函数的主要参数来开展评定的。这类跳转有时候被称作绕道/蹦蹦床。

期待下边的数据图表有利于进一步表明这一个全过程：

特别注意的是，并不是全部的函数都是会被AV/EDR被劫持。一般仅有这些在已经知道恶意程序中被常常乱用的函数才会被hooked，这种函数包含CreareRemoteThread、NtQueueApcThread等。

一定要注意，这一试验事实上是创建在另一个试验的基本以上的。在那一个试验中，我撰写了一个中小型的C 程序，应用MiniDumpWriteDump Windows API转储lsass.exe过程运行内存，敬请浏览

如今，使我们试着在一个被CylancePROTECT监管的系统软件上运作这一段编码（在上面的试验中撰写的程序）。这时候，该程序会因为违反规定而被停止，有关信息为LsassReadstraight away：

如同您猜中的那般，Cylance hook了MiniDumpWriteDump的API调用。更精确地说，它事实上是hook了一个NtReadVirtualMemory函数，该函数来源于ntdll.dll，而它是由MiniDumpWriteDump函数在背后开展调用的。

用程序调试实行该程序，我们可以观查到，在过程运行时，Cylance的内存保护控制模块，即CyMemDef64.dll被引入到Invok-CreateMemoryDump.exe（大家的程序，它会调用MiniDumpWriteDump函数）过程中。这一控制模块将对Invok-CreateMemoryDump.exe中的API调用开展相对的查验。

即然我们知道MiniDumpWriteDump调用了NtReadVirtualMemory，那麼何不检查一下NtReadVirtualMemory的函数界定，看一下是不是有异常之处。

@WinDBG

u NtReadVirtualMemory

大家马上见到，该函数的之一条命令是偏向某一怪异内存地址的JMP命令，该详细地址超过了ntdll控制模块的内存地址范畴：

下边，使我们反编译一下该详细地址：

@WinDBG

u 0000000047980084

我们可以马上注意到，也有好几个偏向Cylance内存保护控制模块CyMemDef64.dll的jmp命令——这确认了函数NtReadVirtualMemory已被hooked：

为了更好地确定大家的程序最后将调用NtReadVirtualMemory，我们可以在其上置放一个中断点并执行程序。如下列屏幕截屏所显示，这儿击中了该中断点：

如果我们执行程序，它将被跳转（jmp命令）到Cylance的内存保护控制模块，而且该程序将伴随着Violation：LsassRead信息的来临而奔溃。

为了更好地开展unhook，也就是说，将被hooked的函数复原到其最初的状态，大家必须了解它在被Cylance改动以前是什么样子的。

根据查验函数NtReadVirtualMemory的前五个字节数，能够非常容易保证这一点；在载入到运行内存以前，该函数坐落于c:\\windows\\system32

tdll.dll库文件。我们可以在ntdll的DLL导出来表格中见到该函数的相对性虚拟注册地址（RVA）——在大家的试验中，该详细地址为00069C70（在您的系统软件上，该详细地址很有可能会各有不同）：

假如将RVA变换为物理学文档部位（因为文档并未载入到运行内存中，因而与RVA同样），我们可以见到该函数的前五个字节数为4c 9a d1 b8 c3：

上边的意思是，如果我们将Cylance引入的NtReadVirtualMemory函数的前五个字节数（e9 0f 64 f8 cf）更换为4c 9a d1 b8 3c，那麼，Cylance可能“双目失明”，进而没法监控MiniDumpWriteDump API调用。

拥有这种信息内容，我们可以升级程序，并让它寻找函数NtReadVirtualMemory的详细地址，并根据将字节数4c 9a d1 b8 3c载入该函数的开始一部分来完成unhook，实际如下边的第17行编码所显示：

再次编译程序并再度运作该程序将取得成功转储lsass.exe过程运行内存，而不容易遭受Cylance的影响：

大家现在可以令转储文档offline并将其载入到mimikatz中……。

在这儿，大家只对一个函数开展了unhook解决；针对别的函数，根据较为硬盘上的DLL文件中的函数界定和运行内存中的函数界定，假如跟运行内存中的函数界定不一样，则代表着它被“勾住”了，这时候，我们可以用硬盘上的界定中寻找的命令开展遮盖就可以。

下边是非常好的参考文献，在其中包含Cylance对unhooking技术性的叙述：

（请在这里 *** 演试视頻）