DEF CON 31 - Using SIM Tunneling to Travel at Light Speed - Adrian Dabrowski, Gabriel Gegenhuber

DEF CON 31 - Using SIM Tunneling to Travel at Light Speed -  Adrian Dabrowski, Gabriel Gegenhuber

Show Video

Good morning, everyone. Yeah, my name  is Adrian Dabrowski. My colleague,   Gabriel Dabrowski. This is work, together  with Wilfried Mayer and Edgar Weippl.   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  

This Trick. I will explain it why. Using  SIM Tunnels to Travel at Light Speed.   For the motivational example, let's  assume we have three medieval city-states,   and they recently invested into technology and  so they switched from landline to wireless,   to cellular networks. And we have all these new  mobile phone operators popping up like KnighT   Mobile or Arthur and Excalibur with the sword  in there and dragonphone, and all the others.   And with that, we also had an explosion of new  social networks and we'll have something like   RoyalTweet and BardBoard and PesantPost. And all  these people are super hooked on social networks,  

so their mobile phone operators think, "Well,  how do we target some demographics that like   social networks?" So they come up with these  new data plans where there is something   already included like video streaming  or messaging or social network apps.   And we have... 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  

that the king over there got actually  so much hooked on it. He's considering   buying RoyalTweet 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 has a few friends abroad and he  also already found a few inconsistencies and   maybe vulnerabilities in his local network, but he  is a bit a prisoner of his own city-state. Well,   when he can travel, he can do the  measurements abroad in another network,   but also when visiting his friends, he actually  would like to spend time with the friends,   and also it's getting very expensive. 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,   or 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, 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 dual-locked services in   another country unless you connect to the Wi-Fi. For other services like voice, you have local   breakout. 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 Archibald likes to   travel, it's getting very expensive, and  all this testing can be quite tedious.   Let's look at an example. So whoever travels  internationally for DEFCON 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 US 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? Let's take one SIM card. We have   one home operator plus three network operators in  other city-state and the other. However, there's   just one SIM card. Of course, there are multiple  carriers within our home network or 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,   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 bankruptcy, so that doesn't work.   Well, you could have one modem in each country  and then ship SIM cards around, but that has   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 MobileAtlas does. The  academic name is Geographically Decoupling   Cellular Measurements and Exploitation. And  with that, we can now solid-state travel. We   can connect SIM cards to different places 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.   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 a off-the-shelf cellular phone,  

then you have a full-blown operating system on  it with all kinds of background tasks that might   interfere with the measurements you are doing  or with the exploits you're testing depending   on what you're precisely doing. And we also  would like to have the full-feature spectrum.   For those who know RIPE Atlas, so our name  Mobile Atlas basically is a homage to RIPE   Atlas. RIPE Atlas is a probe system developed and  maintained by the European internet authorities   or administration and they have 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 phone calls. We   have USSDs. We have text messaging. So  we would like ideally to test or have a   test system that works on all these features. Here, a short diagram. Traditional combinatorial  

explosion. You put in probes in different  countries and replicate all the SIM cards,   or you have something where you can tunnel the  SIM cards to one place and save a lot on costs.   Basically, that's what we did. We decoupled  the SIM cards where 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, at a management on top of it. And   you'll 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 PC/SC 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 that we need on the network side to  authenticate and to encrypt the traffic there.   This has been a project, ongoing for five years  now, so we have... You can see our left probe,   which looks very crude. So we had a Raspberry  Pi and a USB adapter and then a M. 2 modem   attached to this adapter. And because  everything was very loose in the box,  

we put in this yellow piece of foam in there  to hold everything in place. But the current   version looks much more professional.  It's a shield on top of the Raspberry Pi.   And so then the only other thing you need  is an ethernet connection for the uplink.   And so on one side, we have the SIM provider,   which is basically just this piece of software  that works with all the usual SIM provider,   SIM card readers. You can use the more expensive  PC/SC readers or the very cheap Chinese SIM   readers that only speak a very crude serial  protocol, or you can even use an Android phone.   Oh, we didn't have the picture. Or maybe it's  later in our slides. So I briefly want to talk  

