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.

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.

Thanks. Will do.

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.

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.

I read the post and I don't see any "bugs" pointed out per-se.

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.