从调试的可执行文件中查找内存断点

逆向工程 视窗 ollydbg 反调试 保护
2021-06-18 00:50:21

是否可以Memory Breakpoints从调试的可执行文件中找到(作为一种反调试技术?)。不,我不是指 Hardware BreakpointsDr0 - Dr7寄存器NOR INT3 \ code breakpoints .. 断点,就像在 OllyDBG 中一样,当您右键单击内存地址并在访问上设置断点时。

有什么方法可以找到这样的断点?我怎样才能避免被发现?

3个回答

您可以查询要验证的部分的页面级别属性。如果属性包含意外的值(例如PAGE_NOACCESS),很可能有人弄乱了您的页面(可能是调试器设置了内存断点)。

这篇博文对此进行了深入介绍:http : //waledassar.blogspot.com/2012/11/defeating-memory-breakpoints.html

... ...这个技巧可以很容易地检测到内存断点。它依赖于这样一个事实,即如果您尝试读取受保护或不可访问的内存,“ ReadProcessMemory ”函数将返回 false。要使用这个技巧,你所要做的就是调用“ ReadProcessMemory ”函数,其中“ Handle ”参数设置为0xFFFFFFFF,“ lpBaseAddress ”参数设置为图像基础,“ nSize ”参数设置为图像大小. 如果返回 false,则至少存在一个内存断点。

至于你的另一个问题——“我怎样才能避免被发现?” - 在这里回答:https : //reverseengineering.stackexchange.com/a/8510/1562

如果您不知道检测的工作原理,您就无法知道如何避免被检测到。我建议查找和逆向工程检测逻辑,以便您可以禁用它(修补它)或更好地了解如何避免检测。

AFAIK 这是可能的,只需读取您自己的内存并查找 0xCC 字节。然而,这带来了一个问题,因为几个编译器在函数之间插入了 0xCC 字节(我猜是内存覆盖的一种陷阱)

IDA 中显示的函数之间的 INT3 填充

因此,您要做的就是知道之前有多少“无辜”的 INT3 并检查异常情况。听起来很容易失败,恕我直言:)

剧透:IIRC,这是上次 Flare Challenge 中的反 RE 机制之一。