[Script] [Video] wiffy (v0.1)

[Eatme]

new update is perfect...

thanks...g0tmi1k

[jonathan11]

Just tried #19
Im getting some problems with this one.
The first thing I noticed was that it took me really long time to find a client ( was waiting around 10minutes) I then tried to find client manually and I did so in 8 seconds.
I aborted with CTRL+C and wiffy restored environment.
When I ran the script again I did not find a single AP.
I tried to run airmon-ng manually and I find

root@bt:~# airmon-ng start wlan0


Interface       Chipset         Driver

wlan0           RTL8187         r8187 (monitor mode enabled)

*** REBOOTED ***
root@bt:~# airmon-ng start wlan0


Interface       Chipset         Driver

wlan0           RTL8187         rtl8187 - [phy0]
                                (monitor mode enabled on mon0)

root@bt:~#

So yeah, if I abort wiffy script, I need to reboot my system in order to find WLAN's again, re-plugging wlan-card would not make a difference.
I tried wiffy #9 and the problem was not in that version of the script.

Anything I'm doing wrong?

[cseven]

#20 ooooh pretty colors

You know it's a sin to add flashy stuff to linux

* When running mode'"inject" it stalls on installing airpwn because the connection is in monitor mode
* (suggestion list) What would be nice is if the wiffy.keys was searched first to see if the AP is already been cracked. A simple grep <AP Name> wiffy.keys usually suffices though.

[Eatme]

Just tried #19
Im getting some problems with this one.
The first thing I noticed was that it took me really long time to find a client ( was waiting around 10minutes) I then tried to find client manually and I did so in 8 seconds.
I aborted with CTRL+C and wiffy restored environment.
When I ran the script again I did not find a single AP.
I tried to run airmon-ng manually and I find

root@bt:~# airmon-ng start wlan0


Interface       Chipset         Driver

wlan0           RTL8187         r8187 (monitor mode enabled)

*** REBOOTED ***
root@bt:~# airmon-ng start wlan0


Interface       Chipset         Driver

wlan0           RTL8187         rtl8187 - [phy0]
                                (monitor mode enabled on mon0)

root@bt:~#

So yeah, if I abort wiffy script, I need to reboot my system in order to find WLAN's again, re-plugging wlan-card would not make a difference.
I tried wiffy #9 and the problem was not in that version of the script.

Anything I'm doing wrong?

change:

if [ "$wifiDriver" == "rtl8187" ] ; then action "Changing drivers" "rmmod rtl8187 ; rmmod mac80211 ; modprobe r8187" ; fi

to this:

if [ "$wifiDriver" == "rtl8187" ] ; then action "Changing drivers" "rmmod r8187 ; rmmod mac80211 ; modprobe rtl8187" ; fi

or just do a simple quick fix:

:~# rmmod r8187
:~# modprobe rtl8187

[jonathan11]

or just do a simple quick fix:

:~# rmmod r8187
:~# modprobe rtl8187

That did the trick, thanks!
And since I'm trying to learn more about Linux/BackTrack etc, what exactly does that command do?

[Eatme]

That did the trick, thanks!
And since I'm trying to learn more about Linux/BackTrack etc, what exactly does that command do?

I'm sort of new to linux as well, but not backtrack, but someone could back me up on this, this changes a driver to another driver (patch) maybe ?

[roybatty]

I'm sort of new to linux as well, but not backtrack, but someone could back me up on this, this changes a driver to another driver (patch) maybe ?

OMG, linux first then backtrack please. rmmod removes a module from the kernel, modprobe adds a module to the kernel.

Wrt the drivers, to understand the differences read install_drivers [Aircrack-ng]

One seems to inject better (monitor mode), the other one connects better (managed mode).

[g0tmi1k]

change:

if [ "$wifiDriver" == "rtl8187" ] ; then action "Changing drivers" "rmmod rtl8187 ; rmmod mac80211 ; modprobe r8187" ; fi

to this:

if [ "$wifiDriver" == "rtl8187" ] ; then action "Changing drivers" "rmmod r8187 ; rmmod mac80211 ; modprobe rtl8187" ; fi

or just do a simple quick fix:

