(German) spinnt aircrack-ng?

[spitfire666]

<-- 1st Post

Hallo zusammen,

zuerst sei gesagt, dass ich noch net so fit in dem ganzen Thema bin. Ich bin mir aber net so sicher, ob mein installierter aircrack-ng so arbeitet, wie er eigentlich sollte... 

Ich habe mir mit ner Fritz!Box ein Test-WLAN aufgebaut und wollte das mal knacken. Aber aircrack-ng lief nun die ganze Nacht durch und brachte kein Ergebnis. Der bis dahin geschätzte Key (mit den meisten Votes) war weitab vom richtigen Key.

Das hier habe ich mal gemacht:
mit ner Orinoco Silver und den madwifi-ng habe ich mir zwei virtuelle Karten erzeugt: ath0 (ein normaler Client, managed) und ath1 (der sniffer, mode monitor)
Dann bin ich den Anweisungen des Newbie-Tutorials gefolgt, bis zu dem Punkt, wo mit aireplay-ng injected wird und mein ath1 die Daten mitliest.

Beim Cracken hatte ich allerdings keinen Erfolg. Nun habe ich mit -d den Key bis auf ein Byte angegeben, welcher jedoch trotzdem nicht gefunden wurde:

Der WEP-Key ist 123abc123abcA, also 31:32:33:61:62:63:31:32:33:61:62:63:41

aircrack-ng -a 1 -i 1 -d 31:32:33:61:62:63:31:32:33:61:XX:63:41 test-01.ivs

Code:

                                                         Aircrack-ng 0.6.2


                                         [00:00:09] Tested 1025 keys (got 1000001 IVs)

   KB    depth   byte(vote)
    0    0/  1   31(+inf) FE( 220) C8( 185) 39( 170) A8( 170) C3( 120) ED( 118) 3C( 115) CC(  93) D9(  90) 14(  88) A4(  88)
    1    0/  1   32(+inf) C6( 742) 97( 598) C7( 596) CF( 577) FC( 567) 93( 566) 34( 561) 71( 554) CA( 554) EE( 547) C9( 543)
    2    0/  1   33(+inf) F8( 363) 96( 360) 90( 350) 8F( 285) 92( 285) C2( 232) 8E( 170) B4( 155) 37( 140) C9( 135) B2( 123)
    3    0/  1   61(+inf) 5E( 661) 55( 337) 8A( 308) F6( 305) C6( 303) 57( 300) 89( 288) 88( 263) 91( 250) BE( 215) 54( 213)
    4    0/  1   62(+inf) F7(1027) 2A( 585) 5F( 495) 20( 341) EE( 325) 8E( 298) 57( 291) 55( 276) 8D( 275) 22( 271) EB( 243)
    5    0/  1   63(+inf) 8E(1084) C1( 970) F6( 638) 2D( 550) 82( 285) ED( 285) 80( 270) EA( 265) 81( 246) 22( 240) 84( 240)
    6    0/  1   31(+inf) 23(1360) 56(1083) 8B(1010) C2( 596) 28( 355) F0( 323) 13( 312) 48( 310) 80( 275) 14( 266) 1B( 263)
    7    0/  1   32(+inf) E9(1763) 1C(1145) 88(1092) 51( 845) EE( 818) 4B( 319) 58( 316) 7B( 315) 56( 313) 0C( 304) 0D( 303)
    8    0/  1   33(+inf) E0(1393) 15(1205) 4C( 884) 1A( 771) AD( 716) BB( 478) 84( 449) 03( 313) 08( 308) 05( 307) 0B( 291)
    9    0/  1   61(+inf) 74(1956) A2(1793) 0E(1313) 46( 851) DC( 821) D7( 641) 6F( 578) 95( 375) AD( 349) 94( 335) FD( 335)
   10    4/  5   A1(1174) 6A( 921) D9( 699) 12( 571) 4D( 494) C8( 352) 26( 311) 92( 308) EE( 303) F7( 301) F6( 298) 8C( 295)
   11    0/  1   63(+inf) 87(1858) 59(1589) F3(1572) 54(1554) 2B(1264) C1(1134) BC( 807) DC( 758) 64( 616) 9F( 509) 1C( 429)

   Attack failed. Possible reasons:

     * Out of luck: you must capture more IVs. Usually, 104-bit WEP
       can be cracked with about one million IVs, sometimes more.

     * If all votes seem equal, or if there are many negative votes,
       then the capture file is corrupted, or the key is not static.

     * A false positive prevented the key from being found.  Try to
       disable each korek attack (-k 1 .. 17), raise the fudge factor
       (-f)

Hat hier vielleicht jemand ne Idee? Vielleicht habe ich was übersehen... Besten Dank im Vorraus.
Ich kann auch gerne die test-01.ivs zur Verfügung stellen, wenn jemand Interesse hat.

[ASPj]

Keine Ahnung was du angestellt hast, aber die IVs da kannste in die Tonne kloppen 

[spitfire666]

Ich glaube, da stimmt was generell nicht.
Wenn ich mit airodump-ng anschaue, sehe ich als MAC vom AP

