Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vftable, vtable #129

Closed
illegal-instruction-co opened this issue Mar 3, 2023 · 8 comments
Closed

vftable, vtable #129

illegal-instruction-co opened this issue Mar 3, 2023 · 8 comments

Comments

@illegal-instruction-co
Copy link
Contributor

illegal-instruction-co commented Mar 3, 2023

Would be nice to add resolve vftable or vtable helper class to hook some methods in compiling time.

I am thinking to use libmem to reduce dependencies on my next projects for unit tests by hooks. I never saw a methodogy like that for testing process, but i think it would be really usefull.

@rdbo
Copy link
Owner

rdbo commented Mar 3, 2023

I am not sure what do you mean by hooking methods in compile time, but there is an API for hooking vtables. There are no classes, because it is compatible with C, and there is no C++ specific version, only C/C++.
To hook a VMT:

lm_vmt_t some_object_vmt;

LM_VmtNew(*(lm_address_t **)some_object_addr, &some_object_vmt);
LM_VmtHook(&some_object_vmt, 0, hk_some_function); /* hook function of index 0 from some_object's VMT */

/* freeing the VMT */
LM_VmtFree(&some_object_vmt);

@illegal-instruction-co
Copy link
Contributor Author

illegal-instruction-co commented Mar 3, 2023

I am not sure what do you mean by hooking methods in compile time, but there is an API for hooking vtables. There are no classes, because it is compatible with C, and there is no C++ specific version, only C/C++. To hook a VMT:

lm_vmt_t some_object_vmt;

LM_VmtNew(*(lm_address_t **)some_object_addr, &some_object_vmt);
LM_VmtHook(&some_object_vmt, 0, hk_some_function); /* hook function of index 0 from some_object's VMT */

/* freeing the VMT */
LM_VmtFree(&some_object_vmt);

I didnt meant hooking in compile time (:, its about the get address of virtual method in compile time. So basically, if the index changed because of the main code refactored, test case will be healthy as not needed to change.

@rdbo
Copy link
Owner

rdbo commented Mar 3, 2023

You can get the address of the function using LM_VmtGetOriginal:

lm_vmt_t some_object_vmt;
lm_address_t orig_addr;

/* ... */

orig_addr = LM_VmtGetOriginal(&some_object_vmt, 5); /* get original function address at index 5 */

Also, if the index changed because of the main code refactored - not sure what this means either, the index should never change, unless the class itself has changed (e.g they added a new virtual function before the one you're accessing) or at least that's my understanding of it.

@illegal-instruction-co
Copy link
Contributor Author

You can get the address of the function using LM_VmtGetOriginal:

lm_vmt_t some_object_vmt;
lm_address_t orig_addr;

/* ... */

orig_addr = LM_VmtGetOriginal(&some_object_vmt, 5); /* get original function address at index 5 */

Also, if the index changed because of the main code refactored - not sure what this means either, the index should never change, unless the class itself has changed (e.g they added a new virtual function before the one you're accessing) or at least that's my understanding of it.

exactly you got correct.whenever they ( actually we since im not hacking some one else's memory :) ) added new virtual function, the test case shouldnt also need refactoring. so in the compile time, we can create a helper class to solve actual index of function ( or address )

@rdbo
Copy link
Owner

rdbo commented Mar 4, 2023

If you want to get an index from the function address + object, I don't think C++ allows you to get the address of a virtual function. But assuming you got the address, should be something like this (untested):

lm_size_t get_function_index(lm_vmt_t *vmt, lm_address_t func_addr)
{
        lm_size_t i;
        lm_address_t addr = LM_ADDRESS_BAD;
        for (;; ++i) {
                addr = LM_VmtGetOriginal(vmt, i);
                if (addr == func_addr)
                        break;
        }
        
        return i;
}

@illegal-instruction-co
Copy link
Contributor Author

illegal-instruction-co commented Mar 5, 2023

Yes, we can find the function index by bruteforcing checks by a loop if it is equals to address; but in the test cases you should write your code as easy to understand and you are right we are not able to get address of virtual method, but i bet compiler solving it at the compiling time and packs to code in that way. So, somehow we can get address or index at compiling time too. So it could be like this:
int index = lm_smth(Foo.Vmethod);

@rdbo
Copy link
Owner

rdbo commented Mar 5, 2023

Yes, we can find the function index by bruteforcing checks by a loop if it is equals to address; but in the test cases you should write your code as easy to understand and you are right we are not able to get address of virtual method, but i bet compiler solving it at the compiling time and packs to code in that way. So, somehow we can get address or index at compiling time too. So it could be like this: int index = lm_smth(Foo.Vmethod);

Again, if you have the function address, you can use the get_function_index function I provided. Thing is, C++ itself does not allow you to get the address of a virtual method at compile time. So this functionality would not be possible.
Also, the code in the tests are just to make sure libmem works, the examples for users to read have their own folder (although it is lacking some more examples right now).
Best way is probably to just hardcode your indices and avoid changing them, or using signature scanning to find the function address, and then using the get_function_index method to find the index.

@illegal-instruction-co
Copy link
Contributor Author

signature scanning would be best approach. thank you, i am closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants