OpenRCE

About Articles Book Store Distributed RCE Downloads Event Calendar Forums Live Discussion Reference Library RSS Feeds Search Store Users What's New

Customize Theme

Flag: Tornado! Hurricane!

Created: Tuesday, January 1 2008 13:43.13 CST Modified: Wednesday, January 2 2008 03:19.08 CST

Printer Friendly ...

Weird Code: CCs on the Stack

Author: RolfRolles

# Views: 1747

A friend of a friend wanted to know whether I had a better name in mind for the following function:



Write_CCs_To_Stack_WTF proc near



var_CC  = byte ptr -0CCh

var_8   = dword ptr -8



push    ebp

mov     ebp, esp

sub     esp, 0CCh

push    ebx

push    esi

push    edi

push    ecx

lea     edi, [ebp+var_CC]

mov     ecx, 33h

mov     eax, 0CCCCCCCCh

rep stosd

pop     ecx

mov     [ebp+var_8], ecx

pop     edi

pop     esi

pop     ebx

mov     esp, ebp

pop     ebp

retn



Write_CCs_To_Stack_WTF endp

I can't argue:  this sure does look like a WTF on its face.  If you don't often debug debug-build code compiled with MSVC, and know the trick behind this, then it's bound to be a mystery.  I can imagine all sorts of strange thoughts crossing one's mind when encountering this.

What's actually happening here is this.  As an aid to debugging, MSVC has a compiler switch (/GZ) that will force it to write 0xCC bytes atop uninitialized variables of any scope.  This is documented, amongst other places, here.  Notice that var_8 is also overwritten due to the length of the memset.  So /GZ explains the CC bytes on the stack.

Of course, we can clearly see that neither stack variable is used at all after it's declared/initialized, so that adds to the puzzling effect.  An optimizing compiler would have sensed (as the result of a global reaching assignments data flow analysis) that the variables had no uses, and would have eliminated both (and the initializing/saving of ecx code) altogether in its first dead code elimination phase.  Therefore I surmise that the compiler has all optimizations disabled (which makes sense in combination with the previous paragraph -- debug builds are typically unoptimized).

Further evidence for this "no optimizations" theory comes in noticing that ebx and esi are saved in the function's prologue and restored in the epilogue, despite neither being used throughout the course of the function.  This is called "register saving", and is subject to optimization when optimizations are enabled.  In fact, none of the registers need to be saved if the two dead variables and related initialization are eliminated.

With the stack variables eliminated and no alloca() present, the compiler can (and should) decide to use an esp-based frame instead.  The result is that the function needs no prologue/epilogue, and ebp no longer needs to be saved as above.

So really, this whole function should have been optimized down into one instruction:  "retn".  If whole-program optimizations had been applied (and/or devirtualization, if this is a virtual function -- I didn't see the references) this function would be a good candidate for inlining, in which case all call-sites to this function would simply disappear, and the function itself would not be present in the final binary.

Blog Comments

shegget	Posted: Saturday, January 5 2008 00:54.07 CST
awesome! good explanation and a nice reference link!

Active in Last 5 Minutes
	NimfCiste

There are 22,008 total registered users.

Recently Created Topics
How to call C++ func...	Sep/09
	Sep/09
Searching freelist[0...	Sep/05
How to fix this in o...	Sep/03
Trouble linking plug...	Sep/02
PyEmu error when cal...	Sep/02
Restore Themida/Winl...	Sep/02
Anti-olly technique	Aug/30
RAR Password	Aug/29
Heap protection on W...	Aug/23

Recent Forum Posts
Trouble linking plug...	timtoady
reverse engineering ...	Silkut
Trouble linking plug...	jduck
Trouble linking plug...	timtoady
Trouble linking plug...	jduck
Trouble linking plug...	timtoady
Trouble linking plug...	jduck
reverse engineering ...	raiden56
pydbg, memory breakp...	Researc...
RAR Password	Ineedhelp

Recent Blog Entries
	waleedassar	Sep/08
svchost from A to zinc part5
	waleedassar	Sep/06
svchost from A to zinc part4
	waleedassar	Sep/04
svchost from A to Zinc part3
	waleedassar	Sep/04
svchost from A to Zinc part2
	Mcstyle	Sep/03
Cheap Pegeout Partner Tepee...
More ...

Recent Blog Comments
	convik on:	Sep/04
Is it legal??
	djnemo on:	Sep/04
Gunpack (God's Unpacker) - ...
	frozenrain on:	Sep/02
Restore Themida/Winlicense ...
	tosanjay on:	Sep/02
PyEmu 0.0.2
	GynvaelColdwind on:	Sep/01
Is it legal??
More ...

Imagery

SoySauce Blueprint
Jun 6, 2008

[+] expand

View Gallery (11) / Submit