je internetový portál zaměřený na počítačovou bezpečnost, hacking, anonymitu, počítačové sítě, programování, šifrování, exploity, Linux a BSD systémy. Provozuje spoustu zajímavých služeb a podporuje příznivce v zajímavých projektech.


Let's Encrypt free wildcard certificates now live - 14 Březen, 2018 - 12:03 A project dear to its heart, Let's Encrypt has now made wildcard certificate support live in the next step to encrypt the Web. The certificate authority, which offers free SSL and TLS certificates to webmasters, said this week that support is now live for wildcard certificates, alongside ACMEv2.
Kategorie: Hacking & Security

Kaspersky odhalil zvláštní malware. Může to být zbraň některé státní agentury - bezpečnost - 14 Březen, 2018 - 09:00
Kaspersky Lab se před pár dny pochlubil novým malwarem, který je podle jeho slov naprosto unikátní, nejspíše totiž nepozorovaně útočí přinejmenším od roku 2012. Moc se o něm zatím neví – zejména o způsobu nákazy, ale Slingshot, jak jej Kaspersky pojmenoval, dokáže kompletně ovládnout počítač ...
Kategorie: Hacking & Security

Microsoft Patches 15 Critical Bugs in March Patch Tuesday Update

Threatpost - 13 Březen, 2018 - 23:25
Products receiving the most patches included Microsoft browsers and browser-related technologies such as the company’s JavaScript engine Chakra.
Kategorie: Hacking & Security

Patch Tuesday drops the mandatory antivirus requirement after all

Ars Technica - 13 Březen, 2018 - 21:35

(credit: amalthya / Flickr)

In the immediate aftermath of the Spectre and Meltdown attacks, Microsoft created an unusual stipulation for Windows patches: systems would only receive the fixes if they had antivirus software installed and if that antivirus software created a special entry in the registry to indicate that it's compatible with the Windows fixes.

This was due to the particularly invasive nature of the Meltdown fix: Microsoft found that certain antivirus products manipulated Windows' kernel memory in unsupported ways that would crash systems with the Meltdown fix applied. The registry entry was a way for antivirus software to positively affirm that it was compatible with the Meltdown fix; if that entry was absent, Windows assumed that incompatible antivirus software was installed and hence did not apply the security fix.

This put systems without any antivirus software at all in a strange position: they too lack the registry entries, so they'd be passed over for fixes, even though they don't, in fact, have any incompatible antivirus software.

Read 5 remaining paragraphs | Comments

Kategorie: Hacking & Security

13 Critical Flaws Discovered in AMD Ryzen and EPYC Processors

The Hacker News - 13 Březen, 2018 - 21:23
Security researchers claimed to have discovered 13 critical Spectre/Meltdown-like vulnerabilities throughout AMD's Ryzen and EPYC lines of processors that could allow attackers to access sensitive data, install persistent malware inside the chip, and gain full access to the compromised systems. All these vulnerabilities reside in the secure part of the AMD's Zen architecture processors and
Kategorie: Hacking & Security

AMD Investigating Reports of 13 Critical Vulnerabilities Found in Ryzen, EPYC Chips

Threatpost - 13 Březen, 2018 - 21:04
Researchers on Tuesday disclosed over a dozen critical security vulnerabilities in several AMD chips, opening them up for attackers who want to steal sensitive data and install malware on AMD servers, workstations and laptops.
Kategorie: Hacking & Security

Understanding the Cloak & Dagger Attack: Overview & Tutorial

InfoSec Institute Resources - 13 Březen, 2018 - 20:04

The Cloak and Dagger Attack is a method dealing with mismatched permission issues to access certain features on an Android device up to version 7.1.2. Certain vulnerabilities exist in the above-mentioned software, allowing attackers to launch undetectable attacks. The Cloak and Dagger Attack can capture passwords and pins, and ultimately obtain all permissions to leave […]

The post Understanding the Cloak & Dagger Attack: Overview & Tutorial appeared first on InfoSec Resources.

