While exploiting a strcpy() buffer overflow in Win XP, I used the address of ESP after the crash to overwrite EIP. The address contained a null byte so it did not work, so I found a jmp esp instruction and used that instead. Then I ran the program and it worked fine. Then I realized that the shellcode (from msfpayload) also had null bytes allover. However, it executed fine and I got a reverse shell. Why does null bytes in the shellcode not corrupt the rest of the payload whereas a null byte in the return address corrupted the rest of the payload?
As you know the strcpy function has a loop that ends on 0x00 byte and it has no exception. So:
- Re-check your bug trigger situation, are you sure it's strcpy? isn't it memcpy, memmove or even wcs...?
- Check strcpy args, sometimes your target buffer is not the destination of strcpy it may be the source. and as mentioned in comments your assumption about null byte limitation is wrong.
- Check your shell code in your exploit source. not in memory. it could be decoded at run-time.
if none of above is right then check the algorithm, it is possible that the program extends the copy.