Integration of ADALM-Pluto SDR with LTESniffer and UHD Recognition

[apex-jpg]

Hello!

I'm working on a surveillance project and was looking to integrate your UL/DL eavesdropper tool with my SDR (ADALM-Pluto) in order to do some testing. I've encountered a few issues and was hoping to get your pointers on this, because I've tried troubleshooting multiple times and it's not been to much effect.

I'll describe in better detail below, but basically when i go to run LTESniffer on my computer this is what I get:

My setup:

Computer:

• OS: Mint 21.1 Vera
• Intel i7 (octa-core)
• 8 gb RAM
• 1 TB SSD

SDR:

• ADALM-Pluto

Concerns:

1. UHD doesn't recognise PlutoSDR as an RF device: UHD being a core dependency in order for LTESniffer to function, I've been facing issues with getting UHD to recognise my Pluto SDR as an RF device. I did a little digging around and it seems that UHD doesn't officially support the Pluto. But! I was wondering if there were any alternate ways that would enable this configuration? Perhaps with GNU radio (if so, would you have any pointers for constructing the flowgraph that might be integrated with UHD so that I will still be able to use the codebase here in testing out the eavesdropper), or maybe SoapySDR?

• Here's what I've tried: I used the SoapyPlutoSDR plugin for letting SoapSDR recognise my SDR as an RF device:

After that I made changes in the uhd.conf file so that UHD uses SoapySDR:

But, when I then run uhd_find_devices, UHD still doesn't recognise my SDR:

2. In the FAQ section of your documentation you mentioned: "any SDRs supported by srsRAN library such as Blade RF can be used to run LTESniffer in the downlink sniffing mode", and so it got me wondering if there was a similar process as with indirect configuration for UHD (that doesn't involve using additional hardware such as a zync-based board, as is described here) so that my Pluto SDR gets recognised as an RF device. And it would be amazing if I could get any pointers on what I could do to achieve this, and more importantly whether I would have to make changes within the codebase of the LTESniffer itself.

It's been an exhaustive bout of researching and finding various avenues to resolve these issues, but I have not been able to find a definitive solution so far. And so, I cannot think of any place better to look for help than towards the authors of this brilliant repo themselves in shedding light on potential configurations, modifications, or specific steps that can enable successful integration between LTESniffer and the Pluto SDR.

Thanks!

[hdtuanss]

Hi, thanks for your question.
First, I would like to remind you that the use of LTESniffer must follow local regulations on sniffing LTE traffic. If you are doing a surveillance project, please make sure that it is legal in your country.
About your problem, unfortunately, I haven't tested on SoapSDR before. Therefore, I don't have any experience to share with you.
What I can see from your pictures is that there is a problem when connecting SoapSDR to your PC, and you need to solve this problem before you can use SoapSDR with srsRAN or LTESniffer. Could you try to setup on Ubuntu and test again, at least, try to install UHD lib and run uhd_find_device to check whether it can find your SoapSDR or not.
2. To enable the support of srsRAN and LTESniffer to SDRs, you still need to connect your SDR successfully first. There is no solution for indirect configuration for UHD in LTESniffer.
Hopes it is helpful to you.

[apex-jpg]

Hey thank you so much for the reply (and for the disclaimer)!

So, I did the setup on ubuntu and after a little digging around, fixed up the RF device recognition error! However, I've run into another issue, and I wasn't sure whether to start a new issue or just continue along here. Just wondering if I could continue this communication with you over email? I was reading through your paper, and had a couple of questions that I wanted to follow up with as well!

The fix that worked for me:

You were right, it was a missing SoapySDR plugin (SoapyUHD) that I hadn't installed in order to link a SoapySDR supported device with UHD.

My Pluto is now recognised by UHD:

Overview of the current issue:

• When I go to run the Security API function (or even the UL or DL function with their respective code) with (sudo ./LTESniffer/build/src/LTESniffer -A 2 -W 4 -f 1840e6 -u 1745e6 -C -m 1 -z 3, it starts sniffing, but it shows a 'could not find cell in this frequency' error (with different frequency ranges) and it keeps repeating until I kill the function with ctrl+c:
  
  Just wondering if you knew why this was happening? Can I limit the maximum number of times it tries to sniff in range (with a counter in a while loop, for example)? Also, is it feasible to add a function that, after the maximum tries has been reached, runs the function on various frequency ranges in the neighbourhood of the input UL/DL values?

Additionally, when it actually does find a cell, it looks to decode the PBCH, but then resets to start searching for another cell:

• There was a moment when it actually locked onto my test phone:
  
  but this went on for a very long period of time and while it gave me partial output (PCI, CP, PRB, SFN, etc.), I ended up with another error that read as:
  

• Would you consider these issues as being software-based or hardware-based? And if it is software-based, would you say that it might be feasible to just build my own tool basing from yours and tweaking it for the purpose of my SDR?

Any input would be amazing! Thanks and once again, let me know if I can contact you with questions about your paper!

[apex-jpg]

UPDATE

So turns out I was not entering the correct frequency range value, which is why it kept throwing 'could not find cell in this frequency' error and re-trying until I killed it.

The tool is working fine now, but I still keep receiving this error in any of the three functionalities (but especially with Uplink sniffing and security API):

Interestingly, for the Downlink sniffing, it either ends after reading an error like:

or it keeps processing and gives me an empty table:

Three questions:

1. Do you think this is a software compatibility issue or would you say this has to do with hardware components?
2. If it is a software compatibility issue, would you say it's a good idea to re-configure the code to support the Pluto intrinsically (if this is the case, I will seek help from the srsRAN community for configuring full srsRAN support with the Pluto)?
3. Are there any repos that you would be able to point to which might help with this re-configuration of LTESniffer for Pluto?

Again, the fact that you've made this open-source is absolutely amazing, and I really do appreciate and will be grateful for any feedback that you can give.

Thanks!

[hdtuanss]

Hi, sorry for late response.
Based on your log, I can see that the cell you are sniffing is probably an invalid cell, because normally LTE cell has a number of PRB <= 100 PRB.
About your question,
1.1 Hardware compatibility: Could you check whether your PlutoSDR supports 2 clock sources for 2 RX antennas? If not, I worry it will not be compatible to use for uplink sniffing.
1.2 Software compatibility: Technically, any SDR supported by srsRAN lib and has 2 clock sources for 2 RX antennas will work with uplink. In your case, I'm not sure whether PlutoSDR is officially supported by srsRAN or not; and I also dont have PlutoSDR to test. Therefore, I'm sorry that I dont have an exact answer for you.
2. Support from srsRAN community: If your SDR satisfies the clock requirement (2 clock sources), you can ask for the help from srsRAN community.
3. LTESniffer uses original SDR lib from srsRAN, so, there is no specific code of LTESniffer to support PlutoSDR singlely.
Instead of using PlutoSDR, I recommend you use 2 USRP B200s equipped with GPSDO, which is newly supported in LTESniffer v2.0.0.
Thanks.

[apex-jpg]

Hey! Really appreciate your reply, this is insanely helpful!

I did a bit of digging and unfortunately, the PlutoSDR is designed with a single clock source that is shared by both the transmitter (TX) and receiver (RX) components. It does not have the capability to synchronize multiple clock sources or support multiple antennas with independent clocking.

So that would imply uplink sniffing would not be supported. I might look to experiment with time division multiplexing to switch between multiple RX antennas connected to a single Pluto - although I worry about the limitations of simultaneous reception and real-time processing.

I would gladly switch to the USRP B200s, but I am constrained to using the Pluto, so I must find alternate pathways to make this work. I really do appreciate your recommendation though!

1. I understand that LTESniffer uses SDR lib from srsRAN, but if I were to perhaps use a different library (and I could be completely wrong here - but something like gr-lte which is GNU based), would you say that the codebase here would still be useful in building a tool that has similar functionality to what you have achieved here?
2. If I were to build something similar to LTESniffer with something like, say, GNU Radio, I would be very grateful to get your feedback and any pointers/opinions on the same. There's not many places I can go for advice on this topic, so I was really hoping I could occasionally message/email you with updates and ask for your input?

Again, I really appreciate your reply!
Thanks

[apex-jpg]

Further update!

Hello hello again! You'll have to forgive my pestering on but the project I'm working on is extremely important to me, and also I do come bearing good news!

First, please disregard the questions I asked above. I went down the path of attempting to re-build LTESniffer on GNU Radio and it just grew in complexity, to the extent that I would be better off modifying the hardware of the SDR or the codebase here to meet the requirements of my project.

After messaging some of the wonderful folks at srsRAN, and some tinkering with the Pluto itself, I've found that the ADALM-Pluto does in fact have a second Rx port and a second Tx port. I've ordered two antennas to plug into this, but as of now, this implies I've been using the pluto with only one Rx antenna.

1.

In the parameter for number of antennas A, I've been previously setting it to 2, since when I set it to 1, I get this error:

Would you be able to shed light on what's happening here, and why I'm getting this error?

2.

The ADALM-Pluto also supports an external clock, which can be used for better frequency synchronization. And so I could potentially plug in a GSPDO, and alongside implement the zynq_timestamping solution on the software end, to get better readings that match with the LTE requirements.

Just wondering if you could elaborate a little more on what you mean by having 2 clock sources for 2 RX antennas? And also, why this is a requirement?

Again, I really do appreciate you taking the time to read through this, and hope to hear from you soon!

Thanks!

[hdtuanss]

Hi,
I appreciate your hard work on making LTESniffer works with PlutoSDR and GNURadio.
However, I dont have PlutoSDR to test; so, I'm sorry that I dont have any experience to share with you regarding the error you are facing.
Next, about 2 clock sources for 2 RX antennas, let me clarify this a little bit. The exact explanation for this is, you need 2 different LO (Local Oscillator) connected to 2 RX antennas to turn them into 2 different frequencies. Therefore, you need to check whether your SDR supports that feature or not. Please note that GPSDO and external clock sources are different from LO (as far as I know).
I hope you can solve this problem.
Thanks

[apex-jpg]

whoops! I accidentally closed the issue. Apologies for that

[apex-jpg]

Substantial UPDATES

Hello hello!

I'm back with some pretty substantial updates!

Pluto's hardware configuration:

I was recently in touch with one of the chief engineers at Analog Devices - the company that builds the Pluto - and according to them, the Pluto does not support the 2 clock sources for 2 RX antennas requirement, and the only alternative is to get two of the devices and synchronise the internal clocks of each device. A big limitation here is that there will still be random delays between the two Pluto devices, and even the process of synchronisation is a non-trivial task.

I will still continue with developing the dual-transmit and dual-receive functionality of the device, as well as add an external clock with the GPSDO and see whether this would make any difference whatsoever. I will update this issue page with my findings, but in the meantime, in the interest of progressing further, I have ordered a BladeRF micro 2.0!

An alternate piece of hardware: BladeRF micro 2.0 + LEO Bordnar mini GPSDO

I have recently ordered a BladeRF micro 2.0. This is a device that is officially supported by srsRAN and has MIMO capabilities. The engineer from Analog Devices did mention that it isn't much different to the Pluto in terms of functionality, which worries me slightly, but I wanted to get your input on its compatibility with LTESniffer!

Questions

Much of these will be answered once I test the device, but there are some theoretical/predictive aspects to it that I would love to hear from you about.

1. Is the combination of Blade micro 2.0 and a LEO Bordnar mini GPSDO sufficient for uplink sniffing?
2. Focusing in on the Security API that you have developed, is it possible to develop this API with just data from downlink sniffing? So, something like: sudo ./<build-dir>/src/LTESniffer -A 2 -W <number of threads> -f <DL Freq> -C -m 0 -z 3
3. If 2 is not possible, would you be able to suggest any hints/recommendations on repos that might be utilising data from downlink sniffing alone to try and extract relevant information (information mapping, IMSI, etc.)? I've had a look at LTrack mentioned in your paper, but haven't made much progress given the limited documentation available openly for that particular tool.

Once again, I can't stress this enough, but I'm truly grateful for your helpful replies and for the fact that you've developed such an amazing tool and made it open-source!

Thanks and I hope to hear from you soon!

[hdtuanss]

Hi,
1, I would like to remind you that currently, for multiple SDRs to sniff uplink traffic, LTESniffer ONLY supports 2 USRP B-Series (B200/B210s). Our algorithm is based on USRP lib implemented by srsRAN, the dedicated GPSDO clock source/time reference for USRP, and the UHD RX buffer mechanism. Therefore, it is a high chance that the LTESniffer-multi-usrp branch will work with Blade-RF. Please refer to the README file (https://github.com/SysSec-KAIST/LTESniffer/tree/LTESniffer-multi-usrp) for more details.
In conclusion, please follow the SDR requirement in our README. Otherwise, I'm not sure that your setup will work.
2 + 3, In the current version, you cannot use API in downlink mode, as most identities are obtained from uplink traffic. If you modify the code to run API in downlink mode, you might probably see only TMSI from paging messages, and really few IMSI from paging messages if eNB sends IMSI paging. That's why API is run on the uplink sniffing mode.
Thanks