如何解决C ++编译器输出中使用“ xor eax,ebp”
| 我只是尝试在VS2010上编译几个C ++代码片段,然后分析了IDA Pro上的可执行文件。我注意到的是,其中大多数在开始时都有以下内容(在调用__security_check_cookie之后不久)xor eax,ebp
和类似的东西
xor ecx,ebp
在底部。为什么会这样?编译器优化已关闭。
解决方法
这些是缓冲区溢出保护方法,与编译器优化无关。 MSVC将(如果您指定“ 2”开关)将安全cookie推送到返回地址附近的堆栈上,以便它可以检测到堆栈损坏的常见情况。
堆栈损坏可能是由以下方面的错误代码引起的:
char buff[5];
strcpy (buff,\"Man,this string is waaay too long!!\");
或恶意用户利用不良的编码做法,例如使用“ 4”作为用户输入。诸如此类的精心设计的攻击可能会使您的程序无法执行您可能不希望做的事情。
通过将cookie放置在返回地址附近,可以避免大量的错误(和攻击向量),这仅仅是因为内存损坏本质上是顺序发生的。换句话说,如果您覆盖了返回地址,则可能是因为您开始在cookie的一侧开始写入,并且破坏了内存,一直到cookie另一侧的返回地址为止(因此Cookie也将被覆盖)。
由于您可能有类似以下的代码,因此无法捕获所有错误:
char buff[5];
buff[87] = \'x\';
这可能会破坏返回地址而不接触cookie。但是它将捕获所有依赖于输入比预期更长的字符串的恶意代码,这些恶意代码会破坏返回地址(包括cookie)。
您可能在代码中看到的序列类似于:
mov eax,dword ptr ds:___sec_cookie ; fixed value.
xor eax,ebp ; adjust based on base pointer.
mov [ebp+SOMETHING],eax ; store adjusted value.
根据当前的基本指针,它正在自定义cookie。
这将改变每个堆栈级别上实际放置在堆栈上的内容(并且还取决于参数数和大小),并且可能是通过确保将变量签名写入堆栈来进一步保护代码免受恶意意图的尝试。而不是固定值(否则,攻击者可能会输入包含有效cookie的字符)。
最后的序列将如下所示:
mov ecx,[ebp+SOMETHING] ; get the adjusted cookie.
xor ecx,ebp ; un-adjust it,since
; ((N xor X) xor X) == N.
call @__sec_check_cookie ; check the cookie.
它基本上只是上述过程的逆过程。仅当将“ 9”设置为正确的cookie值时,才返回“ 8”调用。否则,将引发故障,如下所示:
__security_check_cookie()
例程很简单:如果cookie没有更改,它将执行the11ѭ指令并结束函数调用。如果cookie匹配失败,则例程调用report_failure()
。
然后,report_failure()
函数将调用__security_error_handler()
。这两个函数在C运行时(CRT)源文件的“ 15”文件中定义。
需要CRT支持才能使这些安全检查起作用。当发生安全检查失败时,程序的控制权传递到__security_error_handler()
,在此处总结如下:
void __cdecl __security_error_handler(int code,void *data)
{
if (user_handler != NULL) {
__try {
user_handler(code,data);
} __except (EXCEPTION_EXECUTE_HANDLER) {}
} else {
//...prepare outmsg...
__crtMessageBoxA(
outmsg,\"Microsoft Visual C++ Runtime Library\",MB_OK|MB_ICONHAND|MB_SETFOREGROUND|MB_TASKMODAL);
}
_exit(3);
}
默认情况下,未通过安全检查的应用程序将显示一个对话框,指出“检测到缓冲区溢出!”。取消对话框后,应用程序终止。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。