Profiling an Operating System (Part 1)

If you would like to read the other parts in this article series please go to:

Understanding how an operating system operates means knowing how it communicates. But what if that communication gives something away?

Profiling an Operating System

You may be familiar with the terms architectural and host profiling. What do those terms mean? Well this is what this article series will answer for you and allow you to do as well. This information would be beneficial to system administrators which, all too often, must also take on the job of maintaining network security. Those who are also looking for ways to further their knowledge of computer security would do well to give this series a read.

What we shall do over the course of this series is learn how to differentiate between operating systems, and also how to identify running services on a computer. In other words, how to profile both a computer’s architecture, and host ie: the computer itself, by what it is running in terms of services. You may have heard of programs such as P0f which will identify operating systems for you, most notably passively. Well programs such as P0f are indeed quite nice. There is one problem though. Once again you are abstracted away from the information. Actually kind of like programming for Windows you might say.

It is very important to understand the “basics” as it were. In this case the basics would be just how your operating system responds to both usual and unusual stimulus. Now for us, we are concerned with just how Microsoft Windows will react. The way that it reacts will be rather revealing. We will know just what it is ie: Win 9x or W2K/XP and the such. Further to that we will also possibly note some interesting TCP/IP stack characteristics as it pertains to networking. All this and more will be revealed shortly. The setup for this exercise is quite simple actually. I have VMware images of W2K Pro, Win XP Pro, and W2K3 Standard. Beyond that I shall also be using the packet crafting tool extraordinaire Hping. I found the Windows version of it buggy, so I used the Linux version. But be aware that there is a Windows port.

Let’s get on with it

Right then. With the background info covered, how about we get on with the task of architectural and host profiling. What I shall send as stimulus to the Windows 2000 Pro computer are three different types of packets. The response from the Windows 2000 Pro box is what we shall study at the packet level. That, as you will soon see, will impart to us a great deal of information. The three types of packets that I will generate are the following: RST, ACK, and the SYN packet. On that note let’s get to it shall we.

The command syntax for Hping as used by me to generate one SYN packet is as follows:

Hping -S 192.168.1.103 -p 135 -c 1

I sent the SYN packet to the TCP port 135 in the hope of hitting a port that was unfiltered by a firewall. In the lab conditions used for this there was no such filtering in place. Let’s take a look at what was sent and received then.

tcpdump.exe: listening on \Device\{B3765DC9-4BE1-40C1-8707-16E03D99092C}

17:48:12.515625 IP (tos 0x0, ttl  64, id 24396, offset 0, flags [none], proto: T
CP (6), length: 40) 192.168.1.101.2834 > 192.168.1.103.135: S, cksum 0x18d1 (cor
rect), 1097760784:1097760784(0) win 512
 0x0000:  4500 0028 5f4c 0000 4006 9767 c0a8 0165  E..([email protected]…e
 0x0010:  c0a8 0167 0b12 0087 416e 8010 0b2b 38b2  …g….An…+8.
 0x0020:  5002 0200 18d1 0000 0000 0000 0000       P………….




17:48:12.515625 IP (tos 0x0, ttl 128, id 675, offset 0, flags [DF], proto: TCP (
6), length: 44) 192.168.1.103.135 > 192.168.1.101.2834: S, cksum 0xd012 (correct
), 2591089004:2591089004(0) ack 1097760785 win 64240 <mss 1460>
 0x0000:  4500 002c 02a3 4000 8006 740c c0a8 0167  E..,..@…t….g
 0x0010:  c0a8 0165 0087 0b12 9a70 e16c 416e 8011  …e…..p.lAn..
 0x0020:  6012 faf0 d012 0000 0204 05b4            `………..




Now as you can see I have underlined several spots in the two above noted packets. The very top packet is the one generated by me and then sent to 192.168.1.103 and on its port 135. The packet directly above this paragraph is the Windows 2000 Pro response to the lone SYN packet sent to it on its listening TCP port 135. You will see in the underlined portions above in 192.168.1.103’s response that it gave back a SYN/ACK because there is a listening service there. Well this is all very much standard, so let’s move on to other interesting fields held in the packet sent back by 192.168.1.103.

First off, we can see that there is a “ttl” or time to live value of 128. This value is associated with Windows 2000/XP and 2003. From the hyperlink I provided, you can see that Netware also has this default ttl value. Well in our case we know it is Windows 2000 Pro ahead of time so we won’t dwell on that. What else does a ttl value of 128 tell you? Is there something of use that you could glean from this. Does it tell you anything about where in the network this computer sits? To spare you the suspense we can tell that the computer we hit is on the same segment as us. In other words we are on the same network. We know this because the ttl value has not yet been decremented by the router. You may think so what, but believe me it is another piece of the puzzle if you are pen-testing a network.

After that we have the win or window size which has a value of 64240. The window size, if you remember from previous articles, is measured in bytes and tells you how much buffered memory the computer has for data being sent to it. Now this value does not fall into the range of that displayed at the hyperlink I supplied. Without digging into other network conditions for such a high win size, let’s just put that aside for a moment. Next up is the mss value of 1460. The mss or maximum segment size is the maximum amount of data that computer wants in any one given packet. This value is not seen on the list seen via the hyperlink supplied, but experience tells me that it is endemic to Win 32. We shall see this in XP and 2K3 in a while.

Wrap up

I will break the article at this point and pick up in part two by further discussing the other packets that we will generate and see in this article. We shall also look at some host profiling information, and how we go about getting it. This will further help us narrow down just what operating system and services we are looking at on the computer that we are actively probing. On that note, I shall see you in part two!

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top