But the code being memcpy'ed is using the parent process's specific symbol relocations. When a library with PIC is loaded the executable code is copied from th

But the code being memcpy'ed is using the parent process's specific symbol relocations. When a library with PIC is loaded the executable code is copied from the file into RAM to a random offset and all references to structures in the ASM are updated to match their now random offset in memory (simplifying). Say function XYZ in library libfoo is in offsetXYZ, parent process loads libfoo at offset 0xDEADBEEF, injectee process loads libfoo at offset 0xDEC0DE. In Windows the call to function XYZ in the parent process uses the address offsetXYZ+0xDEADBEEF, but the call in the injectee process uses offsetXYZ+0xDEC0DE, causing any reference to the parent process's function to fail. GNU/Linux is very similar but library symbols are found based on an offset to a structure in memory that contains the library symbol metadata, that changes every time the program is loaded. So actually the opposite is true, if the code wasn't position-independent and was statically located, the assembly code offsets wouldn't need to be updated and you might be able to call a memcpy'd function. Position-independent code could only possibly work if you updated the reference to the symbol metadata structure in the ASM after the memcpy, but at that point you're re-implementing libdl and no longer just using memcpy.