13. Determining Chipsets and Drivers
The chipset of a Wi-Fi card and the corresponding driver are both important when it comes to penetration testing. In this module we will quickly review how to determine the chipset and driver for a Wi-Fi adapter, even if you can't physically access the hardware itself. This information may also be useful in helping find the right hardware to purchase ahead of time.
While we might prefer to stick to a list of chipsets known to work,1 there may be times when we need to work with an unfamiliar adapter during a penetration test. Learning the wireless chipset manufacturer will allow us to determine which operating systems are supported, what drivers we will need, and what limitations are associated with it.
All wireless cards carry the brand name of the manufacturer, such as Netgear, Ubiquiti, Linksys, and D-Link. These cards contain a wireless chipset, which has a different manufacturer, for example Mediatek, Ralink, Atheros, Qualcomm, or Marvell. Unfortunately for us, the chipset manufacturer is both more important and more difficult to determine. This is because card manufacturers generally don't want to reveal what they use inside their products. Even different versions of the same model of adapter may have different chipsets.
1 (Aircrack-ng, 2021), https://aircrack-ng.org/doku.php?id=faq#what_is_the_best_wireless_card_to_buy ↩︎
13.1. Determining the Wireless Chipset
We first need to determine which wireless chipset our adapter uses. There are several techniques we might use.
We'll begin by assuming that we have physical access to the adapter. This won't always be the case, but it's ideal since it will allow us to read information printed on the device.
One thing we can check for on the device is the FCC ID, which may be printed on a label, or if the adapter is very small, etched on the metal covering of the USB port.
We can enter this information into fcc.gov1 and then browse the internal photos of the device. Those pictures should show the Wi-Fi chip on the device, and the chipset manufacturer should be printed on the chip. Often, this will include the model number as well.
We could also use this same technique for any other device with wireless capabilities, such Wi-Fi Access Points, and cell phones.
Figure 1: Example of FCC ID label
We can also plug in the adapter to get information about it. If we're lucky, drivers (and firmware) get loaded, and when we run airmon-ng without any parameters, it should display the name of the driver and chipset.
If airmon-ng output doesn't show any interfaces, we'll need to check on the loaded modules, or drivers, first. If it's a USB device, we could simply examine the difference between modules loaded before and after plugging in the device. To do this, we would use lsmod, which we'll explore later in this module. We might also need to reboot, as a module may stay loaded after the adapter is plugged in and then unplugged. This method also works when the adapter is on the PCI/PCIe bus with PCI/MiniPCI,2 PCIe/MiniPCIe,3 or NGFF/M24 adapters. However, plugging in a device while the system is running is risky, and we might damage it.
If there aren't any modules loaded, we can look at the dmesg output before and after plugging in the device. This may indicate what the chipset is, and if there are any errors (such as missing firmware). We can also filter using grep with terms like ieee80211, mac80211, cfg80211, wireless, or wifi.
We might also inspect the output of lsusb -vv for descriptions or a USB id. For most internal devices, which are on the PCI/PCIe bus, the command is lspci and lspci -n.
Let's run sudo lsusb -vv and check the output for information that will help us identify our chipset.
kali@kali:~# sudo lsusb -vv
Bus 001 Device 065: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x148f Ralink Technology, Corp.
idProduct 0x5370 RT5370 Wireless Adapter
bcdDevice 1.01
iManufacturer 1 Ralink
iProduct 2 802.11 n WLAN
iSerial 3 1.0
bNumConfigurations 1
Listing 1 - Running lsusb -vv on a cheap-o adapter
In this example, the chipset is relatively obvious. It is an rt5370 from Ralink. The important information here is both the vendor id and the product id, 0x148f:0x5370, which will yield a lot of results in Google.
The names to the right of both these IDs are accurate. lsusb looked up both idVendor and idProduct from a text file (/var/lib/usbutils/usb.ids), then displayed the results. A similar file exists for PCI/PCIe devices, pci.ids, in /usr/share/misc/.
There are additional resources available to us in trying to learn the chipset of a particular device. DeviWiki,5 which is sometimes called WikiDevi, is a great place to start. Deviwiki is an easy-to-use, user-maintained database of wireless adapters and their chipsets. We might also try the Wireless Adapter Chipset Directory,6 and, for older Atheros 802.11a/b/g devices, we can try Rapla.7
We could also check the manufacturer's web page and look for product information on a particular model. This product information does not always include the chipset, though. We can also search the internet for "<card model> chipset", "<card model> linux", or "<card model>. As an added benefit to this particular approach, we can sometimes learn about other users and their experience with a particular product as well.
Windows driver filenames may be an unexpected resource for us. These driver filenames often contain the name of the chipset or the driver to use. If the driver is packed in an executable (with a .msi or .exe extension), we will need to unpack it. In fact, we may need to do so several times, as is the case when it is bundled with a Wi-Fi manager. Universal Extractor 2 (UniExtract2)8 is one of the more useful extraction tools in doing this.
1 (FCC, 2021), https://www.fcc.gov/oet/ea/fccid ↩︎
2 (Wikipedia, 2021), https://en.wikipedia.org/wiki/PCI_Express ↩︎
3 (Wikipedia, 2021), https://en.wikipedia.org/wiki/Conventional_PCI ↩︎
4 (Wikipedia, 2021), https://en.wikipedia.org/wiki/NGFF ↩︎
5 (DeviWiki, 2019), https://deviwiki.com/ ↩︎
6 (H.J. Heins, 2020), http://linux-wless.passys.nl ↩︎
7 (Rapla.net, 2009), http://atheros.rapla.net/ ↩︎
8 (William Engelmann, 2021), https://github.com/Bioruebe/UniExtract2 ↩︎
13.2. Determining the Wireless Driver
Once we have determined the chipset, determining the driver is fairly straightforward. If DeviWiki doesn't have the information, a search on the Linux-wireless wiki1 should help in figuring out which driver to use. Google is available as a last resort.
We shouldn't worry if we find conflicting results. There may be several different drivers on Linux for the exact same wireless card.
One of these drivers will be the vendor driver, which is sometimes closed source. In nearly all cases, it is unusable for monitor mode. Built-in Wi-Fi on most embedded systems, or System on Chips (SoC) fall in this category, and only in rare cases do they provide monitor mode. A few examples of vendor drivers with monitor mode capabilities are the r8187 driver,2 the rtl8812au driver,3 and the nexmon driver.4 r8187 has evolved into a driver with mac80211. rtl8812au is available as a package on Kali. The last one, nexmon, is a driver for some Raspberry Pis and other SoC with various Broadcom chipsets.
We may also want to search for an open source driver since it's likely that such a driver would support monitor mode. Unfortunately, if the chipset or driver is fairly new, it may not be included in the kernel and monitor mode may not be supported yet. In addition, if the chipset has some of the basic Wi-Fi functions built in (known as FullMAC5), monitor mode will rarely be supported even if there is an open source driver. These are typically found in embedded systems, or SoC, but not always.
1 (Kernel.org, 2021), https://wireless.wiki.kernel.org/en/users/drivers ↩︎
2 (Aircrack-ng, 2017), https://www.aircrack-ng.org/doku.php?id=r8187 ↩︎
3 (Aircrack-ng, 2021), https://github.com/aircrack-ng/rtl8812au ↩︎
4 (Seemoo Labs, 2021), https://github.com/seemoo-lab/nexmon ↩︎
5 (Linux-Wireless, 2019), https://wireless.wiki.kernel.org/en/developers/Documentation/Glossary#fullmac ↩︎
13.3. Example: Alfa AWUS036AC
Let's imagine a scenario in which we have an Alfa AWUS036AC USB Wi-Fi Adapter. We have to find the chipset and driver for it, so we might begin by searching Google for "Alfa AWUS036AC wikidevi". This sends us to the following URL: https://deviwiki.com/wiki/ALFA_Network_AWUS036AC
The box on the right of the page contains all the information needed to identify the chipset manufacturer and model. In this case, RTL8812AU.
Figure 2: AWUS036AC in DeviWiki
This page also lists the IDs (0bda:8812), which corresponds to the output of the lsusb command in linux.
kali@kali:~$ lsusb
Bus 003 Device 002: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac 2T2R DB WLAN Adapter
...
Listing 2 - Running lsusb for Realtek 8812au
In this case, DeviWiki indicates the driver is not in the kernel but there is a driver for it. The driver is in the "Probable Linux driver" box.
If the modules are loaded, we can use airmon-ng by itself and get the same information in a different format.
kali@kali:~$ sudo airmon-ng
PHY Interface Driver Chipset
phy0 wlan0 88XXau Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac 2T2R DB WLAN Adapter
Listing 3 - Running lsusb for Realtek 8812au
The output clearly lists the driver (88XXau) and its chipset (RTL8812AU).
In this case, the dmesg command, sudo dmesg | egrep "ieee80211|mac80211|cfg80211|wifi|wireless", doesn't yield any result as this driver doesn't provide much information when its module is loaded.
If we are on Windows, we can check the device manager. The ID would be found in the Details pane of the device itself, in the "Hardware IDs" property. In our case, we will find USB\VID_0BDA&PID_8812. This is the same as the IDs on Linux, but the format is slightly different. Here, the ID is uppercase and contains some additional text, including USB for a USB device, VID for "Vendor ID", and PID for "Product ID".
Figure 3: AWUS036AC in Windows
Searching for these IDs in WikiDevi or any search engine would also help in finding the chipset and driver required. We may get multiple results since multiple adapters share the same USB ID.
If we have exhausted all other options and we do not have access to the device itself, we can try to download the driver. It is very useful when searching for laptops that are too new to be in any search engine results.
In this case, we can download the Windows driver for the AWUS036AC. It doesn't really matter which version of Windows. The important parts are the filenames and content.
Sometimes the name of the files (with one of the following extensions: .cat, .inf or .sys) can indicate the chipset code name. Most of the time this is not the case, and the .inf file needs to be opened in a text editor (supporting UTF-16). There will be lists of IDs that are supported by that driver. In this example, the driver supports both PCI and USB Realtek devices, which will help narrow down what compatibility we have to look for on Linux.
Figure 4: Windows driver INF file excerpt
In this example, each approach gave us enough information to figure out the hardware IDs, which, with a little help from Google, can help us find the driver, rtl8812au. This driver supports monitor mode and can be installed manually by following the instructions on its GitHub page, or with sudo apt install realtek-rtl88xxau-dkms.