Sreenivasulu Yellamaraju | 1 May 10:10 2011

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
j.snelders | 1 May 11:02 2011
Picon

Re: Saving 802.11 WPA/WPA2 decrypted packets


On Sun, 1 May 2011 08:10:18 +0000 Sreenivasulu Yellamaraju wrote:
>- 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.

Hi Sreenivasulu,

You can save the EAPOL packets to a separate file and merge this file with
the other smaller files:
- mark the 4 EAPOL packets
- save the marked packets: File | Save As... | Packet Range: select Marked
packets

The next step is to merge the EAPOL packets with the other files.
Wireshark:
- open the file, with the EAPOL packets
- got to File | Merge...
- select file2.pcap and click Open
- save the new file

mergecap
$ mergecap -w outfile.pcap EAPOL.pcap file2.pcap

Hope this helps
Joke

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

Alexis La Goutte | 1 May 17:04 2011
Picon

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
gaddour olfa | 1 May 20:02 2011
Picon

problem in detecting interfaces

Hello,
I ma working on ubuntu and I wanto use Wireshark to analyze packets of a wireless sensor networks composed of TelosB motes.
I attached a sniffer to the PC, and I opened wireshark 1.5 fom the tutorial in http://www.sics.se/contiki/wiki/index.php/Instant_Contiki_Install_Scripts.
The problem is that Wireshark cannot detect the interface that I should sniff packets from it which is the USB port attached to the telosb mote. attached a screenshot of the detected interfaces.
Please can anyone tell me how can I solve it?

Best Regards,

Olfa
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe
Tamás Varga | 2 May 17:31 2011
Picon

Re: Sectionalizing Network Loss with TCP

 
Hi Barry,
You may find the above paper useful for understanding the challenges of TCP packet loss calculation.
cheers,
 Tamas

From: wireshark-users-bounces <at> wireshark.org [mailto:wireshark-users-bounces-IZ8446WsY0/dtAWm4Da02A@public.gmane.org] On Behalf Of Barry Constantine
Sent: Friday, April 29, 2011 15:34
To: wireshark-users-IZ8446WsY0/dtAWm4Da02A@public.gmane.org
Subject: [Wireshark-users] Sectionalizing Network Loss with TCP

Hello,
 
I am trying to develop a technique to isolate packet loss between networks (i.e. Network A versus Network B loss diagnosis).
 
I've experimented with the common technique that identifies whether a retransmiitted packet has duplicate sequence numbers in the capture file.  The results have been OK, but with acuracy that is not good enough.  Under certain conditions (i.e. when entire windows are not retransmitted), it works well.
 
Has anyone on this list developed a technique using tshark + scripting?
 
Thanks,
Barry
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe
Vikki Taxdal | 4 May 06:05 2011
Picon

Re: Selective ACK ON / OFF does not have any impact ?

Hi Andi,

You asked

On Thu, Apr 28, 2011 at 4:19 AM, Andi Wijaya <stev2711@...> wrote:
> My question is, packet no.193 is the Dup ACK and no.194 is the TCP retransmission,
> but why no.195 does not do a TCP retransmission of 114229
> (which is the next seq.) but go to 137589 (no 195)instead ?

Frame 195 doesn't retransmit 114229 because 114229 was not lost; it
arrived in frame 124.

The TCP analysis flags are confusing when you first read them.
Wireshark tells us at frame 124 that "TCP Previous segment was lost",
but the previous segment is not 114229 but 112769 (111309 + 1460, from
frame 123).

If you display "ip.src == 10.10.1.58" and put tcp.seq and tcp.len in
your columns you'll see that
the client starts complaining about lost segments at frame 127,
continuing up to193.

And then when you display "ip.src == 125.252.232.170" you can see that
the server sends the lost packets all at once (frames 194-216).

Vikki

