Archive

Posts Tagged ‘packet capture’

Over-the-air wireless data frame capture

September 21, 2017 1 comment

Patent analysis often involves investigating how a particular solution functions in order to determine the potential for use of a given patented claim, and sometimes this investigation entails analyzing wirelessly-communicated data.

In an earlier post I described how to capture IP packets sent to/from wireless devices by using a Windows OS computer as a wireless hotspot together with Wireshark, a packet capture and analysis software tool. While that technique works well for capturing and analyzing IP packets communicated between a wireless device on the wireless LAN (WLAN) and a remote server, that technique does not capture lower-level point-to-point MAC frames communicated between devices on the WLAN, such as between the hotspot computer and a wireless device or between two wireless devices connected to the WLAN.

Within a WLAN, devices do not need to leverage transport or network packets (e.g., TCP/IP) to communicate with one another since they are on a shared medium and so can use the data link instead. To capture the frames sent on the shared wireless medium, there is another process I can recommend. This process provides for capturing communicated frames, such as between a computer application and a smartphone on the WLAN. The guidance below presumes that you have permission to capture wireless frames transmitted over the wireless network.

  1. Fire up an unencrypted IEEE 802.11g wireless access point on a channel that is free or the least crowded. The “g” aspect is important, because newer protocols such as “n” and “ac” complicate capture due to variables like channel width and spatial streams. Having the access point be passcode-free and unencrypted is important as well because it allows for reading frames in the clear (presuming no other encryption is used for the transported data), though it is possible to use Wireshark to decrypt encrypted channels if you know the credentials — this is not covered herein.
  2. Boot Kali Linux on a computer. Kali is a Linux distribution with tools built in for performing penetration testing.
  3. Connect a wireless adapter that support IEEE 802.11g along with “monitor mode.” An example is Panda’s PAU05 300Mbps Wireless 802.11n USB Adapter — I have found that this particular adapter works well. Some other monitor mode wireless adapters that may function well are listed here and here.
  4. Use Kali built-in tools like airmon-ng and airodump-ng to monitor Wi-Fi channels and capture data while your devices under test are communicating. This further article on passive Wi-Fi connection sniffing provides alternate, but similar, techniques in deep detail.
  5. Once you have captured the sequence of data you wish, discontinue the capture and open the resulting “PCAP” file in Wireshark, which is conveniently preloaded in the Kali Linux distribution. In Wireshark you can analyze the data there.

Obviously much more could be written about each of the tools and protocols above, and indeed, books have been written about each. However, here you have a short list of high-level steps to perform for passive Wi-Fi data sniffing, along with a complete set of the hardware and software you will need.

For potential future discussion is packet capture in a wired network, such as via Ethernet.

 

Capturing and analyzing encrypted HTTPS communications

September 11, 2013 Comments off

More and more web applications typically encrypt communications with a user browser using Transport Layer Security (TLS), making determination of how the web application works more difficult. However, as part of patent analysis it can be quite helpful to peek into client-server communications to better ascertain how functionality works.

Packet capture tools such as Wireshark capture all Ethernet communications at a network adapter, and so cannot see inside encrypted packets like TLS packets used for securely transferring data via Hypertext Transfer Protocol Secure (HTTPS). TLS encrypts packets using symmetric cryptography between communication counterparts, so that unless you’re the NSA it should be challenging to be a “man-in-the-middle” and read the communications in the clear. For this reason, what is needed is insight at a counterpart endpoint, and in the client case for a web application this is the web browser. The web browser itself obviously must be able to encrypt and decrypt communications with a web application server, so it is here that one can capture and analyze HTTPS packets in plaintext format.

There are a variety of browser-specific add-ons that are available to capture and present sent and received HTTPS communications in plaintext format. One example that I have found helpful is HttpFox, an extension for Mozilla-based browsers such as the Firefox browser. HttpWatch is another solution that works for Firefox and on iOS devices (iPhone, iPad) as its own browser.

HttpFox Firefox browser add-on

HttpFox Firefox browser add-on

Below is a screen shot of HttpFox in action — it has captured several HTTPS communications with a website, including a highlighted GET method to obtain some JavaScript:

HttpFox HTTPS Capture

HttpFox HTTPS Capture

