Started Reverse Engineer GW2 and need some advice

[RevEngRazer]

Hey guys,

I recently started to reverse engineer gw2 myself. But I am a bit stuck and I was hoping for some advice I first want to tell you what I found out and I was hoping you guys could correct me if I got something wrong. If you could give me some tips in what direction I shall looking more into, I would highly appreciate it. Also I am kind of new to all this (coming from a developer standpoint), so I also would love to know more tools, plugins, features, ... I should have a look at

So let me get started.

assert() function

Most of the strings in the binary are part of an “assert()” function with some debug information. This is a gret source to figure out certain passed parameters/variables as well as in what file this function was defined. My question is, most of those functions are probably class methods. Can I most of the time assume that the first parameter (probably on the stack) is the this pointer to the object this method belongs to? If so, how can I get from there to the corresponding vtable?




RTTI and vtables

I found an old gw2 beta torrent where the gw2.exe was still compiled with RTTI. On OpenRCE I found a “ClassInformer” (
) plugin to gather the RTTI and vtable information.



With this it is pretty cool to reverse engineer the class hirarchy structure, as well class functions. Though it’s the first time doing this, and I still haven’t understood completly how vtables are corresponding to classes and how you guys find these pointers to other objects (for example “chcontext+38h = charakter + 44h = agent + 1ch = world” - ). As far as I understand, what you can see on this screenshot is the virtual function table. Which means there are no information about the attributes, right? Can I search the memory for objects pointing to the vtable information, to find the objects in memory and then reverse engineer the attributes?

Class hirarchy, ChContext and pointers

I have read a lot of Threads here and I often find class hirarchies like the following - “ChContext->Character->Agent->World->EntityInWorld->Speed” (). How did you guys figure out those class names and hirarchies? And how did you find the offsets? Were you looking for the memory address with CheatEngine and then did a pointer scan? I was not able to get those pointer paths myself. Any tips for the pointer scan settings or common pitfalls?

It seems like ChContext is the “base” class and from there you can get to all important information. But I can’t find any refernce to ChContext. But there exists a View::CContext. Is this the same?
Also I see WorldViewInt::CContext, View::Context, WorldMapModel::CContext, WvwClient::CContext, … and many more. How do they differ? Or are they basically the same, and it just depends on if you are currently in PVE, WvW, …

Based on a comment in an autoupdater source () I found the following function and address in the current build. Is this the ChContext/CContext? If so, why can’t I follow the many pointer examples like: ChContext+38h -> Charakter + 44h …
How did you guys find this function in the first place? With pointer scans in CheatEngine? Or did you find it statically?



Would appreciate any input
I would love even more to chat with somebody about it. Would be really cool if somebody could share some experience and information with me.
Thank you very much in advance,
kind regards,
RevEngRazer

Here is the link to another project I am working on, so you can estimate my skill level:

[Xereon]

Can I most of the time assume that the first parameter (probably on the stack) is the this pointer to the object this method belongs to? If so, how can I get from there to the corresponding vtable?

No. An assert is an assert, they can check anything they want with them. If the assert condition dont tell you that it is a class method you cant assume that. Though most modern computer programs organize their application logic in classes, that doesnt mean that they dont use any regular functions anymore. Besides that, static methods are compile to the same as regular functions.

Next point: What are calling conventions? Apparently you already know the basics how functions are called usually, but there some other ways to call functions one of them being called a . When a method is called through a __thiscall the this pointer is passed in ECX. Thats the reason why you can assume most of the time ECX is accessed (like MOV EAX, [ECX + 8h]) and not set before, the this pointer is accessed. The example shown before is a classical getter (regarding your other question). So if you see code like this:

MOV ECX, EDX
CALL XYZ
ASSERT(EAX,"m_fooMember")

And XYZ consists of such a line: MOV EAX, [ECX + 8h], one can translate this directly into cpp pseudo code like this:

Foo* EAX = EDX->getFooMember();
assert(EAX, "m_fooMember");

Then you know that m_fooMember is actually located at the offset 8h.
To get back to calling conventions: You cannot always assume that ECX references a object, even if it was not set before in a function. The compiler might optimize and there is still which uses the ECX register too.

Now regarding vftables:
Yes you can. If you know the location of a vftable looking at the first "member" of an object is a great way to find out its type (because it will point to your named vftable). BUT make sure that understand vftables truly. E.g: If you have a class Child inheriting class Parent but not overwriting any methods of Parent, no new vftables are compiled. Therefor you could think accidentally that an object is an instance of Parent, while its actually an instance of Child. Another point to notice is that an object can have multiple vftables, e.g if there would be some additional virtual methods in the Child class.
Vftable calls are usually preceded by a number of moves (/ dereferences) to accquire the vftable ptr and finally the function pointer. Then usually a register is called. Unfortunately I dont have a snippet atm.


Regarding RTTI:
With RTTI you can only find polymorphic classes, always remember that! I once wrote a script to generate header files which could be parsed by doxygen to generate a documentation. Although this is almost a year ago :P and I guess that most of the classes / vftables will be outdated like hell. Nevertheless it could be worth to take a look at the class ierarchy to get an overview.

Ctx:
Im tired of writing, someone lese can surely answere this question.