Omega TradeStation’s WRK File Creation

In my previous article about “Reconstruction of Callstack Information”, I’ve explain the method to perform workaround in case of failed kv command in WinDBG.

The workaround is created to solve the case of failed kv command at the time of the execution steps below in Omega’s TradeStation WRK file creation :

101530e3 push ecx
101530e4 call ebx {kernel32!WaitForSingleObject (7c802530)}
101530e6 mov edx,dword ptr [esi+72h]

The WRK file is created below some temporary folder with the prefix EL*.tmp. This temporary folder in return resides below MyWork folder in TradeStation program directory (for example C:\Program Files\TradeStation 8.5 (Build 2274)\).

So, when I am performing bp at address 0x101530e3 and watch over the files below EL*.tmp folder, the previously empty folder will be filled with CWRKArea.wrk, DWRKArea.wrk, MWRKArea.wrk, PWRKArea.wrk, SWRKArea.wrk files, after the call to WaitForSingleObject (i.e. when I am performing break at address 0x101530e6).

The handle at ecx register is surely created earlier in previous routine. What kind of the object created for this handle ? To answer this question, the next logical step is to examine the stack information.

But as I have already stated earlier, in this case, the kv command yields no information about the stack that eventually leads to the filling of handle that resides in ecx register :

0:000> kv
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
00000000 00000000 00000000 00000000 00000000 orlib20!LoadInputBlock+0x14836

So, by applying the workaround that is described in my previous article, I’ve arrive at :

10151aaa mov dword ptr [ebx+6Ah],eax

This eax register value is the result of :

10151aa3 call esi {kernel32!CreateEventA (7c8308b5)}

So, the handle value that is used in WaitForSingleObject is an Event Object. To prove this conjecture, I can performing break at 0x10151aaa and then compare the result handle value to ecx register at 0x101530e3 execution address.

Actually, it is the second break at 0x10151aaa will yield the proved result that handle value at eax is indeed equivalent with handle at ecx value.

It is now clear that the WaitForSingleObject routine at address 0x101530e4 is waiting for some event to happen before continuing the next executions.

There should be some other threads that gets executed whenever WaitForSingleObject is used in an application.

In the case of TradeStation, this thread is located at :

10151410 mov ecx,dword ptr [esp+4]
10151414 call orlib20!LoadInputBlock+0x16aa0 (10155350)

So, the main routine for this thread is 0x10155350.

Now, the task is get a little more easier, because I can examine the equivalent SetEvent routine for the requested handle inside this thread routine. For those who are curious, the SetEvent is called whenever the thread wants to inform or signal the waiting routine/thread that certain execution is finished. This SetEvent API call is located at :

101554b1 mov eax,dword ptr [esi+6Ah]
101554b4 push eax
101554b5 call dword ptr [orlib20!LoadInputBlock+0x3e794 (1017d044)] ds:0023:1017d044={kernel32!SetEvent (7c80a0b7)}

The value at [esi+6Ah] is the event handle of interest, i.e. handle that is being waited at address 0x101530e4.

I just said that it is a little more easier, because actually there are many SetEvent at the above address for the same event handle value, so I have to examine it one by one, before I located the exact WRK file creation at :

10157516 call dword ptr [ecx+24h] ds:0023:002413c4={RPCRT4!ObjectStublessClient9 (77e7e1ea)}

The ecx value, after close examination, is happen to be pointer to IWHouse interface, and the method # 9 in this case is :

HRESULT ProgramByName(short Type, BSTR Name, [out, retval] IDispatch** pVal);

This interface method is responsible for creating the above 5 WRK file, in the form of compound file storage object, using
StgCreateDocfile function.

Actually, this is just a start, because the WRK file at this phase is still just like an empty paper sheet, ready to be written with some data.

But, at least, this explain the mysterious spontantaneous file existence below this temporary folder after the WaitForSingleObject is called.

The actual data writing routine is still not yet explored at this time, but it is sufficed to say that after all the WRK file is prepared, the EL*.tmp folder is compressed and the copied to the ELD file name supplied by user.

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: