为何无法自行实现memcpy？附可正常运行的代码示例

Let's break down the most common reasons your custom memcpy implementation fails in this scenario—especially since the system-provided version works perfectly for your VTable patching code:

1. You Swapped Destination and Source Parameters #

It's an easy mistake to make! The standard memcpy signature is memcpy(void* dest, const void* src, size_t n)—meaning you copy from src to dest. If your custom version flipped these parameters (e.g., writing from your target address to the bytes buffer), you'd either crash from invalid memory access or write garbage data instead of the intended VTable address. Double-check your parameter order matches the standard.

2. Unhandled Memory Alignment Issues #

The system memcpy is heavily optimized for your CPU architecture—it automatically handles unaligned memory addresses (using instructions like movdqu for unaligned SSE transfers, or falling back to byte-wise copies if needed). If your custom implementation assumes memory is aligned to 4/8-byte boundaries (e.g., using uint32_t* pointers to copy 4 bytes at a time without checking), it will crash or corrupt data when:

• Your address or bytes pointer isn't aligned to your CPU's word size
• The copy spans across memory pages where alignment breaks

Stick to byte-wise copies (using unsigned char* pointers) for a simple, foolproof implementation that works everywhere.

3. Ignoring Memory Protection Edge Cases #

While you're correctly using VirtualProtect to make the destination memory writable, your custom memcpy might not handle edge cases the system version does transparently:

• If the copy spans multiple memory pages with different protection attributes
• Rare scenarios where the source memory has unexpected read restrictions (unlikely here, but possible if your pattern scan hits an odd memory region)

4. Overlapping Memory (You Need memmove, Not memcpy) #

The standard memcpy isn't safe for overlapping memory regions, but some system implementations secretly fall back to memmove-like behavior when overlaps are detected. If your source and destination buffers overlap (unlikely in your VTable code, but possible in other patching scenarios), your custom memcpy will corrupt data.

5. Botched Architecture Optimizations #

If you tried to speed up your memcpy with SIMD instructions (SSE/AVX) or handwritten assembly, you might have introduced bugs:

• Forgetting to save/restore SIMD registers (breaking C++ calling conventions)
• Using aligned-only instructions without checking memory alignment
• Failing to handle leftover bytes after processing full SIMD chunks (e.g., 16-byte SSE blocks)

A Reliable Custom memcpy for Your Use Case #

If you want a simple, working replacement for the system memcpy in your WriteMemory function, use this byte-wise implementation:

void my_memcpy(void* dest, const void* src, size_t byteSize) {
    unsigned char* dest_bytes = static_cast<unsigned char*>(dest);
    const unsigned char* src_bytes = static_cast<const unsigned char*>(src);
    
    while (byteSize-- > 0) {
        *dest_bytes++ = *src_bytes++;
    }
}

One quick side note: your current WriteMemory function doesn't restore the original memory protection attributes after copying. While this might work for your scenario, it's best practice to call VirtualProtect again to set the protection back to NewProtection once you're done—this prevents unintended writes to the memory later.

内容的提问来源于stack exchange，提问作者Haxx0r