Aircrack-ng forum
General Category => Newbies => Topic started by: codemonkey on December 22, 2014, 09:39:18 am
-
I've recently started learning how to use aircrack tools on Arch linux. I take down my wireless interface, launch a monitor and run the tools on the monitor. I have looked into the possibility that I may need to patch my drivers (https://bbs.archlinux.org/viewtopic.php?id=191322), but after some discussion and an evening of learning about patching drivers, I do not believe this to be the case; ath9k should already allow packet injection.
I have tried the same steps on multiple WPA and WPA2 networks running on different hardware, and targeted my macbook, windows 7 pc and android phone with no success. I have also had an attempt at a WEP network using ARP-request replay but did not get any success - I even eventually collected over 15K #Data on the WEP network and aircrack produced an incorrect key from the dump.
So I'm at a bit of a loss. Is there some patch I need that I'm missing? Am I doing some steps wrong? Am I just out of luck with my Qualcomm Atheros AR9462 on Asus Chromebook C720 with Arch linux?
-
I forgot to mention in my opening post that I have also tried aireplay-ng --test. The odd thing here is that it doesn't pick up all the APs that airodump-ng can see, such as FGPM which has a nice low siginal.
-
the step u did is correct..
it seem that the AP and client acknowledge you deauthentication..
if i were u... i will open up wireshark examine the traffic and try having the client device close to me..
-
I'll have a look through Wireshark, I've used it in the past but I don't really know what to look out for. I know, for example, how to find the handshake in Wireshark, but I wouldn't know how to debug this problem. The router(s) are right next to me, as are the devices. I get ~30 signal strength. Thanks for the tips.
-
You ever get this working? I am using Ubuntu 14.10 on a C720 with similar results. Injection just doesn't seem to be working. Nothings responds to fake auth, ARP replay, or injection test, but monitor mode and dumping works fine. I've seen others mention injection working on a C720 though, so I'm not sure what is wrong. I tried patching the drivers and a few different builds. I've used this Aircrack-ng suite on all kinds of distros and chipsets in the past. This is the first chipset that says it's supported that I'm not able to get going >:(
-
Still not working. Sometimes I get some replies instead of flat 0 | 0, but I still cannot get it to deauth or get a wep auth.
-
No.. i tried on backtrack and kali, don't have such problem... can u try on other cards as i suspect could be driver or card problem..
open up wireshark and filter only your AP and your client.. see if any deauth signal and acknowledgement or not...
from what i experience, usually far client difficult to get the signal.. try nearer but confirm AP would respond to deauth signal..
you can attach the captured packets and i may try to examine it if time avail.. ;)
-
also at the same time look at your own client device such as mobile phone to see if it got deauthenticated..
-
Here's something interesting I have found. I do not need to take my adapter down with 'ifconfig wlp1s0 down', I can instead simply start the monitor on the active device with 'airmon-ng start wlp1s0' - I can even stay connect to my own wifi and run airodump-ng. The only problem is, it appears to be stuck on the same channel as the router it is connected to.
This did lead me to an interesting experiment. If I am now connected to the wifi, what happens if I launch a de-auth attack against myself? Well, I got de-authed!
also at the same time look at your own client device such as mobile phone to see if it got deauthenticated..
aireplay-ng --test shows 0 response. I have of course manually checked to see if my own devices are disconnected.
-
Sometimes you might not notice you were deauthenticated. Here is the story. I was using VNC to remote on a machine (both were on wifi) and I deauthenticated myself. The VNC session wasn't interrupted, so I though it failed. What happened is that the driver reauthenticated so quickly I didn't notice a drop in the session. How it behaves really depends on the driver.
-
Sometimes you might not notice you were deauthenticated. Here is the story. I was using VNC to remote on a machine (both were on wifi) and I deauthenticated myself. The VNC session wasn't interrupted, so I though it failed. What happened is that the driver reauthenticated so quickly I didn't notice a drop in the session. How it behaves really depends on the driver.
I was curious about this last night. Running deauth on any of my devices did not cause them to stop pinging e.g. 'ping google.com -t' on the windows machine was uninterrupted, neither did airodump pick up any handshakes despite running the ping and deauth for around 30 minutes whilst all devices were sat in very close proximity. I have noticed that if my target is idle I typically get
Sending 64 directed DeAuth. STMAC: [80:1F:02...] [ 0| 0 ACKs]
Either side of the 0| 0 will occasionally be in the range 1-3. If the target is using the network, say streaming 1 hour of HD cats on youtube, the response leaps up.
Sending 64 directed DeAuth. STMAC: [80:1F:02...] [229| 0 ACKs]
The target still does not deauth.
With myself as the target, running deauth causes the pings to drop but as soon as I stop the attack they resume. In this instance airodump starts to capture WPA handshakes.
Sending 64 directed DeAuth. STMAC: [48:5A:B6...] [ 0|115 ACKs]
Notice I'm now getting high ACKs.
P.S. What exactly does 0| 0 represent? Is it SYN ACK?
-
codemonkey,
0|0 is [ ACKs received from the client | ACKs received from the AP ] meaning neither the client nor the AP responded to the deauth.
See: http://aircrack-ng.org/doku.php?id=deauthentication
d.
-
Sometimes you might not notice you were deauthenticated. Here is the story. I was using VNC to remote on a machine (both were on wifi) and I deauthenticated myself. The VNC session wasn't interrupted, so I though it failed. What happened is that the driver reauthenticated so quickly I didn't notice a drop in the session. How it behaves really depends on the driver.
I was curious about this last night. Running deauth on any of my devices did not cause them to stop pinging e.g. 'ping google.com -t' on the windows machine was uninterrupted, neither did airodump pick up any handshakes despite running the ping and deauth for around 30 minutes whilst all devices were sat in very close proximity. I have noticed that if my target is idle I typically get
Sending 64 directed DeAuth. STMAC: [80:1F:02...] [ 0| 0 ACKs]
Either side of the 0| 0 will occasionally be in the range 1-3. If the target is using the network, say streaming 1 hour of HD cats on youtube, the response leaps up.
Sending 64 directed DeAuth. STMAC: [80:1F:02...] [229| 0 ACKs]
The target still does not deauth.
With myself as the target, running deauth causes the pings to drop but as soon as I stop the attack they resume. In this instance airodump starts to capture WPA handshakes.
Sending 64 directed DeAuth. STMAC: [48:5A:B6...] [ 0|115 ACKs]
Notice I'm now getting high ACKs.
P.S. What exactly does 0| 0 represent? Is it SYN ACK?
I am too getting the same 0 l 0 deauth packet figured. Can you please tell me how you rectified it?
My concerns are
1 - is it because of incompatibility of my wireless adapter?
2 - I tried it on my own wifi network with my android phone connected. But the connected phone was on idle with no background apps consuming any data but was connected and both the ap and phone were in close proximity.
Stuck in a plateau, anyone has a solutions to this?
I need to fix this asap
Cheers!