LTESniffer: An Open-Source LTE Downlink/Uplink Eavesdropper | Hacker News Reader

LTESniffer: An Open-Source LTE Downlink/Uplink Eavesdropper

github.com

256 pointstranspute49 comments

Mobile network standards are full of acronyms. I love it.

In case you did not know, the letter Q in PHICH stands for "request".

If anyone is wondering what the parent poster is talking about — the abbreviation PHICH (which isn't mentioned in the referenced project, but is just an example of a weird mobile-network acronym) expands to "Physical channel HybridARQ Indicator Channel"; and then the embedded "ARQ" inside it, purportedly expands to https://en.wikipedia.org/wiki/Automatic_repeat_request .

Some might claim that the "Q" in "ARQ" is actually "query"; and that people who choose to expand the "Q" as "request" just have a dim view of the average person's vocabulary level.

Personally, though, I'd argue that, if you think about it, the "Q" is probably not "request" or "query", but rather just another appearance of the conventional opaque "Q" that appears in https://en.wikipedia.org/wiki/Q_code.

It's up there with the accepted Tx/Rx for transmit and receive.

At least "receive" makes more sense for Rx than "prescription"

Rx actually stands for "recipe"!

Which makes sense, if you remember that there used to not be such a thing as pre-compounded drugs. Rather, a prescription was literally a recipe a doctor would write out for you to give to your friendly neighbourhood compounding pharmacist, who would follow that recipe to produce a drug for you.

Which in turn lends an interesting clarity to the traditional roles and competencies of "medical doctors" vs "pharmacists". In the 1800s, a trained doctor was someone who would be expected to come up with a — potentially de-novo! — drug formulation, on the spot, as a treatment for a patient; and a trained pharmacist is someone who would be expected to take your prescription, walk into a lab in the back of their shop, and come out having converted that — potentially never-before-encountered — drug formulation into something you could put in your mouth. If the active ingredient was something unusual, they would even be expected to synthesize it themselves! (Which explains why we used to call pharmacists "chemists". They were!)

Interestingly, compounding pharmacists still exist. When my son was less than a year old, he needed some medicine, but there was nothing we could buy over the counter for his weight. So, the doctor literally wrote the recipe down and sent us to a compounding pharmacist across town.

I always saw those as parameters for some reason. Transmit(x), Receive(x).

I thought you were kidding me...

here is the letter Q in PHICH:

https://github.com/srsran/srsRAN_4G/blob/master/lib/src/phy/...

as the sibling comment states, q is the reQuest

Meh, this is not rare.

In colors (design, printing,...), the "K" in CMYK stands for "blacK"

The K in CMYK stands for “Key”, which is the backing plate, usually black inked.

Notice there is no Q in PHICH even.

Nice!

I see that it supports FDD only (no TDD) and is limited to 20MHz, so some limitations.

I see that it can do some amount of real-time decoding, which is interesting. In cell towers, a big part of the processing is done by fairly general-purpose processors, but still much more tightly integrated with the hardware than this software is.

Too bad the hardware for this is eyewateringly expensive :'(

It uses srsRAN which supports SoapySDR which is vendor agnostic.

this should work with limesdr as well.

for something cheaper, try antsdr or adalm-pluto: https://github.com/srsran/zynq_timestamping

lots of good notes here: https://www.quantulum.co.uk/blog/private-lte-with-analog-ada...

I thought it needs 2xUSRP if you want to receive both sides? And it's a lot less useful without that.

Pluto and USRP are almost exactly the same thing at this point, just USB2 vs USB3 so you're limited on data rates outside of the device an technically a different chip but they're an old node and binned, so they're the same in practice. You can still install an external clock into the UFL connector on the Pluto though so you can sync a few if you want or use a GPSDO for frequency accuracy. You can also install the extra Tx/Rx pair onto the UFL connectors they added recently-ish.

For those interested in a more accessible LTE meta-data decoder check out https://github.com/JiaoXianjun/LTE-Cell-Scanner which can work with even cheap rtl-sdr dongles (for some things). It is a fork of an older https://github.com/Evrytania/LTE-Cell-Scanner

Huh how can that work? It's only got 2Mhz bandwidth. An LTE cell is much wider.

Possibly it's decoding MIB only, which is only 1.080 MHz wide.

Seems like if you had a PC already, you could get away with a bladeRF 2.0 micro xA5 for $670, but this can sniff downlink only.

> xA5 for $670

No longer for sale (out of stock with no plan to restock https://www.nuand.com/product/bladerf-xa5/ )

Yeah for me that is already eye-wateringly expensive :) (Being in Spain where purchasing power is low).

Yes, there is cheaper hardware like the Adalm Pluto with enough bandwidth and dynamic range, but it is not supported by the looks of things.

True? How are phone modems inexpensive?

Simple: Mass production, dedicated hardware for that single purpose (but not able to do full monitoring like this).

Because they have to do only one thing, and literally billions are produced every year, so if qualcomm spends 1 billion for R&D, the modem price will only need to be $1 "higher" to cover the r&d cost... if SDR development costs $1 mio (and that's basically zero for hardware design), and 10k units are sold, that's $100 per device in R&D cost.

(numbers simplified and rounded to make an example)

I'm wondering the same thing.

Can someone outline the architectural limitations of using a smartphone modem for such network debugging/sniffing tasks?

Smartphone modems (baseband) are super optimised for battery life. They don't send any traffic that isn't meant for the device itself on to the CPU. That would only cause unnecessary load.

They could perhaps be modified to do that but the baseband firmware is usually very closed source.

There is only one example I know, there was one particular dumbphone from the 2G era for which the baseband sourcecode was available due to a hack. You could use several (one for uplink and one for downlink) of these with modified firmware to sniff 2G traffic. I forget which model it was exactly but obviously the price ballooned on eBay :)

Haven't heard of this happening with later models. Baseband sourcecode firmware is really rare.

Certainly Qualcomm modems can have their diagnostic mode enabled when you have access to /dev/diag - usually on rooted devices but occasionally on stock.

You can ask the processor to send higher layer information via diag, including the messages the base stations send. There’s also commands to lock on to a specific base station so you’re not constantly moving from cell to cell.

There’s plenty of commercial devices that use this functionality to provide network monitoring and management capabilities for mobile network operators checking out base station functionality in the field. TEMS comes to mind for that but they’re certainly not the only ones.

It’s a deep rabbit hole :-)

