Page 4 of 4 FirstFirst ... 234
Results 31 to 38 of 38

Thread: few questions

  1. #31
    Senior Member
    Join Date
    Apr 2008
    Posts
    2,008

    Default

    Quote Originally Posted by caballero View Post
    Funny thing happened to me and I don't know is that good or bad. When last time I restarted my notebook my ipw2200 interface changed from eth1 to eth0. Is that normal? What could be the cause? Because I did not touch configuration before restarting.
    This is a well documented bug, it changes nothing else than the interface the card is listed as and if you find it annoying there is a workaround for it posted on the wiki.
    -Monkeys are like nature's humans.

  2. #32
    Junior Member
    Join Date
    Jul 2008
    Posts
    66

    Default

    Howdy,

    I am running WEP crack attack with client connected described in one of the manuals found here. When I was testing it on my router I was able to crack my WEP in 14 minutes, with considerable trafic of course. But when my neighbour asked to try it on his router it's somehow different story. The problem is that the #Data in airodump-ng is increasing, aireplay --arpreplay is running and injecting packets, but IVs according to aircrack-ng are gathering very slow. For example if the #Data is somewhere at 30.000 then I'm getting only 1000 IV's max or even less. When I tested my AP it was approx #Data = IVs. What could wrong then in this case? The wlan adapter I'm using is of course crappy ipw2200. The commands I'm running on both AP's are identical.

  3. #33
    Just burned his ISO
    Join Date
    Nov 2007
    Posts
    12

    Default

    What kind of attack are you trying to do?

    And how close are you to your neighbor's AP?

  4. #34
    Senior Member
    Join Date
    Apr 2008
    Posts
    2,008

    Default

    Quote Originally Posted by caballero View Post
    The problem is that the #Data in airodump-ng is increasing, aireplay --arpreplay is running and injecting packets, but IVs according to aircrack-ng are gathering very slow. For example if the #Data is somewhere at 30.000 then I'm getting only 1000 IV's max or even less.
    I can think of two possible reasons why you would experience this problem. First of all the most common reason to why people see the ARP-replay attack running fine, but the number of IVs/DATA packets not increasing is that they have either been disassociated from the AP during the process, or where not properly authenticated to begin with. The aireplay attack will then run without problems, but the AP will not respond to the injected packets with new IVs.

    You also mention that you see the data packets increase steadily in airodump-ng but aircrack-ng not finding nearly the appropriate amount of IVs. Is there any other client connected to the AP who might be the only one generating the data packets? If this is the case, it is not unusual to see a high number of data packets collected but a rather low corresponding amount of IVs. I also have to ask whether you are certain that you are using the correct cap file with aircrack-ng? Note that if you interrupt and restart the airodump-ng capturing process at any time a new .cap file will be generated, to select several cap files with aircrack-ng the wildcard symbol (*) can be used.
    -Monkeys are like nature's humans.

  5. #35
    Junior Member
    Join Date
    Jul 2008
    Posts
    66

    Default

    Quote Originally Posted by =Tron= View Post
    I can think of two possible reasons why you would experience this problem. First of all the most common reason to why people see the ARP-replay attack running fine, but the number of IVs/DATA packets not increasing is that they have either been disassociated from the AP during the process, or where not properly authenticated to begin with. The aireplay attack will then run without problems, but the AP will not respond to the injected packets with new IVs.

    You also mention that you see the data packets increase steadily in airodump-ng but aircrack-ng not finding nearly the appropriate amount of IVs. Is there any other client connected to the AP who might be the only one generating the data packets? If this is the case, it is not unusual to see a high number of data packets collected but a rather low corresponding amount of IVs. I also have to ask whether you are certain that you are using the correct cap file with aircrack-ng? Note that if you interrupt and restart the airodump-ng capturing process at any time a new .cap file will be generated, to select several cap files with aircrack-ng the wildcard symbol (*) can be used.
    Ok, so I'm putting the commands that I'm using in case I messed up somethink. Each command runs in separate console:

    Code:
    airodump-ng -w capture -c 9 --bssid 00:90:8c:ac:87:29 eth1
    
    aireplay-ng --arpreplay -b 00:90:8c:ac:87:29 -h 00:02:6f:03:a0:4c eth1
    
    aircrack-ng -f 4 -m 00:90:8c:ac:87:29 *.cap
    But how can I become unassociated if I fallowed the manual? Does this happens for no reason? And then how to find out if I'm properly associated all the time during process? What does that mean "only one generating the data packets"? And yes, I always use *.cap. There 1 to 3 clients connected all the time to the AP, but only one is showing more activity. In airodump-ng usually number of section "Packets" is a bit lower than "#Data". But yesterday there was some change - one of the clients started racing "Packets" like mad, and then when he had "Packets" number at ~100.000, "#Data" was at ~50.000. But gathering IV's did not change anyway, it was like always very slow.

  6. #36
    Senior Member
    Join Date
    Apr 2008
    Posts
    2,008

    Default

    Quote Originally Posted by caballero View Post
    But how can I become unassociated if I fallowed the manual? Does this happens for no reason? And then how to find out if I'm properly associated all the time during process?
    There are a couple of reasons why you could become disassociated from the AP and you could check if this is occurring by examining the received packets with wireshark or tcpdump. The following is an excerpt from aircrack-ng.org
    Quote Originally Posted by aircrack-ng.org
    If at any time you wish to confirm you are properly associated is to use tcpdump and look at the packets. Start another session and...
    Run:
    tcpdump -n -e -s0 -vvv -i ath0 Here is a typical tcpdump error message you are looking for:
    11:04:34.360700 314us BSSID:00:14:6c:7e:40:80 DA:00:09:5B:EC:EE:F2 SA:00:14:6c:7e:40:80 DeAuthentication: Class 3 frame received from nonassociated station Notice that the access point (00:14:6c:7e:40:80) is telling the source (00:09:5B:EC:EE:F2) you are not associated. Meaning, the AP will not process or accept the injected packets.
    If you want to select only the DeAuth packets with tcpdump then you can use: “tcpdump -n -e -s0 -vvv -i ath0 | grep DeAuth”. You may need to tweak the phrase “DeAuth” to pick out the exact packets you want.
    .
    Quote Originally Posted by caballero View Post
    What does that mean "only one generating the data packets"? And yes, I always use *.cap. There 1 to 3 clients connected all the time to the AP, but only one is showing more activity.
    The reason I am asking this is because it is possible that you where never properly authenticated with the AP in the first place and that the increase in data packets have nothing to do with your injected packets and only the activity of the client. Every data packet will then not contain an IV usable for obtaining the WEP key.
    -Monkeys are like nature's humans.

  7. #37
    Junior Member
    Join Date
    Jul 2008
    Posts
    66

    Default

    Quote Originally Posted by =Tron= View Post
    There are a couple of reasons why you could become disassociated from the AP and you could check if this is occurring by examining the received packets with wireshark or tcpdump. The following is an excerpt from aircrack-ng.org

    The reason I am asking this is because it is possible that you where never properly authenticated with the AP in the first place and that the increase in data packets have nothing to do with your injected packets and only the activity of the client. Every data packet will then not contain an IV usable for obtaining the WEP key.
    I've analysed the last *.cap file I had. This is what wireshark shows me:

    Code:
    1	0.000000		SenaoInt_03:a0:4c (RA)	IEEE 802.11	Acknowledgement, Flags=........
    2	0.000001		SenaoInt_03:a0:4c (RA)	IEEE 802.11	Acknowledgement, Flags=........
    3	0.000000	EtrendEl_ac:87:29	Broadcast	IEEE 802.11	Beacon frame, SN=4025, FN=0, Flags=........, BI=100, SSID="plech_ap"
    4	0.210431		SenaoInt_03:a0:4c (RA)	IEEE 802.11	Acknowledgement, Flags=........
    5	0.241152		SenaoInt_03:a0:4c (RA)	IEEE 802.11	Acknowledgement, Flags=........
    6	0.320001		SenaoInt_03:a0:4c (RA)	IEEE 802.11	Acknowledgement, Flags=........
    7	0.321025		SenaoInt_03:a0:4c (RA)	IEEE 802.11	Acknowledgement, Flags=........
    8	0.515073	MitacInt_09:91:95	Broadcast	IEEE 802.11	Data, SN=4041, FN=0, Flags=.p....F.
    9	0.530433		SenaoInt_03:a0:4c (RA)	IEEE 802.11	Acknowledgement, Flags=........
    And so it goes on pretty much in the same manner all the time untill ~50.000 lines. Not sure really what does that mean

  8. #38
    Just burned his ISO
    Join Date
    Aug 2008
    Posts
    3

    Default

    question 4. is it possible to use several *.cap files at once to crack WEP? For example if I'm running aireplay-ng each day at the end of the day stopping it collecting ~25000 ivs, so after 4 days I would have 4 cap files each approx 25000 ivs.

    same question here !

Page 4 of 4 FirstFirst ... 234

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •