and btw:
mov edi,edi was done specyficly for hotfixes, right?
so why instead ms didnt put there 2 nops?

;;padding nops
NOP
NOP
NOP
patching nops
NOP
NOP
NOP
NOP
NOP
MOV EDI,EDI ;;<--where the function begins
    

;;padding nops
NOP
NOP
NOP
;;patching nops
NOP
NOP
NOP
NOP
NOP
NOP ;; <-this is where it really starts
NOP
PUSH EBP ;; <-does it start here???? Looks like it, but "NOPe" :D
MOV EBP,ESP
    

and i belive 2x nop is better that 1 mov.

and why edi nit mov eax,eax, eax operations are faster.

and they sould make some hook chain.

proc hook_GetSystemTimeAsFileTime uses ebx esi
local oldProtect: DWORD
PATCH_SIZE = 7

      mov     ebx, [GetSystemTimeAsFileTime]
      cmp     word [ebx], $FF8B ; "mov edi, edi" but not encoded as FASM do
      jne     .unhookable ; (Trivially)

      lea     esi, [ebx-5]

      invoke  VirtualProtect, esi, PATCH_SIZE, PAGE_EXECUTE_READWRITE, addr oldProtect
      test    eax, eax
      jz      .protFail

      mov     byte [ebx-5], $E9
      mov     eax, hook
      sub     eax, ebx
      mov     [ebx-4], eax

      mov     byte [ebx], $84 ; TEST opcode ("mov edi, edi" is transformed into "test BH, BH")
                              ; This is done to avoid issues on cores that already fetched half of "mov edi, edi"
                              ; (in that case the instruction crossed a 16-byte boundary)
      invoke  GetCurrentProcess
      invoke  FlushInstructionCache, eax, esi, PATCH_SIZE
      test    eax, eax
      jz      .flushFail

      ; At this point the five NOPs cannot be incorrectly cached by any processor and also no processor should still have
      ; "mov edi, edi" half fetched.

      mov     byte [ebx+1], $F9 ; $-5 but also transforms "test BH, BH" into "test CL, BH"
      mov     byte [ebx], $EB   ; JMP rel8 opcode

      ; JMP $-5 Fully assembled at this point. Some cores may still execute "test CL, BH" so we call FlushInstructionCache again

      invoke  FlushInstructionCache, eax, esi, PATCH_SIZE ; Comment if you don't need to make the hook effective as soon as possible.

      call    .protect
      mov     eax, TRUE ; In case VirtualProtect failed

.return:
      ret

.flushFail:
      call    .protect

.unhookable:
.protFail:
      mov     eax, FALSE
      jmp     .return

.protect:
      invoke  VirtualProtect, esi, PATCH_SIZE, [oldProtect], addr oldProtect
      ret
endp    

.protect:
      cmp     [oldProtect], PAGE_EXECUTE_READWRITE
      je      .leftUnprotected

      invoke  VirtualProtect, esi, PATCH_SIZE, [oldProtect], addr oldProtect

.leftUnprotected:
      ret    

i did and its done wrong. overwriting 5 (not 2) bytes on active memory.

exception on memory access - i dont think its good idea.

BUT you can make breakpoint exception and check where it occured.

oh well, it also wont solve 1 prolem.

Quote:

Anyone had checked Microsoft Detours to see how this is done?

i did and its done wrong. overwriting 5 (not 2) bytes on active memory.

api hooking cant be done.

if your truly worried about multi-threading issues you can simply suspend all other threads while yours is hooking and resume afterwards.

Quote:

if your truly worried about multi-threading issues you can simply suspend all other threads while yours is hooking and resume afterwards.

This idea could be problematic (that's the reason I've avoided commenting it). If for some reason your patcher thread takes too long to get CPU-time you will keep the target process suspended for too long. If you are ready to face the possible consequences of doing this then I think you could also just assume that you will be the only one patching the API. Also, catching the exceptions in the patcher thread perhaps is better (and thinking about it perhaps a SEH handler should always be installed as if the patcher crash it should try to avoid by all means to make the crash process-wide).

you don't need to suspend them for the entire duration of your threads existence, only while

hooking, and specifically only while writing the hook. at most it might be a few

milliseconds.

EOT, there is NO way of safe hooking. Editing shared memory without exclusive access is BAD.

Terminal Services isolates each terminal session by design. Therefore, CreateRemoteThread fails if the target process is in a different session than the calling process.