[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