00:30:F1:AD:0F:1B
00:30:F1:AC:D9:B6 sehe ich jedoch im Arp-Cache eines Clients, der den AP pingt.

Wenn ich mir den Aufkleber des AP anschaue, steht da die zweite Addresse (.......B6) drauf.

und die Krönung: Bei einer chopchop-Attacke bekomme ich folgende Konstellation, wenn ich mit einem Client den AP pinge:

BSSID = 00:30:F1:AD:0F:1B
DEST  = 00:30:F1:AC:D9:B6
SOURCE= 00:0F:B5:xx:xx:xx (Die MAC vom Client halt)

Sowohl bei einem T-Sinus 154 DSL-Basic als bei einer Fritz!Box Fon WLAN 7050 sehe ich das mit den leicht unterschiedlichen MACs.

Was hab ich denn da geschafft? *grübelgrübel* Wie gesagt, ich kenne mich net sooo doll aus. Kann das der Grund sein, weshalb meine IVs auch Schrott waren?
Hat jemand ne Vermutung, was das sein kann?

Ich verwende für die Attacken ne Orinoco Silver mit madwifi-ng r1816 (wegen dem Patch von http://patches.aircrack-ng.org/) und Aircrack-ng 0.6.2 mit Gentoo Linux Kernel 2.6.18


[ UPDATE ]
Ich habe jetzt mal BackTrack2.0 Beta ausprobiert. Aircrack-ng hat die Sache hier mit 200k IVs in 1:13 Min. erledigt.
Also ist es net die Hardware, sondern die Software. Ist vielleicht der madwifi-ng-Treiber zu alt? Ich habe extra diese Version mit svn geholt, da der Patch dafür gedacht ist. Oder kann ich vielleicht ne neuere Version holen? Ich weiß halt net, bei welcher Version ich den Patch noch anwenden kann.
Ein weitere Abweichung ist, dass ich aircrack-ng nicht mit "make" usw. installiert habe, sondern mit "emerge aircrack-ng" (is halt gentoo).

Morgen werde ich aircrack nochmal per Hand installieren und testen, ob das dann funktioniert. Oder hat jemand ne andere Vermutung?
[/UPDATE]

[ASPj]

Ja, gute Idee

Schön aircrack und den Treiber per Hand installieren, dann sollte es klappen. Wenn der Madwifi-SVN nicht will, versuch mal das letzte Release.

Viel Glück!

[spitfire666]

Moinmoin!
Hier nun der letzte Stand:

* aircrack-ng 0.6.2 ist von Hand installiert
* madwifi-ng ist nun 0.9.2.1 mit dem Patch madwifi-ng-r1816.patch von Hand installiert

aircrack-ng funzt nun mit meinem Gentoo. Ich denke, das Problem war, dass ich auf meinem Schlepptop mit dem Wifi0 zwei virtuelle ath's angelegt habe, und einen als sniffer hab rennen lassen, und den anderen als pingenden client.

In meinem PC hab ich jetzt eine Netgear-Karte eingebaut und als pingenden Client eingestellt und auf dem schlepptop nur eine sniffende ath0. Läuft sauber und verflucht flott! 

Nun stellt sich mir aber ein nächstes Problem, was eigentlich nicht mehr zum Topic gehört, aber ich hoffe, man sieht es mir nach, wenn ich dafür keinen neuen Thread aufmache (oder soll ich?  )
Ich will mich ja mit allen Methoden vertraut machen und habe mich nun wieder an die chopchop-Attacke gewagt: Wenn ich die BackTrack 2.0 Beta benutze kann ich mit chopchop sehr schnell ein Packet auffangen und decrypten. Wenn ich das aber mit meinem Gentoo mache, erhalte ich diese Meldung:

Code:

The AP appears to drop packets shorter than 37 bytes.
Enabling standard workaround:  IP header recreation.      <--- (wenn ich wüsste, wie das geht... ;) )
This doesn't look like an IP packet, try another one.

Warning: ICV checksum verification FAILED!

Das mit dem 37 Bytes würde ich ja gerne machen/ändern, wenn ich wüsste, wie.

Bei BackTrack erscheint die Fehlermeldung der ICV checksum verification nicht. Weiß jemand zufällig, was das sein kann?

so sieht ne cap-Datei aus, die ich mit meinem Gentoo gechopt habe:

Code:

17:00:55.695931 BSSID:00:04:0e:60:5a:7b: SA:00:0f:b5:34:11:A1 DA:00:04:0e:60:5a:79 LLC, dsap SNAP (0xaa), cmd 0x03; oui Ethernet (0x000000), ethertype IPv4 (0x0800): 192.168.5.100 > 192.168.5.254: [|icmp]

Das war der pingende Client. Man beachte wieder die ähnlichen Addressen von BSSID und DA (Die übrigens bei Backtrack auch so waren).

Für mich als Laien scheint das Packet gut auszusehen, oder? Aber warum würde dieser Prüfsummenfehler kommen...

[ASPj]

Jau, das Packet sieht gut aus. Versuch doch mal mit packetforge was draus zu bauen! Und injecte das dann.

Was der mit der Checksumme will.. hmm, fraglich. Scheinbar stimmt da immernoch was nicht so ganz

