nexmon
nexmon copied to clipboard
seemoo-lab
Malformed EAPOL packets on bcm43596a0 firmware 9_96_4_sta_c0
Heya,
I compiled nexmon using NDK 11c (compiled and installed firmware 9_96_4_sta_c0, libfakeioctl, libnexmon, nexutil and aircrack on a Samsung Galaxy S7 running LineageOS 14.1).
Everything is working as expected, injection also works.
The problem is - EAPOL packets are always recorded as MALFORMED PACKET.
It's the same whether capturing cap file with tcpdump or airodump-ng, so I assume it must be a firmware or libfakeioctl problem.
Any ideas?
You need to figure out why they are malformed? Is some part missing in them? Is it really a Wi-Fi frame, or is it an Ethernet frame detected as a Wi-Fi frame?
davidrozen76 [email protected] schrieb am Do., 7. Juni 2018, 09:29:
Heya,
I compiled nexmon using NDK 11c (compiled and installed firmware 9_96_4_sta_c0, libfakeioctl, libnexmon, nexutil and aircrack on a Samsung Galaxy S7 running LineageOS 14.1).
Everything is working as expected, injection also works.
The problem is - EAPOL packets are always recorded as MALFORMED PACKET.
It's the same whether capturing cap file with tcpdump or airodump-ng, so I assume it must be a firmware or libfakeioctl problem.
Any ideas?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/seemoo-lab/nexmon/issues/231, or mute the thread https://github.com/notifications/unsubscribe-auth/ALP_7vJs-GYSi-p28jIfZg26lBt5UpSmks5t6NZYgaJpZM4Ud4OW .
By all means this is a Wi-Fi frame (no ethernet interface exists).
Here's one for example -
0000 88 02 ca 00 ec 10 7b 31 d1 99 6c 72 20 a0 a2 7a 0010 6c 72 20 a0 a2 7a 00 00 00 00 aa aa 03 00 00 00 0020 88 8e 01 03 00 5f 02 00 8a 00 10 00 00 00 00 00 0030 00 00 01 96 bb 1e 0a ba c3 45 b0 f5 80 04 9c 47 0040 d4 68 bf c5 75 1b 64 36 53 00 f3 8e c7 f0 aa 0a 0050 dc db 63 00 00 00 00 00 00 00 00 00 00 00 00 00 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0070 00 00
Here's another one -
0000 88 01 3a 01 6c 72 20 a0 a2 7a ec 10 7b 31 d1 99 0010 6c 72 20 a0 a2 7a 10 00 06 00 aa aa 03 00 00 00 0020 88 8e 01 03 00 5f 02 03 0a 00 00 00 00 00 00 00 0030 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0070 00 00
The length of the packets is 114, I think it's somewhat smaller than what it's supposed to be (this applies to all other malformed EAPOL packets)
It seems to contain quite some zeros at the end. Please, try to capture such a frame on both a nexmon enabled device and with another monitor mode capable wifi card and then compare what is really difderent between the two frames.
davidrozen76 [email protected] schrieb am Fr., 8. Juni 2018, 08:37:
Here's one for example -
0000 88 02 ca 00 ec 10 7b 31 d1 99 6c 72 20 a0 a2 7a 0010 6c 72 20 a0 a2 7a 00 00 00 00 aa aa 03 00 00 00 0020 88 8e 01 03 00 5f 02 00 8a 00 10 00 00 00 00 00 0030 00 00 01 96 bb 1e 0a ba c3 45 b0 f5 80 04 9c 47 0040 d4 68 bf c5 75 1b 64 36 53 00 f3 8e c7 f0 aa 0a 0050 dc db 63 00 00 00 00 00 00 00 00 00 00 00 00 00 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0070 00 00
The length of the packet is 114, I think it's somewhat smaller than what's it's supposed to be (this applies to all other malformed EAPOL packets)
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/seemoo-lab/nexmon/issues/231#issuecomment-395662975, or mute the thread https://github.com/notifications/unsubscribe-auth/ALP_7l6bpU-zoZUBF5hAIJzLyeOzjqFOks5t6huVgaJpZM4Ud4OW .
Would you be so kind as to compile the bcm43596a0 9.75.155.45_sta_c0 for me and send it to [email protected]? I get errors every time I try to compile them.
Hey matthiasseemoo,
Well, I tried what you suggested.
While using another device with monitor mode, I get the EAPOL packets as expected -
0000 88 02 24 00 14 ab c5 3b 24 c8 6c 72 20 a0 a2 7a 0010 6c 72 20 a0 a2 7a 00 00 00 00 aa aa 03 00 00 00 0020 88 8e 01 03 00 5f 02 00 8a 00 10 00 00 00 00 00 0030 00 00 01 3f c0 11 a8 f7 ca 18 3d 8b 7e e2 c8 9c 0040 a4 d7 48 67 89 67 99 94 b6 f0 21 a5 e2 bd 45 37 0050 e6 3f 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0080 00 00 00 00 00
Comparing to the EAPOL packets I get in the nexmon device - 0000 88 02 24 00 14 ab c5 3b 24 c8 6c 72 20 a0 a2 7a 0010 6c 72 20 a0 a2 7a 00 00 00 00 aa aa 03 00 00 00 0020 88 8e 01 03 00 5f 02 00 8a 00 10 00 00 00 00 00 0030 00 00 01 3f c0 11 a8 f7 ca 18 3d 8b 7e e2 c8 9c 0040 a4 d7 48 67 89 67 99 94 b6 f0 21 a5 e2 bd 45 37 0050 e6 3f 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0070 00 00 00 00 00 00
It seems somewhat identical, but the nexmon device's EAPOL packet has a smaller length.
Looking on the other EAPOL packets - it seems that every data past length 118 is being trimmed (it's missing data existing from the "GOOD" EAPOL packets past length 118)
:\
Then, you need to find out where the last part of the frame is getting lost. You should debug the monitor mode function [1] by adding a printf debug output whenever one of your target frames is being received. By using dhdutil consoledump you can print the console contents.
[1] https://github.com/seemoo-lab/nexmon/blob/master/patches/bcm43596a0/9.75.155.45_sta_c0/nexmon/src/monitormode.c#L73
On Sun, Jun 10, 2018 at 8:59 AM, davidrozen76 [email protected] wrote:
Hey matthiasseemoo,
Well, I tried what you suggested.
While using another device with monitor mode, I get the handshakes as expected -
0000 88 02 24 00 14 ab c5 3b 24 c8 6c 72 20 a0 a2 7a 0010 6c 72 20 a0 a2 7a 00 00 00 00 aa aa 03 00 00 00 0020 88 8e 01 03 00 5f 02 00 8a 00 10 00 00 00 00 00 0030 00 00 01 3f c0 11 a8 f7 ca 18 3d 8b 7e e2 c8 9c 0040 a4 d7 48 67 89 67 99 94 b6 f0 21 a5 e2 bd 45 37 0050 e6 3f 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0080 00 00 00 00 00
Comparing to the EAPOL packets I get in the nexmon device - 0000 88 02 24 00 14 ab c5 3b 24 c8 6c 72 20 a0 a2 7a 0010 6c 72 20 a0 a2 7a 00 00 00 00 aa aa 03 00 00 00 0020 88 8e 01 03 00 5f 02 00 8a 00 10 00 00 00 00 00 0030 00 00 01 3f c0 11 a8 f7 ca 18 3d 8b 7e e2 c8 9c 0040 a4 d7 48 67 89 67 99 94 b6 f0 21 a5 e2 bd 45 37 0050 e6 3f 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0070 00 00 00 00 00 00
It seems somewhat identical, but the nexmon device's EAPOL has a smaller length.
:\
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/seemoo-lab/nexmon/issues/231#issuecomment-396026004, or mute the thread https://github.com/notifications/unsubscribe-auth/ALP_7n4xTKBCcQ9Yr10kut2x-UwP_zAHks5t7MPigaJpZM4Ud4OW .
-- Matthias Schulz Secure Mobile Networking Lab - SEEMOO
Email: [email protected] Web: http://www.seemoo.de/mschulz Phone (new): +49 6151 16-25478 Fax: +49 6151 16-25471
Department of Computer Science Center for Advanced Security Research Darmstadt Technische Universität Darmstadt Mornewegstr. 32 (Office 4.2.10, Building S4/14) D-64293 Darmstadt, Germany
Hey and thanks for your reply.
I'm a bit techie, but I'd greatly appreciate if you could save me up some time figuring out what to do and let me know of the specific printf code to implement in monitormode.c in order to see the debug output in the console :)
Sorry my lazyness :\
Unfortinately, Nexmon is not intended for the lazy among us.
davidrozen76 [email protected] schrieb am So., 10. Juni 2018, 11:52:
Hey and thanks for your reply.
I'm a bit techie, but I'd greatly appreciate if you could save me up some time figuring out what to do and let me know of the specific printf code to implement in monitormode.c in order to see the debug output in the console :)
Sorry my lazyness :\
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/seemoo-lab/nexmon/issues/231#issuecomment-396035918, or mute the thread https://github.com/notifications/unsubscribe-auth/ALP_7vioI41Md55F3vMHX6n0OreQv1Ehks5t7OxZgaJpZM4Ud4OW .
hi matthias, how are you? i am recently working on a same setup as was described in the above correspondence and facing the exact same issue. i added printfs in the monitormode.c file just at the enterance to the wl_monitor_hook function. the following code checks if this is an eapol frame by checking for the LLC type of 802.1X authentication (0x888e), and if so prints it's size, like this: char* t = (char*)p->data; if (t[38] == 0x88 && t[39] == 0x8e) { printf("got an EAPOL frame\n"); printf("frame size=%d\n",p->len - 6); }
when i run the dhdutil consoledump tool, and connect my phone to the test AP i am using i get the following output: ..... 000084.714 got an EAPOL frame 000084.714 frame size=118 000084.743 got an EAPOL frame 000084.743 frame size=118 000084.748 got an EAPOL frame 000084.748 frame size=118 000084.766 got an EAPOL frame 000084.766 frame size=118 ......
what i understand from this is that the "struct sk_buff *p" that is passed to the wl_monitor_hook function is already in the short state.
btw, as in the above correspondance when i sniff from my macbbok pro (in monitor mode) i get valid EAPOL frames with sizes: 162,184,242,162, for eapol meaasages 1,2,3,4 respectively.
would really appreciate it, if you could share your thoughts about it, so i can dig further...
Did you check whether the firmware contains the string splitrx? That would mean that the d11 core splits each received data frame and only passes the first part to the arm firmware and the rest directly to the host. Unfortunately, I do not know how this works in detail and I do not know how to disable it.
Am Di., 6. Nov. 2018, 20:13 hat ronbenzvi [email protected] geschrieben:
hi matthias, how are you? i am recently working on a same setup as was described in the above correspondence and facing the exact same issue. i added printfs in the monitormode.c file just at the enterance to the wl_monitor_hook function. the following code checks if this is an eapol frame by checking for the LLC type of 802.1X authentication (0x888e), and if so prints it's size, like this: char* t = (char*)p->data; if (t[38] == 0x88 && t[39] == 0x8e) { printf("got an EAPOL frame\n"); printf("frame size=%d\n",p->len - 6); }
when i run the dhdutil consoledump tool, and connect my phone to the test AP i am using i get the following output: ..... 000084.714 got an EAPOL frame 000084.714 frame size=118 000084.743 got an EAPOL frame 000084.743 frame size=118 000084.748 got an EAPOL frame 000084.748 frame size=118 000084.766 got an EAPOL frame 000084.766 frame size=118 ......
what i understand from this is that the "struct sk_buff *p" that is passed to the wl_monitor_hook function is already in the short state.
btw, as in the above correspondance when i sniff from my macbbok pro (in monitor mode) i get valid EAPOL frames with sizes: 162,184,242,162, for eapol meaasages 1,2,3,4 respectively.
would really appreciate it, if you could share your thoughts about it, so i can dig further...
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/seemoo-lab/nexmon/issues/231#issuecomment-436373110, or mute the thread https://github.com/notifications/unsubscribe-auth/ALP_7t6_GyMUlx9XUPe5zNW_Wa5ulJq7ks5usd9DgaJpZM4Ud4OW .
Did you check whether the firmware contains the string splitrx? That would mean that the d11 core splits each received data frame and only passes the first part to the arm firmware and the rest directly to the host. Unfortunately, I do not know how this works in detail and I do not know how to disable it. Am Di., 6. Nov. 2018, 20:13 hat ronbenzvi [email protected] geschrieben: … hi matthias, how are you? i am recently working on a same setup as was described in the above correspondence and facing the exact same issue. i added printfs in the monitormode.c file just at the enterance to the wl_monitor_hook function. the following code checks if this is an eapol frame by checking for the LLC type of 802.1X authentication (0x888e), and if so prints it's size, like this: char* t = (char*)p->data; if (t[38] == 0x88 && t[39] == 0x8e) { printf("got an EAPOL frame\n"); printf("frame size=%d\n",p->len - 6); } when i run the dhdutil consoledump tool, and connect my phone to the test AP i am using i get the following output: ..... 000084.714 got an EAPOL frame 000084.714 frame size=118 000084.743 got an EAPOL frame 000084.743 frame size=118 000084.748 got an EAPOL frame 000084.748 frame size=118 000084.766 got an EAPOL frame 000084.766 frame size=118 ...... what i understand from this is that the "struct sk_buff *p" that is passed to the wl_monitor_hook function is already in the short state. btw, as in the above correspondance when i sniff from my macbbok pro (in monitor mode) i get valid EAPOL frames with sizes: 162,184,242,162, for eapol meaasages 1,2,3,4 respectively. would really appreciate it, if you could share your thoughts about it, so i can dig further... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#231 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ALP_7t6_GyMUlx9XUPe5zNW_Wa5ulJq7ks5usd9DgaJpZM4Ud4OW .
@matthiasseemoo Any chance you got this issue resolved?
Same issues on Nethunter running nexutil, exports in terminal on A10 Los17,1, nexus 6p internal adapter is completely useless as it cant capture anything..