Understanding the Cloak & Dagger Attack: Overview & Tutorial was first posted on March 13, 2018 at 2:04 pm.
©2017 "InfoSec Resources". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at
Kategorie: Hacking & Security

CredSSP Flaw in Remote Desktop Protocol Affects All Versions of Windows

The Hacker News - 13 Březen, 2018 - 19:06
A critical vulnerability has been discovered in Credential Security Support Provider protocol (CredSSP) that affects all versions of Windows to date and could allow remote attackers to exploit RDP and WinRM to steal data and run malicious code. CredSSP protocol has been designed to be used by RDP (Remote Desktop Protocol) and Windows Remote Management (WinRM) that takes care of securely
Kategorie: Hacking & Security

Samba Patches Two Critical Vulnerabilities in Server Software

Threatpost - 13 Březen, 2018 - 17:56
Samba released fixes for its networking software to address two critical vulnerabilities that allowed attackers to change admin password or launch DoS attacks.
Kategorie: Hacking & Security

China-Linked APT15 Used Myriad of New Tools To Hack UK Government Contractor

Threatpost - 13 Březen, 2018 - 17:16
Cyber espionage group APT15 is back, this time stealing sensitive data from a UK government contractor.
Kategorie: Hacking & Security

Trump zablokoval spojení Broadcomu a Qualcommu. Má strach z ohrožení národní bezpečnosti - bezpečnost - 13 Březen, 2018 - 17:00
Po patentových válkách a komplikovaných jednání už se pomalu schylovalo k tomu, že Broadcom sídlící v Singapuru koupí americkou společnost Qualcomm (hlavní sídlo San Diego). Transakce to měla být skutečně obrovská – Broadcom by za Qualcomm zaplatil dle posledního jednání 117 miliard dolarů. Do ...
Kategorie: Hacking & Security

Time of death? A therapeutic postmortem of connected medicine

Kaspersky Securelist - 13 Březen, 2018 - 16:00

#TheSAS2017 presentation: Smart Medicine Breaches Its “First Do No Harm” Principle

At last year’s Security Analyst Summit 2017 we predicted that medical networks would be a titbit for cybercriminals. Unfortunately, we were right. The numbers of medical data breaches and leaks are increasing. According to public data, this year is no exception.

For a year we have been observing how cybercriminals encrypt medical data and demand a ransom for it. How they penetrate medical networks and exfiltrate medical information, and how they find medical data on publicly available medical resources.

The number of medical data breaches and leaks per year (source: HIPAA Journal)

Opened doors in medical networks

To find a potential entry point into medical infrastructure, we extract the IP ranges of all organizations that have the keywords “medic”, “clinic”, “hospit”, “surgery” and “healthcare” in the organization’s name, then we start the masscan (port scanner) and parse the specialized search engines (like Shodan and Censys) for publicly available resources of these organizations.

Masscan report extract

Of course, medical perimeters contain a lot of trivial opened ports and services: like web-server, DNS-server, mail-server etc. And you know that’s just the tip of the iceberg. The most interesting part is the non-trivial ports. We left out trivial services, because as we mentioned in our previous article those services are out of date and need to be patched. For example, the web applications of electronic medical records that we found on the perimeters in most cases were out of date.

The most popular ports are the tip of the iceberg. The most interesting part is the non-trivial ports.

The most popular opened ports on medical perimeters (18,723 live hosts; 27,716 opened ports)

Using ZTag tool and Censys, we identify what kinds of services are hidden behind these ports. If you try to look deeper in the embedded tag you will see different stuff: for example printers, SCADA-type systems, NAS etc.

Top services on medical network perimeters

Excluding these trivial things, we found Building Management systems that out of date. Devices using the Niagara Fox protocol usually operate on TCP ports 1911 and 4911. They allow us to gather information remotely from them, such as application name, Java version, host OS, time zone, local IP address, and software versions involved in the stack.

Example of extracted information about Niagara Fox service

Or printers that have a web interface without an authentication request. The dashboard available online and allows you to get information about internal Wi-Fi networks or, probably, it allows you to get info about documents that appeared in “Job Storage” logs.

