maZZoo maZZoo's blog
very low frequency tech postings  -  dect

    code [12]
    dect [4]
    hard [8]
    meta [5]
    security [5]

jul 2009 (1)
jun 2009 (1)
jan 2009 (2)
dec 2008 (1)
oct 2008 (1)
jan 2008 (1)
oct 2007 (1)
jun 2007 (1)
feb 2007 (3)
jan 2007 (3)
nov 2006 (2)
aug 2006 (2)
jul 2006 (1)
may 2006 (1)
nov 2005 (2)
oct 2005 (1)
apr 2005 (2)
mar 2005 (2)
feb 2005 (1)
jan 2005 (1)
may 2004 (1)
jan 2004 (1)
apr 2003 (1)
jan 2003 (1)

Sun, 18 Jan 2009

the "hidden" gigaset menu and how to use it as a poor man's attacking tool

before I get into the above title, lets step back, and let me drop a few word about our very first practical attack against DECT.

impersonating a FP (basestation)

In the DECT standard a mutual authentication between PP (portable part, the "phone") and FP (fixed part, the basestation) is forseen, but it is optional. In all cases we have examined only the PP is authenticated by the FP, but not vice-versa. That means a FP can be sure what PP it is talking to, but a PP is left blind as to whether the basestation is really the one it once was shipped with.

  1. think of a victim's PP which ran out of batteries, is switched off or out of radio range
  2. the victim's FP will still broadcast its identity, the RFPI (radio fixed part identifier)
  3. the attacker takes another FP of her choice and modifies it to broadcast the victim's RFPI
  4. the attacker modifies her FP to accept any PP without authentication
  5. the victim's PP comes back (batteries loaded, switched on or comes into radio range)
  6. the victim's PP will try to find its known FP by RFPI and chooses probably either the first seen, or strongest radio signal
  7. in case the victim's PP decides to use the attacker's FP, the victim lost. All outgoing calls will be sent over the attacker's FP
  8. in case the victim's PP hears both FPs equally loud, the attacker's chance to succeed is 50% (and directional antennas help)
The attack has been proven to be practical in spring 2008. Any further details or implemetaions weren't and won't be released by the team.

The attack is possible due to two big fuckups:
  1. the DECT standard enforces that a PP will aways accept unauthenticated/unencrypted FPs/calls. Even if a PP usually does all possible authentications and ecryptions, it will fall to the attacker, as she accepts the victim's PP without all those bells and whistles
  2. the DECT manufacturers seemingly never implemented mutual authentication, atleast for what we have examind

Please, get that fixed!

In this scenario the attacker still has a lot of margin. As mentioned above, directional antennas can help, but the second idea is to jam the original basestation just by radio interference. So our idea in the early stages of the project was to first implement a DECT radio jammer with the com-on-air card. But at that timeframe the com-on-air card was still a big miracle to us, and really being able to use it only started at december 4th 2008. While the com-on-air jammer is technically possible we have never gotten down to implementing it, maybe one bored day we will...

Now back to the title and jamming with gigasets:
During the 25c3 BeF from the POC showed me a litte trick you can do whith almost all Siemens gigasets (or magenta clones):

switch off your gigaset.
press 1 4 7 simultaneously and keep them pressed while powering on again

(no picture)
now by pressing random numbers you will get some nice screen or display tests, which heavily depend on the model you have.
now restart, switch the gigaset off and on again, keeping 1 4 7 pressed, and once the [service] screen shows up, enter 76200. This will lead you to the service menu.
here you can do various stuff, reading the IPUI, SW-version. Interesting is the "Metering mode".
on the right you see

090 : RSSI value of the FP
1 : channel number (0-9)
01 : timeslot number (0-11)
16H : least significant byte of the RFPI
100 : 100-bit error rate in %

this is fun so far, but doesn't jam yet. Now for jamming re-enter the service menu (keep 1 4 7 pressed while powering on, enter 76200), and select SAR from the menu. SAR means "specific absorption rate" and is a measure of the radio emission a device creates. When selecting SAR you will end up in another menu "1 slot"/"1slot low"/"2 slot" or the like... select the "biggest" one. The menu items probably heavily depends on what your phone supports of halfslot/fullslot/longslot/doubleslot/ecomode. Finally you're confronted with another selection fLOW/fCENTER/fHIGH. Select fLOW for jamming channel 0, fCENTER for jamming channel 5, and fHIGH for jamming channel 9.

here's my measurement setup using a spectrum analyzer with a crappy GSM antenna and a recent gigaset

The gigaset guys seem to have gotten the channel/frequency mapping wrong, their fLOW is the highest DECT frequency, their fHIGH is the lowest DECT frequency; DECT channels go from 0-9 starting at the highest frequency, and channel 9 being the lowest frequency. Here's what I measure with the gigaset jammer:

Now if our attacker is lucky she find's the victim's FP in channel 0, 5 or 9. She can also wait until it jumps there. She adds a directional antenna to her crappy old gigaset, pointing to the victim's PP, and is much more efficient with the above attack.

posted in /dect  |  link  |  comments [3]   
Tue, 06 Jan 2009

back from berlin

For the first time in almost a decade I contributed more than "being there and having fun" to the annual CCC conference in Berlin. We held a talk on DECT, the out-of-the-box-it-works standard for cordless home phones, being widely spread in Europe an Asia.
We could show that pretty much of the phones out there are completely unencrypted, and can be intercepted by a 20Euro Laptop card, and a linux driver and toolset that krater and I hacked up within the last months. On top of this the cryptographers of our team could show up various weaknesses in the remaining encrypted setups:

  1. impersonating a basestation, as-in: hijacking all your neighbours phones
  2. implementation weaknesses in the random number generator of various manufactureres, as-in: doing phonecalls on you neighrbour's installation
  3. cryptographic attacks on the key-exchange algorithm between a base-station and a handset
  4. direct attacks on the stream cipher which is supposed to keep your privacy during a phonecall

All-in-all we hopfully communicated that you'd better not use your cordless phone for any purpose. If you try to resist feel yourself manipulated by what you read here, and better know: they're all listening!

Now one of our main intents and expectations from what we did is that we all can buy really secure cordless phones within a year from today in our favorite supermarket.
the (probably incomplete) catalogue of demands to the DECT industry includes:

  1. AES, blowfish, serpent, or some other publicly worn-off robust cipher for the phonecall
  2. RSA, ElGamal, ECC, or some other publicly worn-off robust key exchange between basestation and handset
  3. mutual authentication, that means both the handset and the basestation cryptographically know who they're talking to, not as today where a victim's handset will happily accept talking to a hacker's fake basestation
  4. perfect forward security. PFS means that even if an eavesdropper records your encrypted calls for days and nights, then intrudes to your home and steals the phone to recover key material, with all skills (s)he may not recover your recent phonecalls
  5. a clear (although technichal) display to the user which key-exchange and which stream-cipher is currently being used. Maybe being a lock icon in the display, which one can gater context information about

DECT is just another proof that security by obscurity does not work. So much of CCC's work ends up just in this one mantra "security by obscurity does not work". So now everybody stand up and say it loud "security by obscurity does not work".

back to the fun part of Berlin's visit:

a dect-sniffer in Berlin, still hiding behind the balustrade

a dect-sniffer in front of the chinese embassy, I do admit they have the better antennas (top right)

a dect-sniffer not so much hiding in Berlin on Jannowitzbruecke, heading for 25c3

This time I went to Berlin by ICE, the fast german trains. And those trains run some kind of DECT installations, I saw three basestations in both of the ICEs going to Berlin and back, and they had sequential RFPI numbers.
The board personel seems to use the installation for communication using normal handsets, the recordings show B-fields in normal fullslots, and no encryption. But then exactly at the moment an announcement over the ICE speakers started, my tools began recording a new pcap file with double-slots.
So seemingly the ICE board speakers can be controlled using DECT, and the audio is some kind of high quality wideband audio codec which is being transported in DECT doubleslots, i.e. using twice the bandwidth of normal DECT calls.
As of now our tools only support one type of audio codec, the widespread G.721/G.726 ADPCM codec. So if you're into codecs or the DECT story, get the file