:~# rmmod r8187
:~# modprobe rtl8187

I dont run it in VMware, and I haven't had this problem myself, so I was just going on this:

In our tests we have found the rtl8187 driver to behave strangely in VMware environments. Eight out of ten times, the card would not go into monitor mode, and spit out this error:

root@bt:~# airmon-ng


Interface Chipset Driver

wlan0 RTL8187 rtl8187 - [phy0]

root@bt:~# airmon-ng start wlan0


Interface Chipset Driver

wlan0 RTL8187 rtl8187 - [phy0]SIOCSIFFLAGS: Unknown error 132

(monitor mode enabled on mon0)


To solve this, you can switch to the ieee80211 r8187 drivers, which will work just fine:

rmmod rtl8187
rmmod mac80211
modprobe r8187

And to make these changes permanent, modify your /etc/modprobe.d/blacklist file to blacklist ONLY rtl8187. Entry should look like this:

blacklist snd_desktop
...
#blacklist r8187
blacklist rtl8187
...

http://www.backtrack-linux.org/forum...ror-132-a.html
However, what your saying is to flip rtl8187 & r8187 the other way around....

That did the trick, thanks!
And since I'm trying to learn more about Linux/BackTrack etc, what exactly does that command do?

man rmmod — simple program to remove a module from the Linux Kernel
man modprobe — program to add and remove modules from the Linux Kernel

It's been used to switch drivers.

[Eatme]

Im not running vmware either, and still get this problem..

@roybatty
I did say I was new first before anything, i put them in order cuz im still new to linux period, but im already familiar with backtrack. Like I said, i didnt know what the commands did per say in depth, so i took a guess what they did. :-\

thanks for the correct info tho.

[jonathan11]

So I was trying to capture a WPA handshake from my network.
I first tried to do in manually with

aireplay-ng --deauth 10 -a 00:**:**:6E:**:** -c 00:1C:**:3A:**:** mon0

I did send countless of DeAuth's, see below:

21:07:47  Sending 64 directed DeAuth. STMAC: [00:1C:**:3A:**:**] [12|41 ACKs]
21:07:47  Sending 64 directed DeAuth. STMAC: [00:1C:**:3A:**:**] [16|30 ACKs]
21:07:48  Sending 64 directed DeAuth. STMAC: [00:1C:**:3A:**:**] [16|19 ACKs]
21:07:48  Sending 64 directed DeAuth. STMAC: [00:1C:**:3A:**:**] [22|20 ACKs]
21:07:50  Sending 64 directed DeAuth. STMAC: [00:1C:**:3A:**:**] [33|46 ACKs]
21:07:51  Sending 64 directed DeAuth. STMAC: [00:1C:**:3A:**:**] [26|52 ACKs]
21:07:52  Sending 64 directed DeAuth. STMAC: [00:1C:**:3A:**:**] [27|56 ACKs]
21:07:53  Sending 64 directed DeAuth. STMAC: [00:1C:**:3A:**:**] [18|53 ACKs]

for about 10 minutes or about 500 DeAuth's with no luck on the handshake.

I then launched wiffy to see if wiffy was able to capture the handshake (I'm still quite a beginner and suspected that I did something wrong.)
Wiffy found the handshake after about 10 seconds and I had a nearly empty wordlist for wiffy, just so I would get the *.cap.
I then tried to crack the cap file wiffy generated with cowpatty. With the results:
"End of pcap capture file, incomplete four-way handshake exchange. Try using a different capture."
I then tried to run the *.cap file that wiffy generated into aircrack-ng

aircrack-ng /root/wiffy/wiffy-NAMEOFCAP.cap -w /root/internal/wordlist/testlist.lst

and aircrack just launches and starts to plow thru my wordlist.

This brought some questions, not all of them are directly related to wiffy I hope it's OK to post them anyways.

Is the CAP incomplete since cowPatty wont take it?
Or does cowPatty require different information then what aircrack-ng does?
Could wiffy caputre a incomplete handshake?
Why did I fail to manually DeAuth my laptop, was the signal strength too low? (As I understood by reading about aireplay-ng the low ACK count could be because of bad signal strength)