- Java锁的逻辑(结合对象头和ObjectMonitor)
- 还在用饼状图?来瞧瞧这些炫酷的百分比可视化新图形(附代码实现)⛵
- 自动注册实体类到EntityFrameworkCore上下文,并适配ABP及ABPVNext
- 基于Sklearn机器学习代码实战
项目地址: https://github.com/0xlane/com-process-inject 。
Process Injection via Component Object Model (COM) IRundown::DoCallback(). 。
该技术由 @modexpblog 挖掘发现,在我对该技术进行深入研究过程中,将原项目 mdsecactivebreach/com_inject 使用了 Rust 重写,希望对使用 Rust 的安全人员在 COM 接口调用、进程注入等方面有所帮助.
对于此项注入技术原理的更保真的解释,还请参考 https://www.mdsec.co.uk/2022/04/process-injection-via-component-object-model-com-irundowndocallback/ ,这里只记录一下工具用法和过程中遇到的一些问题和想法.
PS D:\rust\com-inject> .\target\release\com-inject.exe -h
com-inject (1.0) - REInject
A process injection tool via COM
Commands:
inject Inject special dll or shellcode to target process
list List interface instance in special or all process
help Print this message or the help of the given subcommand(s)
Options:
-h, --help Print help
-V, --version Print version
#############################################################
PS D:\rust\com-inject> .\target\release\com-inject.exe inject -h
Inject special dll or shellcode to target process
Usage: com-inject.exe inject [OPTIONS] <PID>
Arguments:
<PID> Target process id
Options:
-m, --method Use CoGetObject instead of CoUnmarshalInterface to establish channel
-d, --dll <PATH> Inject DLL into target, specify full path
-s, --shellcode <PATH> Inject shellcode into target process
-h, --help Print help
#############################################################
PS D:\rust\com-inject> .\target\release\com-inject.exe list -h
List interface instance in special or all process
Usage: com-inject.exe list [OPTIONS] [PID]
Arguments:
[PID] Target process id
Options:
-v, --verbose Dispaly all interface, default only IRundown
-h, --help Print help
Tips
- DLL 和 Shellcode 文件路径使用绝对路径
- 不论是 list 操作还是 inject 操作,都会尝试开启 DEBUG 权限
- 避免对同一进程交替进行 DLL 注入和 shellcode 注入或者重复进行 DLL 注入,可能会报错 “被调用的对象已与其客户端断开连接。 (0x80010108)”,貌似是多次调用后远程接口会被释放掉
- 如果报错 “不支持此接口 (0x80004002)”,就多试几遍
- 并不是任何进程都能注入,只能对 list 动作显示出来的进程进行注入
先说一下如何使用 Rust 对 COM 接口调用,调用过程可以分这几个步骤:
重点在接口定义,后面几步都是 API 调用,对于一些有文档记录的接口一般都有对应的头文件或 IDL,直接用就行,但是对于其他 COM 接口,调用之前先要定义一个包含方法虚表的结构体/接口,这个虚表的内存偏移、方法顺序需要保证和接口实现一致,后面拿到接口指针才能正确调用对应的方法,c++ 里的接口定义示例:
const IID
IID_IRundown = {
0x00000134,
0x0000,
0x0000,
{0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46}};
MIDL_INTERFACE("00000134-0000-0000-C000-000000000046")
IRundown : public IUnknown {
STDMETHOD(RemQueryInterface) ( REFIPID ripid,
ULONG cRefs,
USHORT cIids,
IID *iids,
REMQIRESULT **ppQIResults);
STDMETHOD(RemAddRef) ( unsigned short cInterfaceRefs,
REMINTERFACEREF InterfaceRefs[],
HRESULT *pResults);
STDMETHOD(RemRelease) ( USHORT cInterfaceRefs,
REMINTERFACEREF InterfaceRefs[]);
};
所有 COM 接口的祖先就是 IUnknown,大部分接口直接继承自 IUnknown,还有部分通过继承 IDispatch 或其他接口间接的继承自 IUnknown。继承在内存布局上实际上就是在父类的内存结构基础上进行新增,所以不继承直接将 IUnknown 中的方法搬过来也行.
由于 Rust 里面接口、类全部都以 struct 的形式表达,并且和 C++ 中的 struct 内存布局是有区别的,所以在定义接口虚表时,全部需要加上 #[repr(C)] ,代表该结构体内存布局和 C 完全一致。C 里面有 IUnknown ,Rust 里也不需要我们从 IUnknown 开始实现,实际上在 windows-rs 和 winapi 这两个 crate 中都有实现,但是实现方式上有所不同。主要体现在对 “接口指针” 的定义上,下面是使用 C、winapi、windows-rs 各自如何声明一个接口指针变量:
声明方式 | |
---|---|
C | IUnknown *p = NULL; |
winapi | let p: *mut IUnknown = ptr::null_mut(); |
windows-rs | let p: IUnknown; |
可以看出来 winapi 的接口定义方式更符合 c 的接口调用风格,而 windows-rs 从声明上则看不出来是一个指针,指针被隐藏在了内部:
#[repr(transparent)]
pub struct IUnknown(std::ptr::NonNull<std::ffi::c_void>);
transparent 可以理解为透传,相当于: pub type IUnknown = std::ptr::NonNull<std::ffi::c_void> ,所以 let p: IUnknown 等价于 let p: std::ptr::NonNull<std::ffi::c_void> ,这样才能看出来是个指针了.
对于这块暂时解释到这里,想更进一步理解具体怎么用 Rust 定义一个接口的话,可以借鉴我代码里对 IRundown 接口的实现方式.
接下来理解 COM 接口方法的调用过程,COM 实际上可以理解为 RPC 的一种上层实现,所以还是 RPC,调用接口的程序称为客户端,真正处理执行调用请求的称为服务端。之前列出的调用过程步骤中的第 3 步,使用 CoGetObject 、 CoCreateInstance 、 CoGetObjectContext 这些 API 获取接口指针,如果获取成功就相当于和服务端连接成功,当通过指针调用方法后,相当于发起一个请求到服务端了.
所以回到该技术中,该技术使用了一个名为 IRundown 的接口,此接口中包含一个可以执行回调的方法 DoCallback ,定义如下:
pub DoCallback: unsafe extern "system" fn(this: *mut ::core::ffi::c_void, pParam: *mut XAptCallback) -> windows::core::HRESULT,
XAptCallback 参数设置回调地址和参数地址:
#[repr(C)]
#[derive(Clone, Copy)]
pub struct tagXAptCallback {
pub pfnCallback: PTRMEM, // what to execute. e.g. LoadLibraryA, EtwpCreateEtwThread
pub pParam: PTRMEM, // parameter to callback.
pub pServerCtx: PTRMEM, // combase!g_pMTAEmptyCtx
pub pUnk: PTRMEM, // Not required
pub iid: windows::core::GUID, // Not required
pub iMethod: i32, // Not required
pub guidProcessSecret: windows::core::GUID // combase!CProcessSecret::s_guidOle32Secret
}
pub type XAptCallback = tagXAptCallback;
pfnCallback 为回调函数指针, pParam 为参数指针。加上之前说的 C/S 架构,接口调用请求实际上是在服务端处理的,所以当服务端进程接收到执行回调的请求后,触发回调执行完成代码注入.
大致的技术利用原理就这些,其他的都是一些细节问题,比如如何获取到该接口指针、如何注入到任意进程中去,这两个实际上是一个问题,前面说过成功获取接口指针即是连接到目标进程,所以对于此类问题的根本是 “哪些进程属于这个接口的服务进程”.
好像目前唯一好用的查看 COM 进程信息的工具就是 OleViewDotNet 了,需要提前使用 windbg 或者其他调试器把 combase.dll 的符号下载到本地,然后配置到 OleViewDotNet 里,否则是查不到任何结果的:
然后在 Processes -> All Proccess -> By Name 打开 COM 进程列表,搜索 IRundown
相当于执行 com-inject.exe list -v .
这些进程中存在 IRundown 接口指针,由于 IRundown 接口的实现者是 combase.dll,所以加载 combase.dll 的进程都有可能.
windbg 里面可以直接按下面的方式找 IRundown 接口虚表:
0:004> x /D /d combase!*CRemoteUnknown*
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
00007fff`637008c8 combase!CRemoteUnknown::`vftable' = <function> *[13]
0:004> dx -r1 (*((combase!void (__cdecl*(*)[13])())0x7fff637008c8))
(*((combase!void (__cdecl*(*)[13])())0x7fff637008c8)) [Type: void (__cdecl* [13])()]
[0] : 0x7fff6353e790 : combase!CRemoteUnknown::QueryInterface+0x0 [Type: void (__cdecl*)()]
[1] : 0x7fff635ae3b0 : [Type: void (__cdecl*)()]
[2] : 0x7fff635ae3b0 : [Type: void (__cdecl*)()]
[3] : 0x7fff63520600 : combase!CRemoteUnknown::RemQueryInterface+0x0 [Type: void (__cdecl*)()]
[4] : 0x7fff6351a390 : combase!CRemoteUnknown::RemAddRef+0x0 [Type: void (__cdecl*)()]
[5] : 0x7fff6352f2b0 : combase!CRemoteUnknown::RemRelease+0x0 [Type: void (__cdecl*)()]
[6] : 0x7fff6355ad50 : combase!CRemoteUnknown::RemQueryInterface2+0x0 [Type: void (__cdecl*)()]
[7] : 0x7fff6355afa0 : combase!CRemoteUnknown::AcknowledgeMarshalingSets+0x0 [Type: void (__cdecl*)()]
[8] : 0x7fff636765a0 : combase!CRemoteUnknown::RemChangeRef+0x0 [Type: void (__cdecl*)()]
[9] : 0x7fff6358ee90 : combase!CRemoteUnknown::DoCallback+0x0 [Type: void (__cdecl*)()]
[10] : 0x7fff6358ee80 : combase!CRemoteUnknown::DoNonreentrantCallback+0x0 [Type: void (__cdecl*)()]
[11] : 0x7fff634d29b0 : combase!CRemoteUnknown::GetInterfaceNameFromIPID+0x0 [Type: void (__cdecl*)()]
[12] : 0x7fff6355b140 : combase!CRemoteUnknown::RundownOid+0x0 [Type: void (__cdecl*)()]
0:004> u 7fff6358ee90
combase!CRemoteUnknown::DoCallback [onecore\com\combase\dcomrem\remoteu.cxx @ 1843]:
00007fff`6358ee90 48895c2408 mov qword ptr [rsp+8],rbx
00007fff`6358ee95 57 push rdi
00007fff`6358ee96 4883ec40 sub rsp,40h
00007fff`6358ee9a 0f104234 movups xmm0,xmmword ptr [rdx+34h]
00007fff`6358ee9e 488bda mov rbx,rdx
00007fff`6358eea1 488d542430 lea rdx,[rsp+30h]
00007fff`6358eea6 f30f7f442430 movdqu xmmword ptr [rsp+30h],xmm0
00007fff`6358eeac e83b000000 call combase!CProcessSecret::VerifyMatchingSecret (00007fff`6358eeec)
0:004> bp 7fff6358ee90
其他细节或者挖掘思路直接看一下大佬的文章解惑吧 https://www.mdsec.co.uk/2022/04/process-injection-via-component-object-model-com-irundowndocallback/ .
原项目运行后可能会遇到一些问题,在重写时简单处理了一下,问题如下:
我在 find_ipid_table 中加了些条件,然后就没遇到过着个问题了:
if (*cpage)._pgalloc._cPages <= 0 || (*cpage)._pgalloc._cEntries <= 0 {
continue;
}
0x0000
或 0xFFFF
,导致回调失败 IPID 是一个 GUID,是对接口指针的标识,具有一定的格式: xxxxxxxx-yyyy-zzzz-xxxx-xxxxxxxxxxxx , yyyy 的位置代表进程 PID, zzzz 的位置代表线程 TID,如果线程 ID 无效会导致获取的 server context 不正确,最后虽然这个接口指针的状态虽然不是 IPIDF_DISCONNECTED ,但是最终调用 DoCallback 时依然返回错误:“被调用的对象已与其客户端断开连接。 (0x80010108)”.
所以我在获取接口指针时,加了些过滤,优先使用 TID 有效的 IPID:
let x: Vec<_> = entries.iter().filter(|x| x.ipid.tid > 0x0 && x.ipid.tid < 0xffff).collect();
let y: Vec<_> = entries.iter().filter(|x| x.ipid.tid == 0x0).collect();
if x.len() > 0 {
(*rc).ipid = x[0].ipid;
(*rc).oxid = x[0].oxid;
(*rc).oid = x[0].oid;
} else if y.len() > 0 {
(*rc).ipid = y[0].ipid;
(*rc).oxid = y[0].oxid;
(*rc).oid = y[0].oid;
} else {
(*rc).ipid = entries[0].ipid;
(*rc).oxid = entries[0].oxid;
(*rc).oid = entries[0].oid;
}
0x0000
或 0xFFFF
时总是注入失败,怎么解决 x86
和 x86_64
的 COM 进程 最后此篇关于COM进程注入技术的文章就讲到这里了,如果你想了解更多关于COM进程注入技术的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
我是 Linux 的新手,并且继承了保持我们的单一 Linux 服务器运行的职责。这是我们的SVN服务器,所以比较重要。 原来在我之前维护它的人有一个 cron 任务,当有太多 svnserve 进程
Node 虽然自身存在多个线程,但是运行在 v8 上的 JavaScript 是单线程的。Node 的 child_process 模块用于创建子进程,我们可以通过子进程充分利用 CPU。范例:
Jenkins 有这么多进程处于事件状态是否正常? 我检查了我的设置,我只配置了 2 个“执行者”... htop http://d.pr/i/RZzG+ 最佳答案 您不仅要限制 Master 中的执
我正在尝试在 scala 中运行这样的 bash 命令: cat "example file.txt" | grep abc Scala 有一个特殊的流程管道语法,所以这是我的第一个方法: val f
很难说出这里要问什么。这个问题模棱两可、含糊不清、不完整、过于宽泛或夸夸其谈,无法以目前的形式得到合理的回答。如需帮助澄清此问题以便重新打开,visit the help center . 关闭 1
我需要一些帮助来理解并发编程的基础知识。事实上,我读得越多,就越感到困惑。因此,我理解进程是顺序执行的程序的一个实例,并且它可以由一个或多个线程组成。在单核CPU中,一次只能执行一个线程,而在多核CP
我的问题是在上一次集成测试后服务器进程没有关闭。 在integration.rs中,我有: lazy_static! { static ref SERVER: Arc> = {
我正在使用 Scala scala.sys.process图书馆。 我知道我可以用 ! 捕获退出代码和输出 !!但是如果我想同时捕获两者呢? 我看过这个答案 https://stackoverflow
我正在开发一个C++类(MyClass.cpp),将其编译为动态共享库(MyClass.so)。 同一台Linux计算机上运行的两个不同应用程序将使用此共享库。 它们是两个不同的应用程序。它不是多线程
我在我的 C 程序中使用 recvfrom() 从多个客户端接收 UDP 数据包,这些客户端可以使用自定义用户名登录。一旦他们登录,我希望他们的用户名与唯一的客户端进程配对,这样服务器就可以通过数据包
如何更改程序,以便函数 function_delayed_1 和 function_delayed_2 仅同时执行一次: int main(int argc, char *argv[]) {
考虑这两个程序: //in #define MAX 50 int main(int argc, char* argv[]) { int *count; int fd=shm
请告诉我如何一次打开三个终端,这样我的项目就可以轻松执行,而不必打开三个终端三次然后运行三个exe文件。请问我们如何通过脚本来做到这一点,即打开三个终端并执行三个 exe 文件。 最佳答案 在后台运行
我编写了一个监控服务来跟踪一组进程,并在服务行为异常、内存使用率高、超出 CPU 运行时间等时发出通知。 这在我的本地计算机上运行良好,但我需要它指向远程机器并获取这些机器上的进程信息。 我的方法,在
关闭。这个问题不符合Stack Overflow guidelines .它目前不接受答案。 想改进这个问题?将问题更新为 on-topic对于堆栈溢出。 8年前关闭。 Improve this qu
我有一个允许用户上传文件的应用程序。上传完成后,必须在服务器上完成许多处理步骤(解压、存储、验证等...),因此稍后会在一切完成后通过电子邮件通知用户。 我见过很多示例,其中 System.Compo
这个问题对很多人来说可能听起来很愚蠢,但我想对这个话题有一个清晰的理解。例如:当我们在 linux(ubuntu, x86) 上构建一个 C 程序时,它会在成功编译和链接过程后生成 a.out。 a.
ps -eaf | grep java 命令在这里不是识别进程是否是 java 进程的解决方案,因为执行此命令后我的许多 java 进程未在输出中列出。 最佳答案 简答(希望有人写一个更全面的): 获
我有几个与内核态和用户态的 Windows 进程相关的问题。 如果我有一个 hello world 应用程序和一个暴露新系统调用 foo() 的 hello world 驱动程序,我很好奇在内核模式下
我找不到很多关于 Windows 中不受信任的完整性级别的信息,对此有一些疑问: 是否有不受信任的完整性级别进程可以创建命名对象的地方? (互斥锁、事件等) 不受信任的完整性级别进程是否应该能够打开一
我是一名优秀的程序员,十分优秀!