How to Build Your Own Mobile Application Testing Lab

How to Build Your Own Mobile Application Testing Lab

A key aspect of testing mobile applications is the ability to observe and modify network traffic. Learn how to use a router with modified firmware to perform HTTP/HTTPS-based traffic interception.

3 Methods for Intercepting Traffic

1. ARP cache poisoning
Testers can use man-in-the-middle tools such as Bettercap to force mobile device traffic to a proxy system. However, this may not always be the most convenient solution.

2. Manual proxy settings
Manually setting the proxy on the mobile device is an option, but has the limitation of only intercepting traffic that respects proxy settings.

3.  Manipulating routing rules
Using a wireless router with modified firmware ensures the testing environment completely captures a device’s network traffic with a minimal amount of test-specific configuration.

At DirectDefense, we use a five-step process to set up a mobile application testing lab using a wireless router with modified firmware.

Step 1: Select Hardware

We prefer to use a TP-Link WR841N router because the installation is straightforward, but anything from the list of OpenWRT supported hardware should work in a similar fashion. Another option is DD-WRT, but some of the syntax is different, so it requires some modifications to the iptables script.

Step 2: Install OpenWRT Firmware

After selecting your hardware, download the OpenWRT firmware binary file and upload it to the router as an upgrade. After the upgrade and reboot, the router is neither broadcasting a Service Set Identifier (SSID), nor has a web interface running. By connecting to the router using an Ethernet cable on any of the non-WAN ports, the proxy system is able to connect to the router using SSH. It is important to not connect to the WAN port for upstream internet, as this will cause IP address conflicts.

The first configuration change is to the password of the router’s root account. As with most Linux-based systems, the “passwd” command is used to make this alteration. After this step, modify the settings within the “/etc/config/wireless” file to broadcast an SSID. The following is a copy of the test router’s “/etc/config/wireless” file after enabling WiFi.

config wifi-device  radio0
            option type     mac80211
            option channel  4
            option hwmode 11g
            option path      ‘platform/qca953x_wmac’
            option htmode  HT20
config wifi-iface
            option device   radio0
            option network  lan
            option mode     ap
            option ssid     MobileSecTest
            option encryption ‘psk2’
      option key           ‘REDACTED’

Figure 1. Example /etc/config/wireless with WiFi enabled.

Next, modify the subnet mask in “/etc/config/network” so it does not overlap with any other subnets in use on the local network. In this example, the network is selected. This modification is highlighted below in a copy of the router’s modified “/etc/config/network” file.

config interface ‘loopback’
            option ifname ‘lo’
            option proto ‘static’
            option ipaddr ‘’
            option netmask ‘’
config globals ‘globals’
            option ula_prefix ‘fd6d:7347:ab27::/48’
config interface ‘lan’
            option type ‘bridge’
            option ifname ‘eth0’
            option proto ‘static’
            option ipaddr ‘’
            option netmask ‘’
            option ip6assign ’60’
config interface ‘wan’
            option ifname ‘eth1’
            option proto ‘dhcp’
config interface ‘wan6’
            option ifname ‘eth1’
            option proto ‘dhcpv6’
config switch
            option name ‘switch0’
            option reset ‘1’
            option enable_vlan ‘1’config switch_vlan
            option device ‘switch0’
            option vlan ‘1’
            option ports ‘1 2 3 4 0’

Figure 2. Example /etc/config/network file with modified IP address.

Next, reboot the router to ensure all changes are working correctly and are persistent. At this point, the router should broadcast the “MobileSecTest” SSID using the password specified. The Ethernet cable can now be disconnected, and the proxy machine can connect to the wireless network. Connect both the test device and the system that will act as a proxy to the test access point’s wireless network. Now, use an Ethernet cable in the test router’s WAN port to connect to a network with access to the internet, such as a cable modem or another router.

Step 3: Configure Proxy

On the proxy system, start the proxy application you plan to use. In this example, we’ll be using Burp from Portswigger. The only changes we need to make from the proxy system are to disable (or create appropriate permit rules in) any host-based firewall, configure the proxy to listen on the external interface, and to enable “Invisible” mode in the proxy. The host-based firewall settings are going to be operating system-dependent. The last two settings are controlled under the Proxy and Options tabs. Edit the default listener generated by Burp. The screen capture below shows these tabs:

Figure 3. Burp default proxy listener configuration.

Either set the listener to run on all interfaces, or just the interface connected to the testing network. This address will be needed again, so make sure to remember it.

Figure 4. Setting the appropriate proxy listener interface in Burp.

Since the intent is to eventually relay traffic to the proxy system without manual configuration on the test mobile device, invisible proxy support must be enabled on the “Request handling” tab as shown below:

Figure 5. Configuring invisible proxy mode for Burp.

Step 4: SSL/TLS Interception

With the proxy correctly configured, it is time to set the mobile device’s manual proxy. The manual proxy setting is only used temporarily to ensure the proxy system is working and to load the certificate onto the mobile device for SSL/TLS interception. Portswigger has provided walkthroughs for several mobile operating systems here:

Android Devices
IOS Devices
Windows Mobile Devices

Once the proxy system has been determined to be working properly, and the certificate has been successfully loaded onto the mobile device, the mobile device’s manual proxy settings can be removed.

Step 5: Cofigure IPTables

Last, configure the firewall on the testing router to pass all traffic to the proxy system. Before modifying the firewall configuration, it’s important to back up the current configuration. Even though this method does not permanently write the iptables changes to the router, it’s often convenient to stop proxying traffic by reverting to the original iptables configuration without rebooting.

The iptables-save command writes the configuration to a file that can be read back with iptables-restore if needed:

iptables-save > /root/iptables_default

