Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
Using a buffer overflow, I have been able to override return addresses. But the problem is that Windows addresses contain zeros at the beginning (e.g. 0x00401020). As a result, the objdump of any C binary will contain zero's. This makes it very difficult to execute shellcode inside a buffer as a shellcode cannot contain zero's for it to work.
Has anyone done this sort of thing? It does not matter even if the exploit is printing hello-world: is it possible?
You should be able to remove the leading zeros, as 0x00401020 = 0x401020.
Why not just shrink the shellcode to omit the most significant bytes? Almost all Windows-based machines (I think literally all current NT platforms) are little-endian, so the most significant byte (the 0x00) is at the end. If all you need to do is overwrite the return address, there's no need to write anything past the first few bytes of it.
Alternatively, find a library or ROP gadget mapped about 0x01000000. Some programs might not have any, if they're really tiny (and ASLR is turned off, as it seems to be here) since Windows likes to pack its system libraries as close to 0x00400000 as possible, but 0x01000000 is only 12 MiB above 0x00400000 so any program that is itself very large, or includes a lot of libraries (or just one big library), will have addresses above that point.
Objdumpa *nix utility? What happens if you used a Windows-specific debugger?strcpyvulnerability? There are many ways of getting buffer overflows, and only strcpy is going to care about null bytes in the payload, but you should have specified anyhow.