Re^6: p0fq.pl and pack

[macli]

It does work on my PC running Fedora Core 3

p0f -Q /var/run/p0f.sock -0 'dst port 443' >> /dev/null &

./p0fq.pl /var/run/p0f.sock src_host 0 dst_host 443

I get:

Genre: Linux
Detailes: 2.6, seldom 2.4 (older, 4)
Distance: 0 hops
Link: ethernet/modem
Uptime: 207 hrs

[ikegami]

What about the Id? The Magic and the Id are in different orders, yet you use L for both.

[macli]

The order is right, here is the p0f query and response structure in p0f-query.h:



struct p0f_query {
  _u32 magic;                   /* must be set toQUERY_MAGIC */
  _u8  type;                    /* QTYPE_* */
  _u32 id;                      /* Unique query ID */
  _u32 src_ad,dst_ad;           /* src address, local dst addr */
  _u16 src_port,dst_port;       /* src and dst ports */
};

#define RESP_OK         0       /* Response OK */
#define RESP_BADQUERY   1       /* Query malformed */
#define RESP_NOMATCH    2       /* No match for src-dst data */
#define RESP_STATUS     255     /* Status information */

struct p0f_response {
  _u32 magic;                   /* QUERY_MAGIC */
  _u32 id;                      /* Query ID (copied from p0f_query) */
  _u8  type;                    /* RESP_* */

  _u8  genre[20];               /* OS genre (empty if no match) */
  _u8  detail[40];              /* OS version (empty if no match) */
  _s8  dist;                    /* Distance (-1 if unknown ) */
  _u8  link[30];                /* Link type (empty if unknown) */
  _u8  tos[30];                 /* Traffic type (empty if unknown) */
  _u8  fw,nat;                  /* firewall and NAT flags flags */
  _u8  real;                    /* A real operating system? */
  _s16 score;                   /* Masquerade score (or NO_SCORE) */
  _u16 mflags;                  /* Masquerade flags (D_*) */
  _s32 uptime;                  /* Uptime in hours (-1 = unknown) */
};

I ran the same perl test script on x86 and Mac, there is the bytes dump for $query and $resonse

x86



query:

0xed 0xac 0xef 0xd 0x1 00 00 00 0x78 0x56 0x34 0x12 0x89 0x52 0x2 0xfd
+ 0x89 0x52 0x2 0x27 00 00 0xbb 0x1

resonse:

0xed 0xac 0xef 0xd 0x78 0x56 0x34 0x12 00 0x4c 0x69 0x6e 0x75 0x78 00 
+00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x32 0x2e 0x36 0x2c 0x20 0x
+73 0x65 0x6c 0x64 0x6f 0x6d 0x20 0x32 0x2e 0x34 0x20 0x28 0x6f 0x6c 0
+x64 0x65 0x72 0x2c 0x20 0x34 0x29 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 0x65 0x74 0x68 0x65 0x72 0x6e 0x65 0x74 0x2f 0x6d 0x6f 0x64
+ 0x65 0x6d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x68 0x69 
+0x67 0x68 0x20 0x74 0x68 0x72 0x6f 0x75 0x67 0x68 0x70 0x75 0x74 00 0
+0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1 00 0x9c 0xff 00 00
+ 00 00 0xdd 0x2 00 00

Mac:



query:

0xd 0xef 0xac 0xed 00 00 00 0x1 0x12 0x34 0x56 0x78 0x89 0x52 0x2 0x3a
+ 0x89 0x52 0x2 0xfd 00 00 00 0x50

response:

0xd 0xef 0xac 0xed 0x12 0x34 0x56 0x78 0x1 00 00 00 00 00 00 00 00 00 
+00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+00 00 00 00 00 00 00 00 00 00 00

Notice that the query type is still 0x1 instead of 00 for Mac,I don't know why it is not set to 00 like on x86.

It looks like too much troublesome to use the pack/unpack to get it right, is there some other way to get around this instead of using pack/unpack?

[ikegami]

You changed the data. When I said I couldn't see how "L L ..." would have worked on the PC (or any machine), you told me the response was
0x0d 0xef 0xac 0xed 0x78 0x56 0x34 0x12 ...
Now you say it's either
0x0d 0xef 0xac 0xed 0x12 0x34 0x56 0x78 ... or
0xed 0xac 0xef 0x0d 0x78 0x56 0x34 0x12 ...
both different from what you told me.

And you didn't mention anything about the server's response being different based on the server on which it runs.

The problem you have is not related to pack, it's related to not knowing how the data is saved. The structure is meaningless. How the data is serialized is not dependent on its structure in memory. You need to know how the data is serialized. There's no escaping that.

In can be in terms of number of bytes, byte orderings, etc (at which point its dead simple to write the proper pack/unpack patterns), but it doesn't have to be.

If you know the library that was used to serialize the data, you could potentially use the same library or a port of it to deserialize the data.

[macli]

ahh, replace C With L works



my ($magic, $id, $type, $genre, $detail, $dist, $link, $tos, $fw,$nat,
+ $real, $score, $mflags, $uptime) =
  unpack ("L L L Z20 Z40 c Z30 Z30 C C C s! S! N", $response);

Thanks for the clue :)

[macli]

Sorry, I am wrong, I accidently ran the c test program instead of perl test script, the c test program works both on x86 and Mac