Open sei-eschwartz opened 2 years ago
It seems that we need a way for possibleVFTableWrite
to describe vftables that are installed in a virtual base
I am sure I'll forget my progress by the time I get back from vacation, so I'll add some notes here. I added a new fact type, thisPtrDefinition, which expresses pointers as expressions.
Here is an example:
[eschwartz@pd4 Lite]$ cat oo.facts | fgrep sv_3544081266679891044
possibleVFTableWrite(0x402487, 0x40247e, sv_18024155638382103558, 0, sv_3544081266679891044, 0x41238c).
thisPtrDefinition(sv_3544081266679891044, add([read([sv(sv_2925039723046125976, 'Mem'), add([read([sv(sv_2925039723046125976, 'Mem'), sv(sv_10664833297080542982, ecx_0)]), 0x4])]), sv(sv_10664833297080542982, ecx_0)]), 0x402487, 0x40247e).
I added a hash for the "full" or "expanded" thisptr to possibleVFTableWrite, which is sv_3544081266679891044 here. Then we can see the definition of sv_3544081266679891044, which must be describing a virtual base. Notice that the "old" fact information of sv_18024155638382103558 and offset 0 is laughably wrong.
So how do we use this on the vft_overwrite branch? Perhaps by verifying that the address is an offset from ecx at some point.
This is in the thisptr-overhaul branch
This branch needs to use thisPtrDefinition from the thisptr-overhaul branch (#224)
This branch apparently has some problems for virtual bases. Basically, when we install a vftable to a virtual base, the thisptr will not match ecx: