Hcxpcapngtool --csv option doesent include coordinates

[kocsaga]

Hello again ZerBea!

I ran the hcxdumptool with an usb gps reciever. I tried the --gpsd method and the direct --nmea_dev method. Both generated nme file with actual coordinates and data. When I try to retrive the coordinates to the ap-s with the hcxpcapng tool --csv option, the lines did not get the coordinates just zeroes. I would like to match the coordinates to the AP-s and the RSSI-s like a wardriving. I am using an vk-172 gps dongle btw. Could you please help me identify where is the error?

[ZerBea]

Can you please add an example pcapng file or the output of $ hcxpcapngtool YOUR_dumpfile.pcapng

BTW: Which version of hcxdumptool do you use? Since 07.04.2023, hcxdumptool (6.2.9-22-gace924f ) doesn't store this information any longer to the dump file.

README.md:

07.04.2023
==========
refactored hcxdumptool: replaced entire hcxdumptool code by hcxlabtool code

and

06.04.2023
==========
release v6.2.9
several bug fixes

This is the last version:
that use WIRELESS EXTENSIONS
that use ETHTOOL to get/set virtual MAC address
that use old style status output
that use soft coded filter lists
that use msec timestamp
that use crypto stuff
that use server/client mode to display status

Next version will go back to the roots:
set focus on WPA PSK (WPA1, WPA2, WPA2 key version 3)
set bandwidth to 20MHz to increase range
set bitrate to lowest values to increase range
use active monitor mode
use NL80211 stack
use RTNETLINK
band a, b, c, d, e support
use NMEA messages:
 $GPRMC: Position, velocity, time and date
 $GPGGA: Position, orthometric height, fix related data, time
 $GPWPL: Position and MAC AP
 $GPTXT: ESSID in HEX ASCII
remove options that slow hcxdumptool down

[ZerBea]

If you take a look at the new status display of hcxdumptool you'll see: a new column "R" which show a "+" if a target is in range and/or under attack or on rcascan display a new column "RESPONSE" which show a time if the AP is in RANGE. RSSI values are removed, because you can get a pretty good RSSI value, but the target doesn't receive hcxdumptool's frames. On the other side, you can get a really bad RSSI, but the target receive hcxdumptool's frames. I'll say, RSSI values are meaningless. It is more (much more) important to get an information that the target is in RANGE and interact with hcxdumptool.

[kocsaga]

Thanks for the fast reply!

My hcxdumptool version is: hcxdumptool 6.2.9-126-ge4e2a4f

An example of an NMEA files,capture: $GPRMC,170150.00,A,xxxx.55448,N,xxxx.55237,E,1.711,,050523,,,A*7C $GPGGA,170150.00,xxxx.55448,N,xxxx.55237,E,1,09,0.84,143.0,M,37.3,M,,*53 $GPWPL,xxxx.55448,N,xxxx.55237,E,7896825xx63d*4b $GPTXT,76xxx267616c616b*60

The line in the csv file: 55311-11-06 11:06:32 78:xx:xx:xx:xx:xx ssid [WPA2] [CCMP] [PSK] 00 11 -87 0.000000 E 0.000000 S 0.000000 0.000000 0 0 0.000000 0.000000 M

I hope you mean this data. Is there any option to include the NMEA file when using hcxpcapngtool? Because I cant find one. The NMEA and the PCAPNG are in the same directory, same name except the pcapng files names extended with the wlan1, but I dont think it causes the problem reading from them to the csv.

As for the RSSI I bow to you knowledge about it. I used some wardriving and after multiple measures I choosen the coordinates with the best RSSI and got pretty good accuracy. But it is okay, I think your reasoning is better.

[ZerBea]

Can you please comment status output of $ hcxpcapngtool YOUR_dumpfile.pcapng

[ZerBea]

Only this part of the status is interesting, because it show if NMEA packets are inside of the dump file: link layer header type...................: DLT_IEEE802_11_RADIO (127) NMEA PROTOCOL............................: 380 endianness (capture system)..............: little endian

[kocsaga]

`$ hcxpcapngtool *.pcapng
hcxpcapngtool 6.2.9 reading from 20230505175647-wlan1.pcapng...

summary capture file

file name................................: 20230505175647-wlan1.pcapng version (pcapng).........................: 1.0 operating system.........................: Linux 5.15.56+ application..............................: hcxdumptool 6.2.9-126-ge4e2a4f interface name...........................: wlan1 interface vendor.........................: ec086b openSSL version..........................: 1.0 weak candidate...........................: 12345678 MAC ACCESS POINT.........................: 0086a0062513 (incremented on every new client) MAC CLIENT...............................: c8aacc1e4323 REPLAYCOUNT..............................: 65476 ANONCE...................................: 6ba680881d8a8eec39c0926de41f1ee746032c4f0ca9417e84c6fb459c374ac3 SNONCE...................................: df791e8800e067646dccbdaee7d666898e470c495a1a167abe17b360e3ba1f91 timestamp minimum (GMT)..................: 05.05.2023 12:56:53 timestamp maximum (GMT)..................: 05.05.2023 13:49:49 used capture interfaces..................: 1 link layer header type...................: DLT_IEEE802_11_RADIO (127) endianness (capture system)..............: little endian packets inside...........................: 11972 packets received on 2.4 GHz..............: 11217 WIRELESS DISTRIBUTION SYSTEM.............: 5 ESSID (total unique).....................: 1507 BEACON (total)...........................: 1438 BEACON on 2.4 GHz channel (from IE_TAG)..: 1 2 3 5 6 7 10 11 BEACON (SSID wildcard/unset).............: 58 BEACON (SSID zeroed).....................: 10 ACTION (total)...........................: 5 ACTION (containing ESSID)................: 5 PROBEREQUEST.............................: 413 PROBEREQUEST (directed)..................: 90 PROBERESPONSE (total)....................: 1063 AUTHENTICATION (total)...................: 1409 AUTHENTICATION (OPEN SYSTEM).............: 1409 ASSOCIATIONREQUEST (total)...............: 213 ASSOCIATIONREQUEST (PSK).................: 211 REASSOCIATIONREQUEST (total).............: 60 REASSOCIATIONREQUEST (PSK)...............: 60 EAP (total)..............................: 3 EAP CODE response........................: 3 EAP-PEAP.................................: 3 EAPOL messages (total)...................: 7262 EAPOL RSN messages.......................: 7255 EAPOL WPA messages.......................: 7 EAPOLTIME gap (measured maximum msec)....: 37185 EAPOL ANONCE error corrections (NC)......: working REPLAYCOUNT gap (suggested NC)...........: 20 EAPOL M1 messages (total)................: 5796 EAPOL M2 messages (total)................: 1052 EAPOL M3 messages (total)................: 235 EAPOL M4 messages (total)................: 179 EAPOL M4 messages (zeroed NONCE).........: 178 EAPOL pairs (total)......................: 16216 EAPOL pairs (best).......................: 149 EAPOL ROGUE pairs........................: 61 EAPOL M12E2 (challenge)..................: 84 EAPOL M32E2 (authorized).................: 65 RSN PMKID (useless)......................: 295 RSN PMKID (total)........................: 1618 RSN PMKID (best).........................: 302 RSN PMKID ROGUE..........................: 255 malformed packets (total)................: 5 BEACON error (total malformed packets)...: 1 IE TAG length error (malformed packets)..: 2 ESSID error (malformed packets)..........: 2

frequency statistics from radiotap header (frequency: received packets)

2412: 4604 2437: 2800 2462: 3813

Information: no hashes written to hash files

session summary

processed pcapng files................: 1 `

[ZerBea]

Ok, you're running 6.2.9-126-ge4e2a4f This version doesn't store NMEA information directly into the dump file any longer. hcxpcapngtool can't convert them, because this information is not present in the dump file. I'll check if I can add it directly to hcxdumptool's NMEA output.

