25
votes

Mobile network operators (also: telephone companies, telcos, providers) sometimes offer low cost data packages that are usable only on the phone. Or so, they say.

How can they distinguish between a user browsing the web with a browser on his Android phone and a user using a browser on a laptop tethered to an Android phone?

In early 2012 I was in Paris and I was using an Orange mobile data package with a Nokia E51 (Symbian S60). Indeed, I could only access the Internet using the phone's browser, not from my laptop tethered to the phone. Now, I a have an Android 2.3 phone, and I am thinking about subscribing to a similar data package in Spain (operator Más Móvil).

1
  • 3
    It can be done with deep packet inspection. You can fight back with TOR, tunnels and vpn's surrounded by Stacheldraht.
    – ott--
    Commented Jun 23, 2013 at 21:11

3 Answers 3

30
votes

How they detect that someone is tethering a device isn't something that network providers often want to talk about, for the obvious reason that the more consumers know about how this is being detected, the easier it is for them to find ways to hide the fact that they're doing it, and avoid the associated extra charges (1). However there are certain known techniques that will give away the fact that you're currently tethering, if your Service Provider happens to be running the right tool to check for these indicators:

Your Phone asks your network if tethering is allowed

The first and easiest method is that some phones will query the network to check whether the current contract allows tethering, and then totally disable the tethering options on the device in software if not. This generally only happens if you are running an OS version that has been customized by your Provider, example 1 example 2.

Your phone tells your network that you are tethering

It's also rumoured that some phones have a second set of APN details saved in them by the phone network, when you enable tethering they switch over to using this second APN for all tethered traffic, while using the normal APN for traffic originating on the phone. However I haven't found any concrete evidence of this, other than people finding odd APNs and wondering what they're for (bear in mind that an unlocked phone bought off-contract may have hundreds or thousands of APNs stored on it, ready for use on whichever network in whichever country the eventual owner decides to use it).

Inspecting the network packets for their TTL (time to live)

Every network packet travelling across a TCP/IP network, like the internet, has a built-in time-to-live (TTL) set on it, so that in case there is a problem with that packet reaching its destination this will stop it travelling around the network forever clogging everything up.

The way this works is that the packet starts with a TTL number (say 128) set on it when it leaves the sending device (your phone, or laptop), and then every time that packet travels through a router of any kind (like your home broadband router, or a router at your ISP or phone company) that router subtracts one from the TTL (which would decrement the TTL to 127 in this example), the next router it travels through will in turn decrement the TTL again, and so on, if the TTL ever reaches zero then the router it's at discards the packet and doesn't transmit it again.

When your phone is tethering it acts like a router so, as the packet passes from your tethered laptop through your phone and onto the phone network, your phone will subtract "1" from the TTL to show that the packet has passed through its first router. The phone networks know what the expected TTLs from common devices are (for instance packets from an iPhone always start at a TTL of 64), and so they can spot when they're one less (or totally different) than they're expecting.

MAC address inspection

Devices on a TCP/IP network, like the internet, all have a unique MAC ID set on their network interfaces. This is made up of two halves, one half identifying the manufacturer of the interface, and the other half being a unique identifier assigned by the manufacturer (like a serial number). Every network packet that is sent out will have been "stamped" with the MAC address of the originating device's network port. The MAC address of your laptop's wifi card will have a very different manufacturer and serial code than the MAC address of your phone's 3G interface.

TCP/IP Stack Fingerprinting

Different computer Operating Systems (eg Android, iOS, Windows, Mac OSX, Linux, etc) set up their TCP/IP stacks with different default values and settings (eg the Initial Packet Size, Initial TTL, Window Size...). The combination of these values can give a "fingerprint" that can be used to identify what operating system is running on the originating device. A side-effect of this may mean that if you're using an uncommon OS, or an OS that's similar to your phone's on your other device, your tethering may not be spotted.

Looking at the Destination IP/URL

You can learn a lot by what a device regularly communicates with.

For instance, many OSs these days do Captive Portal Detection when they first connect to a wifi network (such as your wifi tether connection), they do this by trying to connect to a known web server across the internet, and checking to see if they get the response that they're expecting. If the expected response is not received, then it's likely that the wifi connection you're on is a "captive portal" and may need you to log in, or pay, to connect to it. As Microsoft OSs (like Windows Vista and Windows 7 check with a Microsoft server by default and other OSs like Android, MacOS and so on all connect to their parent company's servers to do these checks, it can be used as a good indication of the operating system just after the initial connection is made.

