Breaking haX completely. We read machine codes as an open book

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

But all is not so bad. Even with scripting support disabled (HXCPP_SCRIPTABLE), lines with the names of methods and fields can be found in the file. We analyze how you can unwind this tangle, compare the names of the methods with their addresses and offsets in the table of virtual methods.

Bit of 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 overridden in classes translated in C ++, and their implementation everywhere looks something like this:


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

Training

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



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

The first stage: we are looking for dynamic wrappers

When both methods are found, you need to go to __Field, look where the branch goes after 0 == memcmp and give names to the wrappers. In this case, both ordinary fields and wrappers can come across. Learning how to distinguish them is easy, here is an example of an ordinary 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 integer operand of orange color. Via Ctrl + R, it must be made an offset in the IDA.

Second stage: the simplest cases

To begin with, let's see how generally after the translation in C ++ the methods and wrappers for them are located:


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

This is not entirely true, but at this stage only the most obvious cases need to be processed - when there is exactly one subroutine between dynamic wrappers, and most likely this is the method. He is given a name by a wrapper that is lower than him.

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

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

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

#define HX_DEFINE_DYNAMIC_FUNC0(class,func,ret) \
 ::Dynamic __##class##func(hx::Object *inObj) \
{ \
      ret reinterpret_cast(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 there are two nameless subprograms between dynamic wrappers 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, then these will be single spaces, and at this stage they will be eliminated.

The fourth stage: closing large gaps in VMT

Sometimes, there are big gaps in VMT, in two or more methods. Once again, we can note the convenience of looking from VMT. So, if you miss one method during the __Field traversal, it will look like three nameless subroutines between dynamic wrappers in the list of IDA routines, but hack can generate additional routines for other needs, and then three nameless subroutines between dynamic wrappers can also be obtained.

From VMT, you can see: if there is a space of two elements, then this is a missed dynamic wrapper in __Field. We find in the list of routines where this gap is, go to the middle routine, it should be a wrapper. Using X, we open the list of backlinks, among them there should be __Field. We go there, find out the name of the wrapper, the space in the list of subprograms is “dragged on” by a strip, and then we put the names of the methods according to the described algorithm.

Hx.Object methods

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

Defining data types for fields and arguments

When methods (like all virtual methods) are called on fields and arguments, you need to understand in which VMT to look for them, and for this you need to understand what types they generally are. If you do not run the debugger, dynamic wrappers help to do this. They receive arguments of formal types (Dynamic, Dynamic, Dynamic, ...) and, to make a call, they first cast Dynamic to the actual type expected by the method. During this transformation, it is just possible to recognize these very types.

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

.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

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

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

Static Fields and Methods

If a class has static elements, it overrides the static methods __GetStatic and / or __SetStatic. In VMT, for obvious reasons, they are not visible, but if the class has both static and regular elements, then the translated code goes in the order of __Field, __GetStatic, __SetField, __SetStatic, so knowing where __Field and __SetField you can calculate __GetStatic and __SetStatic next to them. There also at the beginning of the switch along the length of the string, and then the comparison operation.

Screencast

00:00 We find __Field and __SetField
03:00 The first stage: we are looking for dynamic wrappers
21:30 The second stage: the simplest cases
30:48 The third stage: when there are two routines between the wrappers
33:15 The fourth stage: we close large gaps in VMT
49:00 Hx.Object methods