Quote:
|
Originally Posted by niom
and why is there almost no communication between the app and the driver?
do they use the driver only for the handling of exceptions that are generated by their usermode code?
|
This information I got from xprotector. I'm sure it is still relevant today.
The driver is used to elevate privileges of the usermode application. After the first IO control calls (jemos correctly identified the key elements in it), the application has full read/write access to the driver's memory.
It uses it to do synchronization (ex: wait until some dword in driver = 1) - probably due to the multi-threaded nature of the protection.
I'm not sure if this is still done, but the xprot driver used to give read/write access on the IDT as well; so the user-mode application was able to dynamically change the int1/int3 descriptors.
Another thing which the usermode application has access to is some privileged instructions; mostly for interrupt handling & direct debug register access, like iretd; mov dr0, eax, ...
Quote:
|
and how the hell do they detect vmware? (they are not using the 'documented' backdoor IO port)
|
by detect, do you mean crash? that's what it does here under vmware 4.0.x with windows 2k running on it.