WPA2 (IPv4) packets not decrypted

[Vardalion]

Hiya,

I successfully compiled libtins and wanted to use the example to decrypt WPA2 packets. I successfully receive/see the handshakes on my console output, but IPv4 traffic is not decrypted. There is a strange issue that it seems to be working (ie. successfully decrypting) on Intel-based Wireless cards, but not on my Realtek (PCI-E based on barebone) and Atheros (USB Wifi dongles from Alpha/TP-Link). Is there any way to debug what's going wrong or did you experience the same issue before?

[mfontanini]

Can you attach a pcap file having a full handshake and some data packets that fail to be decrypted? Also, are you using libtins version 3.5? I recently fixed an issue related to QoS Do 11 packets and that might be what's affecting you

…

On May 28, 2017 05:35, "Joey Dreijer" ***@***.***> wrote: Hiya, I successfully compiled libtins and wanted to use the example to decrypt WPA2 packets. I successfully receive/see the handshakes on my console output, but IPv4 traffic is not decrypted. There is a strange issue that it seems to be working (ie. successfully decrypting) on Intel-based Wireless cards, but not on my Realtek (PCI-E based on barebone) and Atheros (USB Wifi dongles from Alpha/TP-Link). Is there any way to debug what's going wrong or did you experience the same issue before? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#216>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA7Jgp03iv1EA5CmirmmB3XDWpEFIVLTks5r-WobgaJpZM4Noora> .

[Vardalion]

Thanks! I cloned the repo, but didn't see you published a newer release. I'll try it out when I get home and upload a PCAP if it doesn't work.

[ghost]

Seems that my Intel card together with the new release of libtins is working properly, thank you! :)

However, it doesn't seem to decrypt one of my laptop's traffic, while it does decrypt other devices (it does have the handshake btw). Is there any way I can securely share the PCAP with you? Maybe you have a clue what might be going on. Thanks again ^^

[mfontanini]

Sure, you can send me a pcap at matias.fontanini@gmail.com. Do note that I'd need the access point's passphrase to be able to see if I can make it work.

[ChrisLundquist]

This is pretty old, but I'm seeing similar behavior trying to decrypt kismet captures.
I do decrypt PPI things in the captures, but they are unwritable because of:
throw pdu_not_serializable();

If I catch these exceptions, I end up writing no packets.
I have ~70GB of data, 30 PMKs and dozens PTKs in the captures, so I'd expect at least some packets to decrypt.

FWIW the airodump (from aircrack-ng) pcaps decrypt. airodump needs more preprocessing with pcapfix and pcapreorder to ensure strict packet ordering so we don't miss handshakes / PTKs

A quick look shows the pcaps do contain a fair amount of QoS Data and Data frames.
This is using libtins 4.0.0.

Could this be related to datalink headers? I'd have to check, but I think Kismet writes out PRISM headers which aren't currently supported. It also looks like we don't have a default warn case for when we drop a packet in that area of libtins.

[ChrisLundquist]

Looks like kismet writes out DLT 105

$ tshark -Vxr /srv/wifi/Kismet-20180111-22-52-07-1.pcapdump | grep DLT: | uniq
    DLT: 105

LINKTYPE_IEEE802_11 | 105 | DLT_IEEE802_11 | IEEE 802.11 wireless LAN.

Which we appear to handle here:

libtins/src/ppi.cpp

Line 60 in 3659d89

case DLT_IEEE802_11:

$ capinfos /srv/wifi/Kismet-20180704-11-52-58-1.pcapdump
File name:           /srv/wifi/Kismet-20180704-11-52-58-1.pcapdump
File type:           Wireshark/tcpdump/... - pcap
File encapsulation:  Per-Packet Information header
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: 8192 bytes
Number of packets:   32 M
File size:           8650 MB
Data size:           8125 MB
Capture duration:    456334.829361 second
First packet time:   2018-07-04 11:52:58.970454
Last packet time:    2018-07-09 18:38:33.799815
Data byte rate:      17 kBps
Data bit rate:       142 kbps
Average packet size: 248.05 bytes
Average packet rate: 71 packets/s
SHA1:                2bf14dff0f865a2034277c97df5d6a81c25fcf94
RIPEMD160:           3f8f9728388c5e2fc199e14adcdc44a0478d3735
MD5:                 37210e911bf18dbaadf744d1ea5bb6c2
Strict time order:   True
Number of interfaces in file: 1
Interface #0 info:
                     Encapsulation = Per-Packet Information header (97 - ppi)
                     Capture length = 8192
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Number of stat entries = 0
                     Number of packets = 32758649

FWIW, I tried editcap -F pcap -T ieee-802-11-radiotap /srv/wifi/Kismet-20180111-22-52-07-1.pcapdump{,.radiotap} and while it does prevent us throwing the exception, I'm still unable to decrypt.