Cell Broadcast, questo sconosciuto

Dopo i primi test del servizio “IT-alert” i complottari incalliti hanno un nuovo nemico.

Nel loro fantastico mondo dove la terra è piatta, lo sbarco sulla luna è un film di Kubrick, dove ti iniettano i chip con i vaccini e si provocano disastri meteorologici con le scie chimiche, poteva mai mancare il telecontrollo via IT-alert?

Tristezza

Non è mia intenzione debunkare questa follia, sarebbe dispendioso come ci insegna anche la “teoria della montagna di merda“:

“Per produrre una montagna di merda ci vuole poca fatica, mentre per pulirla ci vuole una fatica immensa e comunque l’odore ti rimane addosso. Questa è l’asimmetria fondamentale del cospirazionismo.”

Ne approfitto per scrivere due righe su cosa c’è sotto. Intendo realmente, non nel triste mondo dei tristi complottari.

Il servizio IT-alert sfrutta la tecnologia chiamata “Cell Broadcast” la cui architettura è descritta nello standard 3GPP 23.041 e che esiste da praticamente sempre nella storia del GSM, tant’è vero che è supportata su tutte le reti: 2G, 3G, LTE, 5G.

Stralcio della specifica V3.0.0 del 1999

Probabilmente i complottari, da adolescenti, hanno già utilizzato questa tecnologia sui loro primi telefonini senza neanche rendersene conto. Ma, all’epoca non c’era ancora il ragazzino su TikTok che scopriva i segretissimi piani della NASA e del Nuovo Ordine Mondiale.

Se vi ricordate, sui primi telefoni GSM (parlo ai tempi del Motorola 8700, StarTAC, ecc), sul display vi appariva il nome della rete dell’operatore: “I-TIM”, “I-OMNITEL”, ecc.

Nel menu potevate scegliere un “canale” proprio nella voce “CELL-BROADCAST” e, inserendo 50, appariva il nome della vostra città accanto al nome operatore: “I-TIM NAPOLI“. Ecco, questo era un servizio della tecnologia “Cell Broadcast” che doveva servire agli operatori ad applicare tariffe scontate quando la chiamata era destinata allo stesso distretto in cui il telefono era registrato.

Questo, fino ad IT-alert, è stato l’unico servizio attivo in Italia sulla tecnologia “Cell Broadcast” e probabilmente neanche mai sfruttato dagli operatori del tempo.

Manuale Motorola StarTAC
Manuale Motorola StarTAC, anno 1998

Il Cell Broadcast è definito dall’Istituto europeo per gli standard di telecomunicazione (ETSI) ed è incluso negli standard GSM 3GPP. Si tratta di un servizio di rete mobile basato sulla localizzazione che invia in massa messaggi di testo o binari ai telefoni cellulari nel raggio d’azione di una singola cella, di un gruppo di celle, o all’intera rete.

I messaggi Cell Broadcast subiscono una serie di passaggi che coinvolgono i seguenti componenti:

CBE (Cell Broadcast Entity): è il luogo di origine del messaggio Cell Broadcast.

CBC (Cell Broadcast Center): riceve i messaggi dal CBE e si collega alla rete dell’operatore mobile instradandoli alle celle di destinazione attraverso i controllori RAN.

RAN (Radio Access Network): distribuisce il messaggio di trasmissione delle celle alle celle di destinazione. BSC, RNC, MME e AMF sono i controller RAN rispettivamente per 2G, 3G, 4G/LTE e 5G.

BTS: La cella ovvero il ripetitore.

Dispositivo dell’utente finale: il telefono. Il messaggio può essere visualizzato in modi diversi, a seconda del protocollo specifico e del dispositivo specifico.

I messaggi di tipo broadcast hanno una priorità maggiore rispetto al resto del traffico e quindi passano anche in caso di rete congestionata.

In definitiva, è quasi come la ricezione di un SMS, nessuno vi sta spiando. Dormite sonni tranquilli e siate più sereni. Anzi, se il servizio possa servire un giorno a salvare qualche vita dovreste essere solamente contenti.

Se il servizio sarà utile o no lo scopriremo. In diversi paesi è già attivo da anni.

Esempio di avviso a Los Angeles risalente al 2018