The diagnostic mode just lists the cells and their parameters afaik. It doesn't capture IMSIs or traffic to/from other devices like this does. It's like the network diagnostics menu built into Samsung and Apple phones.

It isn't even able to list some crucial parameters needed to identify neighboring cells. It's simply dumping data that's already used by the modem for its regular operation.

It does, however, more than just "listing cells" though. You can sniff all the comms, but only between your device and the base station. It won't listen to anything else, you need SDRs for that.

You may be thinking about the Motorola C123. Back in the days, you could use it to dump TMSI and IMSI using OsmoconBB : https://osmocom.org/projects/baseband/wiki/MotorolaC123

Yes, that was the one! Thanks!

FWIW, the same chipset was used as a modem in the Openmoko phones.

> Haven't heard of this happening with later models. Baseband sourcecode firmware is really rare.

You know what they say. "If you have nothing to hide, you have nothing to fear"

So I wonder what they're trying to hide from all of us. Probably all the backdoors and glaring security issues.

https://hackaday.com/2022/07/12/open-firmware-for-pinephone-...

> With the PinePhone modem.. It was quickly found that the Quectel modem ran a stripped down version of Android on its ARM core, with adb shell available over the modem’s USB interface. When a few adventurous hackers started probing it and got shell access, they found tools like ffmpeg, vim, gdb and sendmail compiled in – certainly not something you’d need on a cellular modem, but hey.

EG25 is an IoT modem and those tend to expose some extra functionality such as HTTP clients or TTS synthesis over AT commands. Some even document how to compile and run software on them - though of course it's only about the application CPU and not the actual modemy stuff that runs on separate DSPs with proprietary signed Qualcomm firmware.

Most (all?) standalone modems are basically screenless smartphones/SBCs with integrated modem these days.

Phone modems (software + hardware) are very expensive to develop and only inexpensive to purchase because of the staggeringly high volumes and the fact that they are highly integrated.

This is the main reason why the number of suppliers as massively dwindled: Large upfront investments are needed and only recouped if you manage to sell 10s if not 100s millions of units.

What does it require?

Only tangentially related, but has anyone ever tried to eavesdrop on DSL? Modern DSL (VDSL2 in particular) is essentially a HF signal guided on an unshielded twisted pair (with line stubs and what not), so it should easily leak out and radiate. Apparently it does so much that radio hamateurs in the UK have been complaining[1] about it a lot. I wonder if the signal can still be demodulated or it's just an annoying baseline on the spectrum.

[1]: https://rsgb.services/public/publications/vdsl/measuring_and...

>eavesdrop on DSL?

VDSL modem spectrum during synchronization https://www.youtube.com/watch?v=7m8pAuk9lsk

Adsl2 handshake sound https://www.youtube.com/watch?v=foPGdfsrskA

I also remember seeing one with DOCSIS Cable Modem, but cant find it :(

That seems to be recorded by tapping into the telephone wire, I meant from RFI.

The other interesting fact which is lesser known is that earlier G's of digital phone xfer are in what is somewhat a sweet spot of cracking, not very easy at all, but just easy enough to be crackable. But their encryption is breakable! THe rainbow table is 2 TB and took several months to build - https://github.com/0xh4di/GSMDecryption?tab=readme-ov-file

Now I wonder if later Gs have a bit of a decryption loophole for this reason or that, this state actor or that.

Fun stuff, glad to see open source stuff like this still being used. Did downlink eavesdropping in the network security lab at college about 10 years ago. One of my projects was measuring how much cell activity dropped during spring break, another was to do timing attacks on known phone numbers at known locations to see if I can pull temporary IDs (not temporary enough IMO) and do repeat calls to see if they’re still in the area.

Makes me want to play with this again.

There are also some 4G dongles with known broken debug modes that can be used to extract info

Not easy to search for... I found 3G https://github.com/P1sec/LTE_monitor_c2xx

Think I was looking at this one

https://github.com/P1sec/QCSuper

I recall researching this and deciding zte mf823 is best bet cause 4g but haven’t actually tried it

As for hard to search - it’s pretty murky turf legally in most countries

LTESniffer claims to be Open Source but does not appear to have a top-level LICENSE file, nor a GitHub repo license set.

Most of the source files have copyright headers indicating that the code is AGPLv3 and forked from existing projects with top-level LICENSE files, https://github.com/falkenber9/falcon and https://github.com/srsran/srsRAN_Project. They should indeed add a top-level LICENSE file to cover the build and other supporting files.

Reply on news.ycombinator.com