ArgusEncode32() accepts little endian?

[Matt Brown]

Thanks for the reply, Carter.

Can you provide any assistance in relation to "translating" the values
given in nDPI classes to the character based hex strings needed for "src ="
and "dst ="?


For instance, if I take an example from afp.c (
https://svn.ntop.org/svn/ntop/trunk/nDPI/src/lib/protocols/afp.c), the
following qualifies "AFP: DSI OpenSession detected."

//from ndpi_protocols.h
https://svn.ntop.org/svn/ntop/trunk/nDPI/src/include/ndpi_protocols.h
#define get_u_int16_t (X,O)  (*(u_int16_t *)(((u_int8_t *)X) + O))
#define get_u_int32_t (X,O)  (*(u_int32_t *)(((u_int8_t *)X) + O))

get_u_int16_t(packet->payload, 0) == htons(0x0004) &&  //if the 16 bits
starting at byte-offset 0 (meaning, bits 0 through 15) of the payload
equals the 16 bit little endian "0x0004" and...
get_u_int16_t(packet->payload, 2) == htons(0x0001) &&  //if the 16 bits
starting at byte-offset 2 (meaning, bits 16 through 31) of the payload
equals the 16 bit little endian "0x0001" and...
get_u_int32_t(packet->payload, 4) == 0 && //if the 32 bits starting at
byte-offset 4 (meaning bits 32-63) of the payload equals 0 and...
get_u_int32_t(packet->payload, 8) == htonl(packet->payload_packet_len - 16)
&& //if the 32 bits at byte-offset 8 (meaning, bits 64-95) are the same as
a 32-bit little endian value equal to the size of the packet minus 16 [must
be a check of sorts] and...
get_u_int32_t(packet->payload, 12) == 0 && //if the 32 bits at byte-offset
12 (bits 96-127) equals 0 and...
get_u_int16_t(packet->payload, 16) == htons(0x0104)) //if the 16 bits at
byte-offset 16 (bits 128-144)


I've commented what I can see as the byte offsets of the given data.

So, I'd simply like to generate the "src = " and "dst = " from this
conditional.


I had some assistance reviewing ArgusEncode32() and it was explained that
it looks at a ptr for binary data and "outputs" that data in a string of
hex.
Knowing that 0x0004, as it is expressed in the nDPI class, is little
endian...
- I believe that if I were to execute ArgusEncode32() with a pointer to
data that can be expressed as hex 0x0004, it would output the string "
00000004".
- I could then use this to build an effective "src = " line for an
raservices.conf file.
Are these two assumptions correct?

With this technique, do you think it's reasonable to generate an
raservices.conf from all the conditionals included in the nDPI classes?


Thanks,

Matt



On Jul 15, 2013, at 7:18 PM, Carter Bullard <carter at qosient.com> wrote:

The ArgusEncode32() printer works on a character basis, so there
isn't any notion of big endian or little endian.

The "n=" is how many samples were used to generate the signature.
We rank them by "n", as a weight for the probability of encountering
that particular pattern.

Carter

On Jul 15, 2013, at 1:15 PM, Matt Brown <matthewbrown at gmail.com> wrote:

Carter,


Hope all is well.  Last Thursday I started to look into reversing the

nDPI classes and creating an raservices() conf file from the byte

pattern classification definitions therein.


I struggled to understand the c notation, etc, but have arrived on the

question of whether or not ArgusEncode32() takes a little endian data

value as input and "outputs" this data expressed as a string made up

of its value in hex.


For instance, if I take a value from afp.c (within nDPI) and see

htons(0x0004), I can assume that when converted with ArgusEncode32(),

the "output" will be "00000004".


Out of this, I can then generate the "src=" or "dst=" portions of a

line for an raservices() conf file.


Is this correct?


Additionally, as for the syntax of the raservices() conf file, what

does the "n=" value mean?



Thanks,


Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130716/d71f7593/attachment.html>