目录
前言
本文是因为在公众号上看到一篇文章随想着实战中利用ToDesk秀操作失败后,实验环境成功复现后写下。ProcDump[1] 是一个命令行实用工具,其主要用途是监视应用程序的 CPU 峰值,并在出现峰值期间生成故障转储,管理员或开发人员可以使用这些转储来确定出现峰值的原因。ProcDump 还支持挂起窗口监视(使用与 Windows 和任务管理器使用的窗口挂起相同的定义)、未处理的异常监视,并且可以根据系统性能计数器的值生成转储。 它还可用作可嵌入到其他脚本中的常规进程转储实用工具。简单来说这个叫ProcDump的工具是一个排查CPU故障的工具,虽然一直有在用但是首次在Microsoft官网看工具介绍,还是挺有趣的。
1.工具教程
本次实验使用了两个工具包含ProcDump和010Edit,对于ProcDump微软官网有相当详尽的介绍了,访问即可了解命令行参数,其中010Editor是一个十六进制文件编辑器,上一次用还是在刚入社会的时候参加技术面试有一些加解密拿flag的题。
ProcDump参数介绍:
使用
-accepteula
命令行选项自动接受 Sysinternals 许可协议。
转储类型 | 说明 |
---|---|
-mm | 写入“小型”转储文件。 (默认值) - 包括直接和间接引用的内存(堆栈及其引用的内容)。 - 包括所有元数据(进程、线程、模块、句柄、地址空间等)。 |
-ma | 写入“完整”转储文件。 - 包括所有内存(映像、映射和专用内存)。 - 包括所有元数据(进程、线程、模块、句柄、地址空间等)。 |
-mt | 写入“分类”转储文件。 - 包括直接引用的内存(堆栈)。 - 包括有限的元数据(进程、线程、模块和句柄)。 - 尝试删除敏感信息,但不能保证删除。 |
-mp | 写入“小型增强”转储文件。 - 包括所有专用内存和所有读/写映像或映射内存。 - 包括所有元数据(进程、线程、模块、句柄、地址空间等)。 - 为了使大小最小化,将排除超过 512MB 的最大专用内存区域。 内存区域定义为相同大小的内存分配的总和。 转储与完整转储一样详细,但大小只有完整转储的 10%-75%。 - 注意:由于调试限制,CLR 进程将转储为完整转储 (-ma)。 |
-mc | 写入“自定义”转储文件。 - 包括由指定的 MINIDUMP_TYPE 掩码(十六进制)定义的内存和元数据。 |
-md | 写入“回调”转储文件。 - 包括由指定 DLL 的名为 MiniDumpWriteDump 的 MiniDumpCallbackRoutine 回调例程定义的内存。- 包括所有元数据(进程、线程、模块、句柄、地址空间等)。 |
-mk | 同样写入“内核”转储文件。 - 包括进程中线程的内核堆栈。 - 使用克隆 ( -r ) 时,OS 不支持内核转储 (-mk )。- 使用多个转储大小时,将针对每个转储大小进行内核转储。 |
010Edit是有图形界面,虽然不熟但是看看手册还是勉强能操作,没有深入了解,但由于能用所以也没多少经验分享了。-_-
2.转储数据
获取todesk进程id,需要注意的是要区分大小写,小写识别不了,选择非ToDesk_Service的PID即可。
tasklist /svc | findsstr "ToDesk"
获取到进程PID 6236后使用Procdump进行数据转储。
procdump64.exe -accepteula -ma 6236
执行该命令后生成一个大小424MB的文件
3.密码获取
打开获取的dmp文件,
4.总结
开始测试我用的其他工具打开的dmp包,但是全文搜索找不到对应的时间,并测试过使用命令获取todesk安装目录下config.ini文件内的临时密码hash根据本地替换解密,也测试失败了。
面对以上未知的问题猜测可能时由于不同版本差异造成的,提供本次测试版本经供参考0.0