We break haks completely. We read machine codes as an open book.

If haXe is translated in C ++, and from it into machine codes, this may seem hopeless, especially since at first glance this code is replete with calls to virtual methods, which, without running the debugger, are difficult to correlate with the addresses of the method bodies.

But it's not so bad. Even with script support disabled (HXCPP_SCRIPTABLE), strings with method and field names can be detected in the file. We analyze how to unwind this tangle, compare the names of the methods with their addresses and offsets in the table of virtual methods.

Some theory

After translation in C ++, all haXe classes are inherited from hx.Object (defined in hxcpp / include / hx / Object.h ). Of particular interest are the following methods:

virtual Dynamic __Field(const String &inString, hx::PropertyAccess inCallProp); virtual Dynamic __SetField(const String &inField,const Dynamic &inValue, hx::PropertyAccess inCallProp); 

These methods are redefined in classes translated in C ++, and their implementation everywhere looks something like this:
')

As you can see, the fields in the understanding of the haX translator turn out to be not only what is usually considered fields, but also methods, however, in dynamic wrappers from which they have yet to be pulled out.

Training

Accordingly, it is worth starting with finding the __Field method. For example, it can be accessed by return link to the string with the name of the method. If you read what lines are in the file, then you can get back links, for example, in __ToString or RTTI. Of these, the reverse link must go to VMT. If the string is a field name, then instead of __Field you can get into a similar __SetField method, which is worse, since there are no references to dynamic wrappers for methods. While in VMT, open the overridden methods (allocated to addresses) and look for which ones are similar to __Field (you can see a large switch at the beginning):



__Field in the virtual method table is earlier than __SetField, and there are usually fewer options. In this example, 13 vs 28.

First stage: looking for dynamic wrappers

When both methods are found, you need to go to the __Field, look where the branch goes after 0 == memcmp and give the names to the wrappers. This can come across as ordinary fields, and wrappers. It’s easy to learn how to distinguish them, here’s an example of a normal field, then a dynamic wrapper for a method:

 .text:010B44B0 loc_10B44B0 ; CODE XREF: __Field+16A↑j .text:010B44B0 LDR R0, [R5,#0x20] .text:010B44B2 B loc_10B4582 .text:010B44B4 ; --------------------------------------------------------------------------- .text:010B44B4 .text:010B44B4 loc_10B44B4 ; CODE XREF: __Field+1B0↑j .text:010B44B4 LDR R2, =(get_error_dyn+1 - 0x10B44BA) .text:010B44B6 ADD R2, PC ; get_error_dyn .text:010B44B8 B loc_10B44D2 

There was, but not in this file, such a problem that pointers to wrappers are not recognized. It looks like an abnormally large orange integer operand. Via Ctrl + R, in IDA it is necessary to make it offset.

The second stage: the most simple cases

First, let's look at how methods and wrappers for them are located after translation in C ++:


It can be seen that the body of the method goes first, then the macro constructs a dynamic wrapper, then the next method, then a dynamic wrapper for it, and so on. Since the names were given to the wrappers at the first stage, but not to the methods proper, the IDA subroutine list should have a “striped” picture when the named subroutines are interspersed with the named ones.

This is not quite true, but at this stage only the most obvious cases need to be handled - when there is exactly one subprogram between the dynamic wrappers, and, most likely, this is the method. He is given the name on the wrapper, which is below him.

Caution : there were cases, but not in this file, when IDA did not recognize the body of the method as a subroutine, but it did recognize something auxiliary, going after the method. This method is backlink from VMT.

The third stage: when there are two subprograms between the wrappers

Dynamic wrappers are created by a macro that looks like this :

 #define HX_DEFINE_DYNAMIC_FUNC0(class,func,ret) \ ::Dynamic __##class##func(hx::Object *inObj) \ { \ ret reinterpret_cast<class *>(inObj)->func(); return ::Dynamic(); \ }; \ ::Dynamic class::func##_dyn() \ {\ return hx::CreateMemberFunction0(this,__##class##func); \ } 

As you can see, two wrappers are created here at once, typed and untyped, but typed is usually thrown out by the C ++ translator as unnecessary. If between dynamic wrappers there are two nameless subroutines at once, then, most likely, the first of them is the desired method, and the second is a typed wrapper.

By the beginning of the third stage, most of the methods should already be named, so if you look from VMT, these will be single spaces, and at this stage they will be eliminated.

Stage Four: Close Large Spaces in VMT

It happens that there are large gaps in the VMT, two or more methods. Once again, the convenience of looking from VMT can be noted. So, if you miss one method while traversing __Field, it will appear in the list of IDA subroutines as three unnamed subroutines between dynamic wrappers, but haX can generate additional subroutines for other needs, and then three unnamed subroutines between dynamic wrappers can also be generated.

From VMT, you can see: if there is a gap of two elements, then this is the missing dynamic wrapper in __Field. We find in the list of subroutines where this space is, go to the middle subroutine, it should be a wrapper. With the help of X, we open the list of backlinks, among them should be __Field. We go there, find out the name of the wrapper, the space in the list of subroutines is “tightened” by a strip, and then follow the described algorithm with the names of the methods.

Hx.Object methods

For completeness, you can open hxcpp / include / hx / Object.h , write out all the virtual methods in order, and identify the methods at the beginning of the VMT.

Defining data types of fields and arguments

When the fields and arguments are called methods (like all virtual), you need to understand in which VMT to look for them, and for this you need to understand what types they are. If you do not run the debugger, dynamic wrappers help to do this. At the input, they receive arguments of formal types (Dynamic, Dynamic, Dynamic, ...) and, in order to make a call, they first lead Dynamic to the actual method expected by the method. During this conversion, it is just possible to find out these same types.

For example, if in the body of the wrapper we see:

 .text:010B3884 LDR R1, =(off_23DE1D4 - 0x10B388E) .text:010B3886 MOVS R3, #0 .text:010B3888 LDR R2, =(off_23E04A0 - 0x10B3890) .text:010B388A ADD R1, PC ; off_23DE1D4 .text:010B388C ADD R2, PC ; off_23E04A0 .text:010B388E LDR R1, [R1] ; hx_Object_ci .text:010B3890 LDR R2, [R2] ; off_22D9DE0 .text:010B3892 BLX.W __dynamic_cast 

... it can be seen that the cast from hx.Object to something else is done. If you have not yet identified hx_Obejct_ci, then both classes will be unknown, but this is solvable. We look at whose pointers they are writing in RTTI (in this example, off_22D9DE0), we put down the names, we draw conclusions.

Similarly, for fields, __SetField comes in handy, which is forced to cast the Dynamic type to the actual field type, thereby giving a hint.

Static fields and methods

If a class has static elements, it will override the static methods __GetStatic and / or __SetStatic. For obvious reasons, in VMT, they are not visible, but if the class contains both static and normal elements, then the translated code goes in order __Field, __GetStatic, __SetField, __SetStatic, so that, knowing where __Field and __SetField, you can calculate __GetStatic and __SetStatic next to them. There is also at the beginning of the switch on the length of the line, and then the comparison operation.

Screencast

00:00 Find __ Field and __ Set Field
03:00 First stage: we are looking for dynamic wrappers
21:30 Second stage: the simplest cases
30:48 The third stage: when there are two subprograms between the wrappers
33:15 Stage Four: Close Large Spaces in VMT
49:00 hx.Object Methods