Python Sniffing from Black Hat Python book

Question

import socket
import os
import struct
import sys
from ctypes import *

# host to listen on
host   = sys.argv[1]

class IP(Structure):

    _fields_ = [
        (\"ihl\",         


        

Answer 1

#raw_buffer = sniffer.recvfrom(65565)[0]
raw_buffer = sniffer.recvfrom(65535)[0]

IP paket size is (2^16) - 1

The problem is with 32 vs 64 bit systems.
ip_header = IP(raw_buffer[:20]) works on x86 Ubuntu.
ip_header = IP(raw_buffer[:32]) works on amd64 CentOS 6.6 Python 2.6.6
ip_header = IP(raw_buffer) works in both.

You have to change these,

("src",           c_ulong),
("dst",           c_ulong)  

self.src_address = socket.inet_ntoa(struct.pack("<L",self.src))
self.dst_address = socket.inet_ntoa(struct.pack("<L",self.dst))

into

("src",           c_uint32),
("dst",           c_uint32)  

self.src_address = socket.inet_ntoa(struct.pack("@I",self.src))
self.dst_address = socket.inet_ntoa(struct.pack("@I",self.dst))

'@I' is unisigned int in native order. because c_ulong is 4 bytes in i386 and 8 in amd64. Check the following,

struct.calcsize('@BBHHHBBHLL')  

is 20 in i386 and 32 in amd64 which is size of _fields_. In actual it's 28 bytes in amd64 plus 4 bytes padded for word alignment.

ip_header = IP(raw_buffer[:20]) now works correctly independent of platforms.

Answer 2

So it's a 64/32 bit problem. The fact that it needed 32 bytes instead of 20 means that the struct was not packed correctly. "c_ulong" is 64 bits in 64 bit linux, and was being mapped that way in the "IP" class.

The IP header is 20 bytes + optional fields. The source and destination ip addresses end by byte 20, which is what the current IP structure is picking up. (if you want the options, you're going to have to parse those out by hand).

I looked up the UDP bit fields and directly set them into the class "IP". Looking at the ctypes docs, integer types can be mapped to limit the number of bits.

class IP(Structure):

    _fields_ = [
        ("ihl",           c_ubyte, 4),
        ("version",       c_ubyte, 4),
        ("tos",           c_ubyte, 8),
        ("len",           c_ushort, 16),
        ("id",            c_ushort, 16),
        ("offset",        c_ushort, 16),
        ("ttl",           c_ubyte, 8),
        ("protocol_num",  c_ubyte, 8),
        ("sum",           c_ushort, 16),
        ("src",           c_uint, 32),
        ("dst",           c_uint, 32),
    ]

If you sum the bit offsets, they sum to 160. 160/8 = 20 bytes, which is what ctypes packs this struct to.

Running that on a ping yields something that looks acceptable.

Protocol: ICMP 127.0.0.1 -> 127.0.0.1
Protocol: ICMP 127.0.0.1 -> 127.0.0.1
Protocol: ICMP 127.0.0.1 -> 127.0.0.1
Protocol: ICMP 127.0.0.1 -> 127.0.0.1

Further, packet size is a function of MTU (or Maximum Transfer Unit), so if you plan on running this on ethernet, the limiting factor is the MTU of the frame. Larger packets will get fragmented in the tcp/ip stack before being pushed out of the ethernet port.

$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:00:00:ff:ff:ff  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1

Also, this question should help clarify the issue on why some platforms have different sized ints and longs:

What is the bit size of long on 64-bit Windows?

As an alternative, I have found that dpkt is a rather good library for decoding/encoding ip packets, unless you specifically need to use or want ctypes.

https://code.google.com/p/dpkt/