Reconstruction of Callstack Information

The callstack is a crucial information to do the track down of certain variable or structure of interest. In WinDBG, this information is invoked using the kv (or other command started with k) command. kv is my favorite 🙂

WinDBG retrieve the callstack information from the series of push command of the ebp register, having the pattern :

push ebp
mov ebp,esp

As long as the prefix certain routines in the application has the above pattern, the kv command will yield the correct callstack information.

But consider this pattern of the routine prefix :

push ebp
mov ebp,dword ptr [esp+14h]

This will in effect destroys previous callstack information, that will show typical callstack information below upon invoked by kv :

The above information will make us think that there are no more stack trace information below the return address after the traces of ip address of returned function starting at address 73dd2a69. In this case, the kv command will not have much usage.

However, it is still possible to reconstruct the destroyed callstack information by manually examining the address after the ret assembly command for each call.

In the above sample case, the ret after tracing the function that is called before address 73dd2a69 will yield the correct previous stack information.

In the case of multiple call of functions with the unusual pattern as above, then the combination of WinDBG’s wt, pa and examining the ret address manually is an indispensable method to reconstruct the missing callstack information.

It’s better to illustrate it by real case study as follows :

In the month of May 2009, I am performing the analysis of the WRK file creation of Omega’s TradeStation application in the event of exporting the ELD strategy to a file.

I’ve found when exporting ELD file from selected strategy name, TradeStation application creates the WRK files in the temporary folder below MyWork folder of TradeStation application folder :

This files is then compressed into one file (compress.tmp) and copied to user supplied ELD file name. As you can see from the above picture, the ELD file is actually consists of compressed files of CWRKArea.wrk, DWRKArea.wrk, MWRKArea.wrk, PWRKArea.wrk, SWRKArea.wrk.

The goal of my analysis at that time is to locate the precise routine that is generating those files. After performing the searching, I’ve found that the routine is located at 0x10153080 which is part of orlib20.dll address space.

This routine then calls the window’s kernel32!WaitForSingleObject, and after the calls to kernel32!ReleaseMutex, the WRK files in the previously empty temporary folder suddenly appears from nowhere, like magic 🙂

From the documentation, the WaitForSingleObject receive the handle that is created in previous routine. So, in order to determine the actual routine that creates WRK files, I have to first locate the routine that creates this handle and determine the object type of this handle.

When the information about this handle is obtained, then the next step is to hunt down of the details of WRK files creation.

The task of finding the previous routine is surely using the kv command, by examining the callstack. I’ve been thinking that it will be a matter of time before I can accomplish the goal of this project, but upon viewing the callstack information :

All I’ve got is just lots of zeros to begin with. Which means there’s no callstack information is available. Needless to say, this situation forced me to terminate this project, and move on to another projects. This is because I believe that the kv is the only and one method to get callstack information.

Later on, in another project activities that is occured on February 2010, I’ve notice that certain call prefix in some routine causes the previously abundant callstack information to be vanished.

By performing the back and forth analysis of this phenomena, I’ve found that after the return of the routine that causes the callstack to vanish, the previous stack information is restored perfectly.

This is the tangible proof that callstack information is not lost, just the flaw in the kv command that demands the certain prefix pattern in routine header to be working properly. In other words, the zeros from above picture is can be just a tip of an iceberg having many records of callstack level.

So, in the time span of about half a year, from the result of another project activities, I’ve suddenly found the breakthrough for WRK file creation hunt down project.

Now, instead of relying on kv command, I am now performing the “pa” command to the address 0x00f8d460. This is the parent address of routines that gets called when the user press the “Finish” button on the last step of ELD export wizard.

The above command will generates lots of step traces, and the next step is to locate and note each ret assembly command to reconstruct missing callstack information.

I can again said that it’s the matter of time before I can find the handle responsible for WRK file creation.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: