<轉> xor eax, ebp” being used

I just tried compiling a couple of C++ snippets on VS2010 and analyzed the executables on IDA Pro. Something I noticed is that there most of them have something like the following at the start(shortly after a call to __security_check_cookie)

<code>xor eax, ebp</code>

and something like

<code>xor ecx, ebp</code>

at the bottom. Why does this happen? The compiler optimization was turned off.

answer:

Stack corruption can either be caused by bad code along the lines of:

or by malicious users taking advantage of bad coding practices, like the use of <code>scanf ("%s", myBuff)</code> for user input. Carefully crafted attacks like that can suborn your program to do things you probably don't want it to.

By placing a cookie close to the return address, a large number of bugs (and attack vectors) can be prevented, simply due to the fact that the memory corruptions tend to be sequential in nature. In other words, if you've overwritten the return address, it's probably because you started writing on one side of the cookie and corrupted memory all the way up to the return address on the other side of the cookie (hence the cookie will be overwritten as well).

It doesn't catch all bugs since you may have some code like:

which could potentially corrupt the return address without touching the cookie. But it will catch all those malicious ones which rely on entering a longer string than expected, which corrupt up to the return address (including cookie).

The sequence you're probably seeing in the code is something like:

which is customising the cookie, depending on the current base pointer.

This will change what is actually put on the stack at each stack level (and also depending on parameter count and sizes as well) and is probably an attempt to further secure the code from malicious intent, by ensuring a variable signature is written to the stack rather than a fixed value (otherwise the attacker could enter characters including a valid cookie).

And the sequence at the end will run something like this:

The <code>__security_check_cookie()</code> routine is straightforward: if the cookie was unchanged, it executes the <code>RET</code> instruction and ends the function call. If the cookie fails to match, the routine calls <code>report_failure()</code>. The <code>report_failure()</code> function then calls <code>__security_error_handler()</code>. Both functions are defined in the <code>seccook.c</code> file of the C run-time (CRT) source files. CRT support is needed to make these security checks work. When a security check failure occurs, control of the program is passed to <code>__security_error_handler()</code>, which is summarized here:

By default, an application that fails a security check displays a dialog that states "Buffer overrun detected!". When the dialog is dismissed, the application terminates.