Datagram analysis

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • TheCotMan
    *****Retired *****
    • May 2004
    • 8857

    #16
    Originally posted by justjake
    Good Morning all!!!!

    So, in looking at dns packets, I'm starting to understand what they mean, but I have a question on why some values aren't being converted. For example,

    00 09 43 09 5d 1c is the actual mac address,
    but when converted to ascii, the address is
    ..C.].

    So i see that that my 3rd and 5th byte can be converted to its ascii equivilant, but not the other bytes. Even though the 1st and 2nd bytes are different values, they are still represented as the same value of "." so how is there any discrimanation as to what each value means?
    You should try to do a google search on "Ethernet frames" to understand what the fields in a MAC address are used for.
    I'll give you some hints:
    man page on ethereal or tcpdump on "unprintable" for correlation with the "." characters you see when converting the Hex vales of the MAC address to "ASCII" that you see printed.
    [It seems the don't use "unprintable" in either manpage. The "." character is used to represent any unprintable ASCII character after conversion from decimal. This is The default behavior for many network sniffing tools. Just because you see"." as the ASCII equivalnet of a hex/dec value does not mean that the hex/dec imal value is really a "."]
    Next, a question for you to consider to answer this question on your own:
    Would you consider converting each octet of an IP Address to ASCII? Why do the same for a MAC Address?
    If you had to consider the "type" of an octet of an IP Address, which datatype would you choose to represent it if you ignored isses of use of memory for each?
    unsigned integer, character, boolean, string?

    I imagine that there is a very simple answer for this such as "it just does, or its discarded, or the actual value in ascii doesn't really matter, as long as you have the actual mac address" which is fine, (and I'm thinking its probably the latter), and if that's the case, then I just move forward and continue the learning of packet analysis.
    Added hint above in your quote. Consider the "packet" you capture with Etherreal is an Ethernet frame, so you will have to strip off the Ethernet "junk" to examine its payload which might be IP, and the examine the IP packets payload to see that it might be UDP, and then examine the UDP payload to see if it contains a DNS lookup. Encapsulation.

    And on a side note, while talking with Mr. Google on various DNS sample packets, I did see some links pointing to crafting some malformed packets for crashing tcpdump and the like, so I'm glad I'm using a firewall and testing on my home network.
    Heh. :-)
    Last edited by TheCotMan; November 5, 2005, 09:39. Reason: added content in []

    Comment

    • justjake
      IamI
      • Nov 2005
      • 11

      #17
      Originally posted by TheCotMan
      Next, a question for you to consider to answer this question on your own:
      Would you consider converting each octet of an IP Address to ASCII? Why do the same for a MAC Address?
      If you had to consider the "type" of an octet of an IP Address, which datatype would you choose to represent it if you ignored isses of use of memory for each?
      unsigned integer, character, boolean, string?
      That is a very good point on not converting an ip address to ascii. I had not thought of that.
      Based on what little I know of programming, I would rule out an unsigned interger because it contains negative numbers?? character because althought it is represented as 8 bits?? the value would be ascii, boolean since its either true or false, so I would chose to have it set as a string, with the slight possilbility of passing the ip address as an array.??? which would make it come back to a char.

      I am aware that there is still much to learn. And read, read, read, I shall.

      Have a good night all!!!

      Jake
      Windows is a stable platform, Linux is user-friendly, Mac's have average graphics.

      Comment

      • TheCotMan
        *****Retired *****
        • May 2004
        • 8857

        #18
        Originally posted by justjake
        That is a very good point on not converting an ip address to ascii. I had not thought of that.
        IP addresses are commonly displayed as base 10 decimal values, but I have seen them as binary (base 2) and hexadecimal (base 16.)

        I would rule out an unsigned interger because it contains negative numbers??
        And this could be a mistake. "Unsigned" don't have negative values. I think you are confused on the meaning "unsigned."

        Unsigned ints can be used to represent hexadecimal values in C with proper formatting.

        I have seen some code that uses "unsigned chars" as int storage and an array of unsigned chars for storing each byte of an ethernet frame, for the sake of memory or function arg data types.

        Whichever storage type is used, we generally view the address octets as numbers (be them in base 2, base 10 or base 16.) So unsigned int is a good way to consider each byte when looking at the theory, since it is easier to describe number from 0 to 255 than it is to only use 256 characters and convert bases on numbers. (ASCII really ends around dec val 127 even though "extended ASCII" and other conversions exist for the top 128 chars.)

        character because althought it is represented as 8 bits?? the value would be ascii, boolean since its either true or false, so I would chose to have it set as a string, with the slight possilbility of passing the ip address as an array.??? which would make it come back to a char.
        Ignore efficiency of storage when looking at the theory of it. It is easier to think of each octet as a number for fields examination. Learn base conversions. Some header fields only use a few bits out of each 8 bit group.

        When you implement, then you can consider the best datatypes to represent your numbers.

        Here is what I think is a really cool example of how base 2 can illustrate something:
        Host1 IP: 10.0.0.2
        Host2 IP: 10.0.0.3
        Host3 IP: 10.0.1.2
        SubnetMask 255.255.255.0
        Gateway/Router IP: 10.0.0.1
        DNS: 10.0.1.1

        Using only boolean math, how can we determine if an IP packet should be sent to the router or the gateway?
        Lets coonvert to base 2:
        Host1 IP: 00001010.00000000.00000000.00000010
        Host2 IP: 00001010.00000000.00000000.00000011
        Host3 IP: 00001010.00000000.00000001.00000010
        SubnetMask 11111111.11111111.11111111.00000000
        Gateway/Router IP: 00001010.00000000.00000000.00000001

        Assume Host1 sends to Host2. Will that need to be sent through the router?
        Host1 IP: 00001010.00000000.00000000.00000010
        Host2 IP: 00001010.00000000.00000000.00000011
        XOR === : 00000000.00000000.00000000.00000001

        Now AND XOR to Subnet mask:
        XOR === : 00000000.00000000.00000000.00000001
        SNM === : 11111111.11111111.11111111.00000000
        AND === : 00000000.00000000.00000000.00000000

        The result is "0" (false) for needing to go throught the gateway/router.
        However, consider a host not on the same subnet. Consider Host 3:
        Host1 IP: 00001010.00000000.00000000.00000010
        Host3 IP: 00001010.00000000.00000001.00000010
        XOR === : 00000000.00000000.00000001.00000000

        Now AND XOR to Subnet mask:
        XOR === : 00000000.00000000.00000001.00000000
        SNM === : 11111111.11111111.11111111.00000000
        AND === : 00000000.00000000.00000001.00000000

        The AND result os non-zero (true) for needing to go through the gateway/router.

        If I used the above, and I stored my IP addresses as unsigned ints of length 32 bit or greater, then I could make routing decisions with two boolean math operations, and if I want to have less readable, make the condition itself be the resulting integer value and the determing factor:
        if ((Host1 XOR Host2) AND SNM) {} else {}

        Or, if we assume x86 Assembly, and values preloaded into the proper registers, perhaps 2 operations (the XOR and AND with result in eax for return, or 3 if we needed a conditional check and jump without a function return.

        Isn't math cool? Maybe I am alone, but when I saw the above use of boolean math on routing decisions I was really happy. :-)

        (The above is not necessarily how this is implemented everywhere, but is an example of how it could be done.)

        Comment

        Working...