RE: Problems capturing sebek win32 3.0.3 traffic on roo honeywall

["Michael A. Davis" <mike () datanerds net>]

I think I found the problem. Sebek header reports datalen*2 because of this:

uiPacketLen += DataLength; 

When uiPacketLen already contains the DataLength. Weird that it works fine
for me here though.

I will repackage a new sebek and get it up to the site later tonight.

Thanks,
Michael A. Davis
Chief Executive Officer
Savid Technologies, Inc.
Main: 708.243.2850
http://www.savidtech.com

This email may contain confidential and privileged information for the sole
use of the intended recipient. Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact
the sender and delete all copies of this message. 

> -----Original Message-----
> From: Edward Balas [mailto:ebalas () iu edu] 
> Sent: Wednesday, October 19, 2005 10:38 AM
> To: Truong, Thanh V.
> Cc: Michael A. Davis; Compton, Rich; honeypots () securityfocus com
> Subject: Re: Problems capturing sebek win32 3.0.3 traffic on 
> roo honeywall
>
> Truong, Thanh V. wrote:
>
> > Michael,
> > I have the same problem.  After a little debugging, I found that
> > pcapheader->caplen is always equal to [(datlen*2) + 
> pkt_head_sz] but in
> > your "if" statement (in sbk_extract.c) you check to see if
> > pcapheader->caplen = datlen + pkt_head_sz.  That will fail.  So, it
> > will complain about the malformed package.
> >
> > After putting that in, it seems to work fine.  But I haven't fully 
> > tested to see if all functions work.
> >
> > I'm running sebekd-3.0.3 on Fedora 4.  I hope that and pcap 
> output from 
> > Rich Compton will help you looking into it.
> >
> >  
> Hey all,
>
> This a not the recomended way to work around this.  
> datalen+pkt_head_sz should equal caplen, if it does not then 
> the client is sending malformed records.
>
> Looking at Rich's data, we see the following for the first packet.
>
> rectype=0
> caplen=176
> len=39
> discrepancy=39
> data*2=0x4d6963726f736f66742057696e646f7773205850205b566572736
96f6e20352e312e323630305d000000000000000000000000000000000000000
> Firing up this same packet into ethereal or other sniffer 
> here is what we see.
>
> caplength of 176
> ip total length of 123
>
> Ethernet header shows a trailer which should not be there of 
> 35 bytes and another 4 bytes which should be the frame check 
> sequence are also null.  So at the tail end of the frame we 
> see 39 null bytes, same as the length of the data.
>
> This is a malformed packet.  Can you provide details on the 
> client system?
>
>
> Edward