=======================================================
On Thu, Apr 28, 2011 at 4:52 PM, Andi Wijaya <stev2711@...> wrote:
> Hi Guys,
> I've uploaded the trace file in cloudshark for your reference.
> My interest is what happen on packet no 193-196.
> http://cloudshark.org/captures/bfc1d3359db2

=======================================================
On Thu, Apr 28, 2011 at 4:19 AM, Andi Wijaya <stev2711@...> wrote:
> Hi Guys,
> This is my first post, and it's so nice to be able to join this community so please excuse me if I make any mistake.
> I'm doing a capture with SACK ON and with SACK OFF, my understanding is with SACK OFF, the server will have to
retransmit the packet from the point of
> packet lost. However what I see is the server does not retransmit the packet at all and just continuing with
the rest of the data (please see the TCP
> Trace screenshot attached). While for SACK ON, everything went well as the theory.
>
> SACK OFF: (I removed some column for easier viewing)
> No  Source           Destination      Seq.#   Nxt.Seq.  Ack.#   Info
> 193 10.10.1.58       125.252.232.170    2286            112769  [TCP Dup ACK 125#34] 1069 > 80 [ACK] Seq=2286 Ack=112769
Win=32768 Len=0
> 194 125.252.232.170  10.10.1.58       112769  114229      2286  [TCP Retransmission] [TCP segment of a reassembled PDU]
> 195 10.10.1.58       125.252.232.170    2286            137589  1069 > 80 [ACK] Seq=2286 Ack=137589 Win=32768 Len=0
> 196 125.252.232.170  10.10.1.58       137589  139049   2286 [TCP Retransmission] Continuation or non-HTTP traffic
> 197 10.10.1.58      125.252.232.170 2286 144889 1069 > 80 [ACK] Seq=2286 Ack=144889 Win=32768 Len=0
>
> My question is, packet no.193 is the Dup ACK and no.194 is the TCP retransmission, but why no.195 does not do
a TCP retransmission of 114229
> (which is the next seq.) but go to 137589 (no 195)instead ?  Am I missing something here ?  Thanks/
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

Vikki Taxdal | 4 May 07:45 2011
Picon

Re: Selective ACK ON / OFF does not have any impact ?

Hi again Andi,

After a talk with someone better versed in TCP than I am I think I
have a clearer understanding now of both your question and your packet
trace.

The client doesn't ask for retransmission beginning at 114229 because
with its "ACK 137589" it is acknowledging receipt of 114229-137588
already.  You could say that the "ACK 114229" you were looking for is
implicit in "ACK 137589".

Vikki

=======================================================
On Wed, May 4, 2011 at 12:05 AM, Vikki Taxdal <vtaxdal@...> wrote:
> Hi Andi,
>
> You asked
>
> On Thu, Apr 28, 2011 at 4:19 AM, Andi Wijaya <stev2711@...> wrote:
>> My question is, packet no.193 is the Dup ACK and no.194 is the TCP retransmission,
>> but why no.195 does not do a TCP retransmission of 114229
>> (which is the next seq.) but go to 137589 (no 195)instead ?
>
> Frame 195 doesn't retransmit 114229 because 114229 was not lost; it
> arrived in frame 124.
>
> The TCP analysis flags are confusing when you first read them.
> Wireshark tells us at frame 124 that "TCP Previous segment was lost",
> but the previous segment is not 114229 but 112769 (111309 + 1460, from
> frame 123).
>
> If you display "ip.src == 10.10.1.58" and put tcp.seq and tcp.len in
> your columns you'll see that
> the client starts complaining about lost segments at frame 127,
> continuing up to193.
>
> And then when you display "ip.src == 125.252.232.170" you can see that
> the server sends the lost packets all at once (frames 194-216).
>
> Vikki
>
>
>
> =======================================================
> On Thu, Apr 28, 2011 at 4:52 PM, Andi Wijaya <stev2711@...> wrote:
>> Hi Guys,
>> I've uploaded the trace file in cloudshark for your reference.
>> My interest is what happen on packet no 193-196.
>> http://cloudshark.org/captures/bfc1d3359db2
>
> =======================================================
> On Thu, Apr 28, 2011 at 4:19 AM, Andi Wijaya <stev2711@...> wrote:
>> Hi Guys,
>> This is my first post, and it's so nice to be able to join this community so please excuse me if I make any mistake.
>> I'm doing a capture with SACK ON and with SACK OFF, my understanding is with SACK OFF, the server will have
to retransmit the packet from the point of
>> packet lost. However what I see is the server does not retransmit the packet at all and just continuing
with the rest of the data (please see the TCP
>> Trace screenshot attached). While for SACK ON, everything went well as the theory.
>>
>> SACK OFF: (I removed some column for easier viewing)
>> No  Source           Destination      Seq.#   Nxt.Seq.  Ack.#   Info
>> 193 10.10.1.58       125.252.232.170    2286            112769  [TCP Dup ACK 125#34] 1069 > 80
[ACK] Seq=2286 Ack=112769 Win=32768 Len=0
>> 194 125.252.232.170  10.10.1.58       112769  114229      2286  [TCP Retransmission] [TCP
segment of a reassembled PDU]
>> 195 10.10.1.58       125.252.232.170    2286            137589  1069 > 80 [ACK] Seq=2286
Ack=137589 Win=32768 Len=0
>> 196 125.252.232.170  10.10.1.58       137589  139049   2286 [TCP Retransmission] Continuation
or non-HTTP traffic
>> 197 10.10.1.58      125.252.232.170 2286 144889 1069 > 80 [ACK] Seq=2286 Ack=144889 Win=32768 Len=0
>>
>> My question is, packet no.193 is the Dup ACK and no.194 is the TCP retransmission, but why no.195 does not
do a TCP retransmission of 114229
>> (which is the next seq.) but go to 137589 (no 195)instead ?  Am I missing something here ?  Thanks/
>
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

Ronald Erdman | 4 May 18:38 2011

Who needs a new protocol disector built? I want to help!

Hi everyone.  I'm a grad student looking to build a new protocol disector for a protocol not already supported.  Unfortunately, I'm a noob when it comes to network protocols, so I was wondering if anyone ever said to themselves "hey, I wish I could filter on XXXX protocol in Wireshark!"  If so, drop me a note and point me to the spec for the protocol and I'll build it and send you a copy when I'm done. 

 

Or, if anyone knows of any that are fairly common but not supported already, any suggestions would be greatly appreciated!

 

Thanks, and hope to hear from somebody soon!

- Ron

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe
Stephen Fisher | 4 May 18:53 2011

Re: Who needs a new protocol disector built? I want to help!

On Wed, May 04, 2011 at 12:38:31PM -0400, Ronald Erdman wrote:

> Or, if anyone knows of any that are fairly common but not supported 
> already, any suggestions would be greatly appreciated!

It would be great to have a full RDP dissector in Wireshark (or at least 
one for the unencrypted portions of the protocol).  Here are notes on it 
including specifications at the bottom: http://wiki.wireshark.org/RDP

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

Chris Maynard | 4 May 19:17 2011

Re: Who needs a new protocol disector built? I want to help!

Stephen Fisher <steve <at> ...> writes:

> > Or, if anyone knows of any that are fairly common but not supported 
> > already, any suggestions would be greatly appreciated!
> 
> It would be great to have a full RDP dissector in Wireshark (or at least 
> one for the unencrypted portions of the protocol).  Here are notes on it 
> including specifications at the bottom: http://wiki.wireshark.org/RDP

Ron, in addition, you might look through the bug reports requesting that
Wireshark support various protocols.  For example:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4165.  I'm sure there are
others.

You might also take a look at the Wireshark wiki's WishList here:
http://wiki.wireshark.org/WishList#Dissector_specific

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


Gmane