Additionally, if a device regularly contacts the Windows Update servers, then it's very likely that device is a Windows PC or laptop, whereas if it regularly checks with Google's Android update servers, then it's probably a phone. Or if they can see that you're connecting to the Apple App Store, but the IMEI of the device that your SIM card is in indicates that it's not an Apple device, maybe you're tethering an iPad to an Android phone?

More sophisticated systems can look at a whole range of data seeing who you're communicating with (eg are you connecting to the Facebook app's API servers which is more likely from a phone, or to Facebook's web servers which is more likely from a PC) and add a whole load of these indicators together to create a fingerprint that indicates what sort of device you're likely to be using. Some of these fingerprints can be caught out when new device types and services come out, for instance there are reports that just after tablets with built-in 3G came out, some owners of these on the AT&T network received mails warning them that they'd been tethering when they hadn't, as the fingerprint from this new style of device didn't look like a typical phone.


(1) Obviously before trying any methods to by-pass tethering detection please remember to check your phone contract and your phone company's policies on tethering. They may have penalty clauses buried in their contract, Fair Use Policy, or Acceptable Use Policy for people who try to bypass their restrictions and limits.

6
  • 1
    Awesome answer! I also contacted Más Móvil again, and this time the customer support representative said that all tariffs and options may be used with tethering. So I booked a very good offer and, yes, tethering with my Android 2.3 phone (via USB) does work without problems. Perhaps the next time I'm in France, I'll try playing with the TTL, to see if that allows me to bypass Orange.
    – feklee
    Commented Jul 3, 2013 at 16:35
  • 5
    thanks for the very knowledgeable and insightful answer. i only want to object to the MAC inspection section. if you're using your phone as a router (as in for tethering your outward internet connection) your clients' MAC addresses are not at all transmitted to the provider, as per the definition of IP routing. they are replaced by the MAC of the phone which is what the operator expects.
    – user39754
    Commented Aug 20, 2013 at 18:27
  • I suspect this is what is happening with my cell. Ever since I "upgraded" to 5.1 tethering with tmo doesn't work. Even when I use https (which would mask the user agent, which is how they used to do it). How can I tell if my phone is in cahoots with my provider? Commented Jul 24, 2015 at 22:10
  • 6
    A note on your MAC address point: Tethering is just NAT (well, it can be that simple). As such, a internal(ip:port) <-> externa(ip:port) mapping must be managed by the NAT device but other than that, the actual IP payload is the only thing needed. Infact, if you somehow identified on your internet interface by the tethered devices MAC it would never route. Not sure how/why the internal devices MAC can/would/should be exposed. Commented Jul 24, 2015 at 22:29
  • I have a family plan with tethering. Taking the sim card out of my iPad (which has tethering) and putting it into a rooted HTC one allowed tethering just fine. However, stock android says that I do not have tethering on my plan. Is there a non-root way to get around this?
    – Drew
    Commented Oct 1, 2015 at 21:20
5
votes

In reality Mobile Network Internet Providers predominantly use Deep Package Inspection with URI fingerprinting to detect tethering. It is the only method that is feasible to use for large scale operation. They can use known sites, e.g. the Windows update server, to detect that it is a non-phone device that is accessing. Or for HTTP, read web browser user agent to detect that the browser is for a non-phone platform.

Having said this, these methods have some significant limitations.

  • Timing offset from start of use until detection can take minutes
  • Detection can be neutralised by using end-user encryption
  • Using all possible fingerprinting techniques often result in triggering false positives

So the reality is that tethering detection is a balancing act from an operator perspective. They typically only implement enough to be able to block regular, non-geek users (which constitute the wast majority of mobile users). Deploying tighter detection to block tech savvy users is typically not worth the effort, and may backfire by generating too many false-positive events. As long as they get paid for used data, they will look the other way.

They rather concentrate their effort on hackers and blocking revenue leakage due to network exploits.

2
votes

The simplest method is TTL inspection. If you route your connection to the second device (via mobile wifi hotspot or in any other way feasible), the phone company's routers will spot that some TTL values are different from the others when packets pass them. Since there are tables of expected initial TTL values available for many devices (their operating systems, more specifically), phone company will immediately spot that something is amiss, as they can easily calculate "how far away" is the source of the packet. It DOES NOT require deep packet inspection, since TTL values are available for all to see, in any kind of IP packet, and are actually MODIFIED by routers (decreased by 1 at each pass) as the packet is passed to the destination. The workaround is therefore quite simple.

1
  • Could you link some sources? BTW, +1 for a researched answer. Commented Nov 26, 2015 at 13:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .