From jmzhou.ml at gmail.com Fri Jun 1 13:36:36 2007 From: jmzhou.ml at gmail.com (jmzhou.ml at gmail.com) Date: Fri, 1 Jun 2007 13:36:36 -0700 (PDT) Subject: [Bro] ssl binpac analyzer -- patches In-Reply-To: References: <200705261938.l4QJcnXi091065@jaguar.icir.org> <4658AB92.9020304@klipix.org> <2e4d286d0705291721u2c555dbblc9bd4fb400701ce2@mail.gmail.com> <2e4d286d0705302211l48fe0853y92213923e405b6b2@mail.gmail.com> Message-ID: On Thu, 31 May 2007, Ruoming Pang wrote: >> . Binpac does not support SunRPC over TCP now. There are four extra bytes >> prepended in RPC packets. Either TCP layer decoder should take care of >> these extra bytes, or the RPC decoder has to do something with it. In >> addition, &exportsourcedata is used in RPC/UDP decoder based on datagram >> mode. It is not supported by flowunit mode. This means, we cannot simply >> change the decoder from datagram mode to flowunit mode for RPC/TCP. > > The way I imagine doing this is to consider RPC on TCP a trivial > lower-level protocol than RPC on UDP. For each RPC-on-TCP message, the > analyzer calls the datagram mode RPC analyzer's NewData() routine. > What do you think? I think the problem is not that simple. First let's look at the case of RPC/UDP, it is possible that a RPC message is transmitted in multiple IP packets due to IP fragmentation. Either the lower layer should reassemble the entire RPC message from IP fragments, or just it sends the fragment pieces to the RPC decoder in order. In the second scenario, the RPC decoder has to use flowunit mode. In the case of RPC/TCP, the first four bytes specifies the length of a RPC record (not necessarily be a complete RPC message from my understanding of the RPC RFC). It is called Record Marker. Because of the stream nature of TCP, the RPC record may be transmitted in multiple TCP packets. Although from some traces, I see that a TCP packet always contains the four bytes and the complete RPC message. I do not think we can make a safe assumption that this is always true. In addition, if a RPC record is not a complete RPC message, this introduces another problem to the RPC decoder. A complete RPC message may be transmitted in two records, and each record is prepended with a Record Marker. The position to split the two records can be arbitrary! I do not see a solution in the current binpac language to handle this kind of cases. Best wishes, Jimmy ____________________________________________________________ The future is not set. There is no fate but what we make for ourselves. - Terminator II, Judgment Day ------------------------------------------------------------ From jmzhou.ml at gmail.com Fri Jun 1 14:08:55 2007 From: jmzhou.ml at gmail.com (jmzhou.ml at gmail.com) Date: Fri, 1 Jun 2007 14:08:55 -0700 (PDT) Subject: [Bro] ssl binpac analyzer -- patches In-Reply-To: <2e4d286d0705302211l48fe0853y92213923e405b6b2@mail.gmail.com> References: <200705261938.l4QJcnXi091065@jaguar.icir.org> <4658AB92.9020304@klipix.org> <2e4d286d0705291721u2c555dbblc9bd4fb400701ce2@mail.gmail.com> <2e4d286d0705302211l48fe0853y92213923e405b6b2@mail.gmail.com> Message-ID: Oooops, I think there is a potential flaw in my Analysis point 2. Imagine that a parsing will just consume an incoming packet - nothing more and nothing less. After the parsing, data_available probably will not be false because of the way flow buffer is implemented - orig_data_begin_ will only be increased to orig_data_end_ upon the next request! So, at the while loop, data_available = true, have_pending_request = true (from last request), and ready = true (from last request, too). So we end up with entering the loop again! In fact, to check orig_data_begin < orig_data_end_ in the current data_available is wrong from its intention. I think we need to do something with the flow buffer implementation. The current method to increase orig_data_begin_ upon new request is tricky and difficult to make things correct. My suggestion is to increase orig_data_begin_ in the end() method. The reason is: whenever you request data from the flow buffer, you always call begin() and end() in sequence. These methods are the only ways that you can access the data in the flow buffer. After the call of end(), the decoder will not call begin() and end() again except in one case which I will address shortly. Thus, it is safe to increase orig_data_begin_ pointer in the end() call. After this change, checking orig_data_begin_ < orig_data_end_ in data_available() method is correct. BTW, it is not needed to check buffer_n_ > 0 in data_available(). Because if something is buffered, and we reach the entry point of the while loop, orig_data_begin_ must be equal to orig_data_end_. The next parsing must use new data instead of the data in flow buffer. In addition, in NewFrame and NewLine, there's no need to increase orig_data_begin_ by frame_length_ after the change of end(). The only case that begin() and end() may be called twice is the &until check of $input for array elements. The &until check will be done before actual parsing of array elements. Thus, it needs to access the data, too. I suggest to add a new method end_no_effect() to flow buffer which does not increase orig_data_begin_. It is called before the &until check of $input. Moreover, if the $input check is true, we must call end() in order to force flow buffer to increase the orig_data_begin_ because there will be no parsing of array element. Regards, Jimmy On Wed, 30 May 2007, Tobias Kiesling wrote: > Jimmy, > > your suggestion sounds good. I implemented the changes and tested them with > my ssl analyzer. Everything worked as expected. :-) > > Attached you can find the patch for these changes (to be applied with -p0 in > the bro directory, after applying all of the other binpac patches that I > provided before). Could you test this further with whatever binpac analyzers > you have got? > > Anyone else any comments on this issue (Ruoming)? > > Tobias > > > On 5/30/07, jmzhou.ml at gmail.com wrote: >> >> On Tue, 29 May 2007, Tobias Kiesling wrote: >> >> > On 5/29/07, jmzhou.ml at gmail.com wrote: >> > >> >> Patch 6: I think there is another issue here: if some buffering request >> >> has been sent to the flow buffer, and the flow buffer is not ready with >> >> partial data, we will end up with entering the loop - a waste of CPU >> >> cycles. >> > >> > >> > Maybe you are right, but what would you suggest as change? Do you want >> to >> > check whether the buffer is ready before entering the loop? But then it >> has >> > to be ensured that the buffer is properly initialized in any case. At >> the >> > moment I cannot see all the consequences of such a change. And do you >> think >> > that the impact on performance is really relevant? >> >> The cost can be a little bit expensive if there are many layers of >> parsing. >> You end up with many unnecessary calls to parsing functions and condition >> jumps. One possible approach is like this: >> >> . add a new boolean member have_pending_request to FlowBuffer, initialized >> as false. >> >> . set have_pending_request to true in call NewFrame and NewLine. >> >> . reset have_pending_request to false in call DiscardData. >> >> . change the while loop condition to: >> while (flow_buffer->data_available() && >> (!flow_buffer->have_pending_request() || flow_buffer->ready())) >> >> Analysis: >> >> 1. The first time, data_available = true, !have_pending_request = true, >> we enter into the loop. Good. >> >> 2. All data are consumed, data_available = false, we do not enter into >> the loop. Good. >> >> 3. A request is not satisfied because of partial data: data_available = >> true, !have_pending_request = false, ready = false, we do not enter into >> the loop. Good. >> >> 4. Parsing is forced to stop because of exception. data_available = >> false. >> We do not enter into the loop. Good. >> >> 5. Parsing current dataunit has finished, we still have residual data - >> wrong data? data_available = true, !have_pending_request = false, ready = >> true (from last parsing). We enter into the loop, and start a new round of >> parsing. As expected. Good. >> >> So far so good. :-) >> >> Jimmy >> >> ____________________________________________________________ >> The future is not set. There is no fate but what we make >> for ourselves. - Terminator II, Judgment Day >> ------------------------------------------------------------ >> >> > ____________________________________________________________ The future is not set. There is no fate but what we make for ourselves. - Terminator II, Judgment Day ------------------------------------------------------------ From rpang at cs.princeton.edu Fri Jun 1 16:02:26 2007 From: rpang at cs.princeton.edu (Ruoming Pang) Date: Fri, 1 Jun 2007 19:02:26 -0400 Subject: [Bro] ssl binpac analyzer -- patches In-Reply-To: References: <200705261938.l4QJcnXi091065@jaguar.icir.org> <4658AB92.9020304@klipix.org> <2e4d286d0705291721u2c555dbblc9bd4fb400701ce2@mail.gmail.com> <2e4d286d0705302211l48fe0853y92213923e405b6b2@mail.gmail.com> Message-ID: > > The way I imagine doing this is to consider RPC on TCP a trivial > > lower-level protocol than RPC on UDP. For each RPC-on-TCP message, the > > analyzer calls the datagram mode RPC analyzer's NewData() routine. > > What do you think? > > I think the problem is not that simple. Hi, Jimmy, Maybe I wasn't clear enough, but I don't understand the problems you raised below. What I mean by a "RPC-on-TCP" message is a complete RPC message, rather than a fragment. Maybe that's where the confusion is. In any case, I think the thin RPC-over-TCP layer can be fully isolated from the datagram-mode RPC analyzer, as long as the RPC analyzer receives only complete RPC messages. The reassembly has to be done in C++, but it's relatively trivial. > First let's look at the case of RPC/UDP, it is possible that a RPC message > is transmitted in multiple IP packets due to IP fragmentation. Either the > lower layer should reassemble the entire RPC message from IP fragments, or > just it sends the fragment pieces to the RPC decoder in order. binpac analyzers do not see IP fragments. They should all be reassembled at lower level, as in Bro. It's the same story at TCP level and at RPC-over-TCP level. Ruoming > In the case of RPC/TCP, the first four bytes specifies the length of a RPC > record (not necessarily be a complete RPC message from my understanding of > the RPC RFC). It is called Record Marker. Because of the stream nature of > TCP, the RPC record may be transmitted in multiple TCP packets. Although > from some traces, I see that a TCP packet always contains the four bytes > and the complete RPC message. I do not think we can make a safe assumption > that this is always true. In addition, if a RPC record is not a complete > RPC message, this introduces another problem to the RPC decoder. A complete > RPC message may be transmitted in two records, and each record is prepended > with a Record Marker. The position to split the two records can be arbitrary! > I do not see a solution in the current binpac language to handle this kind > of cases. > > Best wishes, > > Jimmy > > ____________________________________________________________ > The future is not set. There is no fate but what we make > for ourselves. - Terminator II, Judgment Day > ------------------------------------------------------------ > From kiesling at ICSI.Berkeley.EDU Mon Jun 4 10:38:59 2007 From: kiesling at ICSI.Berkeley.EDU (Tobias Kiesling) Date: Mon, 4 Jun 2007 10:38:59 -0700 Subject: [Bro] ssl binpac analyzer -- patches In-Reply-To: References: <200705261938.l4QJcnXi091065@jaguar.icir.org> <4658AB92.9020304@klipix.org> <2e4d286d0705291721u2c555dbblc9bd4fb400701ce2@mail.gmail.com> <2e4d286d0705302211l48fe0853y92213923e405b6b2@mail.gmail.com> Message-ID: <2e4d286d0706041038u1770bed5i369c212d0884bcc7@mail.gmail.com> On 6/1/07, jmzhou.ml at gmail.com wrote: > > Oooops, I think there is a potential flaw in my Analysis point 2. Imagine > that a parsing will just consume an incoming packet - nothing more and > nothing less. After the parsing, data_available probably will not be false > because of the way flow buffer is implemented - orig_data_begin_ will only > be increased to orig_data_end_ upon the next request! So, at the while > loop, > data_available = true, have_pending_request = true (from last request), > and > ready = true (from last request, too). So we end up with entering the loop > again! In fact, to check orig_data_begin < orig_data_end_ in the current > data_available is wrong from its intention. I was well aware of that fact, but did not see a problem here, as in my SSL analyzer I manually assure that after parsing a data packet, the corresponding data is consumed. In that case, data_available() works just as intended. I don't think, that it is a good idea to introduce side effects into the end() function just for a slight increase in performance. On one hand, the end() function is in the public interface of the buffer and you should never significantly change the behavior of a public method (some binpac users might rely on that behavior), except for very good reasons. On the other hand, in cases where there might be a serious performance problem with the current behavior, the programmer can manually avoid this by explicitly consuming the data, like I do in my analyzer (of course this should be documented ;-). > I think we need to do something with the flow buffer implementation. The > current method to increase orig_data_begin_ upon new request is tricky and > difficult to make things correct. My suggestion is to increase > orig_data_begin_ > in the end() method. The reason is: whenever you request data from the > flow > buffer, you always call begin() and end() in sequence. These methods are > the > only ways that you can access the data in the flow buffer. After the call > of end(), the decoder will not call begin() and end() again except in one > case which I will address shortly. Thus, it is safe to increase > orig_data_begin_ > pointer in the end() call. After this change, checking orig_data_begin_ < > orig_data_end_ in data_available() method is correct. BTW, it is not > needed > to check buffer_n_ > 0 in data_available(). Because if something is > buffered, > and we reach the entry point of the while loop, orig_data_begin_ must be > equal to orig_data_end_. The next parsing must use new data instead of the > data in flow buffer. In addition, in NewFrame and NewLine, there's no need > to increase orig_data_begin_ by frame_length_ after the change of end(). Again, data_available() is a public method that is not just intended for the single use we have discussed so far (I use it explicitly in my analyzer). You can always use it to check whether there is currently any data available, and of course this includes the buffer. Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20070604/20da4893/attachment.html From jmzhou.ml at gmail.com Mon Jun 4 10:44:01 2007 From: jmzhou.ml at gmail.com (jmzhou.ml at gmail.com) Date: Mon, 4 Jun 2007 10:44:01 -0700 (PDT) Subject: [Bro] a small patch to binpac Message-ID: The problem: type MyRecord = record { f1: SomeRecordType; f2: bytestring &length=body_len; } &let { body_len: uint32 = f1.rec_len - sizeof (f1); }; The above definition looks familiar, uh? It is a simplifed version of the DCE RPC PDU. If MyRecord is incrementally parsed, the sizeof (f1) in the &let construct will cause trouble because getFieldBegin and getFieldEnd can only be used for non-incremental parsed record. If the size of SomeRecordType is decideable statically (in the case of DCE RPC, it is), then the patch fixes the problem. Now we can make the PDU incrementally parsed. Cheers, Jimmy ____________________________________________________________ The future is not set. There is no fate but what we make for ourselves. - Terminator II, Judgment Day ------------------------------------------------------------ -------------- next part -------------- --- bro-1.2.1.orig/src/binpac/pac_record.cc 2007-05-24 13:59:23.000000000 -0700 +++ bro-1.2.1/src/binpac/pac_record.cc 2007-06-04 09:29:17.000000000 -0700 @@ -350,6 +350,13 @@ if ( field_size_expr ) return field_size_expr; + int static_size = type_->StaticSize (env); + if (static_size >= 0) + { + field_size_expr = nfmt("%d", static_size); + return field_size_expr; + } + const DataPtr& begin = getFieldBegin(out_cc, env); const DataPtr& end = getFieldEnd(out_cc, env); if ( begin.id() == end.id() ) From jmzhou.ml at gmail.com Thu Jun 7 14:10:44 2007 From: jmzhou.ml at gmail.com (jmzhou.ml at gmail.com) Date: Thu, 7 Jun 2007 14:10:44 -0700 (PDT) Subject: [Bro] binpac const string size patch Message-ID: Hi, Here is a patch to fix length calculation of a const string. The problem: if you define a const string such as "Whatever\x00" in binpac, the size of the string becomes 8 instead of 9! Happy hacking! Jimmy ____________________________________________________________ The future is not set. There is no fate but what we make for ourselves. - Terminator II, Judgment Day ------------------------------------------------------------ -------------- next part -------------- diff -ruN bro-1.2.1.orig/src/binpac/pac_common.h bro-1.2.1/src/binpac/pac_common.h --- bro-1.2.1.orig/src/binpac/pac_common.h 2006-07-26 15:02:40.000000000 -0700 +++ bro-1.2.1/src/binpac/pac_common.h 2007-04-18 11:09:16.000000000 -0700 @@ -105,6 +105,11 @@ if ( pc ) \ for ( ct::iterator i = (pc)->begin(); i != (pc)->end(); ++i ) +#define foreach_rev(i, ct, pc) \ + if ( pc ) \ + for ( ct::iterator i = (pc)->end(); i-- != (pc)->begin(); ) + + #define delete_list(ct, pc) \ { \ foreach(delete_list_i, ct, pc) \ diff -ruN bro-1.2.1.orig/src/binpac/pac_decl.cc bro-1.2.1/src/binpac/pac_decl.cc --- bro-1.2.1.orig/src/binpac/pac_decl.cc 2006-07-26 15:02:40.000000000 -0700 +++ bro-1.2.1/src/binpac/pac_decl.cc 2007-05-08 13:59:22.000000000 -0700 @@ -9,6 +9,7 @@ #include "pac_output.h" #include "pac_param.h" #include "pac_record.h" +#include "pac_flow.h" #include "pac_type.h" #include "pac_utils.h" @@ -70,6 +71,8 @@ if ( ! decl_list_ ) return; + get_flow_decl()->MarkIncrementalInput(); + foreach(i, DeclList, decl_list_) { Decl *decl = *i; diff -ruN bro-1.2.1.orig/src/binpac/pac_expr.def bro-1.2.1/src/binpac/pac_expr.def --- bro-1.2.1.orig/src/binpac/pac_expr.def 2006-07-26 15:02:39.000000000 -0700 +++ bro-1.2.1/src/binpac/pac_expr.def 2007-04-18 11:06:47.000000000 -0700 @@ -14,7 +14,7 @@ EXPR_DEF(EXPR_MINUS, 2, "%s - %s") EXPR_DEF(EXPR_TIMES, 2, "%s * %s") EXPR_DEF(EXPR_DIV, 2, "%s / %s") -EXPR_DEF(EXPR_MOD, 2, "%s % %s") +EXPR_DEF(EXPR_MOD, 2, "%s %% %s") EXPR_DEF(EXPR_BITNOT, 1, "~%s") EXPR_DEF(EXPR_BITAND, 2, "%s & %s") EXPR_DEF(EXPR_BITOR, 2, "%s | %s") diff -ruN bro-1.2.1.orig/src/binpac/pac_field.cc bro-1.2.1/src/binpac/pac_field.cc --- bro-1.2.1.orig/src/binpac/pac_field.cc 2006-07-26 15:02:39.000000000 -0700 +++ bro-1.2.1/src/binpac/pac_field.cc 2007-04-19 09:23:59.000000000 -0700 @@ -12,6 +12,7 @@ decl_id_ = current_decl_id; field_id_str_ = strfmt("%s:%s", decl_id()->Name(), id_->Name()); attrs_ = 0; + prepared_ = false; } Field::~Field() @@ -73,6 +74,11 @@ void Field::Prepare(Env *env) { + /* prevent infinite recursion */ + if ( prepared_ ) + return ; + prepared_ = true; + if ( type_ ) { if ( anonymous_field() ) diff -ruN bro-1.2.1.orig/src/binpac/pac_field.h bro-1.2.1/src/binpac/pac_field.h --- bro-1.2.1.orig/src/binpac/pac_field.h 2006-07-26 15:02:40.000000000 -0700 +++ bro-1.2.1/src/binpac/pac_field.h 2007-04-19 09:24:05.000000000 -0700 @@ -74,6 +74,7 @@ protected: FieldType tof_; int flags_; + bool prepared_; ID* id_; Type *type_; const ID* decl_id_; diff -ruN bro-1.2.1.orig/src/binpac/pac_flow.cc bro-1.2.1/src/binpac/pac_flow.cc --- bro-1.2.1.orig/src/binpac/pac_flow.cc 2006-10-12 14:13:12.000000000 -0700 +++ bro-1.2.1/src/binpac/pac_flow.cc 2007-05-08 13:57:27.000000000 -0700 @@ -15,6 +15,20 @@ #include "pac_varfield.h" +static FlowDecl* g_flow_decl = NULL; + +FlowDecl* get_flow_decl() +{ + return g_flow_decl; +} + +void set_flow_decl(FlowDecl* decl) +{ + assert (NULL == g_flow_decl); + g_flow_decl = decl; +} + + FlowDecl::FlowDecl(ID *id, ParamList *params, AnalyzerElementList *elemlist) @@ -24,6 +38,8 @@ conn_decl_ = 0; flow_buffer_var_field_ = 0; AddElements(elemlist); + + set_flow_decl (this); } FlowDecl::~FlowDecl() @@ -55,6 +71,14 @@ "flow should be defined in only a connection declaration"); } +void FlowDecl::MarkIncrementalInput() + { + if ( dataunit_->type() != AnalyzerDataUnit::FLOWUNIT ) + return; + + dataunit_->data_type()->MarkIncrementalInput(); + } + void FlowDecl::ProcessDataUnitElement(AnalyzerDataUnit *dataunit_elem) { if ( dataunit_ ) @@ -66,7 +90,7 @@ if ( dataunit_->type() == AnalyzerDataUnit::FLOWUNIT ) { - dataunit_->data_type()->MarkIncrementalInput(); + //dataunit_->data_type()->MarkIncrementalInput(); flow_buffer_var_field_ = new PrivVarField( flow_buffer_id->clone(), diff -ruN bro-1.2.1.orig/src/binpac/pac_flow.h bro-1.2.1/src/binpac/pac_flow.h --- bro-1.2.1.orig/src/binpac/pac_flow.h 2006-07-26 15:02:39.000000000 -0700 +++ bro-1.2.1/src/binpac/pac_flow.h 2007-05-08 14:01:13.000000000 -0700 @@ -3,6 +3,8 @@ #include "pac_analyzer.h" +FlowDecl* get_flow_decl(); + class FlowDecl : public AnalyzerDecl { public: @@ -12,6 +14,7 @@ void Prepare(); void set_conn_decl(ConnDecl *c) { conn_decl_ = c; } + void MarkIncrementalInput(); static ParameterizedType *flow_buffer_type(); diff -ruN bro-1.2.1.orig/src/binpac/pac_type.cc bro-1.2.1/src/binpac/pac_type.cc --- bro-1.2.1.orig/src/binpac/pac_type.cc 2006-07-26 15:02:40.000000000 -0700 +++ bro-1.2.1/src/binpac/pac_type.cc 2007-04-19 09:29:56.000000000 -0700 @@ -305,9 +305,40 @@ } } + /* prepare parameter fields first as they may be dependency */ foreach (i, FieldList, fields_) { Field *f = *i; + if (PARAM_FIELD == f->tof()) + f->Prepare(env); + } + + foreach (i, FieldList, fields_) + { + Field *f = *i; + Expr* req; + if (NULL == f->type() /* can be a padding field */ || + NULL == (req = f->type()->attr_requires())) + { + /* there is no &requires dependents, good! */ + f->Prepare(env); + continue; + } + + /* there are dependents on some &let fields :-( */ + ASSERT(Expr::EXPR_CALLARGS == req->expr_type()); + + FieldList::iterator newi = i+1; + for (; newi != fields_->end(); ++ newi) + { + /* not a field of &let, ignore it */ + Field* newf = *newi; + if (LET_FIELD != newf->tof()) + continue; + + if (req->HasReference (newf->id())) + newf->Prepare(env); + } f->Prepare(env); } } @@ -367,7 +398,7 @@ void Type::GenCleanUpCode(Output* out_cc, Env* env) { - foreach (i, FieldList, fields_) + foreach_rev (i, FieldList, fields_) { Field *f = *i; if ( f->tof() != CASE_FIELD ) diff -ruN bro-1.2.1.orig/src/binpac/pac_type.h bro-1.2.1/src/binpac/pac_type.h --- bro-1.2.1.orig/src/binpac/pac_type.h 2006-10-17 15:46:32.000000000 -0700 +++ bro-1.2.1/src/binpac/pac_type.h 2007-04-19 09:28:18.000000000 -0700 @@ -155,6 +155,7 @@ Expr *attr_if_expr() const { return attr_if_expr_; } // TODO: generate the length expression automatically. Expr *attr_length_expr() const { return attr_length_expr_; } + Expr *attr_requires() const { return attr_requires_; } bool attr_refcount() const { return attr_refcount_; } bool attr_transient() const { return attr_transient_; } From jmzhou.ml at gmail.com Thu Jun 7 21:48:04 2007 From: jmzhou.ml at gmail.com (jmzhou.ml at gmail.com) Date: Thu, 7 Jun 2007 21:48:04 -0700 (PDT) Subject: [Bro] binpac const string size patch (fwd) Message-ID: Oooops, sent the wrong patch. Here is the correct one. Sorry about that. ---------- Forwarded message ---------- Date: Thu, 7 Jun 2007 14:10:44 -0700 (PDT) From: jmzhou.ml at gmail.com Reply-To: Jingmin Zhou To: bro at bro-ids.org Subject: binpac const string size patch Hi, Here is a patch to fix length calculation of a const string. The problem: if you define a const string such as "Whatever\x00" in binpac, the size of the string becomes 8 instead of 9! Happy hacking! Jimmy ____________________________________________________________ The future is not set. There is no fate but what we make for ourselves. - Terminator II, Judgment Day ------------------------------------------------------------ -------------- next part -------------- --- bro-1.2.1.orig/src/binpac/pac_type.cc 2007-05-24 13:59:24.000000000 -0700 +++ bro-1.2.1/src/binpac/pac_type.cc 2007-06-07 12:56:52.000000000 -0700 @@ -840,7 +871,13 @@ int ss = StaticSize(env); if ( ss >= 0 ) { - return strfmt("%d", ss); + if (STRING == tot()) + { + StringType* sthis = (StringType*) this; + return sthis->GetStaticSize(); + } + else + return strfmt("%d", ss); } else { --- bro-1.2.1.orig/src/binpac/pac_strtype.cc 2007-05-24 13:59:23.000000000 -0700 +++ bro-1.2.1/src/binpac/pac_strtype.cc 2007-06-07 12:55:38.000000000 -0700 @@ -243,12 +243,17 @@ } } +string StringType::GetStaticSize(Env* env) + { + return strfmt ("sizeof (%s) -1", str_->c_str()); + } + string StringType::GenStringSize(Output* out_cc, Env* env, const DataPtr& data) { int static_size = StaticSize(env); if ( static_size >= 0 ) - return strfmt("%d", static_size); + return GenStaticSize (env); GenDynamicSize(out_cc, env, data); return env->RValue(string_length_var()); } --- bro-1.2.1.orig/src/binpac/pac_strtype.h 2007-05-24 13:59:30.000000000 -0700 +++ bro-1.2.1/src/binpac/pac_strtype.h 2007-06-07 12:55:30.000000000 -0700 @@ -29,6 +29,7 @@ void DoMarkIncrementalInput(); int StaticSize(Env* env) const; + string GetStaticSize() const; bool IsPointerType() const { return false; } From delrabih at yahoo.com Mon Jun 18 03:06:37 2007 From: delrabih at yahoo.com (Diana El Rabih) Date: Mon, 18 Jun 2007 03:06:37 -0700 (PDT) Subject: [Bro] (no subject) Message-ID: <928666.36597.qm@web52603.mail.re2.yahoo.com> my mail is delrabih at yahoo.com --------------------------------- Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20070618/94f043de/attachment.html From delrabih at yahoo.com Mon Jun 18 03:10:20 2007 From: delrabih at yahoo.com (Diana El Rabih) Date: Mon, 18 Jun 2007 03:10:20 -0700 (PDT) Subject: [Bro] Urgent, plz Help me Message-ID: <912736.25167.qm@web52606.mail.re2.yahoo.com> Hi, please i am a researcher interested to test your powerful system Bro compare our method of anomaly detection implemented in our laboratory in france; Plz i have some questions, plz i need a help to know responses on them: our traces are files saved on a certain server in TCPDump format,and we need only to know if the anomalies in these traces are detected or not then we need only to test Bro with offline data and then i am interested to know,can we do that? and then can we avoid the configuration phase of Bro(giving interfaces names and local nets)? How can we get the detection alert of Bro, is it just by email? If i want to run Bro in TRW mode, can i do it?and how? I try to install the Bro but i dont have a root log in and i tried to installa it and when i do configure, it give an error that it does not found the OpenSSL libcrypto library?how can i resolve this problem to arrive to make and make install the Bro? thank you very much. --------------------------------- Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20070618/4f5e5fb3/attachment.html From delrabih at yahoo.com Mon Jun 18 03:10:20 2007 From: delrabih at yahoo.com (Diana El Rabih) Date: Mon, 18 Jun 2007 03:10:20 -0700 (PDT) Subject: [Bro] Urgent, plz Help me Message-ID: <912736.25167.qm@web52606.mail.re2.yahoo.com> Hi, please i am a researcher interested to test your powerful system Bro compare our method of anomaly detection implemented in our laboratory in france; Plz i have some questions, plz i need a help to know responses on them: our traces are files saved on a certain server in TCPDump format,and we need only to know if the anomalies in these traces are detected or not then we need only to test Bro with offline data and then i am interested to know,can we do that? and then can we avoid the configuration phase of Bro(giving interfaces names and local nets)? How can we get the detection alert of Bro, is it just by email? If i want to run Bro in TRW mode, can i do it?and how? I try to install the Bro but i dont have a root log in and i tried to installa it and when i do configure, it give an error that it does not found the OpenSSL libcrypto library?how can i resolve this problem to arrive to make and make install the Bro? thank you very much. --------------------------------- Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20070618/4f5e5fb3/attachment-0001.html From jean-philippe.luiggi at didconcept.com Mon Jun 18 18:22:38 2007 From: jean-philippe.luiggi at didconcept.com (jean-philippe luiggi) Date: Mon, 18 Jun 2007 21:22:38 -0400 Subject: [Bro] Urgent, plz Help me In-Reply-To: <912736.25167.qm@web52606.mail.re2.yahoo.com> References: <912736.25167.qm@web52606.mail.re2.yahoo.com> Message-ID: <20070618212238.6b860f01@mygw.lan.mynetwork.local> Hello all, I'm speaking directly (in French) with Diana in order to help her about the first stages. Be sure we'll come back later as needed. Best regards, Jean-philippe. On Mon, 18 Jun 2007 03:10:20 -0700 (PDT) Diana El Rabih wrote: > Hi, > > please i am a researcher interested to test your powerful system Bro > compare our method of anomaly detection implemented in our laboratory > in france; > > Plz i have some questions, plz i need a help to know responses on > them: > our traces are files saved on a certain server in TCPDump format,and > we need only to know if the anomalies in these traces are detected or > not then we need only to test Bro with offline data and then i am > interested to know,can we do that? and then can we avoid the > configuration phase of Bro(giving interfaces names and local nets)? > How can we get the detection alert of Bro, is it just by email? > If i want to run Bro in TRW mode, can i do it?and how? > > I try to install the Bro but i dont have a root log in and i tried > to installa it and when i do configure, it give an error that it does > not found the OpenSSL libcrypto library?how can i resolve this > problem to arrive to make and make install the Bro? > > thank you very much. > > > > --------------------------------- > Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see > what's on, when. > > > > > !DSPAM:1,467665a0320041214316380!