Developer support list for Wireshark ()

Sreenivasulu Yellamaraju | 1 May 2011 10:10

Saving 802.11 WPA/WPA2 decrypted packets

Hi ,

All of us who are working with 802.11 protocol know that Wireshark can decrypt WEP/WPA/WPA2 traffic if passphrase is provided by the user.

Is there any method to save the decrypted WEP or WPA or WAP2 traffic of 802.11 protocol to an output pcap file?

My requirement is to

- decrypt a huge file containing WPA2 traffic and save the decrypted packets to the output pcap file.

- Split the output pcap file to smaller and manageable files, using the File Save As and Range feature. For example save packet number 1 to 1000,1001 to 2000, 2001 to 3000 etc in separate files

- Open any one smaller output file for analysis. Since the file size will be less, it can even be e-mailed across to someone else

The disadvantages with the bigger input file are

- although it can be opened and decrypted in Wireshark, it takes longer to load ( for example a 800KB file takes 3 minutes to load).
- even if the input file can be split into smaller files using the File Save As and Range feature,not all of the output files can be decrypted with the known passphrase as only one of
the split files will have the EAPOL 4-way key handshake captured and the rest will have only data traffic without EAPOL 4-way handshake captured in them.

Please suggest if there are any known solutions?

Regards,

Sreenivasulu Y

Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe

headers

Max | 1 May 2011 13:51

Freeing memory of se_alloc'ated object

Hi to everyone!

I'm writing a dissector for a TCP-based protocol. I have a
conversation state object of my proto which is managed by
conversation_*_proto_data(). The state object is alloced by
se_alloc(), so it has a lifetime of capture, but the object itself
contains libgcrypt handles which are alloced by g_malloc. How should I
free these handles? Is there any mean to catch the moment when my
state object is about to be destroyed?

--
  Max
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe

headers

Martin Kaiser | 1 May 2011 15:06

nstime_t, time_t, typecasts

Dear all,

I'm working on messages that contain a UTC time info. To display this in
the protocol tree as FT_ABSOLUTE_TIME, I should store the time info in
an nstime_t variable. The output then looks like

Aug 18, 2010 10:32:11.000000000

as nstime_t has nanosecond precision. Is there any chance to limit this
to seconds only (that's all my protocol uses)?

In order to populate the nstime_t, I set the seconds directly, e.g.

nstime_t my_time;
my_time.secs = tvb_get_guint8(tvb, offset);

Is this portable enough with the implicit cast between guint8 and
time_t? What about the other direction

col_append_sep_fstr(pinfo->cinfo, COL_INFO, NULL,
                    "time info is %d seconds", (int)my_time.secs); 

Is it ok to do this in wireshark or is there a more portable way?

Thanks in advance for your feedback,

   Martin

P.S: I know there's a lot of work, but could anyone of the core developers
spare some minutes to commit my patch from bug #5832  ? 
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe

headers

Alexis La Goutte | 1 May 2011 17:04

Re: Saving 802.11 WPA/WPA2 decrypted packets

Hi,

Wireshark is not the better software for this.

Why not use airdecap-ng ( http://www.aircrack-ng.org/doku.php?id=airdecap-ng ) from Aircrack-ng suite ?
and use Wireshark ( tshark ? ) after for split pcap file

Regards,

On Sun, May 1, 2011 at 10:10 AM, Sreenivasulu Yellamaraju <Sreenivasulu.Yellamaraju-kQvG35nSl+M@public.gmane.org> wrote:

Hi ,

All of us who are working with 802.11 protocol know that Wireshark can decrypt WEP/WPA/WPA2 traffic if passphrase is provided by the user.

Is there any method to save the decrypted WEP or WPA or WAP2 traffic of 802.11 protocol to an output pcap file?

My requirement is to

-       decrypt a huge file containing WPA2 traffic and save the decrypted packets to the output pcap file.

-       Split the output pcap file to smaller and manageable files, using the File Save As and Range feature. For example save packet number 1 to 1000,1001 to 2000, 2001 to 3000 etc in separate files

-       Open any one smaller output file for analysis. Since the file size will be less, it can even be e-mailed across to someone else

The disadvantages with the bigger input file are

- although it can be opened and decrypted in Wireshark, it takes longer to load ( for example a 800KB file takes 3 minutes to load).
- even if the input file can be split into smaller files using the File Save As and Range feature,not all of the output files can be decrypted with the known passphrase as only one of
the split files will have the EAPOL 4-way key handshake captured and the rest will have only data traffic without EAPOL 4-way handshake captured in them.

Please suggest if there are any known solutions?

Regards,

Sreenivasulu Y

Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A@public.gmane.org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe

headers

Guy Harris | 1 May 2011 18:25

Re: nstime_t, time_t, typecasts

On May 1, 2011, at 6:06 AM, Martin Kaiser wrote:

> I'm working on messages that contain a UTC time info. To display this in
> the protocol tree as FT_ABSOLUTE_TIME, I should store the time info in
> an nstime_t variable. The output then looks like
> 
> Aug 18, 2010 10:32:11.000000000
> 
> as nstime_t has nanosecond precision. Is there any chance to limit this
> to seconds only (that's all my protocol uses)?

Currently, no.

We would need to either:

	1) add to nstime_t an indication of the precision of the time value (and decide what happens if you add or
subtract two time values of different precision - does the result have the precision of the
higher-precision operand?)

or

	2) add a precision indication to the definition of FT_{ABSOLUTE,RELATIVE}_TIME fields, to indicate how
they should be displayed.

> In order to populate the nstime_t, I set the seconds directly, e.g.
> 
> nstime_t my_time;
> my_time.secs = tvb_get_guint8(tvb, offset);
> 
> Is this portable enough with the implicit cast between guint8 and
> time_t?

That would be an issue only if there were a system where time_t is a signed 8-bit value, and, since such a
system would have a problem at 12:02:07 UTC, January 1, 1970, you're unlikely to ever see such a system.

(Of course, a protocol with an unsigned absolute-time-in-seconds-since-the-Epoch field would have a
problem at 12:04:15 UTC, January 1, 1970, so, in practice, you're not going to see a protocol with a field
that's an FT_ABSOLUTE_TIME where you set the secs field directly to an 8-bit value.  FT_RELATIVE_TIME,
perhaps, as long as intervals less than 256 seconds....)

For a more realistic example, it would work for a 32-bit time-in-seconds-since-the-Epoch value, too.

You still have to set nsecs to 0, of course.

> What about the other direction
> 
> col_append_sep_fstr(pinfo->cinfo, COL_INFO, NULL,
>                    "time info is %d seconds", (int)my_time.secs); 
> 
> Is it ok to do this in wireshark

No, because time_t can be larger than an int.

> or is there a more portable way?

col_append_sep_fstr(pinfo->cinfo, COL_INFO, NULL,
                   "time info is %ld seconds", (long)my_time.secs);

would probably work better.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe

headers

Guy Harris | 1 May 2011 18:29

Re: nstime_t, time_t, typecasts


On May 1, 2011, at 9:25 AM, Guy Harris wrote:

> Currently, no.

Or, rather, there's no way to do it without using proto_tree_add_time_format_value() and formatting the
value yourself with abs_time_secs_to_str().
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe

headers

Guy Harris | 1 May 2011 20:40

Re: Freeing memory of se_alloc'ated object


On May 1, 2011, at 4:51 AM, Max wrote:

> I'm writing a dissector for a TCP-based protocol. I have a
> conversation state object of my proto which is managed by
> conversation_*_proto_data(). The state object is alloced by
> se_alloc(), so it has a lifetime of capture, but the object itself
> contains libgcrypt handles which are alloced by g_malloc. How should I
> free these handles? Is there any mean to catch the moment when my
> state object is about to be destroyed?

If you register a routine with register_init_routine() (the routine takes no arguments and returns no
value), it will be called *after* all the se_alloc()ated memory is freed.  Will that suffice?
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe

headers

Max | 1 May 2011 21:15

Re: Freeing memory of se_alloc'ated object

2011/5/1 Guy Harris <guy <at> alum.mit.edu>:
>
> On May 1, 2011, at 4:51 AM, Max wrote:
>
>> I'm writing a dissector for a TCP-based protocol. I have a
>> conversation state object of my proto which is managed by
>> conversation_*_proto_data(). The state object is alloced by
>> se_alloc(), so it has a lifetime of capture, but the object itself
>> contains libgcrypt handles which are alloced by g_malloc. How should I
>> free these handles? Is there any mean to catch the moment when my
>> state object is about to be destroyed?
>
> If you register a routine with register_init_routine() (the routine takes no arguments and returns no
value), it will be called *after* all the se_alloc()ated memory is freed.  Will that suffice?

Well, the handles to the allocated resources are stored *in* the
se_alloc()ated memory. So a callback which is called just after it is
freed is pretty much useless.

From the other side I can store the handles in two places:
1) in the conversation's state object where I use them;
2) in some global list of allocated resources which is read and
deallocated in the routine you've described.

