[HN Gopher] LTESniffer: An Open-Source LTE Downlink/Uplink Eaves...
       ___________________________________________________________________
        
       LTESniffer: An Open-Source LTE Downlink/Uplink Eavesdropper
        
       Author : transpute
       Score  : 245 points
       Date   : 2024-10-22 00:42 UTC (22 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | slwvx wrote:
       | 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.
        
       | wkat4242 wrote:
       | Too bad the hardware for this is eyewateringly expensive :'(
        
         | teruakohatu wrote:
         | 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.
        
           | wkat4242 wrote:
           | Yeah for me that is already eye-wateringly expensive :)
           | (Being in Spain where purchasing power is low).
        
           | fhsm wrote:
           | > xA5 for $670
           | 
           | No longer for sale (out of stock with no plan to restock
           | https://www.nuand.com/product/bladerf-xa5/ )
        
         | RachelF wrote:
         | 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.
        
         | superkuh wrote:
         | 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
        
           | wkat4242 wrote:
           | Huh how can that work? It's only got 2Mhz bandwidth. An LTE
           | cell is much wider.
        
             | dezgeg wrote:
             | Possibly it's decoding MIB only, which is only 1.080 MHz
             | wide.
        
         | binary_marbl wrote:
         | What does it require?
        
         | tinix wrote:
         | 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...
        
           | wkat4242 wrote:
           | I thought it needs 2xUSRP if you want to receive both sides?
           | And it's a lot less useful without that.
        
             | AnarchismIsCool wrote:
             | 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.
        
         | HeatrayEnjoyer wrote:
         | True? How are phone modems inexpensive?
        
           | paweladamczuk wrote:
           | I'm wondering the same thing.
           | 
           | Can someone outline the architectural limitations of using a
           | smartphone modem for such network debugging/sniffing tasks?
        
             | wkat4242 wrote:
             | 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.
        
               | motrm wrote:
               | 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 :-)
        
               | wkat4242 wrote:
               | 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.
        
               | seba_dos1 wrote:
               | 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.
        
               | throwawayC123 wrote:
               | 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
        
               | wkat4242 wrote:
               | Yes, that was the one! Thanks!
        
               | seba_dos1 wrote:
               | FWIW, the same chipset was used as a modem in the
               | Openmoko phones.
        
               | beeboobaa3 wrote:
               | > 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.
        
               | transpute wrote:
               | 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._
        
               | seba_dos1 wrote:
               | 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.
        
           | wkat4242 wrote:
           | Simple: Mass production, dedicated hardware for that single
           | purpose (but not able to do full monitoring like this).
        
           | mytailorisrich wrote:
           | 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.
        
           | ajsnigrutin wrote:
           | 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)
        
       | anilakar wrote:
       | Mobile network standards are full of acronyms. I love it.
       | 
       | In case you did not know, the letter Q in PHICH stands for
       | "request".
        
         | derefr wrote:
         | 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.
        
           | dylan604 wrote:
           | It's up there with the accepted Tx/Rx for transmit and
           | receive.
        
             | twojacobtwo wrote:
             | I always saw those as parameters for some reason.
             | Transmit(x), Receive(x).
        
             | hnuser123456 wrote:
             | At least "receive" makes more sense for Rx than
             | "prescription"
        
               | derefr wrote:
               | 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!)
        
               | withinboredom wrote:
               | 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.
        
         | froh wrote:
         | 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
        
           | ajsnigrutin wrote:
           | Meh, this is not rare.
           | 
           | In colors (design, printing,...), the "K" in CMYK stands for
           | "blacK"
        
             | selectodude wrote:
             | The K in CMYK stands for "Key", which is the backing plate,
             | usually black inked.
        
             | BenjiWiebe wrote:
             | Notice there is no Q in PHICH even.
        
       | Havoc wrote:
       | There are also some 4G dongles with known broken debug modes that
       | can be used to extract info
        
         | jakeogh wrote:
         | Not easy to search for... I found 3G
         | https://github.com/P1sec/LTE_monitor_c2xx
        
           | Havoc wrote:
           | 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
        
       | tonygiorgio wrote:
       | 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.
        
       | offmycloud wrote:
       | LTESniffer claims to be Open Source but does not appear to have a
       | top-level LICENSE file, nor a GitHub repo license set.
        
         | transpute wrote:
         | 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.
        
       | rnhmjoj wrote:
       | 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...
        
       ___________________________________________________________________
       (page generated 2024-10-22 23:01 UTC)