[spitfire666]

So, da bin ich wieder.

Ich habe jetzt mal ein solches Packet mit packetforge-ng gebastelt:

Code:

packetforge-ng -0 -y replay_dec-1224-131420.cap -a 00:04:0e:60:5a:7b -c 00:0f:b5:34:11:A1 -h 11:11:11:11:11:11 k 192.168.5.17 -l 192.168.5.100 -w arp.cap

Dann hab ich mal den Kram injected:

Code:

aireplay-ng -2 -r arp.cap ath0

Es erscheint sofort die Meldung "End of file.". Ansonsten passiert gar nix.

P.s.: Frohes Fest!

[ASPj]

Hast du auch das ToDS bit gesetzt? Sonst passiert gar nix, is leider ein kleiner "Bug" in packetforge.

[Hirte]

ASPj, da hat sich heimlich einer 500 Posts erschlichen, wa?

Es ist vielleicht wirklich besser standardmäßig das ToDS bit zu setzen, da dies häufiger benötigt wird.

Das ICV Problem hab ich übrigens auch ab und an, da sollte man mal genauer untersuchen, die Funktion zur Berechnung müsste allerdings stimmen, hab gerade mal drüber geschaut... Der resultierende Keystream funktionierte trotz diesem Fehler.

[ASPj]

Hm, das automatische ToDS bit hab ich Mister_X schon für Release 0.6.2 vorgeschlagen. Aber auf mich hört ja keiner 

500 Posts, und das auch noch an Weihnachten, Zeit für ne Party!!! YEAH! 

[spitfire666]

Hast du auch das ToDS bit gesetzt? Sonst passiert gar nix, is leider ein kleiner "Bug" in packetforge.

Öhm, ok, jetzt komm ich an meine Grenzen...

Meinste die Option "-o" beim packetforge-ng? Das habe ich eben ausprobiert. Da kommt das gleiche Ergebnis raus --> EoF
Allerdings steht in der manpage, dass -o das ToDS Bit cleared. Ich denke mal, ich habs falsch verstanden.

Bei aireplay-ng ist das ja nur ne Filteroption ("-t"). Da wüsste ich auch net, was man da setzen kann.

[Hirte]

Das ToDS Bit ist in der aktuellen Version bereits automatisch gesetzt und spitfire666 hat recht, das man es mit "-o" auf 0 setzt.

Allerdings hast du "-y replay_dec-1224-131420.cap" spezifiziert. Das -y Argument benötigt aber eine PRGA Datei, welche einen Keystream enthält. Das sind die xor Dateien von --chopchop und --fragment. Also solltest du "-y replay_dec-1224-131420.xor" verwenden. Da dieses verwechslen nun schon häufiger vorgekommen ist, habe ich für die nächste Version einen Hinweis eingebaut, der einem auf die Finger klopft, falls man keine .xor Datei angibt.

[spitfire666]

*patsch*

Ajo! Jetzt hat es geklappt. Allerdings hab ich mit aireplay-ng mit der neuen arp.cap meinen Client abgeknallt (aber richtig, mit Blue Screen und allem). Als Grund für den Shutdown wurde der Netgear-Treiber genannt. Hm, ich hab jetzt eine 1a-Schrotflinte. 

Mit obigen Befehl (und der Verwendung einer .xor-Datei ) hab ich folgendes Packet gebastelt:

Code:

Size: 68, FromDS: 0, ToDS: 0 (WEP)             <---- Kann das stimmen?

     BSSID  =  00:04:0E:60:5A:7B
  Dest. Mac  =  FF:FF:FF:FF:FF:FF
Source MAC  =  11:11:11:11:11:11

0x0000:  0840 0201 ffff ffff ffff 1111 1111 1111
0x0010:  0004 0e60 5a7b 8001 5500 0000 e2d4 dbe3
0x0020:  dda9 7d33 5d76 8fea fdba faa6 e1ab 7479
0x0030:  7d10 31fa 7e9c f93e c619 cd6b 0a4f 0dc1
0x0040:  8872 79f1

Beim zweiten Mal habe ich keinen Absturz mehr gehabt. Allerdings sehe ich bei airodump-ng meine gefakte MAC bei den Clients, wie diese Daten sendet, ohne Ende. Jedoch sehe ich oben bei den APs dass mein Access Point überhaupt net reagiert... Er schickt gar keine Daten.

[Hirte]

Spezifiziere NICHT das "-o" Argument, du sollst ja gerade ein Frame erzeugen, welches das ToDS Bit gesetzt hat. weiterhin wirst du keine Antwort vom AP erhalten, weil die fake MAC nicht assoziiert ist mit dem AP, deiner 11:11:11:11:11:11 ist es also nicht erlaubt Daten zu senden, verwende bei packetforge eine source MAC eines wirklich vorhandenen und assoziierten Clienten. Somit sollte es dann funktionieren.

[krabbatable]

ich wollte bei mir gestern aircrack auf dem Laptop installieren aber dazu benötige ich einen Code , kann ihn aber nirgens finden.

Wäre toll wenn ihr mir helfen könnt.