Someone said to do something like this to avoid scans for WPM calls: __declspec(naked) BOOL WINAPI SafeWriteProcessMemory(HANDLE hProcess,    LPCVOID lpBaseAddress, LPVOID lpBuffer, SIZE_T nSize,    SIZE_T *lpNumberOfBytesRead){    __asm    {            mov edi, edi            push ebp            mov ebp, esp            pop ebp            mov eax, WriteProcessMemory            add eax, 6            jmp eax    }}I put it in a program and debugged it in olly. I looked at kernel32.WriteProcessMemory. We're using the add eax, 6 to jump from here:MOV EDI,EDI                              ; BOOL kernel32.WriteProcessMemory(hProcess, ...)PUSH EBPMOV EBP,ESPPOP EBPJMP <JMP.&API-MS-Win-Core-Memory-L1-1-0. ; Jump to KERNELBASE.WriteProcessMemoryTo there. Effectively skipping over the instructions between the two. We're executing those instructions in our own call. But I don't understand why those instructions are being executed. We're pushing EBP onto the stack, moving ESP into EBP, then restoring EBP from the stack. That shouldn't actually be doing anything.I debugged it instruction-by-instruction, and still can't figure out why it's being done.Does it have something to do with Windows' useless mov edi,edis at the beginning of functions to allow jump patching?
Why does WriteProcessMemory in kernel32.dll do this? (ASM)
windows;assembly
This is the stolen bytes technique, where the first few bytes of the function are copied to a remote location and executed from there, then the original function is called from the location after the bytes that were copied.The purpose of skipping the first few bytes of the function allows you to call the function body without being detected.  That is, any code which detoured the function at exactly the start would be bypassed.In your example, the EBP manipulation is meaningless.  Those instructions exist in the original function in order to provide a familiar signature for routines that, for example, detour the code (but which is presumably broken by also including the hot-patching support).  Note that the POP instruction did not exist in that location before Windows 7, with the introduction of the kernelbase.dll.  Previously, the real function body would have followed the MOV instruction.