You want to do WHAT with PHP? Chapter 2

PHP developers know text really, really well. We can write SQL, we can build HTML, we can work with XML. But computers don't speak in terms of structured text markup, they speak in terms of bytes. And while there are many PHP developers who can speak at the lower level of bytes and bits and stuch, there are many more that have difficulty there. This chapter is here to help the developers who are not as familiar with communicating directly over the wire. This is a short excerpt from a very long chapter on Binary Protocols.

Domain Name Service is a relatively simple UDP-based protocol that we can use to make our first attempt at using our tool. You can run DNS over TCP, but because that reduces the scalability to some degree, UDP is generally the transport protocol that is used. To test the tool, we can run a simple DNS lookup.

I am using a virtual machine on my local machine to keep things separate. The command I run is

host -t A mcpressonline.com 192.168.129.1

This command is asking 192.168.129.1 (the IP address on which the tool is listening) to look up an A (address) record for mcpressonline.com. I specifically ask for the A record because the host has a tendency to ask for a lot of information. The â€“t A flag makes sure we are doing only one lookup.

Note that the first two bytes have changed. There are a couple of options as to what these two bytes might signify. They could be a timestamp or a unique ID. They could also be both. To find the answer, let's take a look at the response (Figure 2.13) and see whether anything matches.

The first thing that this output tells you is that the protocol is a variable-length protocol. That is an important thing to know. Why? Because it means that there will be either bytes stating the length of individual fields or field markers stating the beginning and end of the fields.

One of the first similarities I see is that of the footer. For both requests, the last bytes are 0x00 0x00 0x01 0x00 0x01. I also see that bytes 3 through 12 are 0x01 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 in both requests.

So let's review what we know so far. Bytes 1 and 2 are likely some kind of message identifier. Bytes 3-12 seem to be some kind of header, and the last five bytes seem to be some kind of footer. Whatever is in between would seem to be the payload. So letâ€™s look at that payload (Figure 2.16).

Take a little bit of time to examine this before reading to the next paragraph. Look for similarities, and look for differences.

The first difference is relatively obvious. Check out the first byte. Itâ€™s different in each example. So, clearly, it has a significant meaning. But what is that meaning? Letâ€™s look throughout the payloads and see whether the value is repeated.

In the php.net example, we see 0x03 repeated once more. So, this value occurs before both â€œphpâ€ and â€œnetâ€. It could be an indicator of separated DNS entries, but that wouldnâ€™t explain the 0x0D in the mcpressonline.com example.

However, if you look carefully at the mcpressonline.com example, you will notice that 0x03 is there as well, before â€œcomâ€. So 0x03 is significant to this example, too. But what about the 0x0D? What is 0x0D in decimal? The answer is 13. How many characters are in "mcpressonline" 13.

Because we know that DNS is a read-only protocol, we should now be able to write a simple script that mimics the earlier DNS request without worrying about changing any data. Figure 2.17 shows such a request.