Are vTable pointers always located inside a module?

[Torpedoes]

Assuming the standard VC++ vTable layout:

  Heap-Addr           TableAddr
+-----------+       +-----------+
| TableAddr | ----> | Funcion-1 | ----> Exec region of module
+-----------+       +-----------+
| a         |       | Funcion-2 | ----> Exec region of module
+-----------+       +-----------+
| b         |       | Funcion-3 | ----> Exec region of module
+-----------+       +-----------+
| c         |       |    ...    |
+-----------+       +-----------+

Is TableAddr guaranteed to always be inside a module or can it be anywhere in the address space, if so, what are the conditions that would make TableAddr be outside a module.

For clarity: A module is any .exe or .dll which has read-only or executable regions of memory allowing functions to be called. From my experience I've only seen TableAddr reside inside read-only sections of modules.

[namreeb]

I don't believe it is strictly guaranteed. You could obviously replace it yourself if you wanted to. So, no, I would say not always.

[DarkLinux]

I would think all function pointers in the table would be within the module. They are your functions that your calling, if your calling someone else's functions from another dll they will be exported and in your import table (can also be hooked the same way). I dont think you will find a vtable address pointing to an exported entry but I could be wrong. A program could map in some asm/shell code, but a compiler would not make a vtable entry for it at run time. I cant really think of any reason that it would not be within the module. It can be easy for a game to check a vtable for modifications, as the table is static and will always be the same in the .data section. You could create your own vtable, copy everything over and then hook. Its still easy to check if a table has been changed but then your not changing anything in the .data section, only the pointer that is on the heap. A little safer but nothing is undetected. I would love to know more about your question, its really open ended.

[Torpedoes]

I would love to know more about your question, its really open ended.

Thanks for your input. This is mainly a research project at the moment but I'm working on a general purposes VTable scanner. One of the things I do is snapshot the address space of the game and analyze it. But if VTable pointers always reside within a module then all I'll need to do is snapshot the modules along with the regions I want to scan, greatly reducing the amount of memory I use. Depending on the size I may even be able to process this information on the GPU. The results of this would be pretty useful as it shows you the locations of all polymorphic classes in the game and they can be sorted and identified based on the VTable address. This combined with some code-path analysis will provide me with some really cool reverse engineering strategies.

[wraithZX]

Cross-referencing vtable entries to find equivalent functionality for polymorphic types is *very* useful. I use runtime vtable analysis for most of my gamebinary-update-resistant code - the vtables are always mapped to a region of module memory as they're constant data prepopulated inside the module. The OS's executable loader will update the RVA's when starting up the app.

It's especially useful for determining things like name/position functions for other types - once you determine one of them, you can backtrack, find the vtable index, and all other classes derived from the same base object share the same index regardless of if you've detected the function correctly. Sticking with the position as an example, you can find the vtable index for GetPosition for a player object, work out that it's 16, and then items/units/gameobjects etc. are all using the same index even if you didn't get a definite match on pattern analysis for their GetPosition functions.

Obviously it's a bit more complicated than that, but it's the gist of it.