[kocsaga]

Yeah i think so and the pcapng does not read nmea files. If I can ask, why it does not collect to the pcapng file anymore?

[ZerBea]

Most of the users (who uploaded their dump files to online hash crackers) don't want included GPS information

I added an issue report to hcxdumptool to add RSSI to NMEA file so that we can close this report here, because it is not caused by hcxpcapngtool: https://github.com/ZerBea/hcxdumptool/issues/319#issue-1698650377

[ZerBea]

Second reason (for me more important): I don't want to do an on the fly option walk through the entire RADIOTAP HEADER to retrieve values like RSSI or FREQUENCY. This option walk has to be done on every received packet. We now get the FREQUENCY e.g via NL80211 instead of searching it in the RADIOTAP HEADER. So I removed the entire RADIOTAP header parsing stuff.

[ZerBea]

I'll check if I can get the RSSI without spending much CPU cycles.

[kocsaga]

Thanks! Alright, I dont tought about that. What do you suggest, to get coordinates to the csv list after all?

[ZerBea]

Partly GPSBABEL can do that: https://www.gpsbabel.org/htmldoc-development/fmt_csv.html but I don't think it can read the ESSID from GPTXT field.

Additional you can parse the NMEA file via a bash script that store the information to a csv file.

But I try to add at least GPRMC and GPGGA information to pcapng if it is selected by an option so that hcxpcapngtool can work on it.

[kocsaga]

The last option would be the most suitable one. I think I will wait for that. Thanks again, you rock and have nice day!

[ZerBea]

By latest commit I added an option to hcxdumptool to save GPS information to pcapng file:

--nmea_pcapng : write GPS information to pcapng dump file

$ sudo hcxdumptool --nmea_dev=/dev/ttyACM0 --nmea_pcapng
$ hcxpcapngtool --csv=test.csv 20230506204855-wlp39s0f3u1u1u3.pcapng
hcxpcapngtool 6.3.0-3-gd615cc2 reading from 20230506204855-wlp39s0f3u1u1u3.pcapng...

summary capture file
--------------------
file name................................: 20230506204855-wlp39s0f3u1u1u3.pcapng
...
timestamp minimum (GMT)..................: 06.05.2023 20:49:00
timestamp maximum (GMT)..................: 06.05.2023 20:49:11
used capture interfaces..................: 1
link layer header type...................: DLT_IEEE802_11_RADIO (127)
NMEA PROTOCOL............................: 12
endianness (capture system)..............: little endian
packets inside...........................: 41
...

[ZerBea]

Now you should get the same information in the csv file (inclusvie RSSI) as on hcxdumptool 6.2.9 (WEXT version) Additional you have a separate NMEA 0183 file containing RAW information. Please try and let me know if it works for you.

[ZerBea]

GPS information is written every 2 seconds to the pcapng dump file.

[ZerBea]

The solution, now: hcxdumptool run time critical functions. It must respond to a request within the defined times. Otherwise an attack is not successful. hcxpcapngtool is off line and we have all the time we need.

In contrast to other tools (which remove the entire RADIOTAP HEADER), hcxdumptool write it to pcapng and hcxpcapngtool do the parsing. That doesn't take CPU cycles on attack site (hcxdumptool). Quite the opposite - in fact we are faster, because hcxdumptool doesn't use a function to verify the header and to remove it.

[kocsaga]

Hello again! I tested the new option few hours after you updated it and I got the coordinates and RSSI. Thank you, excellent job! I have another question. If you look my previous comment here, when I copied a line from the csv and you look the date I got some strange date data. When I did a test measurement for about 2 hours I got 30+ different days and hours in the csv file, so I dont think my date setting would be a problem. And should be the year some 2020ish not 55311-11-06. What do you think about that? With the "cgps" command I got proper time(from the gps), and files metadata in the os says the system time is ok.

[ZerBea]

I think I have an idea. Please give me some time....

[ZerBea]

Please try latest commit.

[kocsaga]

Ah nice! It displays the right date now.