Just stumbled across. To clearify this topic for the rest of us: Calculating the relative JMP offset to a codecave patch works by subtracting your patch address with your current programm counter address:
uint32_t patch_address = (uint32_t) VirtualAlloc(...);
uint32_t jmp_offset = patch_address - (current_offset + current_len);
Note: current_len is the number of bytes your JMP instruction takes. This depends on the fact if its a short jmp (EB) or a long jump (E9). In your example 2 bytes, but a regular JMP (E8 0x12345678) takes 5 bytes.
So here we see that your example wont work easily, because you would have to override the next bytes that belong to the following MOV and even the CALL instruction(s). This relies on the fact that your codecave has a greater distance to the current instruction offset because it is allocated in a different region in the address space.
So what you can do is to copy the overwritten 7 Bytes into your cave. That can only work if you dont mess with EDI register in your patch (because of the "MOV ECX, EDI"). And you would have to correct the CALLs address you are overwriting. So this is probably not the best location to place a codecave, but its doable.
i wrote my own hooking library that cares for generic register arguments, stack cleanup and overwritten asm paddings, but i suggest to use the above mentioned frameworks.
regards,
michael