[00:00.000 --> 00:03.860]  My name is Cooper Quinton, and thank you for coming to my talk,
[00:03.860 --> 00:10.700]  Detecting 4G Base Stations in Real Time. First, a little about me. I am a senior
[00:10.700 --> 00:16.440]  security researcher at the EFF Threat Lab. I have a toddler, so you'll have to forgive
[00:16.440 --> 00:21.620]  the dad jokes and possible baby noises in the background. I'm also a former teenage phone freak.
[00:21.620 --> 00:25.580]  I may have built some boxes to do some nefarious things back in the day,
[00:25.580 --> 00:28.480]  which might explain why I got into the work that I do now.
[00:30.000 --> 00:34.440]  If you're not familiar with EFF, we are a member-supported non-profit.
[00:34.440 --> 00:39.780]  Over half of our annual funding comes from small donations from our members,
[00:39.780 --> 00:44.520]  individual donations, and we defend civil liberties online. So we think that when you get
[00:44.520 --> 00:49.000]  online, your rights come with you, and that when you're using technology, you still have rights,
[00:49.000 --> 00:52.440]  such as freedom of speech and the right to privacy. And we've been doing this work for
[00:52.440 --> 00:58.780]  30 years this year. We started in 1990. So we have a lot of experience under our belt.
[00:58.780 --> 01:02.220]  We've been defending the internet and defending hackers for a long time.
[01:02.820 --> 01:07.280]  I work in the EFF Threat Lab, and I'll talk a little bit more about that in a second.
[01:07.360 --> 01:13.800]  But I want to first introduce my colleague Yamna. She can't be here with me on the DEF CON stage
[01:13.800 --> 01:19.360]  today, but none of this research would have been possible without her hard work. This is as much
[01:19.360 --> 01:25.200]  her project as it is mine, and she is an incredibly smart, incredibly talented person. So if you see
[01:25.200 --> 01:30.600]  her in the virtual halls of DEF CON safe mode, please buy her a virtual beer, or follow her on
[01:30.600 --> 01:36.000]  Twitter. Her name is at RivalElf, and she is a giant, sentient, very excitable radish, so don't
[01:36.000 --> 01:43.060]  be scared when you meet her. This is an actual photo of her. A bit about Threat Lab. We look at
[01:43.060 --> 01:50.300]  technology that targets at-risk people. So by at-risk, I mean people who are at risk of harm
[01:50.300 --> 01:55.240]  just for being who they are, having the beliefs that they do. And this includes activists,
[01:55.240 --> 02:01.340]  human rights defenders, journalists, domestic abuse victims, immigrants, sex workers, minority
[02:01.340 --> 02:08.260]  groups, political dissidents, and so on. Basically anybody who is at risk. So this is the sort of
[02:08.260 --> 02:15.620]  technology that we research and try to get a handle on. And we do this work because even though
[02:15.620 --> 02:21.920]  cybersecurity teams and antivirus companies are doing a good job of what they do, they mostly
[02:21.920 --> 02:26.460]  care about the types of malware that affect their customers, which are usually enterprise customers.
[02:26.460 --> 02:32.740]  And this is things like ransomware, banking Trojans, things that steal sensitive corporate
[02:32.740 --> 02:38.400]  data, things that affect bigger businesses. And we get to care about the types of technology
[02:38.400 --> 02:44.860]  that infringe on civil liberties and human rights of at-risk people. Because these people don't
[02:44.860 --> 02:51.700]  necessarily have the budget to pay a security team. But we also, by virtue of working for a
[02:51.700 --> 02:55.860]  nonprofit, don't have to worry about meeting a bottom line at the end of the day. So we like
[02:55.860 --> 03:00.440]  to think of ourselves as the security team for people who need it most and yet can afford it the
[03:00.440 --> 03:05.720]  least. Our goals in this work are, of course, first and foremost, to protect people. We want
[03:05.720 --> 03:11.640]  to make sure that the people in the communities that we work with are safe and able to express
[03:11.640 --> 03:17.340]  themselves and able to exercise their human rights. We want to broaden the community's
[03:17.340 --> 03:21.920]  understanding of the sorts of threats they face, who the threat actors are, what their capabilities
[03:21.920 --> 03:27.860]  are, and what sorts of technologies they might be facing. And we want them to better understand
[03:27.860 --> 03:32.500]  their defenses as well, how they can protect themselves, in what ways and what sort of
[03:32.500 --> 03:38.420]  measures they might need to take. We want to expose bad actors, such as nation states or
[03:38.420 --> 03:45.340]  companies or cyber mercenaries, that are going after people that are building technology to spy
[03:45.340 --> 03:49.900]  on civilians and violate human rights. And we want to make better laws, because we're a legal
[03:49.900 --> 03:55.000]  nonprofit at the end of the day. We want to make better norms and better laws and better norms in
[03:55.000 --> 04:01.040]  civil society so that these sorts of things don't keep happening again and again. What I want to
[04:01.040 --> 04:07.680]  talk to you about today is cell site simulators, also known as stingrays or MC catchers. I want to
[04:07.680 --> 04:13.000]  talk about how they work, some previous efforts to detect them, and why I think that those efforts
[04:13.000 --> 04:18.660]  aren't so great, and a new method that we've come up with to detect them here at EFF. And also how
[04:18.660 --> 04:25.140]  to fix the problem of cell site simulators once and for all. First, a little bit of terminology.
[04:25.720 --> 04:30.420]  The UE is the phone. It's just the phone. It stands for user equipment, but it's just the
[04:30.420 --> 04:36.120]  phone, the thing you're making the calls on. The MC is the International Mobile Subscriber ID.
[04:36.120 --> 04:42.240]  This is the ID that is burned into the sim card and unique for each sim card. The IMEI is the
[04:42.240 --> 04:47.320]  International Mobile Equipment ID, and this is the unique ID for the hardware that's burned into the
[04:47.320 --> 04:53.120]  hardware and can't be changed. The eNodeB, or the base station, this is what the UE, or user
[04:53.120 --> 04:58.760]  equipment, again, the phone, this is what the UE is actually communicating with. This is the thing
[04:58.760 --> 05:06.920]  that's at the end of the antennas that you're talking to. The EARFCN, or E-A-R-F-C-N, this is
[05:06.920 --> 05:13.640]  the frequency that the UE and eNodeB are communicating on. The sector is a specific
[05:13.640 --> 05:20.240]  antenna that is attached to the base station or eNodeB, and eNodeB can have multiple sectors,
[05:20.240 --> 05:25.080]  and each sector basically is an antenna pointing in a specific direction.
[05:25.760 --> 05:33.080]  The MIM, or master information block, is broadcast by the eNodeB and tells phones where to find the
[05:33.080 --> 05:39.780]  SIB, or system information block, which contains more details about the eNodeB, such as the cell
[05:39.780 --> 05:45.660]  ID, the MCC, MNC, and TAC, which are the mobile country code, the mobile network code, and the
[05:45.660 --> 05:51.540]  tracking area code, respectively. So, finally, I'm going to use the terms MCCatcher, Stingray,
[05:51.540 --> 05:57.240]  Hailstorm, fake base station, and cell site simulator, all kind of interchangeably. These
[05:57.240 --> 06:03.400]  don't mean exactly the same thing. A cell site simulator and a fake base station are fake cell
[06:03.400 --> 06:10.920]  towers. A Stingray and a Hailstorm are two brands of cell site simulator, and MCCatcher is sort of
[06:11.020 --> 06:16.300]  a common term for one of the things that cell site simulators do, although not all MCCatchers
[06:16.300 --> 06:23.220]  are cell sites that fully emulate a cell site. Some MCCatchers can run passively and not actually
[06:23.220 --> 06:28.340]  transmit anything, thus not emulating a cell site. But for our purposes, we're going to use
[06:28.340 --> 06:36.330]  them interchangeably, and that's okay for the purposes of this talk. So, here we have a diagram
[06:36.330 --> 06:42.830]  of the 4G network. This is a pretty high-level diagram, but you can see here that the user
[06:42.830 --> 06:49.050]  equipment, the phone, connects to the eNodeB using the LTVU protocol. Through the uplink,
[06:49.050 --> 06:53.350]  the eNodeBs can talk to each other through another protocol, and the eNodeBs exist in
[06:53.350 --> 07:00.250]  the network called the EUTRAN. And then you have a network called the Enhanced Packet Core,
[07:00.250 --> 07:05.710]  which is behind the eNodeBs, and this contains the MME, or Mobility Management Engine,
[07:05.710 --> 07:10.730]  serving gateway, and the PDN gateway, which connect to the public data network,
[07:10.730 --> 07:17.470]  which connect back to the phone network, and the EPC is also responsible for authenticating
[07:17.470 --> 07:23.570]  user billing, etc. We're not going to focus on the EPC today. There are issues there that we
[07:23.570 --> 07:29.250]  could talk about, but it's out of scope for this talk. We're instead going to focus specifically
[07:29.250 --> 07:34.010]  on the communication between the user equipment and the eNodeB, and that is sort of the area
[07:34.010 --> 07:42.210]  inside of this red circle. So, we started this project because
[07:42.970 --> 07:49.710]  we already knew a lot about the Stingray. Some law enforcement agencies had had the Stingray.
[07:49.710 --> 07:55.310]  The Stingray had been around for a while, and it was pretty well understood how it worked.
[07:55.310 --> 08:00.450]  Kristen Paget did a really great talk at DEF CON several years ago, where she demonstrated
[08:00.450 --> 08:05.350]  building her own homemade Stingray, and it's pretty well understood the vulnerabilities.
[08:05.790 --> 08:09.930]  But what we were noticing was that law enforcement was starting to upgrade
[08:11.410 --> 08:16.450]  their cell-site simulator devices to newer devices, such as the Hailstorm,
[08:16.450 --> 08:23.550]  which purported to be able to operate natively in 4G. And we started wondering, well,
[08:23.550 --> 08:28.590]  we have a pretty good idea of how the Stingray works, but we have no idea of how the Hailstorm
[08:28.590 --> 08:34.010]  and these newer devices operating in 4G, how they might work. So, let's dig into this,
[08:34.010 --> 08:39.210]  and let's start by figuring out how they could possibly work. And the first thing we want to
[08:39.210 --> 08:46.050]  look at is what changed between 2G and 4G. And there are three significant changes that affect
[08:46.050 --> 08:52.870]  the way that a cell-site simulator might work. The first, and most important, is that the
[08:52.870 --> 08:57.750]  eNodeB and the UE in 4G mutually authenticate each other.
[08:59.330 --> 09:07.030]  In 2G, the user equipment or the phone had to authenticate itself to the eNodeB or the
[09:07.030 --> 09:11.890]  base station, but the base station never had to prove that it was a real base station.
[09:12.210 --> 09:16.250]  And this was the source of a lot of fake base station attacks, such as the ones that the
[09:16.250 --> 09:25.590]  Stingray used in 2G. With 4G, this is no longer a problem. Also, in 2G, you had terrible encryption.
[09:26.370 --> 09:31.810]  The base station would dictate to the user equipment what cipher to use, and it could
[09:31.810 --> 09:38.150]  even dictate that the user equipment use a null cipher. What's more, the ciphers that were used
[09:38.150 --> 09:45.050]  by 2G were actually quite weak and could be broken in real-time or near real-time by anybody
[09:45.050 --> 09:51.390]  recording the packets between the base station and the phone, without even having to transmit
[09:51.390 --> 09:58.030]  anything. This is no longer the case in 4G, now that eNodeB and UE mutually agree on what
[09:58.030 --> 10:05.390]  encryption to use, and the ciphers are much, much better. Also, in 2G, the phone would always just
[10:05.390 --> 10:12.410]  connect to the strongest tower that it could see, and in 2G, you could even dictate how strong
[10:12.410 --> 10:18.210]  your signal was, telling the phone to ignore the actual signal strength and just trust what you
[10:18.210 --> 10:23.630]  were saying the signal strength was. Neither of these are the case anymore in 4G. The phone no
[10:23.630 --> 10:27.950]  longer naively connects to the strongest tower. Instead, there are a set of cell selection criteria
[10:28.490 --> 10:34.870]  that it follows. So, great, we've solved all the problems, right? Well, clearly not, because there
[10:34.870 --> 10:41.310]  are still cell site simulators that are operating natively in 4G. So, me and Yamna, set to work
[10:41.310 --> 10:48.250]  reading all of the academic literature that we could about vulnerabilities in 4G, and what
[10:48.250 --> 10:53.410]  could possibly be making cell sites and next generation cell sites and simulators work.
[10:54.190 --> 11:00.870]  And after several months of reading, over a year of reading really, Yamna wrote a really
[11:00.870 --> 11:06.890]  amazing paper called Gotta Catch Em All, which summarizes all of our findings, everything that
[11:06.890 --> 11:13.690]  we learned, about what vulnerabilities next gen CSSs might be taking advantage of.
[11:13.930 --> 11:21.250]  And we really figured out that there's one specific area where 4G is extremely vulnerable.
[11:22.590 --> 11:28.270]  So, 4G has a bit of a glass jaw. Even though the UE authenticates with the tower, or
[11:28.270 --> 11:33.510]  authenticates the tower now, there are still several messages that get sent, received, and
[11:33.510 --> 11:38.850]  trusted, before that authentication ever happens, or without authentication ever happening in the
[11:38.850 --> 11:44.410]  first place. And this is the weak spot in which the vast majority of 4G attacks happen.
[11:44.770 --> 11:49.030]  I'm not going to get into those attacks here today, because Yamna has already done a really
[11:49.030 --> 11:53.950]  excellent job of summarizing those in that paper, and I highly suggest that you go read it. It's an
[11:53.950 --> 12:02.270]  excellent paper. But to give a high level summary, this is the handshake protocol between the user
[12:02.270 --> 12:08.570]  equipment, the phone, again, and the base station. And it starts with the user equipment looking on
[12:08.570 --> 12:13.950]  each ERF SIN, or frequency, for a frame synchronization signal from a base station.
[12:13.950 --> 12:19.290]  Once it finds synchronization signals, it is able to find the MIB, master information block,
[12:19.290 --> 12:24.030]  and decode that, which lets it find the SIN and decode that, which gives it enough information
[12:24.710 --> 12:30.890]  about the mobile country code, the mobile network code, to decide whether it wants to connect,
[12:30.890 --> 12:38.170]  and then send an RRC, radio resource control, RRC connection request. It does that handshake,
[12:38.170 --> 12:44.890]  and then it begins the attach request. And here, in step 7, is where the authentication finally
[12:44.890 --> 12:52.430]  starts. All of the messages before that are never authenticated. And some of the messages that get
[12:52.430 --> 13:00.550]  sent in that area can contain things like the IMSI of the phone, allowing you to uniquely identify it,
[13:00.890 --> 13:05.610]  it can contain even the GPS coordinates of the phone, allowing you to locate it,
[13:05.610 --> 13:09.610]  and a bunch of other things. Attacks that allow you to downgrade it to TeamG,
[13:09.610 --> 13:12.490]  or allow you to kick it off the mobile network entirely.
[13:13.310 --> 13:18.270]  So this is where the heart of all of the vulnerabilities lie at 4G, and this is the
[13:18.270 --> 13:26.450]  part that we find really interesting. So now that we had a pretty good handle on how 4G
[13:26.450 --> 13:33.350]  cell-site simulators are probably being used, we wanted to get an idea of how often they're
[13:33.350 --> 13:39.490]  being used. And if we want to learn how often they're being used by U.S. law enforcement,
[13:39.490 --> 13:47.870]  the best way to do this is to file FOIA requests. ACLU filed a really excellent FOIA request,
[13:47.870 --> 13:55.210]  which came back, which just got published this year, in 2020, about ICE and DHS's use of cell-site
[13:55.210 --> 14:00.890]  simulators. And in it, they discovered that ICE, or U.S. Immigration and Customs Enforcement,
[14:00.890 --> 14:09.770]  used cell-site simulators between 2017 and 2019 a total of 466 times, hundreds of times per year.
[14:10.050 --> 14:18.490]  DHS, on the other hand, used their cell-site simulator 1,885 times between 2013 and 2017.
[14:18.590 --> 14:24.710]  We also found out that Customs and Border Patrol, or CBP, owns 33 cell-site simulators,
[14:24.710 --> 14:28.230]  which is a ton. And we don't know how often they're being used,
[14:28.230 --> 14:32.390]  but we can assume that it's probably on par with ICE and DHS.
[14:33.850 --> 14:41.030]  Oakland, on the other hand, the Oakland PD, Oakland's local police department in California,
[14:41.530 --> 14:48.510]  they used their cell-site simulator, which is a hailstorm, three times in 2017. In 2018,
[14:48.510 --> 14:55.790]  it was used four times, and in 2019, it was used only once. But on the other hand,
[14:55.790 --> 15:01.750]  Santa Barbara PD, the local police department for Santa Barbara, California, used their cell-site
[15:01.750 --> 15:08.590]  simulator 231 times in 2017, roughly matching up with the numbers from ICE and DHS.
[15:08.990 --> 15:13.490]  So, what makes Oakland so much different in this case? Well, we think that it's because
[15:13.490 --> 15:20.890]  Oakland has stronger privacy laws. Oakland has pretty strong regulations about when and where
[15:20.890 --> 15:26.010]  the cell-site simulator can be used, how it can be used, and what sort of reporting, public
[15:26.010 --> 15:32.570]  reporting, needs to happen afterwards. And we think that that has really kept Oakland PD on a
[15:32.570 --> 15:40.110]  leash as far as their use of cell-site simulators is concerned. So, we encourage other communities
[15:40.110 --> 15:45.910]  to come up with similar rules and regulations about how these can be used. But of course,
[15:45.910 --> 15:51.070]  not everybody using a cell-site simulator is going to follow rules and regulations,
[15:51.710 --> 15:57.850]  nor can they be FOIAed. We have pretty good evidence that foreign spies are using cell-site
[15:57.850 --> 16:02.830]  simulators. The Department of Homeland Security put out a report last year where they demonstrated
[16:02.830 --> 16:07.550]  that they found several cell-site simulators around the White House and around Washington,
[16:07.550 --> 16:14.750]  D.C., which almost certainly belong to foreign spies trying to spy on the political class in
[16:14.750 --> 16:21.370]  Washington, D.C. We also have reason to believe that cyber mercenaries such as NSO Group have
[16:21.370 --> 16:27.530]  access to cell-site simulators. A report from Amnesty International that was put out this year
[16:27.530 --> 16:35.810]  in 2020 detailed a campaign against a Moroccan journalist to spy on a Moroccan journalist
[16:35.810 --> 16:42.590]  by NSO Group, where they also use cell-site simulators to intercept his calls. And finally,
[16:42.590 --> 16:48.050]  we think that just straight-up criminals have access to these. There's rumors that drug cartels
[16:48.050 --> 16:53.290]  have access to a cell-site simulator, and it makes sense. Cell-site simulators are pretty
[16:53.290 --> 16:58.150]  easy and pretty cheap to build at this point. And if you don't want to build one, you can acquire
[16:58.150 --> 17:05.630]  them from companies in Israel, companies in Saudi Arabia. They're really pretty ubiquitous and pretty
[17:05.630 --> 17:11.610]  easy to acquire. And of course, these people can't be FOIA. We can't ask them how often they're
[17:11.610 --> 17:18.170]  being used, so we have no idea how often these groups are using these. So that being the case,
[17:18.170 --> 17:24.950]  our next step is we start to think about, okay, how can we detect cell-site simulators?
[17:25.430 --> 17:33.840]  And there are two schools of thought for how to detect cell-site simulators.
[17:35.300 --> 17:43.040]  One is app-based, and this is applications like Aim60 or Android MCCatcher Detector,
[17:43.040 --> 17:49.560]  Snoop Snitch, or Darshark. The strengths of these are that they're cheap. It's an app,
[17:49.560 --> 17:53.980]  you install it on your Android phone, and they're easy to use. You start the app,
[17:53.980 --> 18:00.320]  you let it run, it lets you know if it finds something that's suspicious. All you need is
[18:00.320 --> 18:05.320]  an Android phone. And it might need to be rooted, it might need to be a specific type of phone,
[18:05.320 --> 18:09.760]  but you don't really, as long as you have that phone already, you don't have to spend any further
[18:09.760 --> 18:17.500]  money. The weaknesses of these are that you're going to get very limited data. Aim60 only gives
[18:17.500 --> 18:25.520]  you, on an unrooted phone at least, only gives you the MCC, MNC, and the location and the location
[18:25.520 --> 18:31.460]  area. And some information about the signal strength. Snoop Snitch and Darshark get more
[18:31.460 --> 18:35.180]  info because they're able to read baseband messages on the phones that they support,
[18:35.180 --> 18:42.620]  but still you're only getting the info about cells that your phone is connected to. And
[18:43.220 --> 18:47.960]  you're getting a lot of information about weird things happening, but a lot of those end up being
[18:47.960 --> 18:54.760]  false positives, because many of the things that could be indicators of cell-site simulators
[18:55.520 --> 19:03.780]  are also just weird, these sorts of weird things that happen in the cell network quite often.
[19:04.140 --> 19:08.580]  And because of that, you get a lot of false positives, and it's hard to tell
[19:09.240 --> 19:15.700]  what is actually a cell-site simulator and what is maybe just the cell network being the cell
[19:15.700 --> 19:24.580]  network. The other school of thought is radio-based, and this is basically things where you have a
[19:24.580 --> 19:29.200]  software-defined radio or a cellular modem, and you're getting information about all of the towers
[19:29.200 --> 19:33.700]  around you, and you're putting that in a database and running some heuristics to determine what's
[19:33.700 --> 19:39.200]  suspicious. Projects that are examples of this are Seaglass from the University of Washington,
[19:39.960 --> 19:44.800]  Sitch from Ashwilson, and Overwatch, which is a commercial product. The strengths of these are
[19:44.800 --> 19:49.280]  that you can get better data. You can get data from all of the towers in an area, not just the
[19:49.280 --> 19:55.660]  ones that you're connecting to. You can also get lower-level information. You can get as low-level
[19:55.660 --> 20:02.940]  information as you want based on what you can program with your radio, right? The weaknesses
[20:02.940 --> 20:09.140]  of these are that they're harder to set up. They can be harder to use and interpret because you
[20:09.140 --> 20:14.480]  maybe have to run Linux and set up a server, and you have to put together some hardware,
[20:14.480 --> 20:18.420]  and maybe even have to know a little bit of programming. Also, the weaknesses that you have
[20:18.420 --> 20:22.740]  to buy that hardware, and hardware can be expensive. You might have to spend a couple
[20:22.740 --> 20:27.860]  hundred dollars to get running, whereas the app is free. So there are strengths and weaknesses
[20:27.860 --> 20:36.540]  to both of these. But armed with this knowledge, we started hearing rumors about cell-site
[20:36.540 --> 20:45.120]  simulators being used at the Standing Rock protest, or at the Dakota Access Pipeline protest
[20:45.120 --> 20:53.080]  in Standing Rock, North Dakota. And given that we had some ideas about how maybe one could detect
[20:53.080 --> 20:57.500]  cell-site simulators, and we wanted to know if they were being used at protests, we decided to
[20:57.500 --> 21:03.100]  go down to Standing Rock and see what we could find. So I armed my phone with Snoop Snitch and
[21:03.100 --> 21:09.260]  AimSickD, and I brought along a couple of RTL-SDRs, which I figured I could do some spectrum analysis
[21:09.260 --> 21:17.900]  with, and made my way down to Standing Rock. And what I figured out was that I had no idea
[21:17.900 --> 21:24.620]  what I was doing. And by the way, this dog is, I don't know, our patronus is canceled now?
[21:24.840 --> 21:30.160]  If not, this dog is my patronus. I very much identify with this dog.
[21:30.360 --> 21:36.420]  But we had no idea what we were doing. When we got there, what we realized was there were no
[21:36.420 --> 21:45.220]  2G towers anywhere to be found, whether they be legitimate or illegitimate. And all of our
[21:45.220 --> 21:53.380]  detection methods were focused on detecting 2G towers. If a 2G cell had shown up all of a sudden,
[21:53.380 --> 21:58.720]  that would have been a pretty strong indicator. But we weren't able to find any evidence of 2G
[21:58.720 --> 22:08.140]  cells while we were at Standing Rock. And the conclusion that we came to is that if cell site
[22:08.140 --> 22:13.660]  simulators were being used at Standing Rock, they must be next generation cell site simulators that
[22:13.660 --> 22:21.000]  were operating natively on 4G. Which leaves us with the question, how can we detect 4G-based
[22:21.000 --> 22:27.960]  cell site simulators? And how can we improve on previous attempts to detect cell site simulators?
[22:28.720 --> 22:35.860]  Well, first off, I think that the radio-based method is solid. SeaGlass had already put up
[22:35.860 --> 22:41.660]  some pretty interesting results. And the idea of getting information about all of the cells in an
[22:41.660 --> 22:46.880]  area, everything that's broadcasting, not just the ones that your phone's connecting to, and comparing
[22:46.880 --> 22:53.080]  that data over time, I think are really interesting. So let's add on top of that, looking
[22:53.720 --> 23:01.020]  specifically at 4G transmissions, having heuristics based on what we've learned from
[23:01.020 --> 23:08.160]  mine and Yamna's research, and let's verify the results. When we find a suspicious tower,
[23:08.160 --> 23:15.300]  let's go track it down and see what it actually is. Is it on top of a cell tower? Yeah, great.
[23:15.300 --> 23:20.820]  It's probably fine. Is it on top of a building? Yeah, that's fine. It's probably a small cell.
[23:20.820 --> 23:25.060]  Is that building an embassy? Well, that's a lot more suspicious.
[23:25.460 --> 23:31.320]  And finally, is it in an unmarked van or in a van surrounded by police officers? Well,
[23:31.320 --> 23:37.770]  that's very suspicious. So without further ado, I introduce to you Crocodile Hunter.
[23:38.880 --> 23:44.760]  Crocodile Hunter is an open source project that we've been working on at EFF for the last couple
[23:44.760 --> 23:51.820]  of years and are releasing here at Virtual Black Hat and DEF CON this week. Crocodile Hunter is a
[23:51.820 --> 23:59.320]  hardware and software based. It uses an SDR and the software, the backend is based on SRS-LTE,
[23:59.320 --> 24:05.980]  which is an open source LTE software stack that's able to emulate both the Enhanced Packet Core,
[24:06.600 --> 24:13.880]  the eNodeB, and also the user equipment, which we use to measure the cell network in the area.
[24:13.880 --> 24:24.340]  It's written in C++ and we wrote a program in the SRS-LTE API to scan the cell network for us.
[24:24.340 --> 24:31.360]  The frontend, which it communicates with over a local socket, is written in Python 3.
[24:32.020 --> 24:36.600]  The frontend is responsible for getting data from the socket from SRS-LTE,
[24:37.460 --> 24:42.940]  adding it to the database, running heuristics, and displaying tower locations.
[24:42.940 --> 24:49.280]  And we also have an API so that if you want to gather data from multiple sensors or if you want
[24:49.280 --> 24:55.860]  to share data between multiple researchers, you can. Here's an example of what the user interface
[24:55.860 --> 25:01.840]  looks like. This is from a scan that me and my colleague Dave Moss did in downtown San Francisco
[25:01.840 --> 25:09.620]  during the Dreamforce conference last year. Each of these points on this map is, we think,
[25:09.620 --> 25:15.840]  probable location of a cell in downtown San Francisco on that day. The orange points are
[25:15.840 --> 25:20.640]  cells that we didn't find to be suspicious, and the black skulls are cells that we did think
[25:20.640 --> 25:26.480]  were suspicious. And I should note here that certainly there's no way that each of these
[25:26.480 --> 25:32.920]  black skulls is a cell site simulator. In fact, probably none of them are cell site simulators.
[25:32.920 --> 25:36.560]  But we think they're suspicious and require further checking.
[25:38.260 --> 25:44.640]  And I'll go into more depth about that later. On the hardware side, the hardware stack is a
[25:44.640 --> 25:49.720]  laptop or a Raspberry Pi running Ubuntu, and you need a battery for the Pi if you want it to be
[25:49.720 --> 25:57.640]  mobile, a USB GPS dongle, and an SDR with some LTE antennas. For the SDRs, we've tested it with
[25:57.640 --> 26:05.660]  BladeRF and an Edis B200. It should support all models of Edis and BladeRF. It also theoretically
[26:05.660 --> 26:10.680]  could support a Lime SDR, which is significantly cheaper. I think the BladeRF will run you about
[26:10.680 --> 26:16.820]  $500, whereas a Lime SDR will run you about $250. But we have not tested it with that. But that is
[26:16.820 --> 26:20.600]  on the roadmap because we would like for this hardware stack to be cheaper.
[26:22.100 --> 26:26.060]  Here's what the hardware looks like sitting on my kitchen counter. As you can see, it's actually
[26:26.060 --> 26:33.060]  pretty compact, and you can easily put it into a backpack or load it into your car and go for a
[26:33.060 --> 26:40.440]  drive around your city. And it's pretty... and you can do it pretty discreetly.
[26:40.440 --> 26:45.140]  So the general workflow is we start by scanning all of the frequencies that we know about
[26:45.140 --> 26:50.560]  and decoding each MIB and SIB that we find. We record those into a database, we map the
[26:50.560 --> 26:55.640]  probable location of those cells, we look for any anomalies in the readings, and then we locate
[26:55.640 --> 27:00.320]  suspicious cells and confirm the results. And I'll go into each one of those in more depth.
[27:01.000 --> 27:07.200]  So we start by scanning a list of ERFsens, again, frequencies. We start by scanning a list of ERFsens
[27:07.200 --> 27:12.980]  that we get from an open source database called Wiggle. Wiggle is an open source database of
[27:12.980 --> 27:19.500]  war driving readings of Wi-Fi networks and also of cell networks. So we get all of the ERFsens for
[27:19.500 --> 27:24.960]  the given geographical region we are in, and then we scan each of those. And our theory behind this
[27:24.960 --> 27:30.240]  is that we think that a cell-site simulator is going to have to operate on the same frequencies
[27:31.000 --> 27:35.340]  that real cells are, so that phones will be more inclined to connect to them.
[27:35.920 --> 27:41.920]  So we scan each of these frequencies, and if we find a MIB, we decode the MIB and the SIB,
[27:41.920 --> 27:47.860]  and we send it to the front end over our socket. The front end stores the information in a database,
[27:47.860 --> 27:54.160]  and it stores in that database the mobile country code, the network code, the tracking area code,
[27:54.160 --> 28:00.040]  physical ID and ERFsens, the latitude and longitude of where the reading was made,
[28:00.040 --> 28:05.680]  the timestamp, the signal strength, the e-node BID, the sector ID, and a few other IDs,
[28:05.680 --> 28:14.180]  and finally the raw data from the SIB1. And then the next step is that we try to map out
[28:14.180 --> 28:20.560]  the antennas in real time. And we map them out using a process called trilateration,
[28:21.280 --> 28:26.840]  which is a process where we have distance estimates that we're able to get from a combination of the
[28:26.840 --> 28:31.580]  frequency of the transmission and the signal strength. We can estimate the distance and then
[28:31.580 --> 28:37.600]  with multiple readings, figure out where the towers are. And then we can compare this to a
[28:37.600 --> 28:43.840]  ground truth such as wiggle or open cell ID or the FCC database to see if other people have seen
[28:43.840 --> 28:50.220]  a cell with those identifiers in that area historically. A quick explanation of trilateration
[28:50.220 --> 28:57.820]  versus triangulation. So trilateration is where you have a measurement of the distance away from
[28:57.960 --> 29:04.760]  a transmitter that you are, but not what direction the transmitter is in. So you draw a circle around
[29:04.760 --> 29:10.880]  the point where you're at, and somewhere on the edge of that circle is where the transmitter is
[29:10.880 --> 29:17.760]  going to be. Once you've made three measurements, you can draw three circles, and the place where
[29:17.760 --> 29:22.670]  those three circles intersect is the place where the transmitter is going to be located.
[29:23.540 --> 29:28.360]  Triangulation, on the other hand, is where you have a bearing, that is to say a direction of the
[29:28.360 --> 29:36.980]  signal, but you don't know how far away the signal is. With triangulation, you get two readings with
[29:39.260 --> 29:47.200]  a bearing, with a direction, and then you can make a triangle with one line between the two readings
[29:47.200 --> 29:52.100]  and the other two sides with the direction of the readings. And where those two directions intersect
[29:52.800 --> 30:01.000]  is where the location of the tower will be. So triangulation is good if you have direction,
[30:01.000 --> 30:06.160]  direction but not distance, and trilateration is good if you have distance but not direction.
[30:06.160 --> 30:11.480]  For trilateration, you only need one omni-directional antenna. But for triangulation,
[30:11.480 --> 30:16.340]  you either need three omni-directional antennas with all of their clocks synced,
[30:16.340 --> 30:20.680]  so that you can actually measure the angle that the signal is coming from,
[30:20.680 --> 30:26.940]  or you need a directional antenna that's constantly spinning so that you can figure
[30:26.940 --> 30:32.320]  out which direction it points has the strongest signal and thus figure out the bearing.
[30:34.100 --> 30:38.080]  Given that we figured most people running this would only have one omni-directional antenna
[30:38.080 --> 30:43.640]  and not a spinning antenna or three clock-synced antennas and thus three clock-synced radios,
[30:43.640 --> 30:46.720]  we figured that trilateration was our best bet.
[30:47.400 --> 30:52.320]  So finally, we look for anomalies. And what are we looking for in terms of anomalies?
[30:52.520 --> 30:57.760]  We're, well, looking for things like cells that move over time, cells where the signal
[30:57.760 --> 31:02.600]  strength changes, cells that aren't where they should be, in other words, cells that are here
[31:02.600 --> 31:10.720]  and also across the city, cells that change parameters. Suddenly this node BID is broadcasting
[31:10.880 --> 31:16.120]  a different country code or a different network code or suddenly it's broadcasting a different
[31:16.120 --> 31:21.560]  bandwidth or something like that. We're also looking for cells that are missing some of
[31:21.560 --> 31:27.040]  the more obscure parameters in the SID or higher SIDs. And we're looking for new cells that are
[31:27.040 --> 31:32.380]  showing up. And again, it's important to mention here that just because we find an anomaly doesn't
[31:32.380 --> 31:36.580]  mean we've found a cell-site simulator. We actually need to go verify it.
[31:38.820 --> 31:43.960]  So if you know anything about 4G attacks and know how they work, you might be thinking at this
[31:43.960 --> 31:49.840]  point, but there's a lot of heuristics that you could have if you could actually connect to the
[31:49.840 --> 31:55.360]  tower. And that is true. There are a lot of really cool heuristics that we could get if we could
[31:55.360 --> 32:00.340]  connect to a cell. We could see if we got a reject message or we could see if it accepted us. Either
[32:00.340 --> 32:05.340]  one of those might be interesting. We could see if it was missing some of the higher level or more
[32:05.340 --> 32:11.700]  esoteric parts of the LTE stack. Or there's all sorts of things we could measure. We could see
[32:11.700 --> 32:16.840]  how many paging messages it's sending out or how many other UEs are connected to the cell.
[32:16.840 --> 32:22.280]  But all of those would require connecting to the cell. And connecting to the cell requires
[32:22.280 --> 32:28.300]  transmitting. We thought it'd be a great idea until the EFF lawyers pointed out that that's
[32:28.300 --> 32:35.000]  illegal. Because we're using a software-defined radio, it's not actually licensed to communicate
[32:35.900 --> 32:41.860]  to transmit on the cellular bandwidths. Whereas your cellular modem in your phone
[32:41.860 --> 32:47.440]  is licensed to transmit on those bands. So we can't transmit on those bandwidths without violating
[32:47.440 --> 32:52.780]  on those bands on those frequencies without violating the law. And we don't want to go to
[32:52.780 --> 33:00.040]  jail. So we decided not to transmit. But despite that, we still got some results.
[33:00.040 --> 33:05.480]  So what we've found so far. Our first test was at the Dreamforce conference,
[33:05.480 --> 33:09.880]  which I mentioned previously, with my colleague Dave Moss. Me and Dave spent all day running
[33:09.880 --> 33:14.120]  around downtown San Francisco. And for those of you who aren't familiar with Dreamforce,
[33:14.120 --> 33:19.200]  lucky you. Dreamforce takes over all of downtown San Francisco. And there's sales
[33:20.600 --> 33:26.220]  people running around everywhere. We wandered around the main park where Dreamforce was
[33:26.220 --> 33:33.680]  happening. And we noticed this little cluster of suspicious cells here on the park near the where
[33:33.680 --> 33:41.860]  the event was taking place. So we started walking down Third Street and getting to the point where
[33:41.860 --> 33:46.000]  we thought the suspicious cells were. And we're thinking, hey, yeah, I think it's probably right
[33:46.000 --> 33:51.880]  about here. When we looked up and saw this giant black truck with a satellite dish on top of it.
[33:51.880 --> 33:55.760]  The satellite dish was pointing at a building about a block away that had a couple of cell
[33:55.760 --> 34:03.520]  antennas on top of it that we had noted previously. After looking at the truck, looking up the company
[34:03.520 --> 34:07.760]  that was listed on the side of the truck and talking to the guys in the truck, we determined
[34:07.760 --> 34:13.600]  that this is in fact a cell on wheels and not a cell-side simulator. A cell on wheels is a
[34:13.600 --> 34:21.620]  portable cell tower that people bring out, companies bring out, to expand the cellular
[34:21.620 --> 34:26.960]  capacity in a given area, usually for large events. In fact, there was even one at Stading Rock.
[34:29.000 --> 34:32.600]  We don't think that this was a cell-side simulator. And in fact, cells on wheels are
[34:32.600 --> 34:38.220]  pretty common. But they have some interesting similarities to cell-side simulators.
[34:41.880 --> 34:47.780]  Namely, in that they are a portable cell that shows up that isn't usually there, is suddenly
[34:47.780 --> 34:56.580]  there, and then leaves. And that they are acting like legitimate cells.
[34:56.580 --> 35:04.180]  The main differences are that they're not actually trying to exploit any of the characteristics of
[35:04.180 --> 35:10.080]  the 4G network, and the people operating them are probably not using them to spy on you.
[35:10.440 --> 35:17.340]  But we still think that this is a successful test. We were able to use our heuristics to find a new
[35:17.340 --> 35:22.900]  cell that had just showed up, and we were able to use our map to actually track that down and see
[35:22.900 --> 35:28.160]  what it was. If we had just been using an app, maybe that app would have called this out, maybe
[35:28.160 --> 35:33.240]  it wouldn't have. And even if it had called it out, we wouldn't have known what to go look for or what
[35:33.240 --> 35:41.080]  it might have been. So, we considered this a success. Earlier this year, we did a second test
[35:41.800 --> 35:44.940]  at ShmooCon in Washington, D.C.
[35:45.960 --> 35:53.740]  So, I loaded up Crocodile Hunter on a Raspberry Pi running around ShmooCon with it in my
[35:53.740 --> 36:00.360]  backpack for the entire time. And what we discovered at ShmooCon was two really interesting sets of two
[36:00.360 --> 36:07.260]  different ENOBs that would occasionally broadcast, instead of the country code and network code of
[36:07.260 --> 36:14.060]  310410, which maps to USA and AT&T, would broadcast a completely different country code
[36:14.060 --> 36:22.400]  and a completely different network code. Looking into it further, the first one was broadcasting
[36:22.400 --> 36:28.120]  on the same ERCIN as what we think is the legitimate tower, but would broadcast a different
[36:28.120 --> 36:39.480]  MCC and MNC of 350 and 490. 350 is the country code for Bermuda, and the MNC 490 is not used by
[36:39.480 --> 36:45.800]  any network in Bermuda. In the U.S., it's used by Sprint and T-Mobile, but again, this is an AT&T
[36:45.800 --> 36:53.680]  network. It was also broadcasting the same physical ID, but a different sector ID and a different
[36:53.680 --> 37:00.500]  tracking area code. So we find this really interesting. In another instance, there was
[37:01.360 --> 37:06.860]  another ENOB broadcasting on the same ERCIN as what we think is a legitimate ENOB,
[37:06.860 --> 37:12.760]  this time broadcasting a country code of 308 for St. Pierre and Miquelon, which, if you need a
[37:12.760 --> 37:17.720]  point of reference, these are a couple of small islands off the coast of Nova Scotia. I was also
[37:17.720 --> 37:23.020]  not aware of them until I looked them up for this talk. And the network code 451
[37:23.020 --> 37:30.120]  is not used by any network for anything ever anywhere in the world. This network was also
[37:30.120 --> 37:35.640]  broadcasting the same physical ID, and in this case was broadcasting the same sector ID as the
[37:35.640 --> 37:40.240]  legitimate tower and the same tracking area code as the legitimate tower. So these were really
[37:40.240 --> 37:46.160]  interesting. Unfortunately, I, as I said, was running around with the Crocodile Hunter in my
[37:46.160 --> 37:51.280]  backpack and didn't notice these results until after the fact, so I didn't get a chance to go
[37:51.280 --> 37:55.720]  track them down. So hopefully in the future, we'll find something like this and actually get
[37:55.720 --> 38:03.420]  to go physically look at them. We do have ongoing tests, though. Our partners in Latin America with
[38:03.420 --> 38:09.220]  the Fake Intended Detection Project have previously run around Mexico City and other places
[38:10.480 --> 38:14.680]  with SeaGlass and have gotten some really interesting results there, and are planning
[38:14.680 --> 38:19.040]  next to run around there with Crocodile Hunter and see what they can find. And I'm really excited
[38:19.040 --> 38:25.780]  for what they will find. We also have partners running Crocodile Hunter in Washington, D.C.
[38:25.880 --> 38:30.320]  and in New York City, and we hope now that the project is open source that you'll want to run
[38:30.320 --> 38:39.960]  this in your hometown as well. In the future, we hope to get better heuristics for Crocodile Hunter.
[38:40.320 --> 38:45.560]  Some of the heuristics I have right now aren't great, and I think that there are other ones
[38:45.560 --> 38:51.000]  that we could do. We have a lot of ideas. We also can improve these once we get a
[38:51.000 --> 38:56.240]  better sense of how ABC catchers and cell site simulators are operating in the wild.
[38:56.700 --> 39:01.020]  Speaking of heuristics, once we get a lot of readings, we think that we can start to do some
[39:01.020 --> 39:07.020]  machine learning to build a classifier for what towers are behaving normally and giving normal
[39:07.020 --> 39:13.020]  characteristics and what towers are suspicious, maybe in ways that a human wouldn't notice.
[39:13.280 --> 39:17.760]  I also want to get better location finding. Right now, my location finding can sometimes be about
[39:17.760 --> 39:23.720]  50 meters off, and that's not great. It's still pretty close, and I'm okay with it. I think it's
[39:23.720 --> 39:31.420]  good enough. But I would like to get it much better, and that means we need better distance
[39:31.420 --> 39:38.700]  estimates, which is beyond my math and physics knowledge, unfortunately. And the other thing we
[39:38.700 --> 39:43.680]  need is we want to port it to cheaper hardware. Like I said, the Blade RF will ring you about
[39:43.680 --> 39:51.780]  $500. We think that it can work on the Lime SDR, which is cheaper at $250. My dream is that it
[39:51.780 --> 39:58.300]  would work on the RTL SDR, which would cost like $20, but I'm not convinced that the RTL SDR and
[39:58.300 --> 40:03.940]  Raspberry Pi are actually powerful enough or have the bandwidth to do what we need them to do,
[40:03.940 --> 40:11.540]  so that's still up in the air. And finally, what's with the name? Well, you may remember
[40:11.540 --> 40:17.760]  that one of the brand names for a cell-site simulator is the StingRam. You may also
[40:17.760 --> 40:24.040]  remember that the StingRam is the animal that finally killed Steve Irwin, the crocodile hunter.
[40:24.320 --> 40:28.360]  So, we named it Crocodile Hunter to press F for Steve.
[40:30.320 --> 40:38.180]  Finally, what can we do to stop cell-site simulators? Well, we can start by having a
[40:38.180 --> 40:45.440]  toggle on iOS and Android to turn off 2G support. One of the main attacks for native 4G cell-site
[40:45.440 --> 40:52.000]  simulators is to use that pre-authentication area to downgrade your connection to 2G. And once your
[40:52.000 --> 40:57.920]  phone is downgraded to a 2G connection, they can do things like inspect content or do passive
[40:57.920 --> 41:04.600]  attacks to decrypt the messages between you and the cell tower, or they can emulate a 2G base
[41:04.600 --> 41:11.180]  station. So, your phone still supports 2G, and the reason for that, there's a good reason for that.
[41:11.180 --> 41:17.400]  It's because many people in the world still use 2G cells as their primary form of communication,
[41:17.400 --> 41:25.440]  and lots of 2G networks are still up. So, iOS and Android can't just disable 2G by default,
[41:25.440 --> 41:30.060]  but what they could do is build in a toggle for users who are concerned about this to be able to
[41:30.060 --> 41:37.060]  turn off their 2G radios if they wish. And we've written a blog post that encourages them to do so.
[41:38.020 --> 41:41.680]  The main thing we need to fix, though, is these pre-authentication messages.
[41:41.680 --> 41:46.740]  All of the messages that happen after your phone connects to the tower, but before the authentication
[41:47.980 --> 41:54.020]  starts. And that's a problem not in 4G, but not just in 4G, but in 5G as well.
[41:54.020 --> 42:03.420]  There's a pretty interesting proposal for covering all of the messages, or authenticating
[42:03.420 --> 42:08.460]  all of the messages between the tower and the user equipment with TLS. There's a pretty good
[42:08.460 --> 42:15.800]  paper about this, and it'll be linked here in the notes for this presentation, that proposes a way,
[42:15.800 --> 42:19.480]  and it's still in its infancy, and it's going to take some more work, but we really think that
[42:19.480 --> 42:25.960]  long-term, that's the solution. But that's going to have to be implemented by a standards body,
[42:25.960 --> 42:32.340]  such as the 3GPP. And the 3GPP is the standards body that makes all of the standards for cell
[42:32.340 --> 42:37.600]  networks. It's also going to have to be implemented by carriers, manufacturers, and OEMs, and we need
[42:37.600 --> 42:45.440]  more incentives for the standards, or as the carriers and the OEMs, to care about user privacy.
[42:45.440 --> 42:50.680]  Right now, it often feels as though user privacy is an afterthought, and connectivity is really the
[42:50.680 --> 42:58.700]  most important, the primary goal of these organizations. And we need to change that.
[42:58.700 --> 43:05.460]  The 3GPP costs several tens of thousands of dollars to get a seat on, and as such, there are no
[43:05.460 --> 43:10.280]  representations from civil society, from privacy organizations, from non-profits, and that needs to
[43:10.280 --> 43:15.780]  change. None of these solutions are going to be tool-proof, of course, and our detection, and
[43:15.780 --> 43:20.960]  Carcine Hunter is tool-proof, but we're not even doing the bare minimum yet, and I think that we
[43:20.960 --> 43:28.460]  should be doing at least that. So what do I want you to take away from this? Well, we have a pretty
[43:28.460 --> 43:33.260]  good understanding of the vulnerabilities in 4G, which commercial cell site simulators might
[43:33.260 --> 43:37.880]  exploit. And if you want to read more about those, I really highly suggest you read Yama's paper,
[43:37.880 --> 43:43.520]  Gotta Catch Em All. None of the previous MCCatcher detector apps really do the job anymore.
[43:43.520 --> 43:49.300]  CGLASS could certainly still detect older MCCatchers, but none of them are able to detect
[43:49.300 --> 43:55.520]  newer MCCatchers. But we've come up with a method similar to established methods, but targeting 4G
[43:55.520 --> 44:02.300]  natively. And we think that the worst problems of CSS abuse can be solved with a little bit of elbow
[44:02.300 --> 44:09.500]  grease and a lot of politics. Finally, thanks to the following people. Yamna, of course. I couldn't
[44:09.500 --> 44:13.640]  have done this project without her, and she did so much amazing work. Thanks so much to Yamna,
[44:13.640 --> 44:18.820]  and please buy her a virtual beer, or just challenge her to a game of Dance Dance Revolution
[44:18.820 --> 44:23.400]  if you see her. And of course, thanks to the whole EFF crew, and especially Threat Lab,
[44:23.400 --> 44:28.140]  who have been a huge support through all of this. Huge thanks to Andy and Bob at Wiggle for a lot
[44:28.140 --> 44:33.360]  of programming help and a lot of... for giving me unfettered access to their API. Thanks to Roger
[44:33.360 --> 44:38.840]  Piqueros-Jover, who is one of the smartest people in the world about cell networks. He really knows
[44:38.840 --> 44:44.300]  his stuff, and he gave a lot of advice and a lot of encouragement. Thanks to my test crew, Neema
[44:44.300 --> 44:51.160]  Fatemi with CanDo, and Surya, Matthew, and Simon from the Markup. Simon Fondry-Tiedler, thank you.
[44:51.780 --> 44:56.320]  Carlos with the Fade Project, and everybody else involved in the Fade Project, thanks for
[44:56.320 --> 45:02.200]  running Practical Hunter in South America. Carl Kosher and Peter Ney and others at the University
[45:02.200 --> 45:09.280]  of Washington, who authored Seagloss, as well as giving me tons of advice, tons of support,
[45:09.280 --> 45:14.200]  coming out to Standing Rock with me. Really fantastic people. And of course, thanks to Ash
[45:14.200 --> 45:18.420]  Wilson, the author of Siege, and Eric Escobar, Defcon Justice Beaver, who also gave me a lot
[45:18.420 --> 45:22.820]  of inspiration and advice. And last but not least, thanks to Kristen Padgett for doing all the
[45:22.820 --> 45:27.420]  research on suicide simulators and really paving the way for hackers to start looking at these.
[45:27.420 --> 45:32.640]  And also, thanks for the Geophones, Kristen. And finally, thank you for coming to the talk.