But am I the only guy who finds this ugly? In this situation  it would
be perfect if se_alloc() engine could call a callback with a user
supplied argument before it starts to deallocate anything.

--
Max
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev <at> wireshark.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request <at> wireshark.org?subject=unsubscribe

headers

Guy Harris | 1 May 2011 21:21

Re: Freeing memory of se_alloc'ated object


On May 1, 2011, at 12:15 PM, Max wrote:

> But am I the only guy who finds this ugly?

No.

> In this situation  it would
> be perfect if se_alloc() engine could call a callback with a user
> supplied argument before it starts to deallocate anything.

The init mechanism was created before the ephemeral memory stuff even existed, and has never been updated.

Some better mechanism, such as the one you suggest, would probably be a good idea.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe

headers

Max | 1 May 2011 21:44

Strange desegmentation behavior

Hi,

I'm dealing with a strage problem when using desegmentation, but I
don't know for sure is it intended, is it a bug or am I an asshole? :)

I'm dissecting a protocol which consists of a constant length header
and a variable length payload following each other in a TCP stream.
The payload length is supplied in the header.  A payload may be absent
and in this case the header provides payload's length of 0 and the
next header immediately follows this one.  Normally one TCP packet
contains both the header, the payload and nothing more.

But sometimes it happens that TCP stream gets segmented that is why I
use desegmentation funcionality (that one which involves packet_info's
can_desegment, desegment_offset and desegment_len fields). But
sometimes I get the following situation:

1) The header comes in the end of the packet. It indicates a payload
of non-zero length but the actual payload comes in the next packet.

2) After the header is parsed, I check that there is enough data to
dissect the payload otherwise I request desegmentation. So according
to the 1st item the desegmentation is requested, but desegment_offset
is equal to the actual length of the packet, because I don't need the
header anymore.

3) The root dissector routine is called for the next packet. The TVB
contains the right data - nothing from the previous packet and the
whole data with payload from this packet. It has
pinfo->fd->flags.visited equals to zero (which is normal AFAIU) *BUT*
p_get_proto_data() retuns data associated with the previous frame,
which is innormal. At least flags.visited and p_get_proto_data() are
both zeroes when desegmentation happens in the usual scenario.

So what is happening here? Is it a bug? Or may be I just misuse this feature?

--
Max
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe

Mon	Tue	Wed	Thu	Fri	Sat	Sun

						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

96	June 2013
244	May 2013
306	April 2013
286	March 2013
226	February 2013
157	January 2013
141	December 2012
145	November 2012
271	October 2012
231	September 2012
270	August 2012
259	July 2012
212	June 2012
271	May 2012
155	April 2012
188	March 2012
218	February 2012
267	January 2012
141	December 2011
189	November 2011
271	October 2011
297	September 2011
702	August 2011
519	July 2011
330	June 2011
367	May 2011
371	April 2011
293	March 2011
235	February 2011
278	January 2011
311	December 2010
369	November 2010
376	October 2010
313	September 2010
248	August 2010
254	July 2010
225	June 2010
341	May 2010
382	April 2010
357	March 2010
313	February 2010
382	January 2010
204	December 2009
287	November 2009
341	October 2009
350	September 2009
380	August 2009
463	July 2009
372	June 2009
393	May 2009
425	April 2009
397	March 2009
368	February 2009
192	January 2009
266	December 2008
288	November 2008
330	October 2008
218	September 2008
259	August 2008
348	July 2008
347	June 2008
280	May 2008
555	April 2008
342	March 2008
344	February 2008
350	January 2008
279	December 2007
513	November 2007
389	October 2007
325	September 2007
633	August 2007
431	July 2007
305	June 2007
433	May 2007
394	April 2007
675	March 2007
512	February 2007
736	January 2007
386	December 2006
523	November 2006
536	October 2006
578	September 2006
392	August 2006
322	July 2006
84	June 2006