Friday, 25 October 2013

Create a local WiFi hotspot for testing using connectify.me

We took delivery of the new iOS devices for mobile testing. And in order to activate them, you need to connect over Wi-Fi  But they wouldn't connect to the Wi-Fi network during the activation wizard. What to do?

I decided to use my laptop as a local Wi-Fi hotspot. That way I could configure it with different passwords and encryption types to try the different options and hope that the iOS device would connect.

I had trouble sharing the Wi-Fi connection using the in built windows functionality (ably explained on lifehacker)

So I installed connectify.me to help me use my laptop as a hotspot. And LO! The iOS devices happily connected through my local hotspot and activation could ensue.

Of course - once I had activated them, the iOS devices had no problems connecting to the Wi-Fi network I originally wanted to use for activation.

I suspect that the local hotspot approach might have some useful secondary benefits that I may have to research:
  • monitor traffic without having to setup a proxy
  • throttle the network speed

This also means that I can configure my mobile devices to connect over a single Wi-Fi network, and route the requests over other Wi-Fi networks by configuring the laptop connection rather than on multiple mobile devices.

Anyone else doing this? Any hints and tips or other uses you want to share?

Thursday, 24 October 2013

How to chain HTTP Debug Proxies

I chain HTTP debug proxies.

That way I can use features from all of them, at the same time:
  •     Fiddler Autoresponders
  •     BurpSuite passive sitemap building
  •     ZAP's multiple breakpoints
  •     etc.

Fiddler

I usually work on Windows, so the first proxy I start is Fiddler. Fiddler hooks into the windows system seamlessly without any additional config. All other proxies I point at Fiddler as the down stream proxy.

When fiddler is running. Test your setup by pointing your browser through Fiddler.

BurpSuite

BurpSuite Options tab. Upstream Proxy Servers. Add an entry for Fiddler:

  • Destination Host: *
  • Proxy Host: localhost
  • Proxy Port: 8888

At this point - test your setup again. Don't chain everything together and then try and figure out where the problem is. Point your browser at BurpSuite and check you can see traffic through them all.

If you get stuck, use the Alerts tab in BurpSuite to check for errors.

Hint: Firefox and Opera maintain their proxy settings independently from the Windows settings so test your setup with Firefox or Opera.

ZAP

Tools \ Options \ Connection. Then point it at BurpSuite
  • Port: 8082 (or whatever you bound BurpSuite too)
Find the port you have bound ZAP to in Tools \ Options \ Local Proxy

And point the browser at this port now.

End

Voila, you should have it all chained.

If not, just revisit the last step. And don't panic.

Step by step. check each part of the journey. If its not working, it will probably just be some stupid error where you had previous config left over from a previous session.

Just remember to unwind them when you are done.

I have a video in the Technical Web Testing 101 course that shows this in more detail.

Links:

Wednesday, 23 October 2013

How to view http traffic on your mobile phone device via a computer proxy

Viewing the HTTP traffic from your mobile browsers doesn't take that long to set up, but there are a few gotchas to be aware of:
  • You need to find the right IP address on your desktop
  • You need to change your proxy settings on your phone
  • Make sure your proxy allows external connections
  • Make sure both Mobile Device and Proxy Machine are on the same network



The setup I normally use:
  • Phone connected to wifi network
  • Windows Desktop connected to same network via wired connection (or laptop connected via wireless)
As an example, using Fiddler as the debug proxy, on the desktop:
  • Start Fiddler
  • Check that Fiddler has "Allow remote computers to connect" (via Tools \ Fiddler Options \ Connections)
  • Start a command prompt and use "ipconfig" to show you the current list of ip addresses for you computer
On the mobile device, details below are for android (but the principle is the same for other operating systems):
  • Open Settings
  • Wi-Fi settings
  • Long press on the wireless network you are using to access the connection settings
  • Modify Network Config
  • Proxy Settings - Manual
    • change the Proxy HostName to the IP Address of your desktop
    • Add the port for your debug proxy e.g. 8888 for Fiddler
Then your browser should be connecting to the proxy.

Other applications may not use the proxy in this way. You might need to setup port forwarding use adb to feed them through to your proxy (don't leave comments asking how to do this check on google. I haven't had to do this for some time so my memory of hacking around on the android device to get it working is hazy.)