about the challenges that we faced, and I have  to pick two because of time. So let's talk about   the SIM interface and the SIM protocol. So 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 kinds of that. And also, it was designed  to work within one device with very low latencies.  

When we stretch that over half of the globe, we  need a few techniques to cope with the latency.   You can see, for example, this is how we connected  it with the 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 Schottky diode. Why is that? Because the SIM  card I/O pin is actually an open collector bus.   So on the Raspberry Pi side, we need a Schottky  diode to split up the send and the receive   channels for the UART. And the pull-up  register 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 a thousand   milliseconds. So this should actually be  good enough even for Starlink connections   and future work. We'd like to also locally  emulate some of the files that are not necessary   for the modem or for the measurements to work. The second problem that I like to mention is   traffic metering. And we need a way to control  the background traffic. Let's step back. So some   of the tests we want to do is test the accounting,  the data counting 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 ours.  But internationally, this can be something around   this. And also, there is no standardized way to  check your account balance, so some operators   use an app or web application. Some can use  or support USSD codes or SMS inquiries.   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 only that one talks to the modem.  So all the traffic from that process group 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 binary  encoding. So what we do is, for example,   the first test is what, 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, maybe a day later when it's  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 tunnel physical SIM   cards across the globe. What about eSIMs?"   The problem with eSIMs, even though for example  in the US, they're pretty relevant. 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 rSAP 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 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 the 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.   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 wanted for the customers.   But with a system like this, the carriers can  actually verify the services and especially things   like Voice over LTE roaming, which lacks good  auto configuration protocol and it causes a lot   of trouble internationally. This might actually  help to test the different configurations.   What have we learned during the implementation of  our system? 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 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 are using as a visitor.  You're selecting someone that has all the   contracts in place with all the operators in  the different country so that they have just one   place to do their accounting and to work with. And the other 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 lousy hardware,  

weak drivers, the power consumption, even  if you use active hubs. And we've tried   several things. Here are the pictures. So on the  left, you can see we bought a box of a hundred SIM   card readers on AliExpress. And then we tried to  run them naively on all the single USB hubs. That   turned out to be very error-prone. And then we  also tried these professional USB hubs that are   used by, or have been used by miners for these  USB FPGA boards, but this also didn't work well.  

Where do we stand today? So now, our system is  deployed to 10 European countries and to North   American. You can see Canada isn't  fully covered. That has to do with,   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 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 a GSM implementation  or you can get an LTE implementation,   but you cannot get 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   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 curating measurements.  It will be billing measurements. And also,   after presenting the measurements, we will show  some proof of concept, how you could abuse these   zero-rating offers or how an attacker could  abuse this to gain some free internet traffic.  

What is zero-rating? Actually, there are some  providers that offers this kind of programs   and offers. Usually, they provide several groups  for applications. So in this screenshot 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 by buying this package, they gain  unmetered 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 it needs to be  separated. It needs to be classified into billed   traffic and also zero-rating traffic. And let's  take a look at which possibilities they have for  

the cellular carrier. Which metrics could be used  for the classification? A very old 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   4 for free. And yeah, you could easily fake  this port. Thereby, 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 service 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 classification  mechanism doesn't only look at packets 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 deep packet inspection classification. For   deep packet inspection, we mainly focus on  hostname-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 at deep packet inspection.   So this is an example for hostname-based  classification. If the traffic is just HTTP3,   it's pretty straightforward because we do not have  any encryption. So the classifier can simply take   a look at host data of the protocol. If it's  an encrypted connection like HTTPS or HTTP3,  

the classifier actually has to take a look  at the TLS handshake and thereby take a look   at the clientele message that contains  the server name indication. But yeah,   it's again pretty similar. So just the hostname 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 available zero-rating  

applications. And we figured that WhatsApp,  Snapchat, and Facebook, and Facebook Messenger   were the most popular applications. Like any  Android or iOS application, they're heavily   communicating via Web APIs via web endpoints. We got some traffic dumps from those applications   and also reverse-engineered applications. And  yeah, we found some endpoints that we could use   of our measurements to probe this kind of web  servers. And for the selected web endpoints,  

