Edits from previous

I only added __declspec(noinline) before every function in the header in order to prevent inlining

Differences

First of all, both decompilers show the decompilation much clearer

I have also now decompiled it using IDA:

However now mentions of the vftable are almost complete gone

Dynamic Analysis

x64dbg is smart and already comments on the side of the pure virtual call what it will be, but let’s analyze it further

We look at RAX (which we know thanks to the x64dbg comments, contains the pointer to the vftable) 00007FF62D0133F0 (.rdata)

It contains a pointer (Little Endian): 00007FF62D0115D0 (.text)

Once there, if we right-click and disassembly:

We can easily spot our marker bytes:

For completeness we take a screenshot of the memory map too:

Class method calling convention

We can also notice that for every call of a method, the pointer to the class (usually referred to as this) is passed in ECX , this is also valid for virtual functions.

Ghidra cleverly names the first parameter this in the decompilation

While Binanry Ninja leaves it to the analyst

This is all consistent with what declared by the official Microsoft documentation where simple the class instance is just passed as first parameter:

Conclusions

The big takeaways from this are:

• ECX on class methods is a pointer to the class base address (this)
• vftable isn’t obvious in most reverse engineering occasions