It should be noted that while browser extensions such as HttpFox are helpful for capturing and analyzing secure encrypted communications with browsers, these are not helpful for decrypting communications to/from other client applications because these other applications are TLS counterpart endpoints that are using cryptography without providing insight into the communications.

 

Categories: Analysis, Software Tags: , ,

Wireless packet capture and analysis

July 3, 2013 Comments off

Update (Sep 14, 2017): As of Windows 10, you no longer need to use the relatively complex VirtualWiFi solution described in the original post below. Instead, the “Mobile hotspot” solution provides a much more straightforward technique to set up a connection through your computer for Wireshark packet capture of IP traffic traversing through the computer.

Update (Sep 21, 2017): Additionally, see this later post about capturing Wi-Fi data frames in a passive over-the-air manner.


 

Fairly often when performing patent analysis, particularly when creating claim charts mapping one or more patented claims against a target product or service, I find it helpful to capture and analyze packets sent from a wireless device. Internet Protocol (IP) packet capture when using a personal computer, such as a Windows or Mac computer, is relatively straightforward using a packet capture tool. I have been using Wireshark (formerly Ethereal) for years as my preferred packet capture tool, although there are certainly other available options from which to choose, both paid and free.

Packet capture for packets sent to and from other wireless devices such as smartphones and tablets is not so straightforward, therefore I provide below details of a solution that I leverage so that you can take advantage of this approach as well during your patent analysis. The high-level summary of this solution is to set up a Windows OS computer to use Wireshark to capture packets on a virtual Wi-Fi adapter — see this Microsoft explanation of the solution, termed VirtualWiFi, which I can confirm works for me with Windows 7. Credit goes to Eric Geier for documenting how to set up virtual W-Fi adapters here.

Steps:

1. In a command prompt (“cmd”), enter the following to set up your hosted network connection: netsh wlan set hostednetwork mode=allow ssid=YourVirtualNetworkName key=YourNetworkPassword  — You can set up your SSID (YourVirtualNetworkName) and password (YourNetworkPassword) as you wish, though of course you’ll need to know these when you try to connect from your wireless device that you’re testing.

Packet capture - step 1

2. Before enabling the virtual hosted network, configure the physical network adapter to share its Internet access using the Internet Connection Sharing (ICS) feature of Windows. To enable ICS, open the Network Connections window, then right-click the network adapter that is actually connected to the Internet and select Properties. Then select the Sharing tab, check the “Allow other network users to connect through this computer’s Internet connection” checkbox, choose the hosted network connection (that you enabled in step #1) from the drop-down listbox, and click OK.

Packet capture - step 2a Packet capture - step 2b

3. In the command prompt, enter the following to start your hosted network connection: netsh wlan start hostednetwork

Packet capture - step 3

4. Open Wireshark and select Capture->Interfaces, and select the adapter for your physical network connection and click Start. You can confirm that you have the correct adapter through comparison of MAC addresses, though the easiest solution is probably just to watch the packet count of adapters when using the target wireless device — the adapter with corresponding increases in packet count is the one to use.

Packet capture - step 4

5. Connect to the new hosted Wi-Fi network with the target wireless device and execute the desired application, website, service, etc. on the target device being tested and step through whatever sequence for which you wish to analyze the corresponding packets.

6. Once done with testing and recording, select Capture->Interfaces->Stop in Wireshark to stop packet capture.

7. You will then have a set of packets to analyze, and you’ll need to determine the IP address of the wireless device being tested. There are many different considerations here as far as best approaches to walk through the packet data, such as filtering, stream following, searching, exporting, etc., so I suggest that you reference the documentation that Wireshark provides here.

8. Disable the hosted network through entering the following command in the command prompt: netsh wlan stop hostednetwork

If at any time during the steps above you wish to see the current status of the hosted network, such as the MAC addresses of connected devices, enter the following command in the command prompt: netsh wlan show hostednetwork

Packet capture - show network

Once you have performed steps 1-2 above, on system reset the hosted network will not automatically start up, so you would need to execute this command again: netsh wlan start hostednetwork. In fact, once steps 1-2 have been performed once, from then on you should not have to perform them again for subsequent testing — you can start at step 3.

I hope you enjoy your wireless packet capturing and analysis!