Descriptions of Omega TradeStation’s CWRKArea.WRK File

In the article about Decompression utility, I’ve use the viewer utility to show the portion of the record in CWRKArea.WRK file. This file is supposed to contain the compiled strategy source code, but how the TradeStation use this record ?

To answer the above question, the obvious place to look for is at the Import Wizard routine. There should be some routine that process the record and append it into the TradeStation Platform’s data.

By performing some analysis at Import Wizard routine and by using the method I’ve describe about trapping the thread routine at WaitForSingleObject function, the access to code record is started at :

Because it is already identified that the call to ecx+18h is the call to some object in WHServer.exe, and also in my previous article the objects in WHServer.exe is derived from IDispatch interface, then the NdrProxyForwardingFunction6 should refer to Invoke method of IDispatch interface.

Invoke method is well-documented by Microsoft and it contains several parameters as described by the commented code snippet above. The 0x1 flag indicates that Invoke method is calling some method that corresponds to 0x5DC dispatch id member. What’s important is a series of move (the blue box) to the pDispParams, which indicates that this method do not using any argument. So the sole result of this call should be the pVarResult.

Let’s examine the returned value after the call to this method :

At a glance, the retrieved code record should consists of the header portion and the actual data portion. By looking at the boundary, it seems that the header size is 0x44. This is proved by the access to this record by some routine at import wizard that specify 0x44 as the length of memory bytes.

Below this header record starting with 0x8644 is hopelessly meaningless bytes of data. Facing with this kind of information, there are several possibilities, with the topmost two is whether this data is compressed, or whether it is encoded.

By performing detailed examination of the header bytes, it is indicated that the second candidate, i.e. that the data is encoded is a most likely one. It is proved by the value of 0x20 (red box) which is the key length and 0x10 (blue box), which is block length. This information will be used subsequently for decoding the code data record.

Hunting down the routine responsible for decoding the encoded record lead me to the precise location of decoding routine :

The add instruction strongly suggests that 0x44 is indeed the size of the header portion. After this operation, this, in effect will put the eax pointer to the first byte of code data record that starts with 0x86 byte. You can also see from the call address, which is 0x10169920 is not an exported function, which means it is internally used by TradeStation Platform.

This also means it is next to impossible to create an utility for decoding routine, just like the one I created for decompression utility.

By examining the argument before and after the call, it is indicated that the edx value points to the decoded code record. So, by performing the breakpoint just after this call, and examining the edx content :

We now at last have some meaningful data at hand. The decoded code record revealed a wealth of information, among the other things, one of it is the actual compiled strategy source code that gets executed when certain strategy routine is invoked. For ELD decompilation enthusiasts :), this is an important piece of information.

Viewed as data format, the compiled code looks like this :

But when using the dissasembly utility such as WinDBG, the code will look like this :

Which is a perfect and legal assembly code. While it is still a long mile to go from the compiled code to the decompiled code, let alone to create an application for this task, yet this is a very important starting point that shouldn’t be missed šŸ™‚


10 Responses to “Descriptions of Omega TradeStation’s CWRKArea.WRK File”

  1. john Says:

    Hi, ekasiswanto

    How can we use windbg to get what you have done. I try kv command but itsn’t working. And in wich dll or exe can we spot the code that you have display in this article. Do you load the Orplat.exe or you execute the orplat.exe and attach after dll or exe.

    Keep the good work. I read all your article.

  2. john Says:

    And I would like to know if it’s possible that the code generate in CWRKArea.WRK be paste in the unprotected zone to be decompile from the tradestation platform?. Because the assembly code that generate the protected file maybe it use the same thing in the unprotected file. If it’s the case the then maybe copying the code from the protected file to the other file that it’s unprotected and then… decompile code.

  3. john Says:

    ok, I found the byte that are locate with OLLYdbg.exe

    They are in the orlib20.dll at bp 10169e37.

    The thing that I remember his that the two website that offer the decompilation service are putting both in the decompile file the line

    #EVENTS OnDestroy = EasyLanguageRtlOnDestroy ;
    #END ;

    and at the memory address that are putting the 5B 8B… code. If you look a bit up in the memory map you will see EasylanguageRtlOnDestroy. Maybe it will give some clue where to go next.

    Hope that will help

  4. ekasiswanto Says:

    Sorry for the late reply, I just coming back and logged on after the weekend. For your question about protected/unprotected ELD file, if you choose the unprotected option, then the source is available at SWRKArea.wrk, as for the protected option, the SWRKArea.wrk is generated but the platform do not write anything there.

    So, basically, at protected ELD file, you have only compiled strategy code at hand and have to work all the way to create real decompilation routine for yourself.

    If you try to open the imported protected ELD file, you will get very familiar message that says you can’t view the protected strategy, this I suppose because the platform do not see any record in imported SWRKArea.wrk file, but this conjecture has to be proved for sure.

    Because you’ve already found the address, I suppose you can now view the decoded code record in CWRKArea.wrk for yourself isn’t it ? šŸ™‚

    Are you also studying this application, i.e. TradeStation ?

  5. john Says:

    I saw the decode code taht you mention. it’s seem to be a partial decode code. I saw that when you have text in this section. You see it in the code but not the rest of the code you don’t. I was thinking about there debugger that tradestation use. They can retreive information about a funtion or indicator that you have put a breakpoint in the code and run it. You will discover that you the debugger will say some information about the vars(ex.intrabarpersist) and other things. Can this debugger hide some information that they aren’t show in the debugger interface but show in the memory of the program.

    I look to tradestation decompilation process. I’m not a programmer but I try to learn new thing all the time.

  6. Eka Siswanto Says:

    You can determine the size of code record from the size of the M_3_Code stream object (shown in some of the picture of my previous article), minus the header size which is 0x44.

    As far as I know, the debugger actually retrieves its information solely from this record (i.e. variables, function names, function’s parameter, etc), but not the actual source code, if the ELD file is a protected one.

    Also I don’t see the facility to perform break-point on-the-fly, or at least view the source, even for unprotected strategy when the debugger runs.

    I see that you’re not a programmer, so what’s your current main activities ?

  7. john Says:

    I’m mainly a part time Trader. šŸ™‚

    Do you think that we will need a decompiler that read the assembly language from the code?.

  8. john Says:

    I forgot that Multichart read unprotected source code from ELD file. Do you that they program there own decompiler?

    THx for your fast answer

  9. Eka Siswanto Says:

    I think, yes, in the end, a decompiler should be made. I don’t see any short-cut as of now. At the last, I hope to find some form of intermediate meta-data before it is generated to actual executable code within the decoded code record. It’s called object file in compiler jargon.

    For unprotected ELD, the source is inside SWRKARea.wrk. You can see it for yourself. You can try to export some analysis un-protected, then extract / decompress the ELD file.

  10. Dan Says:

    Hi, ekasiswanto

    Reading through your article and following the instructions using TradeStation 9.5.

    I was able to reach to the point where the call to WHServer is returned and find the strategy code, however I couldn’t get to the point where the code is decoded (add eax, 44h ….).

    Any ideas?


Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: