When I was at DEFCON a week an a half ago, as I talked about in my last post, I scanned carrier LTE networks at the conference as well as the Wifi networks. There wasn’t a Private LTE CBRS network being broadcast so I ended up changing my modem with AT commands to scan the carrier networks bands. It was all just LTE though because my tools did not support 5G on the program side. I have a 5G modem but until the tools support 5G I can’t capture that data.
For the last several months, I’ve been playing with the SCAT Python code scripts. The project has been actively receiving regular updates. The main developer has been asked about supporting 5G multiple times over the last several years since I discovered the project. He has on multiple occasions said that the reason he wasn’t supporting 5G was a an issue with the GSM Tap V2 that is used to create the PCAP files. I put in a request, and he obliged to add my request as a temporary work around until GSM Tap V3 is ratified.
So, SCAT now supports outputting 5G traffic data to a certain extent, just can’t display the data in PCAPs, yet.
GSMTapV2 vs GSMTapV3
The TAP headers are data that is passed down by the driver but isn’t actually captured on the air interface over the air.
When looking at a WiFi PCAP, you will see the Radiotap Header. This header holds information such as the channel, band, and captured signal strength. All that data is not sent over the air but is recorded when received by the modem.
On Cellular PCAPs we use the GSM TAP Header instead of the RadioTap Header. The GSMTap is the same as the RadioTap in that it captures data that wasn’t transmitted over the air but passed down from the driver. It holds the ARFCN, Signal Level, SINR, and other physical layer information. There is an issue with some of that data when you get into 5G PCAPs with how the data is currently interpreted.
For example this LTE capture has an EARFCN of 8665. This is a T-Mobile network as determined from the MCC-MNC being broadcast. Some of other information was not captured in this GSMTap Header PCAP.
Here is a capture that shows the issue at hand. This is a capture of a LTE CBRS network using MCC/MNC 315-010. Notice the ARFCN field is 0.
As this capture shows, the reasons for the issues with the 5G PCAPs is actually not just a 5G issue. My previous LTE captures have been hitting the same issue. For LTE, the code was just modified to output an EARFCN of 0 instead of displaying the full EARFCN.
This comes down to programming limitations of the field sizes in the GSM Tap V2. The EARFCN field in the GSM Tap V2 is too small to hold the larger EARFCNs of newer LTE bands and the NR-ARFCNs of all 5G bands.
The EARFCNs for LTE CBRS Band are 55240 for 3.55GHz for the lowest channel to the upper channel of 56739 for 3.7GHz. The NR-ARFCN or 5G version are even bigger when it comes to CBRS. The NR-ARFCN range is 636667 for 3.55GHz to 646666 for 3.7GHz.
As a side note, ARFCN stands for Absolute Radio-Frequency Channel Number. It is a mathematical calculation to display the uplink and downlink channels instead of the individual frequencies that may be different depending on the band. For 4G LTE, the E in EARFCN stands for Evolved stemming from LTE or Long Term Evolution. When it comes to 5G, the NR in NR-ARFCN stands for New Radio. 5G is often called New Radio or NR for short.
The GSM Tap V2 field only allows numbers up to 4 digits in length in the ARFCN field. Any of the newer Bands are using field sizes in the 10000 or 100000 range which are way too big to fit in the 1000 digits GSM Tap V2 field.
The developer and others are pushing for GSM Tap V3 to be ratified to solve this issue. The EARFCN/NR-ARFCN are the most notable field that has this issue; although, there are others in the PCAP. GSM Tap V3 allows for much larger fields to accommodate these new field size requirements.
SCAT Updates
In preparing for DEFCON, I was looking at the SCAT Github page and notice there were a few new changes. Over the last few weeks, the developer has been making regular updates to the code. The first noticed change was how you install and run SCAT. The second was a bigger update that added 5G support, but I didn’t notice it until after DEFCON.
First, there is a new way to install and run SCAT. The installation has changed from downloading the ZIP file and running the ./scat.py file. Now you run the following, and it will download and install the code.
$ pip install git+https://github.com/fgsect/scat
The installation puts the scat folder in the following path. You don’t need to know this to run SCAT though.
/usr/local/lib/python3.9/dist-packages/scat/As a note, I had an error when I installed it the first time and had to add the “git+” piece to resolve the issue. The regular instructions say to just run this code:
$ pip install https://github.com/fgsect/scatIf you have issues with either version of the install command, try running the other one.
Once you have SCAT installed, you can run it in any folder since it is installed now. You don’t have to put the path or move into the scat folder.
Previously, you had to run the code with the whole path and .py from the scat folder:
sudo ./home/wlanpi/scat/scat.py -t qc -s /dev/ttyUSB0The new version removes that requirement and makes it a regular application installed on Linux. To run SCAT now, you just run this much more simple command:
sudo scat -t qc -s /dev/ttyUSB0
The second major update I found was resolved a week after DEFCON. I had put in the following request on Github:
I know there’s issues with wireshark that are harder to solve as stated above. That said, how difficult would it be to edit the diagnrlogparser.py parser to just output at least some of the 5G information to the terminal like the current diagltelogparser.py does? That would give us at least some insight into the 5G traffic. This may be a stop gap and less of a lift than building the wireshark side.
Amongst other comments, I got this response to my comment on the Github page and the issue about 5G Qualcomm was closed.
Please test release 1.1.0, which will print out NR RRC/NAS packets to stdout in this moment. As soon as GSMTAP v3 is ready I will switch to that.
The developer said that the code was updated to support my request to just output to the terminal screen the 5G information. I was excited, so I had to download and test it out.
SCAT 5G Support
I have two 5G Modems that will support this, my original one from SIMCOM and a new one from Quectel. The hardware modem is required to support 5G. So, any device that the modem only supports 4G LTE will only output LTE traffic as it has always done. Your modem needs to support 5G and the band you are interested in such as Band n48 or the 5G version of the CBRS Band.
The day I found out about the update, I installed the new version of SCAT on a Raspberry Pi running WLANPi OS sitting around with my SIMCOM Modem attached. I set out to test it… and the results were just LTE traffic.
I quickly realized that I had forgotten to change the Modem from being locked to the LTE CBRS Band. All my CBRS radios are currently broadcasting on LTE not 5G yet. That was a simple fix using Minicom and AT Commands. These commands below are specific to the SIMCOM. My previous post on locking modems to the CBRS band has more commands and documentation for other modems. If you are scanning just for CBRS networks, be sure to lock your Modem to Band 48 on LTE and Band n48 on 5G or the respective bands you want to scan.
sudo minicom -b 115200 -D /dev/ttyUSB2
I then tested it again and suddenly got a different result… SUCCESS!!! In the middle of the LTE packets was some 5GMM results.
These are 5G NR Frames being captured by SCAT. It showed the State 1/2/1 which I still don’t understand. It showed the PLMN 310/260 which is T-Mobile. The TAC was 0 and the GUTI is just ff’s. It’s unable to determine those last two fields, probably because of there not being a SIM installed. It is good to see data being captured about 5G.
Since SCAT doesn’t support 5G PCAPs yet, the developer outputs some of that data that would be in the PCAP to the terminal. My device doesn’t have a SIM but it was able to capture these PCCH or Paging traffic. With a 5G SIM card, there would be even more traffic captured, albeit limited to the carrier of the SIM. The PCCH transmissions are from the Radio to different clients. It specifically tells the client that the radio has information such as a text message waiting for them.
Notice the new NR-ARFCN 126510 and PCI 460 information. 126510 is Band n71 and correlates to 678.55 MHz Uplink and 632.55 MHz Downlink FDD. That NR-ARFCN is the issue we are having with building the PCAP that I referenced before because it is bigger than 4 characters.
The PCI is the Physical Cell Id or identifies which radio sent the transmission. You can use the PCI to map the transmission to a specific cellular tower on Cellmapper.net for most public carriers or within your Private Cellular Core.
We now have 5G Data being captured!! It currently doesn’t show signal information unlike the LTE traffic. Looking at the code, the functions that relate to signal data have a “TODO” note. Hopefully, these will be updated soon, and I might try figuring it out myself. I’m excited to have 5G traffic being captured! Kuddos to the developer for building this! This is so useful for measuring our Private Cellular, LTE and 5G, Networks. I’ll continue playing with this and will write future posts when I find new stuff. I’ll also go do some 5G War Driving like I did before.
