[Bro-Dev] #968: Add bytestring_to_uint16, uint32, uint64 functions

Bro Tracker bro at tracker.bro.org
Mon Apr 22 12:58:04 PDT 2013


#968: Add bytestring_to_uint16, uint32, uint64 functions
--------------------+------------------------
  Reporter:  yun    |      Owner:
      Type:  Patch  |     Status:  new
  Priority:  Low    |  Milestone:  Bro2.2
 Component:  Bro    |    Version:  git/master
Resolution:         |   Keywords:  bytestring
--------------------+------------------------

Comment (by yun):

 Replying to [comment:33 jsiwek]:
 > Replying to [comment:31 yun]:
 > > Replying to [comment:30 robin]:
 > > > Thinking about it, would it be better to switch the boolean to
 > > > indicate host- vs. network-byte order, rather than big-endian vs
 > > > low-endian?
 > >
 > > I think that would not work as that would make the bro script platform
 dependent. So for example using the bro script on a little endian platform
 would read the bytestream differently on a big endian platform if you
 specified host order.
 >
 > If a bytestring is parsed from some network traffic and delivered to the
 script-layer, it's either going to be in host order or network order and
 usually no one has to care the endianness that's behind those if they've
 got access to `hton*/ntoh*` functions that will hide any of the byte
 swapping that may be needed.
 >
 > So I think it makes more sense for a `bytestring_to_count` function to
 have a boolean flag for network vs. host order (instead of big vs. little
 endian).
 >
 > Or has endianness explicitly been exposed to the script-layer for some
 reason in your case?

 The problem is that Bro does not have access to {{{hton*/ntoh*}}}
 functions, I did add the {{{reverse()}}} function that could be used for
 that. That's why the initial function was only {{{bytestring_to_count()}}}
 without any boolean flag. But indeed if Bro had access to these functions
 then the boolean could go away.

 It's true that I don't care in what byte order it's stored on my machine
 but I do care when I read it from a packet. Most applications send bytes
 as big-ending/network-order, but in some cases it's sent as little-endian.

 A good example is Metasploit. Which when it sends the Meterpreter payload
 to the victim it will first send a 32bit unsigned integer (4 bytes) of the
 payload size before sending the actual payload.
 Normally you would expect it to be in network-order/big-endian, but
 Metasploit sends the size in little-endian.. So if I read this from the
 packet, I definitely want to ensure that I read it from the known order.

 If the payload size was 255 bytes long I could have read 0xFF000000
 instead of 0x000000FF.

 I hope this make sense, it's been a long discussion :)

-- 
Ticket URL: <http://tracker.bro.org/bro/ticket/968#comment:34>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker



More information about the bro-dev mailing list