Reverse Engineering Omega’s TradeStation Application

A couple of months ago, in a freelance projects, I found interesting request to de-compile TradeStation’s EasyLanguage (ELD) file.

Based on my research on the Net, Easy Language (EL) was developed in the mid-1980 by Omega Research of Miami, FL and it is a programming tool only useful to Omega’s TradeStation. Usually this file contains the strategy or utility that is related to online trading systems.

There is a source file version and compiled file version of ELD file. The compiled version is like executable version of some application, can be protected to prevent the TradeStation showing its source code.

When ELD file is protected for security and secrecy reason, the user can not see the original source code, but still can load it into the TradeStation platform so certain strategy can be executed.

In order to examine the protected ELD file creation process, I create some small TradeStation strategy named myTest2, consists of only variable declaration :

Then, I try to create the protected ELD file.

The protected ELD file is created by series of export wizard which instructs the user to select the category (Analysis Type) and name of strategy/analysis techniques to be exported (in my case is myTest2), the kind of ELD file, whether it is to be protected or un-protected and ends with specifying the file name for ELD file to be exported :

By performing the analysis of these mechanism, I’ve found that the TradeStation client program (ORPlat.exe) communicates with WHServer.exe using COM interface to generate the desired ELD file.

So, using the OLEView.exe provided by Microsoft, I’ve found several interesting methods that maybe related to the ELD file creation in WHServer.exe :

For example, one of interesting method to be examined is CreateProgram. But the problem is, how to locate the routine in WHServer.exe that corresponds to this method ?

Again, by using the OLEView.exe, it is found that the GUID of the interface that contains CreateProgram method is
7CEEA903-D59E-11D3-8394-00C04F7BDF10 :

By performing WinDBG’s memory search within the WHServer.exe address space for the GUID of this interface :

s 00000000 LFFFFFFF 03 a9 EE 7C 9e d5 d3 11 83 94 00 c0 4f 7b df 10

I’ve found several locations that hold this global memory, and by performing the memory access break at these location, I arrive at interesting routine that is called by MS Windows RPC’s invoke, which is typical pattern on server side method calls :

The memory at address 0x00432490 is a pointer to pointer to the GUID of IWHouse interface that we sought for. I suspect that this routine (0x00409B70) is QueryInterface method of IWHouse, because in typical COM infrastructure, the first 3 methods is always assigned to QueryInterface, Addref and Release methods.

The above three methods must exist, because every COM classes must be ultimately descended from IUnknown interface, and IUnknown always has these methods.

So, let’s examine what’s the routine doing in the case when the comparison from the given parameter yields the same with GUID located in 0x00432490 :

The memory at address 0x00432394 should be vftable of IWHouse interface, because it calls the offset 0x4 of vftable which is AddRef method.

By examining again the inheritance of this interface by OLEView.exe, this interface inherits from IDispatch which has several method, and after the last of these methods then we should arrive at CreateProgram method.

IDispatch has some methods like GetTypeInfoCount, a total of 4 (four) methods, by adding the 3 (three) methods from IUnknown with a total of 7 (seven) methods, so CreateProgram method is located at 8th routine (0x00417280) :

Does the suspected routine at 8th location (0x00417280) is CreateProgram method ?

From OLEView.exe this methods accepts 2 parameters which is type and name. Let’s examine the input parameter of this routine :

The second (ebp+0xC) parameter which contains the value 0x0003 is clearly some Type code, and at third parameter (ebp+0x10) that should contains the program name is indeed our test strategy name (myTest2).

Now, I am confident that the routine name at 0x00417280 should be CreateProgram, and the rest of the routines should be maps nicely to the methods list of IWHouse interface as provided by OLEView.exe application.

In the end, it is by no means that I can then continue on to get the above proposed projects (i.e. to carry out the ELD de-compiling task). To do this, there should be many steps included, and also steps that has the possibility to be sued by TradeStation’s program owner 🙂

This is only to demonstrate that the preliminary steps in Reverse Engineering process of this kind of architecture (in this case TradeStation’s program) is still possible.

This type of analysis can also be applied to the applications that do not provide the type library info such as TradeStation’s WHServer.exe application above. In this case, the RE process would be more difficult because the method names is unknown.

I will end this article by placing some notes to the reader : Any potential mis-use that will ends up getting sued by the owner of TradeStation program is beyond my responsibility.