[简介]
常用网名: 猪头三
出生日期: 1981.XX.XX
个人网站: https://www.x86asm.org
QQ交流: 643439947
编程生涯: 2001年~至今[共20年]
职业生涯: 18年
开发语言: C/C++、80x86ASM、PHP、Perl、Objective-C、Object Pascal、C#、Python
开发工具: Visual Studio、Delphi、XCode、Eclipse
技能种类: 逆向 驱动 磁盘 文件
研发领域: Windows应用软件安全/Windows系统内核安全/Windows系统磁盘数据安全
项目经历: 磁盘性能优化/文件系统数据恢复/文件信息采集/敏感文件监测跟踪/网络安全检测

[序言]
我在2018年开始为某软件进行二次开发并以插件形式发布且一直运行良好(备注:该某软件的二次开发是合法的, 它提供官方接口进行挂接). 但是随着该某软件的发展势头越来越好, 国内用户量越来越大, 导致针对该某软件的二次开发的行为开始泛滥且进行三次深度开发, 把该某软件的功能修改得比官方还要强大. 因此官方在前年也就是2019年下半年开始用VMProject 3.x进行加壳保护, 直到今年现在2021年08月份, 竟然使用了VMProject 3.5最新版进行加密. 为什么在去年2020我一直没有处理该某软件的VMProject 3.x脱壳. 因为我的插件已经完成并正常运行很久, 没有代码调试的需求, 而且也不需要深度定制该某款软件. 但是直到2021年3月份, 我发现我的插件有一个小bug, 需要修复并进行调试, 结果下载最新版的该某软件进行调试测试时发现, Visual Studio 2019竟然无法对插件源码下断点, 导致我无法修复插件的bug. 直到2021年的今天08月27日我才有空开始针对该某软件VMProject 3.x进行脱壳, 以便修复我的插件的bug.

[这次脱壳我用了多长时间]
周5开始部署逆向环境, 然后周6开始脱壳, 周日完成脱壳任务. 周6和周日, 2天每日用4个小时分析, 总计时常8小时, 找到了该某软件的OEP并完成了Dump.?

[开始部署逆向环境]
本人从2005年开始接触逆向, 到现在也有16年的经验. 但逆向技术只是我编程生涯里面的一个辅助技术, 由于长年从事Windows系统的安全软件开发的缘故, 所以一直会接触逆向的相关技术研究. 废话不多说, 写这个[部署逆向环境], 其实是为了记录并方便以后不在另外花费时间重新摸索配置一轮.

1> 在VMware安装原版的32位Windows7旗舰版sp1
2> 配置x64dbg动态调试器. 尽量使用最新版. 然后解决x64dbg默认配置无法显示中文的问题.
解决方案: 菜单->选项->外观->字体 全部选择 "仿宋" 即可. 当然为了美观, 字体样式配置为"常规"和"9号大小", "应用程序"字体样式配置为"加粗"
3> 安装x64dbg动态调试器的插件: ScyllaHide和x64dbg_tol, 尽量使用最新版.

[VMProject 3.x和VMProject 3.5逆向过程中碰到的一个最烦人的问题]
我很少去脱带有高度Anti-Debug模式的VMProject3.x甚至VMProject 3.5这样的高阶版, 原因很简单: 我不是靠逆向吃饭的. 好了, 回归正题, 一般逆向初学者在接触VMProject的时候, 碰到一个最烦人的问题就是下面这个提示:
"A debugger has been found running in your system. Please, unload it from memory and restart your program"

其实我也尝试搜索了相关的文章(我也很懒, 不想自己摸索), 竟然发现没有人分享. 就算有相关文章可查询, 但都解释得很肤浅, 大多数停留在"多更换几个Ollydbg版本试试", "使用SharpOD插件看看", "使用StrongOD行不行", 甚至还有"更换操作系统版本, 用Windows XP"...等等太多毫无意义的建议.

[我是如何处理和绕过VMProject的反调试呢? 其实很简单, 很巧妙, 我是站在巨人的肩膀上完成任务]
周末2日, 我在处理VMProject 3.x/3.5的时候, 发现一个现象: x64dbg加载了ScyllaHide默认的VMProject的Anti-Anti-Debug策略之后, 对该某软件的旧版调试, 没有"a?debugger has been found running in your system"的提示, 但是该某软件的新版就有. 由此可证明该某软件的旧版使用VMProject 3.x低阶配置版, 而新版的应该是升级使用VMProject 3.x甚至可能是VMProject 3.5的高阶版并打开了高强度Anti-Debug模式. 然后我就进一步分析是什么样的情况下触发debugger被检测呢? 慢慢找规律, 结果发现是 只要下"硬件断点", 就被检测到. 知道这个规律就好办了, 说明最新版的VMProject 3.x/3.5对"硬件断点"的检测机制进行了更新. 那么我就去思考一下反"硬件断点"检查的技术有哪些, 通过查阅目前主流的Anti-Anti-Debug的相关技术资料, 结果发现: KiUserExceptionDispatcher 这个技术细节最贴近了. 然后我马上重新对ScyllaHide默认的VMProject的Anti-Anti-Debug策略进行调整, 结果发现竟然有"KiUserExceptionDispatcher"的选项, 马上毫不犹豫选上"DRx Protection"->"KiUserExceptionDispatcher", 经过测试, 完美绕过最新VMProject 3.x/3.5高阶版的Anti-Debug机制. 内心发自赞美: ScyllaHide实在太强大了!! 这里附上配置图:

[总结和建议]
希望这篇文章让逆向初学者得到帮助并学会我的逆向分析逻辑思维, 也希望那些尝试逆向VMProject 3.x甚至VMProject 3.5以上的高阶版初学者, 不再被"a?debugger has been found running in your system"所困扰. 另外给一个中肯的建议: x64dbg太好用, 手感太好, 配合ScyllaHide无敌了! ^_^