[Bro] Hashing incomplete files

Josh Liburdi liburdi.joshua at gmail.com
Tue Apr 25 10:43:06 PDT 2017


I take it back, my code was off -- seems fine now. It would be nice if this
could be enabled as an option via an argument.

On Tue, Apr 25, 2017 at 11:56 AM, Josh Liburdi <liburdi.joshua at gmail.com>
wrote:

> Actually, I think I understand what you mean now -- with some of the PCAPs
> I have, the hash for incomplete files changes from run to run.
>
> On Tue, Apr 25, 2017 at 10:55 AM, Josh Liburdi <liburdi.joshua at gmail.com>
> wrote:
>
>> Kevin was correct -- filling in the incomplete space with nulls produces
>> the same MD5 hash.
>>
>> Johanna, in the case of an "incomplete" file, could multiple simultaneous
>> streams produce an inconsistent hash? Not sure I understand how multiple
>> streams might affect a file's completeness, but would happy to hear your
>> thoughts.
>>
>> Josh
>>
>> On Tue, Apr 25, 2017 at 10:49 AM, Johanna Amann <johanna at icir.org> wrote:
>>
>>> On Tue, Apr 25, 2017 at 02:34:41PM +0000, McMahon, Kevin J wrote:
>>> > I’m guessing that Bro doesn’t pass a string of nulls to the hash
>>> > function when there’s an undelivered chunk.  But that’s what ends up in
>>> > the file (I don’t know if that’s a side effect or intentional – but it
>>> > is useful as all the other bits end up in the right place and you can
>>> > find the holes after the fact).  So I wouldn’t expect that the hash
>>> > would be the same.
>>>
>>> Just to add a bit to this - I think this behavior is intentional and
>>> used,
>>> e.g., when a file is downloaded from over multiple streams
>>> simultaneously.
>>>
>>> Johanna
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20170425/425845d7/attachment-0001.html 


More information about the Bro mailing list