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.
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 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.
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.
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)
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.
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.
> 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.
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.
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.
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.
In case you did not know, the letter Q in PHICH stands for "request".