Free Internet, New Style: How and Why I Used Data for Free While Roaming

About a year ago, I published an article in “Hacker” about how pre-billing systems work for mobile operators. This time, I want to share a real-life story that demonstrates a weak spot in these systems and their potential (and in my case, very real) vulnerability.

As you know, no code is perfect. All programs are made by people, and no one can predict every possible outcome in every situation. Sometimes, especially in complex systems, this opens up completely unexpected opportunities. This is a story about one such case.

Back in 2014, I was in China and used my phone in roaming. To access the internet, I bought a local SIM card. When I returned home to Russia, I forgot to remove the SIM from my tablet and kept using it. As long as there was money on it, it worked perfectly abroad, even though the APN (Access Point Name) was set to the Chinese operator. This is totally normal: when roaming, a guest subscriber isn’t required to manually change the APN all the time.

A month went by, and the tablet with the Chinese SIM kept working in Russia. I got curious—why wasn’t the balance changing, especially while roaming? Another burning question: could this situation be reproduced? Luckily, I had everything I needed to investigate.

Who Provides Internet While Roaming?

Generally, when you travel to another country with your mobile phone and roaming is enabled, the following process takes place:

1. After turning on your phone, the guest operator’s equipment performs a GPRS Attach procedure (or, in reverse, a detach).
2. Your phone starts communicating with the guest operator’s packet network.
3. Your IMSI, KSI (Key Set Identifier), and available services are checked.

If we simplify the interaction scheme for a mobile phone using the internet while roaming, it looks like this:

• GRX (Global Roaming Exchange): A network created by mobile operators to transmit packet data for roaming subscribers.
• SGSN (Serving GPRS Support Node): The main equipment that provides data transmission functions, similar to a switch (MSC) in a mobile network.
• GGSN (GPRS Gateway Support Node): A router that connects mobile subscribers to the “outside world” and provides actual internet access.
• GTP (GPRS Tunneling Protocol): Protocols for tunneling and managing packet traffic in the mobile network.

When roaming, you’re physically served by the guest operator’s equipment. The settings on this equipment can (and likely will) differ from your home operator’s settings.

This scheme is greatly simplified and is just to help understand the main components. A more detailed logical diagram would look a bit different.

How Is Internet Traffic Billed While Roaming?

There are two possible scenarios:

1. Billing is done directly (CAMEL-roaming) through the home operator’s billing system based on data from the equipment via evaluation files.
2. Billing is based on evaluation files received from the roaming operator along with other records (voice, SMS).

In the second case, evaluation files can be transferred between operators with significant delays. Usually, clearing centers of mobile operators are involved, which receive data about their roaming users and pass on data about guests. Typically, all data between operators is sent in a single stream—internet traffic, SMS, voice—sometimes all in the same CDR files.

I won’t go into detail about how GRX networks work. They have many vulnerabilities, which are well documented online. If you’re interested, look them up. I’ll just say that the whole system is built and operates based on standards, mostly set by the 3GPP consortium. And it’s precisely because of standardization that problems and vulnerabilities arise. Any deviation from the standard—whether in equipment or software settings—can confuse the system.

How Did This Happen and Who’s to Blame?

Back to my story with the “endless” Chinese SIM. If I hadn’t worked at a company that processes mobile traffic, I probably wouldn’t have noticed anything (and even if I had, I wouldn’t have bothered investigating).

When I checked the settings, I noticed the APN entry looked like this: “ internet” — with a space at the beginning. I decided to check the standard for valid APN values and saw that spaces are not allowed.

Since the operator where the SIM was roaming was my employer, I could dig deeper. I checked the SGSN equipment logs to see the hexadecimal representation of this entry. The APN value was “ 20696e7465726e6574”. That’s the word “internet,” but the leading space is just a space—it’s not encoded in any special way.

Next, I checked what happens in pre-billing when such a record comes in. Unsurprisingly, it causes an error:

11:14:27.120 MSK main (TLVParser) DEBUG4: TLVParser.callback(): received node 78.7[5]
11:14:27.120 MSK main (TLVParser) DEBUG3: TLVParser.callback(): calling parselet[5] with node [78.7[5]] : [20696e7465726e6574]
11:14:27.120 MSK main (APNStringParselet) : APNStringParselet.parse()
11:14:27.121 MSK main (StreamSource) : StreamSource.byteRead()
11:14:27.122 main ERROR: Error in decoding an attribute APN Value = 20696E7465726E6574, Node TagPath = 78.7[5], Matching TagPath = 78.7[*], Bad length in the APN string at index 21 : 20696E7465726E6574.

As a result, this record is simply discarded as erroneous in pre-billing, and the operator forgets about it. SGSN and GGSN equipment should filter out such subscribers, but they’re not required to. So, clients with incorrectly set APNs are allowed onto the network and can use data services.

The standard doesn’t specify at which level such filtering should occur, nor how to replace or correct an invalid APN. This leads to confusion about how equipment should be configured.

Ideally, if the equipment were set up according to the standard, a guest subscriber wouldn’t be able to use the internet in the guest network. But in practice, default settings often allow deviations from the standard. In any case, the error occurred at the pre-billing stage, before the record was sent to the subscriber’s home operator (in this case, China).

This raises a tricky question: should such records be passed to clearing to be sent to the home operator? Is it right to modify them to fit the standard? Usually, in these cases, the home operator files a complaint against the guest operator for sending incorrect data. In nine out of ten cases, these will cause the same error on their end.

In reality, it’s simpler. Since the flow of such records from roaming subscribers is very small, they’re just discarded, and no one wants to deal with it. Staff already have enough headaches without Chinese roaming issues.

As a result, the home operator receives nothing and charges nothing, while the subscriber happily uses the internet in the guest operator’s network for free.

Is That All?

Actually, that’s not all. Such exceptions happen often and with different types of traffic. It all depends on the volume of these records. If loss detection systems (like FMS-RLC, etc.) can’t spot these issues in the overall traffic flow because they’re negligible, these “tricks” go unnoticed and no one cares.

In another similar case, I once found SMS records where the recipient’s number ended with some hieroglyphs. Somehow, they were still delivered, and the sender wasn’t charged. Apparently, the equipment ignored the extra characters on both ends, and billing threw an error.

I’m not encouraging you to try to repeat my experience. First, this happened a long time ago and the vulnerability has already been fixed. Second, with a slightly different set of circumstances, the method won’t work. And it would be especially unpleasant to find out after you’ve racked up a lot of roaming data. Also, prolonged or mass use would likely force the operator’s staff to change the settings.

The real moral of this story is different. We’ve seen how easy it is to trigger an error in the pre-billing and billing systems of a mobile operator. You can initiate a call, send SMS, MMS, USSD, and transmit data not covered by the standard, but which still passes through the operator’s equipment. And the longer the chain (in this case, guest operator → their pre-billing → clearing → home operator), the more likely records will be marked as erroneous and lost in the general flow.