Github仓库地址: 2d0K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6U0M7K6q4A6L8h3g2Q4x3V1k6w2k6i4u0F1k6h3I4p5N6$3@1`.
本文中涉及到的技术与源码不得用于非法用途!
之前在Github上看到了一个有意思的仓库 6bcK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6%4j5X3q4T1P5g2)9J5c8V1c8G2N6h3u0D9k6f1y4S2L8r3I4n7j5h3y4C8
有三次commit,原作者应该就是busy10了
原理是内核层调用用户层dwm的DirectX11 vtable函数,用户层把vtable里的函数替换成ntdll里的LdrpIsCODServiceEnabled
触发内核中的注册表回调
接着调用vtable里的函数实现绘制,伪代码如下
不知为啥DirectX11能把Texture copy进Surface里面,DirectX12就不行了...总之DWM应该会一直使用DirectX11的,一个融合器也没必要上DirectX12这么复杂的API
这里的绘制实现是CPU写像素,安排上图形学的算法就行,busy10大佬已经帮我们写好基本的算法了 81fK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6%4j5X3q4T1P5g2)9J5c8V1c8G2N6h3u0D9k6f1y4S2L8r3I4n7j5h3y4C8i4K6u0r3j5X3I4G2j5W2)9J5c8X3#2S2M7%4c8W2M7W2)9J5c8V1c8G2N6h3u0D9k6f1y4S2L8r3I4T1j5h3y4C8i4K6u0r3e0r3g2Y4j5h3y4&6f1X3g2F1k6r3g2J5i4K6u0W2K9l9`.`.
难点主要集中在内核层调用用户层和hook dwm
Windows提供的内核层调用用户层的标准函数是KeUserModeCallback
这里找到一篇文章分析这个函数 18bK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2S2L8Y4q4#2j5h3&6C8k6g2)9J5k6h3y4G2L8g2)9J5c8Y4m8G2M7%4c8Q4x3V1k6A6k6q4)9J5c8U0p5^5y4o6t1K6x3#2)9J5x3$3R3J5i4K6u0V1x3b7`.`.
只需要看 KiCallUserMode
的实现就行了,由于sysret将rcx作为了返回用户模式地址的寄存器,那就要返回用户层的时候要先跳到KiUserCallForwarder
的后半段以实现从栈上获取到预先设定好的Windows x64调用约定中前4个由寄存器传递的参数(rcx,rdx,r8,r9)
sysret之前把rax设为目标函数地址,返回地址设定为NtCallbackReturn
即可。
关于KeUserModeCallback
还额外需要申请一个内核栈,个人猜测应该是内核层回到用户层调用函数的时候,函数里面又要调用一些API进内核需要一个全新的栈。
对于kvashadow的gs:[xxxx]偏移,切换堆栈的时候必须涉及到这个,kvashadow是用来防幽灵熔断漏洞的,看了一下这个漏洞的实现原理,想要防只能给用户模式单独做一张没有内核模式敏感信息的页表,正常渠道进内核就用正常的页表
所以IA32_LSTAR
的值肯定是由系统根据有无开启kvashadow自动分配的
开了kvashadow的syscall入口函数:
没开kvashadow的syscall入口函数:
IA32_LSTAR
记录的syscall地址如果开了kvashadow就是KiSystemCall64Shadow
,没开就是KiSystemCall64
,再加上一个固定偏移就能完美定位
实现代码:
经过Infhook测试发现DirectX11在Present之后必定会调用NtGdiDdDDIGetDeviceState
,而这个函数在内核层是可被Hook的
hook点的完整栈回溯如下图
hook点位于DxgkGetDeviceStateInternal
返回时机通过Process->DxgkProcess
中的函数表调用UserScreenAccessCheck
注入的过程,我尽量写的隐蔽性高一点,蓝屏几率小一点
DWM进程是被Windows保护的,有很多保护机制存在,如果采用mdl映射用户层内存或者ntapi申请内存的形式,会在VAD里面留下一个大小造成检测方向,并且可能会被Windows的安全机制或者杀软的安全机制拦截
申请RWX内存的实现是通过ExAllocatePool申请内存,通过暴力添加pte条目实现内存映射,把申请到的内存映射到用户层模块 ntdll.dll
向上的地址区域
暴力映射内存的实现在源文件位置 59bK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6U0M7K6q4A6L8h3g2Q4x3V1k6w2k6i4u0F1k6h3I4p5N6$3#2Q4x3V1k6T1L8r3!0T1i4K6u0r3L8h3q4K6N6r3g2J5i4K6u0r3d9$3g2J5L8X3g2D9c8s2N6E0i4K6u0r3d9$3g2J5L8X3g2D9c8s2N6E0i4K6u0r3k6s2N6E0i4K6u0r3e0h3q4C8k6g2t1K6e0h3g2E0i4K6u0W2j5%4m8H3
Hook MultiplanePresent和PresentImpl,执行的时候记录第一个参数就行
源码位置: 854K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6U0M7K6q4A6L8h3g2Q4x3V1k6w2k6i4u0F1k6h3I4p5N6$3#2Q4x3V1k6T1L8r3!0T1i4K6u0r3L8h3q4K6N6r3g2J5i4K6u0r3c8s2N6E0c8r3I4D9c8X3q4U0N6r3!0J5i4K6u0r3c8s2N6E0c8r3I4D9i4K6u0r3c8s2N6E0c8r3I4D9i4K6u0r3k6s2N6E0i4K6u0r3k6s2S2Z5L8$3!0C8i4K6u0W2j5%4m8H3
要注意源码里的hook写内存用的是VirtualProtect
函数,会触发Copy on write造成检测方向
ID3D11Texture2D* SurfaceD3D11 = 0;
pSwapChain->GetBuffer(0, __uuidof(ID3D11Texture2D), (
void
**)&SurfaceD3D11);
D3D11_TEXTURE2D_DESC desc = { 0 };
SurfaceD3D11->GetDesc(&desc);
desc.BindFlags = 0;
desc.MiscFlags = 0;
desc.Usage = D3D11_USAGE_STAGING;
desc.CPUAccessFlags = D3D11_CPU_ACCESS_READ | D3D11_CPU_ACCESS_WRITE;
ID3D11Texture2D* Texture = 0;
pd3dDevice->CreateTexture2D(&desc, 0, &Texture);
pd3dDeviceContext->CopyResource(Texture, SurfaceD3D11);
D3D11_MAPPED_SUBRESOURCE MapRes = { 0 };
pd3dDeviceContext->Map(Texture, 0, D3D11_MAP_READ_WRITE, 0, &MapRes);
ByteRender(MapRes.pData);
pd3dDeviceContext->Unmap(Texture, 0);
pd3dDeviceContext->CopyResource(SurfaceD3D11, Texture);
Texture->Release();
SurfaceD3D11->Release();
ID3D11Texture2D* SurfaceD3D11 = 0;
[培训]内核驱动高级班,冲击BAT一流互联网大厂工作,每周日13:00-18:00直播授课
最后于 2023-10-10 20:07
被cslime编辑
,原因: 加上注入