Am 2018-07-01 um 10:07 schrieb Zebediah Figura:
Sorry, I'm confused. Is the issue that static (COM) methods are hotpatchable and shouldn't be, or that they aren't and should be?
When I implemented this in 2009 Microsoft did not make them hotpatchable. We decided we want to do be able to make them hotpatchable though.
Windows applications that hotpatch 32 bit code need to be able to process code that is different from the standard "8b-ff 55 8b-ec" instruction sequence, or at least used to in 2009. Windows before XP Service Pack 2 did not have the 2 byte NOP. This is why some apps hotpatch functions without DECLSPEC_HOTPATCH successfully sometimes. But because there are many, many possible opcodes, no Windows application will handle all possible code that is out there.
are there really applications that choke on "mov %edi,%edi", and, secondly, since GCC currently has freedom to put whatever it wants to there (like the PC thunk) wouldn't we need some way to guarantee it's compatible anyway?
I don't know anything that chokes on the mov edi, edi (8b ff). This is why we had no problem with using DECLSPEC_HOTPATCH for things that are not technically hotpatchable on Windows. Eliminating everything Steam et all don't understand is hard (we don't know what it understands and what it doesn't), so putting something there that it understands is a way easier solution - even if we know that it technically incorrect.
(There are "easier" ways to hook COM methods than hotpatching bytecode - create a proxy object, replace the vtable in the object, overwrite the function pointer in the vtable. Afaik no Windows application goes that route though)
I still think adding a 2 byte (or 8 byte) NOP to every WINAPI or CDECL function is wasteful.