and try your best to get some audible fragments out of it. This will only work like 50%, as our driver firmware currently cuts off reception after the length of a fullslot. So if you want to contribute, try to get that running, this would be a high motivation for us to really support doubleslots in the firmware, too.

To read the DECT standard in all of its glory go to, register by email, and download all EN 300 175-[1-8] standards.

Update: Not all ICEs have such high quality wideband audio DECT doubleslot installations. Some announcements come in crappy telephone quality:

posted in /dect  |  link  |  comments [0]   
Sun, 28 Dec 2008

talk at 25c3 is announced

after pausing for one year I am back at 25c3 the annual CCC conference in Berlin between Xmas and New Year.


So far it's been very nice to meet up with friends and people I work with for some time now. The last two month I was busy getting the Dosch+Amand DECT card to do something useful. And it seems we're getting somewhere.

There will be a talk on day 3 at 17.15h in Saal 1, and its simply named "DECT". We'll have fun with the protocol, its security, and yes, we'll have quite a bunch of open-source code going public after tha talk. For now we keep our stuff still under the hood on

If you're around and want to meet me, my DECT number is 6299, "mazz". We'll see if that one still works after the talk :P

posted in /dect  |  link  |  comments [0]   
Fri, 03 Nov 2006

DECT pcmcia cards

DECT today is seldomly found in the context of PCs. One of the few solutions out there is a Com-On-Air PCMCIA card, originally manufactured by Dosch+Amand, today solely sold by ARC Computer.
They're designed to be used with a Windows software, which then turns the PC to a DECT-VoIP (SIP) gateway.
I got my self one of the Type III and one the Type II PCMCIA cards, but figured out that there's no Windows around here. I hope to get something working on that card under linux, and I can think of more than only a DECT basestation.

As there's no public documentation for the DECT-baseband processor, I probably have to do some (and learn!) reverse-engineering to get linux-support. For now I had a look at the Windows drivers using the HT Editor which seems a brilliant (free) way to reverse-engineer all sorts of Win-SW (and even VxD LE driver binaries) under other OSes.
The CR16 CPU in the baseband processor can be programmed using AS.


- National Semiconductor PCMCIA/PCcard interface PCM16C010 (datasheet, local copy)
- National Semiconductor DECT-baseband processor SC14421CVF, contains a CR16 CPU (no public documentation, share your knowledge!)
- 2kByte microwire EEPROM 93LC86, organized as 1k*16 (datasheet, local copy)
- 512kByte Flash PAI001, only on the Type III card (no datasheet either)
- HCT04 hex inverter
- analog radio Type III card: LMX3161 radio transceiver (datasheet, local copy)
- analog radio Type III card: 2205AF .5W RF power amp
- analog radio Type II card: didn't look at the (availability of datasheets of) devices yet
- only Type III has a LED


If you happen to know anything about
- the DECT baseband chip SC14421CVF or others from the SC144xx family
- the flash PAI001, and why it is only on the Type III card
- the SW architecture/split of the Windows SW that comes with the cards
- any open source driver using the PCM16C010 PCMCIA/PCcard chip (OK, it's documented, but ...)
please contact me and share your knowledge.

com-on-air Type III card HW porn:

top side overall:


PCMCIA controller:


DECT baseband controller:


bottom side overall:


flash and EEPROM:




radio TRX:


radio PA:


com-on-air Type II card HW porn:

top side overall (bottom side has no components):


Type II digital chipset (only differs from Type III in that it has no flash)


radio (all different than on Type III):


Update: the "512kByte Flash PAI001" was identtifies as hex inverter.

posted in /dect  |  link  |  comments [4]   

validate HTML