we found that they support HTTP, HTTPS, and HTTP3.  And also they are hosted via dual stack so you   could communicate to them via IPv4 or IPv6. Yeah,  we've had two measurement campaigns. And yeah,   we've executed measurements in the domestic  case, but also during roaming conditions.   Our basic methodology for these kind of  zero-rating measurements was to get the   credits then to execute some experiments and  then wait for the data to be built. And again,   get the credit and calculate the delta. Within  the experiment, we had some payload that was   potentially zero-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 zero-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 learn more   about the classification, so to detect IP-based  or hostname-based classification methods.   This is a chart for the very first experiment. We  have our MobileAtlas 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 a 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  hostname-based classification, but we needed to   introduce another actor. In this test case, we  automatically spin up an AWS instance that just  

forwards all the necessary ports to the WhatsApp  application, so through the WhatsApp web server.   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 hostname 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 hostname-based classification is used. Let's come to some results. As you can see, we  

found that operators are using both IP-based and  hostname-based classification. Sometimes they even   combine it. So in this 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 smartphones, so we just verified it.   We downloaded the Facebook application. We plucked  our SIM cards, the corresponding SIM cards,   and we again did some measurements. 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 yeah, nevertheless,  we found some operators still doing this.   Additionally, we found one operator that  was billing traffic when the endpoint was   retrieved by IPv6. So when IPv6 was used, the  packets again were wrongfully built similarly  

for HTTP3. So when we were accessing the relevant  endpoints, the relevant application by 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 billed   in the first period, but then it got fixed,  and in the second period it was fine. Yeah.  

Archie is a security researcher, so he's 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  hostname-based classification was used. In this   case for HTTP, it's pretty straightforward. You  just would need to write some relaying script   that fakes the host data. 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 implement   something on the top of OpenVPN and spoof the  SNI to pretend to be WhatsApp traffic, for   example. So this is similar to domain-fronting,  this technique, if it's for TLS connections.   For IP-based classification, this however is a  little more complex. And so you would need to  

have a server where you could spoof IP addresses.  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 at 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.   Yeah, for TCP, it might be a little more  complex because we have this connection-based   approach and we have the 3-way handshake.  But for UDP, this is totally feasible.   And this is what we did. We had a SIM card with  free Spotify. We set up a VPN with WireGuard on   the server where we could spoof the packets.  And yeah, then we wrote a kernel module,   a kernel extension that rewrites the IP address  of the outgoing packets. And for the provider,   these kinds 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 tone for different regions. So  

for example, in the US 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.   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 that the amplitude differs,   so it's louder for the German provider. And  if we compare to another German provider,   we see that the frequency stays the same, but  the amplitude change. Also, the signal is less   clear. There are some side lobes. 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 nicely scattered, nicely  divided across the diagram, the figure. So   yeah, you can easily take those two metrics and  determine the operator that terminated the call.   Yeah, you can use this to 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 an attacker perspective for SIM swapping   because you could also use this to find out  the responsible home operator and then you know   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.   Since we tell 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.  There is this instruction set of proactive SIM   commands where the SIM basically can take over  control and tell the smartphone what to do. So   the SIM could tell the smartphone to send an SMS  message, to display some text on the handset,   and yeah, since we have all this communication  of our measurements, we can analyze it.   And for measured SIM cards, we found  two SIM cuts 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  smartphone user doesn't know of it. Interestingly,  

also, we had some cases where this kind of  binary SMS were also built by the operator.   So during roaming, these SMSs 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 IMEI but also from the SIM card,   so ICCID and the IMSI, where in there. If you're interested in getting some more  

insights, we've published two papers. So the  first one is about zero-rating measurements,   it's called Zero-Rating One Big Mess. And  the second one is basically the white paper   of our platform. It was just presented  at USENIX Conference some days ago.   For conclusion, Archibald  can now, when he's traveling,   spend more times with his friends because for all  the measurements like longitudinal measurements or   exploit 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.   And we showed you a few use cases. You'll find  more in our paper from two days ago from USENIX   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, and some internals   such as proactive SIM communication. We'd like to thank all these institutions  

like NLnet, University of Vienna, Technical  University of Vienna, SBA Research, CISPA,   and the 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-sourced. 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 DEFCON. And yes, thank you a lot.

2023-09-23 05:08

Show Video

Other news