Bro-Dev Group,
ISSUE: I encountered an issue where Bro is not logging some rather
significant SMB1 commands in the smb_cmd.log file. I understand that some
SMB commands are deliberately omitted from the log (such as Negotiate
Protocol, Session Setup, and Tree Connect); however, I observe that an
10:46 PM
To: Fernandez, Mark I
Cc: bro-dev@bro.org
Subject: Re: [Bro-Dev] Bro DCE-RPC Fix for AlterContext and
AlterContextResponse Parsers
On 2 Feb 2018, at 9:54, Fernandez, Mark I wrote:
> 5. Bro Issue Tracker
>
> I plan to submit this to Bro Issue Tracker. Just wanted to give you a
Bro-Dev Group,
I am digging thru the BinPAC code for the DCE-RPC analyzer, and I noticed a
couple of developer-comments that I think could be related, and perhaps even
resolved, by a simple fix.
1. Developer BinPAC Comments
See Lines 153-155 of dce_rpc-protocol.pac
[https://github.com/bro/bro
probably the preferred
long-term solution. Con: It may be a little more challenging for me to code it
correctly, take me a lot longer to implement.
Am I close to the right answer for sending data to the at-svc parser?
Thanks,
Mark
From: Seth Hall [mailto:s...@corelight.com]
Sent: Wednesday,
Bro-Dev Group,
I am doing a little research into using Bro to log and analyze specific
Microsoft DCE-RPC interfaces and methods. I notice that the Bro events for
'dce_rpc_request' and 'dce_rpc_response' provide the length of the RCP data
stub (aka 'stub_len'). I found reference that these eve
Aaron,
>> I have a protocol that loads a given TCP packet with as many publish
>> messages as possible in a worst case scenario - often it just has a
>> single message, but it is not guaranteed. When a publish message
>> contains more than one subsequent message, there is not an indicator
>> that
As you can see, Line 1019 passes '1' as the value for trailing_CRLF and then
Line 156 complains if the value is '1', causing Bro to abort.
Mark
From: Fernandez, Mark I
Sent: Tuesday, November 01, 2016 9:45 AM
To: 'bro-dev@bro.org'
Subject: Bro Debug Mode :: Assert
Bro Dev Team,
While trying to translate the ICAP Analyzer into a Bro Plugin, I discovered
that my ICAP Analyzer fails an assertion in HTTP.cc Line 156. I discovered it
only recently because last week I compiled Bro in debug mode for the first time
in order to troubleshoot the Plugin. (Fact: I
In support of submitting the ICAP Analyzer as a Bro Package, I am porting the
ICAP Analyzer to build as a dynamic Plugin. Originally, I inserted the ICAP
Analyzer straight into the source code tree, under /src/analyzer/protocol/icap,
and compiled it as part of the Bro core. But in an effort t
event handler
for 'http_request' and therein set the value of 'c$http$orig_u' accordingly.
Fortunately, this worked, but I wonder why it did not work within
'icap_header', why the value was lost?
Thanks!
Mark I. Fernandez
-Original Message-
From: Seth Hall [m
I am reviewing my source code and scripts for the ICAP Analyzer that I
presented last week at BroCon, with the intent of releasing the new analyzer to
the Bro community. There is one key aspect which I designed a certain way, but
I wonder if it would be acceptable by the community or if it woul
11 matches
Mail list logo
