Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

help with filters

Status
Not open for further replies.

weather9

ISP
Oct 4, 2002
7
US
Hi,

If I wanted to build a filter that checks for an ascii string that could appear anywhere in the tcp payload, how would I do this? The current filter mechanism only permits matching to a specific location (offset) in the frame or am I overlooking something? Thanks.

Bill.
 
If you already have an example of the payload in a trace you could add a pattern by going into Data Pattern and then add a pattern and then setting the ASCII data from the hex.

Else I would not know at the moment, I'm not a filter expert.....
 
Hi, that would not work if the string can apear "anywhere" in the payload (assuming that with TCP payload you mean the TCP header and everything that follows in the frame).

The pattern match function uses an ofset that is static (from the beginning of the frame or the layer 3 header).

So for every offset in the payload you should make a data patern all connected with the OR function. Assuming your largest frame format is 1518 on Ethernet and the biggest part then is payload, you need a lot of paterns to do this.
Robert
Robert A.H. Wullems
Sniffer University Instructor
SCM / CNX / MCP
Citee Education
the Netherlands
 
I'm getting the impression that there is no practical way to do this, right? I ask because I've tried to figure this one myself for the past few years. 'Making things work better; bit by bit.'
 
No, i really don't think there is a practical way. Ofcourse everything is possible, read the message abvoe, but not very handy

Hopefully somebody at NAI starts thinking about these things. It would be nice if you could just enter a HEX or ASCII string and give Sniffer a kind of search option in a frame to find it.
Robert Robert A.H. Wullems
Sniffer University Instructor
SCM / CNX / MCP
Citee Education
the Netherlands
 
Since it works with the Display->Find feature, I figured NAi would get a similar feature to work with the Capture filter. 'Making things work better; bit by bit.'
 
That sounds easy, but there is a difference in programming. The find feature uses the decoded tracefile. During capturing the tracefle is not fully decoded. only the expert is "filled in" by the sniffer. The "trace file" then only consist of a long string of bits wich are decoded after the capture is stopped. You can even visually see that because the post analyses tabs appear after you stop the capture. The actual decode is a comprehensive process wich takes a lot of CPU cycles. Just press the stop capture button with a really large trace file. It can tak up to minutes before the decode is complete depending of the size of the file and you CPU.

It would be nice if the NAI engineers find a way to implement this "search" function in a non decoded trace file.
Another option is what wildpackets is doing with there real time decode in the Etherpeek analyzer. Then they can just use the normall search funtion to impelement

Robert
Robert A.H. Wullems
Sniffer University Instructor
SCM / CNX / MCP
Citee Education
the Netherlands
 
I use a utility called commview which is much easier to setup filters. I dont know why NAI makes it so difficult.
Checkout a demo at
It costs less than $200.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top