SP（堆栈指针）反调试技巧 - x86
清单 7.1 级联病毒的解密器
lea si, Start ; position to decrypt (dynamically set)
mov sp, 0682 ; length of encrypted body (1666 bytes)
Decrypt:
xor [si],si ; decryption key/counter 1
xor [si],sp ; decryption key/counter 2
inc si ; increment one counter
dec sp ; decrement the other
jnz Decrypt ; loop until all bytes are decrypted
Start: ; Encrypted/Decrypted Virus Body
请注意，该解密器具有反调试功能，因为 SP（堆栈指针）寄存器被用作解密密钥之一。
有人可以解释一下为什么使用 SP 寄存器的行为就像反调试功能？如果我错了，请纠正我，但我不认为运行调试器会改变堆栈布局......
提前致谢
Listing 7.1 The Decryptor of the Cascade Virus
lea si, Start ; position to decrypt (dynamically set)
mov sp, 0682 ; length of encrypted body (1666 bytes)
Decrypt:
xor [si],si ; decryption key/counter 1
xor [si],sp ; decryption key/counter 2
inc si ; increment one counter
dec sp ; decrement the other
jnz Decrypt ; loop until all bytes are decrypted
Start: ; Encrypted/Decrypted Virus Body
Note that this decryptor has antidebug features because the SP (stack pointer) register is used as one of the decryption keys.
Can somebody explain why using the SP register is acting like an anti-debug feature? Correct me if I'm wrong but I don't think having a debugger running changes the stack layout...
Thanks in advance
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我的 x86-fu 已经生锈了，但我似乎记得大多数断点调试工具都是通过触发 CPU 中的故障并将自己声明为主管进程来工作的 - 这将为您提供一个新的堆栈以及相应更改的堆栈指针。因此，单步执行该代码将为您提供
sp值，这些值与进程在没有被调试器捕获时通常看到的值不同。My x86-fu is rusty, but I seem to recall most breakpoint debugging tools work by triggering a fault in the CPU and asserting themselves as a supervisor process - which would give you a new stack, and a correspondingly-altered stack pointer. Thus, stepping through that code would give you values of
spwhich are different to those the process would normally see had it not been trapped by a debugger.大多数调试器期望 [e]sp 有效并指向堆栈区域。我想如果 sp 没有指向有效内存，一些调试器可能会崩溃，但我不知道有什么。
Most debuggers expect [e]sp to be valid and pointing to a stack area. I guess it's possible that some debuggers crash if sp does not point to valid memory, but I don't know of any.
设置断点或中断会将数据“推入堆栈”，这将损坏堆栈指针引用的区域中的数据字节。因此，如果您使用调试器在代码中放置断点 (INT n)，则您的调试行为（遇到断点）将破坏该代码尝试解密的数据。
如果没有发生中断，这段代码可能会在 DOS 下运行；也许他们首先禁用中断。实际上，您无法在 Windows 或 Linux 下使用它（无论如何都是 16 位代码）。
Taking a breakpoint or an interrupt will "push data onto the stack", which will damage the data bytes in the area that the stack pointer references. Thus, if you put a breakpoint (INT n) in the code using a debugger, your very act of debugging (encountering the breakpoint) will destroy the data that this code is trying to decrypt.
This code might work under DOS if no interrupts happen; maybe they disable interrupts first. You can't realistically use this under Windows or Linux (its 16 bit code anyway).
如果堆栈段等于数据段（是.com还是.exe病毒？好像是.com，因为DS已经等于CS），那么任何堆栈的使用（调试器甚至中断）都会修改ss所在的内存:[sp] 正在指向，它将指向病毒体内的某个地方（因为它被用作计数器）。
If the stack segment is equal to the data segment (is it .com or .exe virus? seems .com, because the DS is already equal to CS) then any use of stack (debugger or even interrupt) will modify the memory where ss:[sp] is pointing, and it will be pointing somewhere in the virus body (because it's used as counter).