关于这节课程的一点内容补充
GadgetToJScript
整半天没用明白这个工具，然后搜到了RastaMouse的Blog
https://rastamouse.me/d-invoke-gadgettojscript/
NOTE: I had some wild issues where creating new *.cs files in the project would just cause the serialised gadget to not execute. Simply moving the classes into a single .cs file made everything work again.
把Win32.cs的内容复制到Class Program里得了
直接上P/Invoke
x86 & x64
本地的Word能运行宏
准备丢虚拟机里面测一下ASR绕过的，结果发现不能运行
调试半天发现虚拟机装的是x86的Office
想着创建个x64进程应该就能注入x64 Shellcode了，结果不行
整体测试了一遍
测试结果如下
| Gadget | CSharp_PE | Word | Process | Shellcode | Result |
|---|---|---|---|---|---|
| x86 | x86 | x86 | x86 | x86 | TRUE |
| x86 | x86 | x86 | x86 | x64 | FALSE |
| x86 | x86 | x86 | x64 | x86 | FALSE |
| x86 | x86 | x86 | x64 | x64 | FALSE |
| x86 | x86 | x64 | x86 | x86 | FALSE |
| x86 | x86 | x64 | x86 | x64 | FALSE |
| x86 | x86 | x64 | x64 | x86 | FALSE |
| x86 | x86 | x64 | x64 | x64 | TRUE |
| x64 | x64 | x86 | FALSE | ||
| x64 | x64 | x64 | x86 | x86 | FALSE |
| x64 | x64 | x64 | x86 | x64 | FALSE |
| x64 | x64 | x64 | x64 | x86 | FALSE |
| x64 | x64 | x64 | x64 | x64 | TRUE |
| x86 | x64 | FALSE | |||
| x64 | x86 | FALSE |
测试结论如下
- Gadget和编译的Loader PE架构必须一致，否则不能生成VBA代码
- x86的Office在宏里不能运行x64的二进制序列化PE的反序列化对象
- x64的Office创建x86进程无法执行x86 Shellcode
感觉还是有点问题，拿CSharp和CPP的Loader再测了以下
只有以下情况能够执行ShellCode
| CSharp | Process | Shellcode |
|---|---|---|
| x86 | x86 | x86 |
| x64 | x64 | x64 |
| CPP | Process | Shellcode |
|---|---|---|
| x86 | x86 | x86 |
| x64 | x86 | x86 |
| x64 | x64 | x64 |
CPP比CSharp多了一种x64 Loader创建x86进程并注入x86 Shellcode的情况
估计是语言底层的问题
也就是说CSharp只有在Loader，创建进程和Shellcode三者的架构一致的情况才能执行ShellCode
再反推在开始的测试结果
| Gadget | CSharp_PE | Office | Process | Shellcode | Result |
|---|---|---|---|---|---|
| x86 | x86 | x64 | x64 | x64 | TRUE |
这一条就显得有些令人疑惑
但是根据结果来反推原因就可以得出以下猜测
CSharp所编译得到的PE其实也还是IL，并不是机器码，最终的执行在.NET框架的CLR中
而编译的PE是x86还是x64其实没有本质上的区别，所以x64的Word能够运行x86的二进制序列化PE
由于自身运行环境是x64，所以只能执行x64的ShellCode
上述猜测未经验证，给自己一个停止折腾的理由罢了
Arch Identifying
1 | IntPtr.Size == 8 |
根据返回结果来分别写x86和x64时的执行语句
二进制序列化PE用x86的就行了，反正x86跟x64的Word都能用
File System Redirector
x86进程访问C:\Windows\System32\时会被重定向到C:\Windows\SysWOW64\
需要使用C:\Windows\sysnative才可以访问C:\Windows\System32\
使用函数CreateProcessW()的时候ApplicationName跟CommandLine都填的sysnative，结果CommandLine是system32，调用的程序还是SysWOW64
只能禁用重定向了
1 | Wow64DisableWow64FsRedirection() |
但是x86进程没办法往x64进程注入x64 ShellCode
然并卵
Update
看OSEP教材的时候说CSharp可以以用x64进程向x86进程注入ShellCode
跟着试了一下用CreateRemoteThread函数确实可以跑
想了一下应该是当时测试的时候CSharp程序创建远程线程用的是QueueUserAPC函数
而CPP则是使用CreateRemoteThread函数
在CPP用QueueUserAPC函数从x64进程向x86进程创建线程
果然失败
EOF