Disclaimer – this blog is old, and was imported from an old site – remember this when reading what’s below.
The script in question
The script I’ve written is designed to provide an easy user interface for performing de-authentication attacks against known devices. For those who don’t know, a de-authentication attack is one that removes a targets connection to the access point it’s connected to. The specifics of how this works are explained later in the post
I decided to do this after finding it inconvenient to perform the attacks manually, what with the large amount of both command syntax and raw data that is necessary for the attempt to be successful. I figured it would be far easier to spend several days straight creating a script rather than an extra minute every now and again. The script is designed to work best on networks that have already been infiltrated, as then the internet providers own router hosted site can provide an accurate list of both the MAC addresses that are essential and the custom device names that make the script particularly useful and unique. It’s functionality is entirely based around the pre-existing suite of aircrack-ng tools, information on which can be found here: https://www.aircrack-ng.org/. These tools are some of the most commonly used in cracking (breaking into) WiFi, particularly networks with outdated WEP and WPA security.
In my attempts to give this blog the semblance of being useful to people interested in my coding style and experience for genuine reasons, I’ve uploaded the project to GitHub, which can be accessed through the provided URL at the bottom of the post.
I’ve decided to be original and split my code into small sections, so that I can then delve into these sections in reasonable depth one at a time. That way if a particular area takes your fancy, you can skip to the relevant sub-title.
Libraries and startup()
The libraries in question shouldn’t be surprising to anyone who’s attempted to integrate other tools into a python script without much work or effort required. However, I feel I could have avoided using sys, as it was only used in a single line of the program, highlighted below.
Although there may be a more elegant solution out there, I decided that throwing an entire library at the issue was the most python-esque way of dealing with the problem.
For those unaware, the os library allows python to essentially use the command line of the host OS – in this case, by running this command:
This command opens up a separate terminal window running the tool needed to set the wireless interface, wlan0, into monitor mode. This allows the interface to inject packets into wireless devices, in a similar fashion to how a router does. Monitor mode isn’t available to all hardware, so you should take care if you wish to experiment with WiFi based penetration testing. This process also renames the interface from wlan0 to wlan0mon, which can clearly be seen referenced in the rest of the code.
The rest of the code
The largest chunk of the code can half be seen below:
Creatively named “main”, this function contains almost all the actual functionality of the code. It begins by creating variables that would otherwise cause errors if left undefined.
The next section of code, which could easily be its own function if the program was modulated correctly, is entirely focused on formatting the “addresses.txt” text file into a format usable in the program. I’ve included a copy of a default template in the git-hub project, as well as a screenshot below.
The text file is designed to contain all the information needed to run the program, namely the BSSID of the access point, and the device names with their associated MAC addresses. At this point in time the user of the script would have to enter in the data manually – but only once per access point. Although the formatting of the text file could be seen as the most vanilla part of the project, it probably cost me the most amount of time debugging, potentially due to my previous experience with Python 3. However my efforts proved not to be in vain, with the BSSID being stored separately to the rest of the data which is instead stored in a dictionary for easy calling of specific MAC addresses.
The last part of the code in this section lists the devices names, and prompts the user to select one. Again, note the slightly forced input validation.
The rest of the code part 2
Pictured above are the main workings of the script, in which the last user input is required in the form of a timeout length desired. I decided to use the “timeout” Linux tool to easily set a limit should the user desire, with the program first checking if “-1” had been entered, which would ensure the attack ran indefinitely. In either case, the following command had to be run.
This line is potentially the most confusing of the script, so I’ll break it down in a table.
| Code | Description |
| os.system(“”) | Runs the string within to the Linux command line |
| xterm -e | Whatever string follows it will run in a newly opened window |
| timeout 5 | Sets the command following to run five seconds |
| airodump-ng | Starts the airodump-ng tool |
| -d “+ BSSID | Filters the output to only display hosts of the correct BSSID |
| -c 11 | Sets airodump to only search on channel 11 |
| wlan0mon | Sets the interface used to wlan0mon |
This line is necessary because another tool used in the script, aireplay-ng, is unable to distinguish which channel the network devices are communicating on when run first. In my extensive five minute testing session I found that the easiest method of ensuring the script would work on startup is to run this line, which essentially “discovers” the local networks – in this case filtered so that only the target access point is found. This apparently allows following probing of the network to run smoothly, perhaps due to the details of the network being saved into cache memory. In either case, it causes the following window to appear. Each line shows a de-authentication packet that has been sent.
The most important line of the script is also in this final section, in two separate variations – one includes a time cap, using the users input, and the other does not. The line can be seen in its timed variation below.
Due to the fact that the first three portions of the line have been explained already, I’ve decided not to indulge in another table.. “aireplay-ng” refers to the tool being used here, which is designed to inject packets into a device or devices. The content, type, destination, and frequency of the packets are determined by the commands “arguments”. Arguments are given to the command in the format of “command -argument_name argument_value”. In this particular case, the first argument given is “-0 0 “, referring to the fact that de-authentication packets should be sent without stop. These de-authentication packets are what interferes with the targeted device’s connection, as they essentially block the communication from both the access point and the target device. This is a concise explanation, and I can recommend the following Wikipedia page: https://en.wikipedia.org/wiki/Wi-Fi_deauthentication_attack. The next argument used is “-a”, followed by the BSSID that was taken from the text file used for data entry. This argument sets the access points MAC address, needed as this specific attack sends packets to both the AP and the target. The next argument, “-c “,followed by the MAC address associated with the device name selected earlier reinforces this. Almost finally, the argument “-x 15” is used to set a custom number of packets to be sent per second (surprisingly 15 in this case), as I found the default would still allow the target to communicate with the AP somewhat. Finally, “wlan0mon” is once again used to distinguish the wireless interface being used.
The last interesting line run by the script is as follows.
Using the same tool as first used, this will put the wireless interface back into “managed” mode, allowing for normal use of the device – as I discovered in far too long a time period, you cannot use a wireless adapter in monitor mode for normal internet browsing or indeed connection.
A conclusion of sorts
To draw an end to this blog, I thought it would be wise to finish with a witty and inspired quote. Unfortunately I couldn’t think of any. If you’ve managed to read this far, I can only give you my congratulations – and a link to the git-hub repository. In terms of plans and projects for the future, I already have a few ideas up my sleeve. I’ll leave you with the (hopefully) functioning URL for you to clone the repository for yourself.