Shodan told us that some medical organizations have an opened port 2000. It’s a smart kettle. We don’t know why, but this model of kettle is very popular in medical organizations. And they have publicly available information about a vulnerability that allows a connection to the kettle to be established using a simple pass and to extract info about the current Wi-Fi connection.

Medical infrastructure has a lot of medical devices, some of them portable. And devices like spirometers or blood pressure monitors support the MQTT protocol to communicate with other devices directly. One of the main components of the MQTT communication – brokers (see here for detailed information about components) are available through the Internet and, as a result, we can find some medical devices online.

Not only Smart Home components, but also medical devices are available via MQTT Spirometer

Threats that affect medical networks

OK, now we know how they get in. But what’s next? Do they search for personal data, or want to get some money with a ransom or maybe something else? Money? It’s possible… anything is possible. Let’s take a look at some numbers that we collected during 2017.

The statistics are a bit worrying. More than 60% of medical organizations had some kind of malware on their servers or computers. The good news is that if we count something here, it means we’ve deleted malware in the system.

Attacks detected in medical organizations, 2017

And there’s something even more interesting – organizations closely connected to hospitals, clinics and doctors, i.e. the pharmaceutical industry. Here we see even more attacks. The pharmaceutical industry means “money”, so it’s another titbit for attackers.

Attacks detected in pharmaceutical organizations, 2017

Let’s return to our patients. Where are all these attacked hospitals and clinics? Ok, here we the numbers are relative: we divided the number of devices in medical organizations in the country with our AV by the number of devices where we detected malicious code. The TOP 3 were the Philippines, Venezuela and Thailand. Japan, Saudi Arabia and Mexico took the last three spots in the TOP 15.

So the chances of being attacked really depend on how much money the government spends on cybersecurity in the public sector and the level of cybersecurity awareness.

Attacked devices in medical organizations, TOP 15 countries

In the pharmaceutical industry we have a completely different picture. First place belongs to Bangladesh. I googled this topic and now the stats look absolutely ok to me. Bangladesh exports meds to Europe. In Morocco big pharma accounts for 14% of GDP. India, too, is in the list, and even some European countries are featured.

Attacked devices in pharmaceutical organizations, TOP 15 countries

On one in ten devices and in more than 25% of medical and 10% of pharmaceutical companies we detected hacktools: pentesting tools like Mimikatz, Meterpreter, tweaked remote administration kits, and so on.

Which means that either medical organizations are very mature in terms of cybersecurity and perform constant audits of their own infrastructure using red teams and professional pentesters, or, more likely, their networks are infested with hackers.

Hacktools: Powerpreter, Meterpreter, Remote admin, etc.


Our research showed that APT actors are interested in information from pharmaceutical organizations. We were able to identify victims in South East Asia, or more precisely, in Vietnam and Bangladesh. The criminals had targeted servers and used the infamous PlugX malware or Cobalt Strike to exfiltrate data.

PlugX RAT, used by Chinese-speaking APT actors, allows criminals to perform various malicious operations on a system without the user’s knowledge or authorization, including but not limited to copying and modifying files, logging keystrokes, stealing passwords and capturing screenshots of user activity. PlugX, as well as Cobalt Strike, is used by cybercriminals to discreetly steal and collect sensitive or profitable information. During our research we were unable to track the initial attack vectors, but there are signs that they could be attacks exploiting vulnerable software on servers.

Taking into account the fact that hackers placed their implants on the servers of pharmaceutical companies, we can assume they are after intellectual property or business plans.

How to live with it
  • Remove all nodes that process medical data from public
  • Periodically update your installed software and remove unwanted applications
  • Refrain from connecting expensive equipment to the main LAN of your organization

More tips at “Connected Medicine and Its Diagnosis“.

Firefox turns out the lights on two privacy-sucking features

Sophos Naked Security - 13 Březen, 2018 - 15:08
Thanks to some illuminating privacy research, it's "lights out" for another pair of esoteric APIs.

‘Hacked’ Facebook taunt leads to 1-star restaurant reviews

Sophos Naked Security - 13 Březen, 2018 - 15:04
Rival football fans either punished the eatery with fake reviews after the "zombies" remark or there was a sudden plague of gastroenteritis.

