Good morning, everyone. Yeah, my name is Adrian Dabrowski, my colleague Gabriel Dabrowski.
This is work together with Wilfred Meyer and Edgar Weipel. We will be talking about decoupling the
SIM card from the mobile phone or the modem to get all kinds of fancy measurements. And it's
called cellular carriers hate district. I will explain it why. Using SIM tunnels to travel at
light speed. So for the motivational example, let's assume we have like three medieval city
states and they recently invested into technology and so they switched from land line to
wireless to cellular networks and we have like all this new mobile phone operators popping
up like night mobile or after and Excalibur with the sword in there and dragon phone and all the
others. And with that, we also had like an explosion of new social networks. And we have
something like royal tweet and bar board and peasant post. And all these people are like super
hooked on social networks. So the mobile phone operators think, well, how do we do this? How do we
target some demographics that are like social networks? So they come up with this new data
plans where there is something already included like video streaming or messaging or social
network apps. And we have like it's super transformative. It's very addictive. You have all
these people spending hours and hours on end on the social networks. And I heard the king over there,
got actually so much hooked on it, he's considering buying royal tweet and renaming it to the
Roman numeral of 10. And so this is Archibald. He recently switched from Alchemy to cellular
network research. And he also likes has a few friends abroad. And he also already found a few
new inconsistencies and maybe vulnerabilities in his local network. But he is a prisoner of his
own city-state. Well, when he can travel, he can like do the measurements abroad in another
network. But also when he's visiting his friends, he actually would like to spend time with
the friends. And also it's getting very expensive. So why is roaming so complex or why is it so
interesting? The interesting thing with roaming is that you have your home network operator on
one side and your visiting mobile network operator that's using some interconnection in between.
Pretend to you as the customer that they're providing a singular set of services. And a consistent
set of services. Although they're using completely different configurations, hardware, software,
manufacturers, whatnot. And so at a closer look, we see that this picture of a consistent service
pretty fast falls apart. And you might wonder, well, when I'm abroad, how is my traffic actually
routed? And there are two ways. You can have either local breakout or you can have home routing.
Interestingly, depending on the service that you're using, you can have home routing or you can have local
breakout. So if you're using, it will either use one or the other. So, for example, if you're using
data, that's usually home routed. So even if you're abroad, all your data will exit with an IP address
of your home network operator. So you can't use all the fancy geo-locked services in another country.
Unless you connect to the Wi-Fi. For other services, like voice, you have local breakout. So if you're
using, for example, back in the 1980s, when GSM was specified, or even today, voice is considered
as a time-critical service. So you like to get it out into the public networks as fast as possible
with a route as short as possible. So technically, for example, voice roaming works by the visiting network operator
issuing you a temporary phone number in that country that you're visiting, and your home network operator
then reroutes all the incoming calls to this new temporary phone number. So you have all the small differences
in roaming. And so, while ArchDribbble likes to travel, it's getting very expensive, and all this testing
can be quite tedious.
So let's look at an example. So whoever travels internationally for DEF CON might have received that
SMS. That's because AT&T doesn't support voice roaming for most European carriers. However, it does
support data and SMS. So you might even get billed for voice traffic while in the U.S. without being
able to use voice. And so you have all the small oddities, and let's see, can we measure that in our
toy example? So let's take one SIM card. We have, like, one home operator plus three network operators
in one other city state and in the other. However, that's just one SIM card. Of course, there are
multiple carriers within our home network. So you can see that there are multiple carriers within our home
country. So we'll have to buy multiple SIM cards. But there are also more than one data plan, which might
be important because they support different services. So we'll have to multiply by that. But then, of
course, you have all the network operators in the other city states as well, and we end up, like, just in
our toy example, with 190 combinations.
So clearly, that doesn't scale well. And what are the possibilities here for Archibald to continue his work?
Well, he could buy a lot of SIM cards and a lot of modems and position them everywhere, well, in the
three countries. But, well, the hardware costs, the monthly costs, and soon after that, a bankruptcy.
So that doesn't work.
Well, you could have, like, one modem.
One modem in each country and then ship SIM cards around. But that has, like, large overhead and the shipping times
and a lot of manual labor. Or what we did is try to decouple the SIM card from the modem. So usually the SIM card
and the modem are, like, one unit. And they communicate with each other. But what if we can extend this internal bus
all around the globe?
And so that's what Mobile Atlas does. The academic name is Geographically Decoupling Cellular Measurements and
Exploitation. And with that, we can now, like, solid state travel. We can connect SIM cards to different places
all around, to our modems all around the world, and pretend to the network operators that we are in that country
and do our measurements there.
And tests.
So what were our goals with the project?
Well, of course, scalability, automatability, but also an important point is control the background noise.
If you use, like, an off-the-shelf cellular phone, then you have, like, a full-blown operating system on it with all kinds of
background tasks.
And that might interfere with the measurements you are doing or with the exploits you are testing, depending on what
you are precisely doing.
And we also would like to have, like, the full feature spectrum.
So for those who know RIPE Atlas, so our name, Mobile Atlas, basically is an homage to RIPE Atlas.
RIPE Atlas is a probe system developed and maintained by the European Internet authorities or administration.
And they have, like, the probes.
And you can do pings and trace routes between different autonomous systems.
However, in a cellular world, we have more than just an Internet or data connection.
We also have, like, phone calls.
We have USSDs.
We have text messaging.
So we would like to ideally to test or have a test system that works on all these features.
So here, short diagram.
Traditional combinatorial explanation.
You have an explosion.
You put in probes in different countries and replicate all the SIM cards.
Or you have something where it can tunnel the SIM cards to one place and save a lot of costs.
So basically that's what we did.
We decoupled the SIM card.
We can have a SIM card reader connected to a computer.
And we have done a TCP tunnel to our measurement probes and replicate the SIM card there.
And so, like, at a management on top of it, and you end up with a system, like, on the left side, you have the probes.
On the right, you have the SIM cards.
And you have a SIM provider, which is basically just a piece of software that connects to a PCSC or serial or even an Android phone and routes the SIM card traffic to the probes.
It needs to be an online connection because the SIM cards produce all the cryptographic material.
It needs to be an online connection because the SIM cards produce all the cryptographic material that we need on the network side to authenticate and to encrypt the traffic there.
So this has been a project for ongoing for five years now.
So we have, like, you can see our left probe, which looks very crude.
So we put in, we had, like, a Raspberry Pi and a USB adapter and then an M2 modem attached to this adapter.
And because everything was very loose in the box, we put in a USB adapter.
And because everything was very loose in the box, we put in, like, this yellow piece of foam in there to, like, hold everything in place.
And because everything was very loose in the box, we put in, like, this yellow piece of foam in there to, like, hold everything in place.
And because everything was very loose in the box, we put in, like, this yellow piece of foam in there to, like, hold everything in place.
And because everything was very loose in the box, we put in, like, this yellow piece of foam in there to, like, hold everything in place.
And because everything was very loose in the box, we put in, like, this yellow piece of foam in there to, like, hold everything in place.
And because everything was very loose in the box, we put in, like, this yellow piece of foam in there to, like, hold everything in place.
all the usual SIM card readers, you can use the more expensive PCSC readers or the very
cheap Chinese SIM readers that only speak a very crude serial protocol or you can even
use Android phone. Oh, we didn't have the picture. Okay. Maybe it's later in our slides.
So I briefly want to talk about the challenges that we face and like have to pick like two because
of time. So let's talk about the SIM interface and the SIM protocol. The SIM card protocol is
basically a smart card protocol but it's now 40 years old. So you have a lot of different options,
voltages, speeds and all of that. So the SIM card protocol is basically a smart card protocol but
kinds of that and also it was designed to be to work within one device so with
very low latencies when we stretch that over half of the globe we need a few
techniques to cope with the latency so you can see for example this is how we
connected it to the GP with a sim slot of the modem to the GPIO pins of the
Raspberry Pi we just made a very small simple adapter that we slot in our first
version was actually directly soldered in and you can see just one component on
it and that's a short kid yield why is that because the SIM card I open is
actually an open collector bus so on the Raspberry Pi side we need a short
kiti out to split up the send and receive channels
so on the Raspberry Pi side we need a short kiti out to split up the send and receive channels
for the UART. And the pull up resistor is already provided by the modem. Luckily for us, this
reduces a lot of complexity for us. We can negotiate speeds and voltages and other parameters
independently on the SIM provider side and on the modem side. We don't have to pass it one on
one. So that eases much of the problems. We can also add waiting time extensions and we tested
it for latencies up to 1,000 milliseconds. So this should actually be good enough even for, like,
Starlink connections. And future work we would like to also locally emulate some of the files
that are not necessary for the modem or for the measurements to work. So that's something we
can do. The second problem that I'd like to mention is traffic metering. And we need a way to
control the background traffic. So let's step back. So some of the tests we want to do is test the
accounting, the data accounting of network operators. So we need very precise measurements on
what we are sending to the network and what is then accounted. And so the background traffic is
something that will mess up with these measurements. And the other thing is that the call data
records often are shown on the operator website with a large delay. So domestically this can be, like,
hours. But internationally this can be something around days. And also there is no, like,
standardized way to check your account balance. So some operators use an app or web application that
is not licensed. And some can use or support USSD codes or SMS inquiries. So to eliminate
background traffic, we basically use Linux network spaces. That's the same thing that Docker does.
So our measurement process is put into a separate namespace that's then connected to the modem. And
and only that one talks to the modem.
So all the traffic from that process groups
is routed through the modem and all the other things
like the management suite is all over the VPN.
They're completely separated.
How do we deal with delayed traffic accounting?
Well, we came up with a binary encoding.
So what we do is like, for example,
the first test is what, like one megabyte in size,
the second test is two megabytes,
the third one is four, and the fourth test is eight,
and so on.
So one of these also will be a control group
so that at the end, like maybe a day later
when it finally shows up on the accounting balance,
we can then distinguish exactly which test was accounted
and which wasn't, like which traffic group.
You might ask, well, you do all this thing
to like tunnel physical SIM cards across the globe.
What's about eSIMs?
The problem with eSIMs, even though, for example,
in the US, they're pretty prevalent,
they are not widely available everywhere,
and also it usually tends to only cover some data plans
and not all, and they're not always easy transferable
between devices.
So what we actually can do is we can use Bluetooth R-Sub
protocol to connect to an Android phone that then shares
the SIM card over Bluetooth to our system.
The SIM access profile was actually delivered,
I think, or developed somewhere in the 90s
to allow cars to connect to your phone
and then use the SIM card on your phone,
and the modem from the car.
But today, this is rarely actually used.
So the only thing you need to do on an Android
is make the eSIM your primary SIM card,
and then you get the screen and you allow the usage.
In the title, we said carriers hate this trick.
That might be a little bit controversial.
Why do we think carriers hate this trick?
Well, SIM tunneling isn't exactly new.
It has already been used for over-the-top bypass fraud.
So that's when you use batteries of SIMs or SIM banks
to terminate international travel
or international calls within a country
because usually local call rates are cheaper
than international interconnect fees.
However, we do actually the opposite.
We are tunneling from domestic to abroad
to test all the other networks.
So this might also hint why this might be an opportunity
for carriers to have such a system
because nowadays, carriers have to rely
on their roaming partners to deliver the services
the way that they want it for their customers.
But with a system like this,
the carriers can actually verify the services
and especially things like voiceover LTE roaming,
which lacks a good auto-configuration protocol
and it causes a lot of troubles internationally.
This might actually help to test
the different configurations.
So what have we learned during the implementation
of our system?
There are a few, well, some surprising results.
First, if you read almost any book on cellular networks,
they will basically say something among the lines
that the IMSI is basically the unique identifier
of a SIM card and that they're also used
to find your home operator and stuff like that.
However, even in our small tests,
we found several examples of SIM cards
that can actually update the IMSI over the air
or change it dynamically.
This is usually used for selecting a roaming network,
so it's not like you're not selecting the network
that you're using as a visitor, you're selecting someone
that will then, that has all the contracts in place
with all the operators in the different country
so that they have just one, like, one place
to do their accounting and to work with.
Another thing that we've learned is that
theoretically there is a 127 device limit on USB,
but practically it's hard to get over 20 or 30.
That has to do with like, five, six, seven, eight, seven,
lousy hardware, weak drivers, the power consumption, even if you use active hubs.
And we've tried several things.
Here are the pictures.
So like on the left you can see like we bought like a box of 100 SIM card readers on AliExpress.
And then we tried to run them like naively on all the single USB hubs that turned out
to be very error prone.
And then we also tried this professional USB hubs that are used by or have been used by
miners for like this USB FPGA boards.
But this also didn't work well.
Where do we stand today?
So now our system is deployed to ten European countries and two North American.
You can see Canada.
Canada isn't fully covered.
That has to do with that in Canada not all the bare metal operators are available in
all the provinces.
Our current probe in Canada is in the Yukon territory.
So that's why it's just half green.
Ethical considerations.
So there are some ethical considerations we have to talk about.
You might, for example, ask why don't.
Why do we use modems and don't use software defined radios?
I mean, on the one side, software defined radios give you much more capabilities on
the radio side.
On the other side, all the open source implementations usually only focus on one access technology.
So you can get like a GSM implementation or you can get an LTE implementation.
But you cannot get like one implementation that covers all the access technologies.
And the other thing is that it's.
A regulatory minefield.
So we give out or so far we gave out these probes to friends and family in different
countries.
And we cannot like subject them to the risk of having a software defined radio and all
the radio regulatory problems that might come with that.
So we rather opt for unmodified globally certified modems.
That are safe to use in all the countries.
The second thing that I want to mention is we do not enrich ourselves with our tests.
For example, with the traffic accounting tests.
So we made sure that at the end of the month we let expire at least that amount of traffic
that wasn't accounted in our tests.
And with that.
I'll switch over to Gabriel who will talk about the results and what you can actually
do with our system.
Yeah.
Thank you.
So I would say let the games begin.
So let's take a look at what we can do with this fancy platform.
I'll walk you through a few showcases.
Of course our platform has very versatile capabilities.
But the first one will be an internet related measurement case.
So it will be about zero rating measurements.
It will be billing measurements.
And also after presenting the measurements, we will show some proof of concept how you
could abuse this zero rating offers or how an attacker could abuse this to gain some
free internet traffic.
So what is zero rating?
Actually there are some providers that offers this kind of programs and offers.
Usually it's the same thing.
Usually they provide several groups for applications.
So in this screen shot example, there is a group for messaging application, for social
media applications and also for video.
So for example for Netflix.
And yeah.
They offer this.
The customers can buy a package and then they can gain by buying this package they gain
unmeted access to this kind of applications.
Of course from a carrier perspective.
This data traffic, all the data traffic that passes the provider needs to be classified.
So they need to be, it needs to be separated and needs to be classified into bill traffic
and also zero rating traffic.
And let's take a look at which possibilities there are for the cellular carrier.
So which metrics could be used for the classification.
A very old metric.
A metric that has been used back in the days to classify and to then block BitTorrent
traffic was the TCP or UDP port.
Nowadays it's mainly used in conjunction with some other metrics.
Because it's kind of vague.
Most of the traffic anyway is web traffic.
So it might be using port four for free.
And yeah.
You could easily like fake this port.
There by it's not that reliable.
However the IP address.
Is kind of accurate.
Especially for all those big services like WhatsApp.
Usually the IP address of the services is pretty static.
So it's a reliable classification metric.
Some provider might use some cloud hosting.
So some applications.
But yeah.
Usually if it's a big application it's pretty stable.
So it's a good classification metric.
Also some operators use the packet inspection.
So this is.
When the.
The classification mechanism doesn't only look at the packet header.
But also at the content of the packets.
So the classifier needs to be protocol aware.
It needs to understand what the fields of the protocol mean.
And yeah.
This is also commonly used.
Also for our measurements we focused on IP address.
And on the packet inspection classification.
So.
For the packet inspection we mainly focused on host name based classification.
But also there are some other metrics.
So some operators for example classify by the time to live.
To detect or to block mobile hotspots.
And since this is kind of popular.
With any problem.
There are also some people throwing machine learning at it.
Yeah let's take a look for the packet inspection.
So this packet inspection.
So this is an example.
For host name based classification.
If the traffic is just HTTP free.
It's pretty straight forward.
Because we do not have any encryption.
So the classifier can simply take a look at the host header of the protocol.
If it's an encrypted connection.
Like HTTPS or HTTP free.
The classifier actually has to take a look at the TLS handshake.
And thereby take a look at the client hello message.
That contains the server name.
Indication.
But yeah.
It's again pretty similar.
So just the host name is extracted.
And thereby the traffic is classified.
Within our study we've bought some SIM cards.
We've measured seven operators of three different countries.
And within those SIM cards we've analyzed the available applications.
Your rating applications.
And we figured that WhatsApp, Snapchat and Facebook.
And Facebook Messenger were the most popular applications.
And like any Android or iOS application.
They are heavily communicating via web APIs.
Via web endpoints.
We got some traffic dumps from those applications.
And also reverse engineered the applications.
And yeah.
We found some endpoints that we could use for our measurements.
So to probe this kind of web servers.
And for the selected web endpoints.
We found.
That they support HTTP, HTTPS and HTTP free.
And also they are hosted by a dual stack.
So you could communicate to them via IPv4 or IPv6.
Yeah.
We've had two measurement campaigns.
And yeah.
We've measured.
We've executed measurements in the domestic case.
But also during roaming conditions.
Basic methodology for this kind of seed rating measurements.
Was to get the credits.
Then to execute some experiments.
And then wait for the data to be built.
And again.
Yeah.
Get the credit.
And calculate the delta.
And within the experiment.
We had some payload that was potentially seed rated.
And afterwards.
As Adrian already explained.
We also had some control traffic.
That was acting as a marker.
So we knew when all the data units were built.
And for the seed rating experiments.
We had three experiments.
The first one was to verify that the web endpoints that we selected are actually zero rated.
And the other two were to kind of learn more about the classification.
So to detect IP based or host name based classification methods.
So this is a chart for the very first experiment.
We have our mobile Atlas measurement probe on the left side.
And we have some web endpoints on the right side.
So in this case.
We are probing WhatsApp.
So we are just repeatedly querying or retrieving some web endpoints.
Until our specified data units were retrieved.
And afterwards.
We do the same with some control traffic.
That usually is bigger.
And when the control traffic is built.
We know that the experiment is finished.
And we can say.
Whether the first traffic was subtracted from our data quota or whether or not.
To detect IP based classification.
The test case was pretty similar.
So the actors didn't change.
But we just spoofed the host header.
So the data packets were still going to the WhatsApp web server.
But the host header didn't match the WhatsApp endpoint anymore.
And so if for this case.
The packets still were zero rated.
We knew that most probably some IP based classification is in place.
And we did a similar thing to detect host name based classification.
But we needed to introduce another actor.
So in this test case.
We automatically spin up an AWS instance.
That just forwards all the necessary ports to the WhatsApp application.
So to the WhatsApp web server.
And thereby.
The host header.
Didn't change.
Because the content of the data packets was exactly the same.
But the IP address changed.
So when the traffic classifier is watching the data packets.
Is inspecting the data packets.
The host header is still WhatsApp.
But the IP address is the IP address of our AWS instance.
And thereby.
If the traffic is still zero rated in this case.
We knew again.
That some host name based classification.
Is used.
So let's come to some results.
As you can see.
We found that operators are using both IP based and host name based classification.
Sometimes they even combine it.
So in these cases.
They zero rated the traffic when either one of the rules applied.
And interestingly for two operators.
Actually we were not able to verify zero rating.
So all the.
Tested.
Packets.
Were fully built.
Although.
This operator.
Promoted.
And sold some zero rating packages to their customers.
We were very surprised by this.
And to make sure that this isn't just a quirk of our measurement methodology.
We also simulated this on our smartphone.
So we just verified it.
We downloaded the Facebook application.
We plugged our SIM cards.
The corresponding SIM cards.
And we again did some measurements.
And we could verify that a huge portion.
So over 90% of the actual application traffic was wrongfully built.
Yeah additionally some operators turned off zero rating during roaming.
So this already was challenged by the national regulators in some countries.
And nevertheless we found some operators still doing this.
Additionally.
We found one operator.
That was billing traffic when the endpoint was retrieved via IPv6.
So when IPv6 was used.
The packets again were wrongfully built.
Similarly for HTTP3.
So when we were accessing the relevant endpoints.
Relevant application via HTTP3.
Again the traffic was fully built.
And interestingly for one operator.
As I showed earlier.
We had two measurement campaigns.
For one operator.
Actually the packets got built in the first period.
But then it got fixed.
And in the second period it was fine.
Yeah.
So Archie is a security researcher.
So he is not only interested in how those things work.
But also how he or how an attacker could exploit this kind of things.
Yeah.
We have two cases.
So the first one.
Is if.
Host name base classification was used.
In this case.
For HTTP.
It's pretty straight forward.
You just would need to write some relaying script.
That takes the host header.
Sometimes the provider during the classification even just uses a simple regex for the host
string.
If HTTPS was used.
It's maybe a little more complex.
But still this is just content of the packet.
So you can spoof that.
You can change that.
And you could maybe.
Like.
Like.
Like.
Implement.
Implement.
Something on the top of open VPN.
And spoof the SNI to to kind of pretend to be.
WhatsApp traffic.
For example.
So this is similar to.
To domain fronting.
This technique.
If it's for TLS connections.
For IP base classification, this is a little more complex.
So you would need to have a server where you could spoof IP addresses.
Also.
Also, it would only work for the downlink because if the client sends some packets to
some Spotify IP or some WhatsApp IP, obviously the packets will just land at Spotify or WhatsApp.
But for the downlink, this is a feasible thing to do.
So you could simply replace the source IP address at your relay point, at your VPN maybe,
and then pretend to be Spotify, and then the packets will be classified as zero-rated packets
and you can get some free internet, or an attacker could do that.
For TCP, it might be a little more complex because we have this connection-based approach
and we have the freeway handshake, but for UDP, this is totally feasible.
And this is what we did.
We had a SIM card with Spotify, with free Spotify.
We had a SIM card with Spotify, with free Spotify.
We set up a VPN with WireGuard on the server where we could spoof the packets.
And then we wrote a kernel module, a kernel extension that rewrites the IP address of the outgoing packets.
And for the provider, these kind of packets look like Spotify.
And we already came up with a nice name for this proof of concept, and I hope you like it as well.
So we called it Spoofify.
Okay, now let's continue with some other showcases.
So the second one is some privacy-related showcase.
It's location tracking with ringback tones.
So what is the ringback tone?
The ringback tone is the tone that you hear when you call somebody
and when you basically wait for them to pick up.
So it's this audio feedback that you get.
The interesting thing is that this is issued by the terminating operator.
So in case of roaming, this is issued by the roaming partner.
And the interesting thing as well is that we have different ringback tones for different regions.
So for example, in the U.S., operators use this dual ringing of 440 and 480 hertz.
And in Europe, most operators use something around 425 hertz.
So for these two cases, you could even hear the difference with your bare ear.
But also we found that within Europe, when operators use very similar settings,
it's totally feasible to...
record this tone and to differentiate between operators.
So I'll show you some examples.
This is from Vodafone in Romania.
We have a peak frequency of 430 hertz.
This is the spectrum.
And also at the left, we see the amplitude.
If we compare it to a German provider, we see that another different frequency is used.
And also the amplitude differs, so it's louder for the German provider.
And if we compare it to another German provider,
we see that the frequency stays the same, but the amplitude changes also.
Like the signal is less clear.
There are some side loops, some...
Yeah.
And we did this for all the available operators.
And then we printed a scatterplot with the amplitude and with the frequency.
And as you see, this is kind of nice scattered, nice divided across the diagram, the figure.
So yeah, you can easily take those two metrics.
And...
And determine the operator that terminated the call.
And yeah, you can use this to kind of find out the country of the person that you just called.
So you just need one test call, and then you know the country where the person is in.
Also, you could, of course, use some other metrics like the overtones I just showed you or some duty cycle.
We also had differences in this.
Or you could also use some other call progress tones to fingerprint.
And this is also interesting from a tech perspective for SIM swapping.
Because you could also use this to find out the responsible home operator.
And then you know, yeah, whom you need to call to swap the SIM card, maybe.
Yeah.
Now let's come to the last showcase.
So this is some proactive SIM communication showcase.
Yeah.
Yeah.
So we have all this SIM communication.
We have full access to the communication, to the payload that is sent between the modem and the SIM card.
And SIM cards are kind of mighty and powerful microcontrollers.
So they can even run some Java.
They can...
There is this instruction set of proactive SIM commands where the SIM basically can take over control and can tell the smartphone what to do.
So the SIM could tell the smartphone to send an SMS message to display some text on the head.
And for the hand...
Since we have all this communication of our measurements, we can analyze it.
And for measured SIM cards, we found two SIM cards that were phoning home.
So that were covertly sending some binary SMS messages.
And this is pretty scary, actually.
Because it happens totally in the background.
The user, the smartphone user doesn't know of it.
Interestingly also we had some cases where this kind of binary SMS also...
built by the operator so during roaming these SMS's were even built. That's
pretty shit from a user perspective. Yeah we tried to analyze the content of this
binary SMS and we found out that there is some information about the user
equipment so for example the EMI but also from the SIM card so ECCC ID and
MC were in there. If you're interested in getting some more insights we've
published two papers so the first one is about seer rating measurements. It's
called Seer Rating One Big Mess and the second one is basically the white paper
of our platform. It was just presented at USNIC's conference some days ago.
So for conclusion Archibald can now like when he's traveling
spend time from the SOC to the ALLC
more times with his friends because for all the measurements, like longitudinal measurements
or export testing and development, he can now use a platform to do this from the comfort
of his home.
We find roaming especially interesting because it's this special case where two operators
with completely different setup have to cooperate and pretend to be one.
We showed you a few use cases.
You find more in our paper from two days ago from Usenik Security about how to hide and
dress up traffic as one of the free services so you don't have to pay for it, how you can
locate other subscribers based on the ringback tone.
We'd like to thank all these institutions like NLNet, University of Vienna, Technical
University of Vienna, SBA Research, CISPA, and SSL Laboratory from UCI for supporting
us over these five years.
You'll find the URL and our contact information up here.
The whole project is open source.
If you are from a country that you think that is interesting to us to host a probe, please
get in contact with us.
We have actually brought some probes here to DEF CON, and yes, thank you a lot.
Thank you for watching.