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 events previously provided a byte string containing the stub data itself, but at some point it was reduced to just the stub_len instead. I have a few questions that I hope you could answer:
The original idea was to get extensive parsing in place for DCE-RPC messages by parsing the IDL files for those services. Someone in the community had hoped to take it on, but hasn’t had time yet to complete it. If you’d be interested in discussing that, I think that could be a huge addition to Bro (hundreds of new events!).
The At service parsing file is still there because I didn’t want to lose track of it but I think there was some slight architectural change that needed to happen before I could pass data to it. I don’t think that data is even going to that parser, it’s not just that there aren’t events. I’d have to refer back to the code to see what exactly is wrong though.
As for an approach to this problem right now, I’d prefer to see parsing done in the core. Architecturally we try to avoid passing unparsed data to Bro script land because of performance concerns and we generally don’t have the intrinsic tools to be able to do parsing well in Bro scripts.
.Seth
Seth,
If you’d be interested in discussing that, I think that could be a huge
addition to Bro (hundreds of new events!).
Yes, I am interested in parsing IDL files, but I plan to do so very selectively. For example, for the At service, I don’t care about all four opnums it exposes… I just care about NetrJobAdd (which indeed is how you designed, too), and I want to log the command and the remote host to which the command was sent. Similarly, for the Server Service, I don’t care about all fifty opnums that it exposes… I just care about a handful of them, and I want to log key pieces of information associated with the function call.
At this point, I have my eye on a few, maybe up to a dozen, specific RPC UUIDs. What is it you would be looking for? Would you want parsers for every opnum in the IDL file? Or just select functions?
…I’d prefer to see parsing done in the core. Architecturally we try to
avoid passing unparsed data to Bro script land…
Thank you. That is very important guidance, exactly what I was looking for. It gives me a definitive starting point.
The At service parsing file is still there… but I think there was some slight
architectural change that needed to happen before I could pass data to it.
An architectural change? The sound of that makes me worry. I see a couple of approaches:
Yep, I don't know the "best" answer, but I think you're on the right track with either direction that you outlined. If that code just magically existed with either of your outlined implementations I don't think we could resist merging it in. 
.Seth