Tweet thieves suspended by Twitter

Sophos Naked Security - 13 Březen, 2018 - 14:36
'Tweetdecking' plagiarists have been making thousands per month, ripping off jokes and tweets and selling retweets.

Cryptomining isn’t going to make you rich

Sophos Naked Security - 13 Březen, 2018 - 14:05
Is cryptomining-with-consent the simple alternative to web advertising that some publishers think it is? Perhaps not.

How to assemble a GSM phone based on SDR

Positive Research Center - 13 Březen, 2018 - 13:50

The smartphones so familiar to most of us contain an entire communication module separate from the main CPU. This module is what makes a "smartphone" a "phone." Regardless of whether the phone's user-facing operating system is Android or iOS, the module usually runs a proprietary closed-source operating system and handles all voice calls, SMS messages, and mobile Internet traffic.

Of course, open-source projects are more interesting to security researchers than closed-source ones. The ability to look under the hood and see how a particular program component works makes it possible to find and fix errors, plus verify that undocumented functionality is not present. As a pleasant bonus, access to source code helps novice developers to learn from colleagues and make contributions of their own.

OsmocomBB project
These considerations inspired creation of the Open Source Mobile Communications (Osmocom) project all the way back in 2008. Initially, the developers' attention was focused on OpenBSC, a project for running a self-contained cellular network on hefty commercial base stations. OpenBSC was first presented in 2008 at the Chaos Communication Congress annual conference.

Over time, Osmocom branched out into more projects. Today it serves as the umbrella for dozens of initiatives, one of which is OsmocomBB—a free and open-source implementation of the mobile-side GSM protocol stack. Unlike its predecessors, such as TSM30, MADos for Nokia 33XX, and Airprobe, OsmocomBB caught the attention of researchers and developers, and continues to be developed.

OsmocomBB was initially envisioned as a full-fledged firmware for open-source cell phones, including a GUI and other components, focusing on an alternative implementation of the GSM protocol stack. However, this idea did not catch on among potential users, so OsmocomBB today serves as an indispensable set of research tools and learner’s aid for those new to GSM.

With OsmocomBB, researchers can assess the security of GSM networks and investigate how the radio interface (Um interface) functions on cellular networks. What kind of encryption is used, if any? How often are encryption keys and temporary subscriber IDs changed? What is the likelihood that a voice call or SMS message will be intercepted or forged by an attacker? OsmocomBB allows quickly finding the answers to these and many other questions. Some of the many other uses include launching a small GSM base station, investigating the security of SIM cards, and sniffing traffic.

Similar to the case with the Aircrack-ng project and network cards, OsmocomBB's primary hardware platform consists of mobile phones based on the Calypso chipset. Generally speaking, these are Motorola C1XX phones. At the start of OsmocomBB development, it was decided to use the phones in the interest of saving time—otherwise, the process of designing and manufacturing new equipment could drag on indefinitely. Another reason was that some parts of the source code and specifications for the Calypso chipset had been leaked to the Internet, which gave a head start to reverse engineering of the firmware and subsequent development.

However, this expedient came at a price. Phones based on the Calypso chipset are no longer produced, forcing researchers to search for secondhand models. Moreover, some parts of the current implementation of the GSM stack physical layer are heavily based on a Digital Signaling Processor (DSP). The code of this processor is proprietary and not fully known to the public. Both factors create roadblocks for OsmocomBB, reducing its potential and increasing the barrier to entry for developers and project users at large. As just one example, implementing GPRS support is impossible without changing the DSP firmware.

Breathing in new life with a new hardware platform
The OsmocomBB software consists of a number of applications, each of which has a specific purpose. Some applications run directly on a computer in any UNIX-like environment. Other applications are provided in the form of firmware that must be loaded on to the phone. The applications interact through the phone serial port, which is combined with the headset connector. In other words, an unremarkable TRS connector (2.5-mm microjack) can be used for transmitting both sound and data! Similar technology is used in smartphones in order to support headphone remotes, selfie sticks, and other accessories.

Lack of other interfaces (such as USB) and the need to use a serial port also impose certain limitations, particularly on the data transfer rate. The low bandwidth of the serial interface limits the ability to sniff traffic and run a base station. Moreover, a ready-made cable for connecting the phone to USB is difficult to find; in most cases this cable must be DIY'ed, raising the barrier to entry higher still.

Eventually, the combination of these difficulties gave rise to the idea of switching to a different hardware platform that would remove these software and hardware limits. Such a platform should be available to everyone, in terms of both physical availability and price. Due to rapid growth in popularity and availability, Software-Defined Radio (SDR) technology perfectly meets these requirements.

The essence of SDR is to develop general-purpose radio equipment not tied to a specific communication standard. Thanks to this, SDR has become very popular both among radio amateurs and manufacturers of commercial equipment. Today, SDR is actively used in cellular communications for deployment of GSM, UMTS, and LTE networks.

That said, the idea of using SDR to develop and launch a GSM mobile phone with OsmocomBB is not new. Osmocom developers worked on this but abandoned their efforts. A Swiss laboratory also attempted to do so, unfortunately never advancing beyond the proof-of-concept stage. Nonetheless, we decided to resume work in this direction by implementing support for a new SDR-based hardware platform for OsmocomBB. The platform is identical to the Calypso chipset in terms of backward compatibility, while also being more open to modifications.

The remainder of this article will describe the process of developing the new platform, the problems encountered, and the solutions we found. In the conclusion, we will share our results, limitations of the current implementation, ideas for further development, and advice for how to get OsmocomBB working on SDR.

Project history
As mentioned already, OsmocomBB includes two types of applications: some run on a computer and others are loaded on to the phone as part of alternative firmware. The  both sides interact via osmocon, a small program that connects them to each other through the serial port. Interaction occurs using the simple L1CTL (GSM Layer 1 Control) binary protocol, which supports only three types of messages: request (REQ), conformation (CONF), and indication (IND).

We decided to preserve this structure, as well as the protocol itself, for transparent compatibility with existing applications. This resulted in a new application, trxcon (short for "transceiver connection"), which serves as a bridge among high-level applications (such as mobile and ccch_scan) and the transceiver (a separate application that manages SDR).

The transceiver is a separate program that performs low-level tasks of the GSM physical layer, such as time and frequency synchronization with the network, signal detection and demodulation, and modulation and transmission of the outgoing signal. Among ready-made solutions, there are two suitable projects: OsmoTRX and GR-GSM. The first is an improved modification of the transceiver from the OpenBTS project (it is used by Osmocom projects for running base stations), while the second provides a set of GNU Radio blocks for receiving and decoding GSM signals.

Despite the completeness of its implementation and out-of-the-box support for signal transmission, OsmoTRX with its cocktail of C and C++ will not please the developer who values clean, readable source code. For example, altering a few lines of code in OsmoTRX may require studying the entire class hierarchy, while GR-GSM offers incomparable modularity and freedom of modification.

Nevertheless, OsmoTRX still has a number of advantages. The most important of these are performance, low resource requirements, and small size of executable code and dependencies. All this makes the project fairly friendly to embedding on systems with limited resources. By comparison, GNU Radio looks positively gluttonous. Development targeted OsmoTRX exclusively at first, but ultimately the choice was made to use GR-GSM as transceiver.

To ensure backward compatibility, a TRX interface was implemented in trxcon. This interface is also used in the OsmoTRX, OsmoBTS, and OpenBTS projects. The interface uses three UDP sockets for each connection; each socket has a separate purpose. One of them is the CTRL interface, which allows controlling the transceiver (setting frequency, gain, and so on). The second one is called DATA—as the name implies, it exchanges information that needs to be transmitted (Uplink) or that has already been received (Downlink). The last socket, CLCK, is used to pass on timestamps from the transceiver.

