Hi @threntnelson, yes. The generated code will consist in a copy the sub opcode and the mov will be converted to an absolute mov. Sometimes there is no 1-1 conversion so they are converted to several instructions preserving register values if they must be temporarily used.
HN user
mxmauro
Hi @naveen99.
We upload precompiled samples but time to time Google marks us as harmful when they aren't. Feel free to download the source code from https://github.com/nektra/. Visual Studio projects are provided too.
When the stub for calling the original function is created, most hooking engines assumes the prologue contains the standard "mov edi,edi/push ebp/mov ebp,esp" and it is wrong.
If the prologue contains, for e.g., a relative jmp, copying opcodes is not enough. You must convert it to an absolute jump in the generated stub. The same applies to several instructions doing relative/indirect addressing.
I'm asking about the security issues. Although they usually implies bugs the only one I mentioned is the OLE packager one that generated a big security problem.
Why you consider it is a huge security hole? Just because of the OLE Packager bug?
COM/DCOM, where OLE rests, can be very secure if they are properly used.
By the way, OLE is used widely mainly in Microsoft products.
Yes also, unless previously changed, I always reached the limit of 10,000 records in normal computer usage.