rizin
rizin copied to clipboard
Devirtualize method calls using class vtables
Consider the following call: call dword [eax + 0x6c]
Let's assume eax
is the base pointer of a vtable we have saved in classes' analysis and we want to find out the actual address of the called method.
So there should be a command that takes the offset (in this case 0x6c) and looks up the actual destination. It should be possible to call this command with a specific class, so it only looks into its vtable, or without a class, so it gives a list of possible destinations for all vtables that are not too small for the offset.
When that is implemented, one could also add a command that does the same thing, but automatically takes the offset from the opcode at the current seek.
This already exists:
| acvf [offset] ([class name]) lookup function address on vtable offset
Should be easy to do this on the offset from an opcode, but I think it will be more useful to be able to automatically have structs created from vtables and integrate this into the overall analysis so call dword [eax + 0x6c]
is just a special case of a lookup into a struct.
Should be easy to do this on the offset from an opcode, but I think it will be more useful to be able to automatically have structs created from vtables and integrate this into the overall analysis so call dword [eax + 0x6c] is just a special case of a lookup into a struct.
Exactly how I imagined it. In my opinion, the analysis should do this for the user. if it found that eax
holds the base of the vtable, then every eac + offset
should the appropriate function.
If the analysis did not detect that eax
is the base of a virtual table, then the user should be able to set it as one, and then every eax+offset
will be showed properly.
@tyeyeah This issue is asigned to you as RSoC micro-task, so you could work on this from now on. Feel free to ask questions and send Pull Requests.
In case for anyone who is not aware about RSoC.
CC @XVilka
This issue has been automatically marked as stale because it has not had recent activity. Considering a lot has probably changed since its creation, we kindly ask you to check again if the issue you reported is still relevant in the current version of rizin. If it is, update this issue with a comment, otherwise it will be automatically closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. Considering a lot has probably changed since its creation, we kindly ask you to check again if the issue you reported is still relevant in the current version of rizin. If it is, update this issue with a comment, otherwise it will be automatically closed if no further activity occurs. Thank you for your contributions.