We also implemented a new application, grgsm_trx, for GR-GSM. The application initializes the basic set of blocks (flow graph) and provides the TRX interface for an external control application, which in our case is trxcon. The flow graph initially consisted only of blocks for reception, that is, detection and demodulation of bursts—the smallest information pieces of the GSM physical interface. Every burst that is output by the demodulator is a bit sequence consisting mainly of a payload and midamble that allows the receiver to synchronize with the transmitter but (unlike a preamble) is located in the middle.

At this point in development, high-level applications such as ccch_scan were already able to set the SDR to a certain frequency, launch the synchronization process with the base station, and demodulate the received signal. However, these initial successes were accompanied by difficulties. Since most of the implementation of the OsmocomBB physical layer previously relied on the phone DSP, encoding and decoding of packets according to GSM 05.03 specifications was not implemented separately—it was performed with proprietary code.

The newly implemented transceiver would pass on bursts to the upper layers of the implementation, while the current implementation of the upper layers was expecting LAPDm byte packets (mostly 23 bytes each) from the physical layer. Moreover, the transceiver needed accurate Time Division Multiple Access (TDMA) with the base station, even though high-level applications were completely unaware and transmitted outgoing packets when needed.

To fix this, we implemented a TDMA scheduler that accepts LAPDm packets from high-level applications, encodes them into bursts, and passes them to the transceiver, determining the transmission time using frame and timeslot numbers. The scheduler reassembles bursts arriving from the transceiver, decodes them and passes them on to the upper layers. According to GSM 05.03, coding and decoding involve, respectively, adding redundant data to information bits and then recovering LAPDm packets from those padded sequences by using the Viterbi algorithm.

It may sound confusing, but a similar process of encoding and decoding LAPDm packets takes place both on the mobile phone and on the base station. Fortunately, a free open-source implementation already existed, in the form of Osmocom Base Transceiver Station (OsmoBTS). This project's code related to GSM 05.03 was reworked, documented, and moved to libosmocore (the Osmocom project  core) as a child library called libosmocoding. Thanks to this, many projects—including OsmocomBB, GR-GSM, and OsmoBTS—can all take advantage of this implementation without duplicating code. The TDMA scheduler itself was also implemented in a way similar to OsmoBTS, but taking mobile phone workings into account.

After this, receiving was successful! But the most important feature for the functioning of a mobile phone—data transmission—was still missing. The problem was that initially there were no blocks in GR-GSM for modulating and transmitting the signal. Fortunately, project author Piotr Krysik supported implementation of this functionality and contributed to collaboration for this purpose.

To avoid wasting time while data transmission was being worked on, we came upon a temporary workaround. As it turned out later, this workaround was a very useful solution in its own right—a set of tools for emulating the transceiver as a virtual Um interface. Since both OsmocomBB and OsmoBTS now support the TRX interface, the projects can be easily interconnected: each Downlink burst from the OsmoBTS is passed on to the trxcon application, while every Uplink burst from OsmocomBB is passed on to OsmoBTS. A simple application written in Python, called FakeTRX, allowed running a virtual GSM network without any equipment!

Thanks to this set of tools, a large number of bugs in implementation of the TDMA scheduler were subsequently found and fixed. Support for dedicated channels, such as SDCCH and TCH, was also implemented. The first type of GSM logical channels is mainly used for sending SMS messages, USSD requests and (sometimes) establishing voice calls. The second type is used for voice transmission during a call. The GSM Audio Packet Knife (GAPK) project helped to provide basic support in OsmocomBB for recording and encoding, as well as decoding and reproduction of sound, since this task was previously performed by the phone DSP.

Meanwhile, Piotr Krysik developed and successfully implemented all the missing blocks necessary for signal transmission. Since GSM uses Gaussian Minimum Shift Keying (GMSK) modulation, he used the existing GMSK Modulator block from GNU Radio. However, the main problem was to ensure synchronization with the base station. Each burst must be transmitted on time, that is to say, within the timeslot allocated by the base station. Timing buffers in the TDMA system allow compensating for small discrepancies. The situation was complicated by the lack of an accurate clock generator in most SDR devices, due to which the whole system would tend to drift.

