Consider the code below:
char *args[3];
char *arg = "\x90\x90\x00\x90\x90";
args[0] = "/path/to/exe";
args[1] = arg;
args[2] = NULL;
execve(args[0], args, NULL);
Because arg is null terminated in the middle, when execve creates a new process image, everything beyond the \x00 is not copied for the new process. Is there any way to "trick" execve to copy everything beyond the \x00?
The short answer is no. The parameters to execve (actually, the entire exec family) are C strings and, therefore, null-byte terminated. If it didn't stop at the null byte, it would have no way to know the length of the string. For the same reason, no executable should ever expect a null byte in its argv.
The C convention for strings is null termination and that includes syscall apis like execve.
Even it were possible to circumvent the execve shim to the kernel syscall interface, it would be invalid for the kernel to support args with real embedded nul bytes into the process table as the syscalls, libraries, tools and interfaces (eg procfs) around process management would also show truncated process arguments even if it were possible.
If you are interested in calling the linux kernel execve syscall, directly the following article may be useful: http://hackoftheday.securitytube.net/2013/04/demystifying-execve-shellcode-stack.html?m=1
Once you read that article you will see that the execve api is fundamentally an array of nul terminated strings, which is passed to the kernel which it processes.
TL;DR there is no getting around it.
one technique would be to replace null with some other character say 4 FF's, assuming 4 consecutive FF will never be part of your data. and then replace them back in to null. Assuming you can modify the exe being called.
