Share via

Debug Fundamentals Exercise 4: The GAMEOVER exercise

  • Article

 

We are back with another addition to the debugging fundamentals series here in 2009! Regardless of your debugging experience we hope you enjoy this one. Don’t worry too much if you can’t answer them all but give them your best shot.

The problem:

 

While debugging an application, a developer observes a crash and is puzzled. The developer saves a memory dump of the process using the command “.dump /ma dbgex4.dmp” and sends it to you for debug assistance.

0:000> r

eax=53454750 ebx=00000000 ecx=00000100 edx=000001b0 esi=001bfe20 edi=00ac36bc

eip=47414d45 esp=001bfe00 ebp=4f564552 iopl=0 nv up ei pl zr na pe nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246

47414d45 ?? ???

The attached zip, dbgex4.zip, includes three files. The program itself, the program’s symbols file and the saved memory dump file. (NOTE: You do not need to execute the program for the exercise however you may want to in order to solve the bonus’. You will need to rename the file dbgex4.ex_ to dbgex4.exe in order to run it).

Using the accompanying files, answer the following questions:

Part One – Debugging

1. What caused the access violation?

2. Examine the registers at the time of the crash. Is there anything interesting about the contents?

3. How did the registers get into this state?

4. Find the offending data structure which caused this state to occur. What are its contents?

5. Are there security concerns with this access violation? Why?

6.  Why is this class of crashes not seen in the wild much anymore?

Part Two – Reverse Engineering

Examine the functions main(), snap(), crack(), pop(), and boom().

1. Describe with a sentence or two what each one is doing. (There is no need to comment on every assembly instruction or re-write the code in C here unless you really feel you need to.)

Bonus:

1. If this access violation occurred while the program was running without a debugger present, would there be anything different about the crashing register state or the data structure which caused it? If so what is it and why? (HINT: If you would like to observe the crashing state like this, you can register windbg.exe to be the Just-In-Time debugger using the –I switch like so “windbg.exe -I”. When you run the dbgex4.exe program, it will crash and windbg.exe will launch automatically and attach to it.)

2. The functions from “Part Two – Reverse Engineering” perform operations on a set of data. During this manipulation some data is lost. Find this data and decode its “secret” message.

 

Share this post :

dbgex4.zip

Comments

  • Anonymous
    February 28, 2009
    The comment has been removed
  • Anonymous
    March 02, 2009
    so where do we find the answers, and better yet, the step through to solve this? Thanks! [We'll post the answers next week after everyone has a chance to work through the quiz. Thanks, Ron]
  • Anonymous
    March 02, 2009
    The comment has been removed
  • Anonymous
    March 03, 2009
    I have not had a chance to download the attachment but based on a quick look and having seen a lot of things like this in the past, I think I can offer a few answers shooting from the hip.
  1.       What caused the access violation? Not having looked at the dump, I would say that some sort of stack destruction was the culprit.
  2.       Examine the registers at the time of the crash.  Is there anything interesting about the contents? Absolutely - EIP and EBP (as well as EAX) all appear to have some sort of ASCII text (4 bytes) stored in them.
  3.       How did the registers get into this state? My guess is some sort of data overrun.  A temporary stack location used to hold a string and a sprintf() or similar call overran that buffer on the stack.
  4.       Find the offending data structure which caused this state to occur. What are its contents? Have not had a chance to look deeply into that.
  5.       Are there security concerns with this access violation? Why? Yes.  Malware can take advantage of this overrun and have valid instructions written instead of just text (ASCII).  Carefully crafted destruction can wreak all kinds of havoc and compromise security on a node (or worse).
  6.        Why is this class of crashes not seen in the wild much anymore? Hopefully, because developers are using Visual Studio 2005 (or newer) and have taken heed of the warnings about using unsafe functions such as sprintf(), strcat(), etc.  Best practices would be to modify existing code to use the secure C run time functions (like sprintf_s()) to help prevent buffer overruns and data corruption. Just my 2 cents from looking at only the register dump.  Here's hoping that many years of seeing this type of footprint has served me well. Mike

  • Anonymous
    March 05, 2009
    Hi GES team. Nice day and thanks for the “Happy debugging”. The secret message is the following: GAMEOVER Happy debugging courtesy of Platforms GES! Anyway, the access violation is caused by a corruption of stack, the edp is corrupted and move the eip to an incorrect memory area. This  memory area cannot read/write. Code resides only in a read memory area. The data structure used to corrupt the stack is the following: char buf[] = {0x74, 0x11, 0xD4, 0x54}; This crash is a protection introduced by the DEP. This feature provides the ability to sign a memory area that can be read or read/write. This protection try to avoid a runtime injection of malicious code. Is very difficult to introduce this kind of error in the day by day programming work.

  • Anonymous
    March 06, 2009
    the number of things done wrong in this program, are hard to count, lets see, procedures without returns, procedure that doesn't rebalance the stack (cause of crash), no string sanitization, string coping onto the buffer, the list is long and bad. Cause of access violation, I didn't look too hard, but simply, setup stack frame and then returns without disassembling the stack from, but from what I could see, you might overright the proper return address to boot. return caused eip, eax was set, the others I didn't look at, not sure if SEH changed ebp or if it was overwritten, didn't check too hard, the program is rather one big mess.

  • Anonymous
    March 08, 2009
    The comment has been removed

  • Anonymous
    March 13, 2009
    We’re posting the answers to Debug Fundamentals #4 in this blog. Additionally we posted all of your answers