The solution we found involves using the hardware clock of SDR devices, such as those from USRP, based on which incoming bursts are stamped with the current hardware time. By comparing these stamps and the current frame number decoded from the SCH burst, it is possible to perform adjustment and set the exact time for transmitting outgoing information. The only problem was that standard GNU Radio blocks designed for interaction with SDR do not support temporary stamps, so we had to replace the blocks with UHD Source and Sink, restricting support to USRP devices.

As a result, when the transceiver was ready for operation, the time had come to venture beyond the virtual Um interface. But some glitch is always bound to come up during the first trial run of something new—and sure enough, our attempt to run the project on real equipment was unsuccessful. We had not taken into account one aspect of timing in GSM: the time count for the signal transmitted by the phone (Uplink) is specially delayed by three timeslots relative to the received signal (Downlink), which gives phones with a half-duplex communication module the time needed to perform frequency hopping. One small adjustment later, the project was up and running! For the first time, with the help of OsmocomBB and SDR, we could send an SMS message and make a voice call.

Thanks to this work, we managed to build a bridge of sorts between OsmocomBB and SDR transceivers functioning through the Universal Hardware Driver (UHD). We implemented the main components of the GSM physical layer that are necessary for high-level applications, such as ccch_scan, cbch_scan, and mobile. All our work was made available to the public in the OsmocomBB main repository.

Now, by using SDR as a hardware platform for OsmocomBB, it has become possible to run a completely transparent GSM protocol stack that is free of proprietary components that have closed source code, such as a DSP of Calypso-based phones, while also allowing on-the-fly debugging and modification of each component. In addition, developers and researchers gain a number of opportunities, for example:
  • Running the network and phone in other frequency bands (such as 2.4 GHz)
  • Integrating alternative audio codecs (for example, Speex or Opus)
  • Implementing the GPRS / EGPRS stack

The tools for creating a virtual Um interface, which we referred to previously, were also published in the project repository. These tools are useful both for experienced developers (for example, for simulating load levels for various components of cellular network infrastructure and testing their stability) and for novice users, who can begin studying GSM in practice without the need to search for and purchase equipment.
However, the current implementation of the new hardware platform for OsmocomBB still contains certain limitations, most of which come from the SDR technology itself. For example, most available SDR  devices, such as USRP, UmTRX, and LimeSDR, have a relatively small transmit power when compared to the maximum transmit power of ordinary phones. Another implementation gap is lack of support for frequency hopping, which enables the subscriber to simultaneously communicate with multiple base stations at different frequencies, which reduces interference and complicates signal interception. Frequency hopping is implemented on the networks of most operators; in addition, GSM specifications define this technology as mandatory support for every phone. While the problem with signal power can be solved with the help of amplifiers or simply by using a laboratory base station, implementing frequency hopping will require much more effort.

Further development plans include:
  • Supporting physical (non-virtual) SIM cards
  • Introducing support for a wider range of SDR devices
  • Supporting Circuit-Switched Data (CSD)
  • Implementing an embedded transceiver based on OsmoTRX
  • Supporting GPRS / EDGE
The project was also presented at 34th annual Chaos Computer Club conference:

Conclusion: tips for getting started with your own SDRHere is our advice for how to run GSM on your own SDR. To start with, we suggest experimenting with the virtual Um interface with the help of our TRX Toolkit:

In addition to OsmocomBB, you will need a complete entire set of central network infrastructure components from Osmocom: either OsmoNiTB (Network in The Box) or all components separately, including BTS, BSC, MSC, MGW, and HLR. Instructions for compiling source code can be found on the project website, or you can use ready-made packages for Debian, Ubuntu, or OpenSUSE.

To test the implementation on your own network, you can use any available implementation of the GSM network stack, such as Osmocom, OpenBTS, or YateBTS. Launching your own network requires a separate SDR device or a commercial base station, such as nanoBTS. Because of the described limitations and other possible flaws, we highly recommended to not test the project on actual operator networks!

To build the transceiver, you will need to install GNU Radio and compile a separate branch of the GR-GSM project from source code. For details on installing and using the transceiver, visit the Osmocom project website.

Good luck!

Author: Vadim Yanitskiy, Positive Technologies

Syndikovat obsah