Figure 6. Command line for backing up the current iptables configuration.

Now the firewall configuration can be modified without fear of losing the ability to route traffic normally. The goal here is to route all mobile device traffic that is pertinent to the application through our proxy system at

The script does not use command line arguments since it proved to be extremely difficult to implement effective input sanitization with the default version of OpenWRT. The following shell script performs traffic routing and ensures that the router logs all other traffic from the mobile device. In doing so, no pertinent network traffic will be missed during testing.

WAN_IFACE_ACCEPT=zone_wan_dest_ACCEPTiptables -I $WAN_IFACE_ACCEPT -p tcp -m multiport ! –dports 80,443 -j LOG
iptables -I $WAN_IFACE_ACCEPT -p udp ! –dport 53 -j LOGiptables -t nat -A PREROUTING -i $IFACE -s $LAN_NET -d $LAN_NET -p tcp –dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -i $IFACE ! -s $PROXY_IP -p tcp –dport 80 -j DNAT –to $PROXY_IP:$PROXY_PORT
iptables -t nat -A PREROUTING -i $IFACE -s $LAN_NET -d $LAN_NET -p tcp –dport 443 -j ACCEPT
iptables -t nat -A PREROUTING -i $IFACE ! -s $PROXY_IP -p tcp –dport 443 -j DNAT –to $PROXY_IP:$PROXY_PORTiptables -t nat -I POSTROUTING -o $IFACE -s $LAN_NET -d $PROXY_IP -p tcp -j SNAT –to $GW_IP
iptables -I FORWARD -i br-lan -o $IFACE -s $LAN_NET -d $PROXY_IP -p tcp –dport $PROXY_PORT -j ACCEPT

Figure 7. script for configuring iptables traffic routing rules.

The first part of the script is dependent on the individual testing network. Bold elements in the following section of the script should be modified to apply to individual testing environments:


Figure 8. Variable definition section of the intercept script.

The next section configures iptables logging in case the device uses communication on a port other than TCP 80 (HTTP), TCP 443 (HTTPS), and UDP 53 (DNS):

iptables -I $WAN_IFACE_ACCEPT -p tcp -m multiport ! –dports 80,443 -j LOG
iptables -I $WAN_IFACE_ACCEPT -p udp ! –dport 53 -j LOG

Figure 9. Script segment to log unintercepted traffic.

Next, the script routes all network traffic coming from our wireless testing environment on ports 80 and 443 to our proxy system on the appropriate port. If you are testing an application or device that uses another port, you may have to add that port to this section as well.

iptables -t nat -A PREROUTING -i $IFACE -s $LAN_NET -d $LAN_NET -p tcp –dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -i $IFACE ! -s $PROXY_IP -p tcp –dport 80 -j DNAT –to $PROXY_IP:$PROXY_PORT
iptables -t nat -A PREROUTING -i $IFACE -s $LAN_NET -d $LAN_NET -p tcp –dport 443 -j ACCEPT
iptables -t nat -A PREROUTING -i $IFACE ! -s $PROXY_IP -p tcp –dport 443 -j DNAT –to $PROXY_IP:$PROXY_PORT

Figure 10. Script segment to route network traffic to the proxy system.

Finally, the script changes routing rules to allow the proxy to send traffic to the internet.

iptables -t nat -I POSTROUTING -o $IFACE -s $LAN_NET -d $PROXY_IP -p tcp -j SNAT –to $GW_IP
iptables -I FORWARD -i $IFACE -o $IFACE -s $LAN_NET -d $PROXY_IP -p tcp –dport $PROXY_PORT -j ACCEPT

Figure 11. Script segment to allow outbound traffic from the proxy.

At this point, running the interception script should route all traffic from the mobile device on ports 80 and 443 through Burp on the proxy. This traffic should be visible on Burp’s “Proxy” tab. After using the application to populate Burp, it is prudent to check the router’s logs to see if there is any traffic that is operating a port other than 80 and 443. In our OpenWRT instance, these can be found using the “logread” and looking for any kern.warn messages. The logs that follow were generated using the command:

ogread | grep kern.warn

Figure 12. Command line to find iptables “kern.warn” level events.

The DPT field shows which port should be added to the script. The following screenshot depicts communication between the testing host and port 8081 on a remote system. There are also logs for some UDP communication that was not pertinent to the application being testing.

If the application uses non-HTTP traffic (much more common with IOT and thick client apps as opposed to mobile), then a different proxy application that is either specific to the protocol or uses a protocol-agnostic proxy must be used in place of Burp.

At this point, the test environment should be ready to begin running dynamic tests against the application and the associated server-side components. The following is a screenshot of Burp successfully proxying traffic generated by the Gmail Android application.

Figure 14. Burp successfully intercepting GMail for Android network traffic.

After following this five step process, you should have a wireless access point that is configured to intercept network traffic from any device connected to the access point. Any time a new mobile or smart that uses WiFi for its internet connection needs to be tested, simply run the intercept script to begin traffic interception. This setup allows testers to intercept, view, and modify network traffic to find vulnerabilities as they would when testing other web-dependant systems.




Written by: Stephen Deck

Stephen Deck is a Senior Security Consultant with over 15 years of experience in the information technology field. He currently focuses on performing software security assessments, but has also spent several years in incident response, security engineering, and software development.

Before joining DirectDefense, Stephen worked for Synovus Financial Corporation doing application security testing of in-house developed applications, embedded systems, and COTS software. Prior to Synovus, Stephen worked for Aflac Incorporated and focused on testing software as well as handling security incidents and engineered security solutions. Stephen also spent eight years developing software as a federal government contractor and four years as an infantry officer in the US Army.