On Android: Chrome, Firefox, Dolphin and the inbuilt browser all worked without issue. I had some hassle connecting Opera, but didn't try and diagnose why.

Try it and see how you get on.

 It makes a big difference to the visibility of your testing when working through mobile.

Additional Notes: 
  • For burpsuite, in "Proxy \ Options" edit the proxy listener to Bind to address "All interfaces"

Friday, 4 October 2013

Android Screen Capture, Streaming and ScreenRecording tools for Mobile Testing

I looked at my mobile testing options and I realised that I didn't have a full toolbox to help me.

I first wanted to identify screen capture and screen recording options for my Android devices.

Most of the tools I found wanted root devices. When testing, you may not have this option, people might come across paranoid about interfering with the device state.

So I limited myself to tools which did not require root access. They all pretty much work the same way using ADB and Debugging over USB enabled.

If you bought all tools that I recommend in here, then the total cost would hit the dizzying height of £8.98, so I don't see a lot of point trying to roll my own solution.

To use these tools you pretty much need to have a working SDK setup. So work on that first. And if you can connect to your device with adb or monitor.bat then you're probably good to go.

http://developer.android.com/sdk/index.html

In order to record the screen for some of these I use them in combination with a desktop screen recording tool like Camtasia or the Blueberry Software tools BB FlashBack or BB Test Assistant

Free and Open Source Tools

Both Droid@Screen and Android Screen Monitor offer much the same functionality. I think your ultimate choice will depend on which GUI you prefer.

Droid@Screen



Droid@Screen is a pretty good wrapper around the adb.

The main GUI display shows a continually refreshed view of the device.
  • You can take a screenshot very easily. 
  • The main GUI has easy orientation buttons to adjust the GUI display for landscape or GUI.
  • You can capture screenshots to a folder automatically.
  • You can view device properties
  • You can scale the output view
On my Samsung Galaxy Note II the refresh rate was a little slow (about 1 - 2 frames per second), but it is a pretty high res screen. For lower resolution screens you might find that you can use this for screen recording as well.

Android Screen Monitor



Much the same as droid@screen, the GUI is simpler with a right click menu instead of icons.

Sometimes this is a little faster than droid@screen, sometimes droid@screen is a little faster.

Commercial

ASC - Advanced Screen Capture



ASC performs on device screen capture, so it writes a movie file to the phone's memory. It has a bunch of options to adjust framerate. What I particularly like is that it will highlight the taps you make on the screen so you can view the interaction on the device.

On non rooted devices requres you to use an 'activation' program on the PC or mac. The desktop activator program acts as a simple way of making a connection to your device and taking a screenshot, so an easy way of accessing some of the sdk funtionality.

Looking at the popups as the screen 'activates' it is using adb in some way - I assume to enable the android screenshot api.

Application description on the play store says it only works on non-Tegra devices. The trial worked fine on my Samsung Galaxy Note II.

Buy through an in-app purchase for £3.99

Activation Notes: I had some trouble activating it after purchase, but after a few emails with the developer. I had to uninstall it, then re-install it, then click the 'buy' again (I wasn't charged twice). The activation does work, but a bit more fiddly than it needed to be.

VMLite VNC Server

Costs £4.99

A desktop program to start the server on your phone if you work non-rooted.

Once the server runs I can head off to http://<deviceip>:5801 to use the HTTP interface.

Or connect a desktop vnc server to <deviceip>:5901 

The HTML5 viewer was about the same as Droid@Screen or Android Screen Monitor. 

The Java Applet VNC is a little faster, and the best out of the desktop tools I tried.

The video was not as smooth as ASC, but remember that this has the advantage that I can interact with the android device as well from the desktop and use my mouse and keyboard.


Used But Can't Recommend Fully

I also tried a couple of other Open Source Tools, but they didn't work well on my machine, that doesn't mean they won't work on yours, so I list them below:

Summary

A mix of tools there:
  • Desktop Connection for Screenshots and low frame rate streaming
  • VNC for higher framerate and interaction
  • On Device Capture for High Frame Rate
What do you use when you test on mobile devices to record the testing you perform? Leave a comment and let myself and the world know, so we can evaluate the tools you recommend and expand our options.

>