While the OsmoSDR is still not available, some Osmocom team members (notably Steve Markgraf) have been hacking away on an alternative least-cost solution: rtl-sdr.
So what is rtl-sdr? It is a creative form of using consumer-grade DVB-T USB receivers, turning them into fully-fledged software defined radios.
Those DVB-T receivers supported by rtl-sdr are based on the Realtek RTL2832U chipset plus a tuner IC like the Elonics E4000.
The RTL2832U has some undocumented commands/registers, by which it can be placed into a mode where it simply forwards the unprocessed raw baseband samples (up to 2.8 MS/s 8-bit I+Q) via high-speed USB into the PC, where they are routed into gnuradio.
At a street price of about USD 20 to USD 25, they are undoubtedly the most capable low-cost SDR hardware that can be bought. So now there is really no more excuse for anyone to not learn gnuradio. You don't have to buy a USRP, not even a FCDP or an OsmoSDR: A USD 20 device is all that's needed for receiving signals like GSM, GMR, DECT, TETRA, APCO25 and many others.
All the current patches that were pending in the sylvain/gmr branch of our osmocom Wireshark tree have now been merged into the official trunk. Thanks to the Wireshark folks for reviewing them and merging them quickly.
What's supported :
- BCCH partial support (segment 1/2A/3A fully dissected)
- CCCH partial support (all messages ever seen on Thuraya are supported)
- RR partial support (all messages ever seen on Thuraya are supported)
- MM/CC forwarded to GSM dissectors and are mostly correct
The sylvain/gmr branch will now be removed but may re-appear in the future if new dissectors are written. Basically if we have new gmr stuff pending inclusion it'll be in that branch, and if the branch doesn't exist it just means the official trunk contains everything so far.
Osmo-GMR now has support for cipher stream generation. This allows to see past the CIPHER MODE COMMAND in the examples (I will put the key along with the demo files soon).
You can see the actual code in the git : http://cgit.osmocom.org/cgit/osmo-gmr/commit/?id=c70e5208d5a0daa9b3ff77c28f54d97f549d90f2
The algorithm was re-implemented by the Osmo-GMR team based on the reversing work done at the University of Bochum by a team comprised of Benedikt Driessen, Ralf Hund, Carsten Willems, Christof Paar, and Thorsten Holz. The Osmo-GMR team actually contributed in the late stages of this work by providing real world captures to validate the reversed algorithm and the attacks.
On February 2nd 2012, researchers Benedikt Driessen und Ralf Hund of the University of Bochum will report on their analysis of the GMR-1 and GMR-2 ciphers.
According to the abstract , the cipher used in GMR-1 and thus Thuraya is more or less the same than GSM's A5/2, and can be broken at similar complexity (i.e. almost none).
OsmocomBB team member Andreas Eversberg has been working on a new RSSI monitor firmware application within OsmocomBB.
Using this firmware, it is possible to monitor the RSSI of individual ARFCNs or even the entire spectrum.
Depending on the hardware capabilities (e.g. Hardware/FilterReplacement), it is also possible to measure the uplink RSSI.
More details are available at rssi.bin.
The current status of this firmware is available from the laforge/monitor branch in git, but is expected to be merged soon into master.
At 28c3, the OsmoSDR team was busy verifying the hardware design on the first prototypes.
The result can be summarized as:
- SAM3U is working, enumerates on USB and can be programmed via SAM-BA
- E4K tuner driver is working
- Si570 driver is working
- FPGA can be flashed via JTAG bit-banging from SAM3U
- FPGA and SAM3U can speak via SPI
However, there are at least two bugs:
- USB socket footprint pin-out was mirrored
- clock output level of Si570 doesn't match FPGA clock input specs (amplitude too low)
The issues have been worked around, and firmware + FPGA development has made progress.
OsmocomGMR main author Sylvain Munaut has given a presentation about the GMR-1 standard and the OsmocomGMR software at the 2011 annual CCC conference (28C3).
It is a great introduction into the topic, and a recommended read/view for everyone wanting to experiment with our OsmocomGMR software.
The slides are available from http://events.ccc.de/congress/2011/Fahrplan/attachments/2027_28c3_introducing_osmocom_gmr.pdf
The video is available from http://mirror.fem-net.de/CCC/28C3/mp4-h264-HQ/28c3-4688-en-introducing_osmo_gmr_h264.mp4
I've merged the DECT tree with the Linux 3.1 release and pushed out experimental support for P640j (Wideband) in the MAC/DLC/NWK layers. Besides the kernel, libnl and libdect need to be rebuilt (Build_instructions).
Asterisk wideband support is still unfinished and chan_dect will currently not build cleanly, only update if you intend to work on chan_dect yourself or want to play with wideband using the libdect example code.
As some of the readers may already know, a couple of Osmocom developers have been working on a new sub-project: OsmocomGMR.
The primary goal of this project is to provide a reusable and clean implementation of the various layers of GMR-1.
What is GMR-1 ? Well, it stands for "GEO Mobile Radio" and it's a set of specifications describing a satellite based mobile phone network heavily inspired from GSM. One of the major commercial operators of GMR-1 technology is "Thuraya", providing coverage over Europe/Africa/Asia/Australia?.
So far the implementation focused on the lowest layers:
- Physical layer with FCCH sync and demodulation support for pi4-CBPSK and pi4-CQPSK bursts.
- Channel coding layer (scrambling/puncturing/convolutional coding/crc/interleaving/...)
And some ancillary tools to exploit those:
- A good capture tool to listen to particular ARFCN and channelize them properly
- Wireshark support (BCCH only so far)
The first 'demo application' using all of the above provides functionalities similar to what airprobe is for GSM: An air interface protocol analyzer that goes all the way from capturing data off-the-air to sending packets to wireshark for analysis. Limited to BCCH only currently but this will evolve with time.
Development was mainly done by Sylvain Munaut, with help from Dimitri Stolnikov (early signal captures and his great capture tool), Harald Welte (initiating the project) and Steve Markgraf (testing different setup and antenna ideas).
If you'd like to know more, you are encourated to read the wiki and join the mailing list
I've pushed out P640j/wideband support, so far only for the 1442x firmware, the upper layers still need a bit of work. P640j can only be enabled if the PCMCIA driver is deselected and requires a firmware rebuild. I'd appreciate feedback whether things are still working properly on the PCMCIA devices.