How to detect the parity error in PySerial

The PySerial documentation says that if you pass the parity parameters to the __init__(), the “parity checking” feature is enabled. Easy, but it doesn’t work!

The hack is to manually set the right termios flags importing the termios library in addition to the serial lib.

The right termios input flags (c_iflag) are: PARMRK, INPCK and IGNPAR.

Here is an example:

import serial
import termios

ser = serial.Serial (....)

# Get termios settings
iflag, oflag, cflag, lflag, ispeed, ospeed, cc = termios.tcgetattr(ser)

# Enable input parity checking & parity mark with \xff\x00
iflag |= termios.PARMRK | termios.INPCK
iflag &= ~termios.IGNPAR

# Apply termios settings
termios.tcsetattr(ser, termios.TCSANOW, [iflag, oflag, cflag, lflag, ispeed, ospeed, cc])

The parity error will reported as 0xFF, 0x00 prefix.

Not all USB-UART adapters are the same!

I have three USB-UART adapters, the first is a PL2303 from “Prolific Technology”, the second one is a CH340 from “QinHeng Electronics” and the other is a CP2102 from “Silicon Labs” and I tried to use them in a project involving non-standard baud-rate (1600 bps) on the serial bus.

The PL2303 and the CH340 are capable of non-standard baud-rate talking as long as a fixed parity setting (ODD, EVEN, NONE, MARK or SPACE) is used.

The CP2102 is not capable of non-standard baud-rate communication at all.

I checked with a logic analyzer and some python lines, here are the results.

The test code

import time
import serial

ser = serial.Serial(
    port='/dev/ttyUSB0',
    baudrate=1200, # 1200 or 1600
    parity=serial.PARITY_NONE,
    stopbits=serial.STOPBITS_ONE,
    bytesize=serial.EIGHTBITS,
    timeout=None
)

while True:

    ser.write(b'\x01\x02\x03\x04\x05\xFF\x00')
    time.sleep(2)

Silicon Labs CP2102 test restults

CP2102 @ 1200 bps (standard) – OK
CP2102 @ 1600 bps (non-standard) – BAD DATA

Prolific Technology PL2303 test results

PL2303 @ 1200 bps (standard) – OK
PL2303 @ 1600 bps (non-standard) – OK

QinHeng Electronics CH340 test results

CH340 @ 1200 bps (standard) – OK
CH340 @ 1600 bps (non-standard) – OK

How about 9-Bit framing also know as Multi-Drop Bus (MDB)?

Neither device is capable of talking on a Multi-Drop Bus.

Serial communication with 9-Bit framing (9-Bit protocol, 9 bit mode) is mainly used to identify the address byte within messages running on a RS-485/RS-232 multi-drop network.

On this type of network one “master” controls one or many “slaves”, the 9th bit is used to distinguish the address from the data.

This type of protocol is not a POSIX-standard, but some devices supports the Mark/Space Parity (CMSPAR) and can use the “Parity Bit” to emulate the 9th data bit.

Acting as TX device, the UART parity settings needs to be set accordly with the type of byte to send: sending an address the parity needs to be set to “MARK” (logic 1), for the data parts the parity needs to be set to “SPACE” (logic 0).

Changing MARK to SPACE parity settings on the fly (reconfigure the UART without closing and reopening the port) is supported by PySerial, but my devices are not behaving as expected.

Acting as RX device, the value of the 9th bit can be recovered observing the parity-error. For example: settings the UART with SPACE parity, we should receive a parity-error when an “address” is received.

Unfortunately, this does not work with any of my devices via PySerial library.

How to run Splashtop for RMM on Linux

Splashtop for RMM on Linux

Splashtop is a remote support software that enables remote computer access for IT support included in several RMM (Remote monitoring and management) like NinjaOne.

Unlike “Splashtop for Business”, “Splashtop for RMM” is not available for Linux, but you can run it with Wine adding a “st-rmm://” protocol handler to your system.

Tested with NinjaOne, Splashtop for RMM v3.4.6.1, Ubuntu 22.04 LTS with wine-7.22 (Staging).

Check this repo for all the needed: https://github.com/siddolo/splashtop-for-rmm-linux