I just read bunnie's brilliant post on H1N1. I just want to recommend it to you, take some time and follow the links. It left my mind with lot of good and evil ideas - such as when is the right time to start a company selling RNA/DNA-firewalls to sequencing companies.
While I am still reading on the subject I stumbled across the Spiegelman monster which does biological replication in impressive 36 bytes.
Update (2009-09-22): It seems the industry is keeping pace with my ideas. VeriChip filed patents to develop implantable virus detection systems in humans. H1N1 and others are to be detected by those patented biosensors. Now, suppose there's really a small industry coming up with those products. Inevitable also new (royality-free) virusses will come up. In the computer-anti-virus industry we have seen that some of the companies came up with own virus creations to have a competitive advantage over others in the same industry, or simply to sell more products. Whether this holds true for an anti-human-virus industry or not - filing patens on the countermeasures on diseases, is a violation of Human Rights atleast in my eyes. And I am not saying "the United Nations Universal Declaration of Human Rights" but the basic humanitarian idea behind human rights in general. As of today we have some piles of patents on medication, plants, animals and maybe soon humans. The United Nations need to act now, and declare all of them invalid, illegal and void. (via Fefe)
geocaching is fun, GPS devices are cheap, and nowadays get integrated into mobile phones. But mobile SW is crap.
I had a WinCE5.0 based HTC device (o2 XDA Orbit/HTC Artemis/HTC P3300/T-Mobile MDA Compact III). While the HW sounded promising, the Win-SW is completely crap, often the phone traps into a state where everything still works, but the phone won't react on incoming calls. The good thing about the device is that starting TomTom almost turns it into another device. TomTom is a great navigation SW, that I like and I still use the device for that.
For geocaching however TomTom5.0 is also not very smart, as geocachers note their coordinates in such a form:
DDD° MM.MMM', DDD° MM.MMM'
N 48° 12.345', E 12° 34.567'
whereas TomTom only shows coordinates in this style:
N 48.20575°, E 12.57612
now for a normal geocache this is no problem - you calculate your destination coordinates at home and enter them in the format the device likes.
But for a multicache it becomes nasty, you only discover coordinates for the next hint on the way, and have to calculate them en route. Sitting with a calculator or the calculator SW in your mobile phone takes much of the fun of geocaching.
For some month I use a Nokia E71 - it was recommended to me, and I like it - the type of bugs and crashes is different, but its a revelation alone not to see random windows error message popups. Mobile SW still has a long way to go.
But the Nokia E71 is not any better, GPS wise. The shipped Nokia GPS application only shows coordinates in the same format as TomTom:
N 48.20575°, E 12.57612°
So I started looking for a simple geocaching SW that met my requirements:
- runs on one of my 2 devices
- coordinates displayed in the geocaching style DDD° MM.MMM', DDD° MM.MMM'
- works offline (I don't have a flatrate nor am I expecting every cache to have 2G/3G coverage, also I am unwilling to pay)
- opensource would be nice but is no must
I looked at like 10 different "solutions" which all failed for me. So I did something - and hopefully unique - I wrote a JAVA(tm) program:
It's very minimalistic, and has all features you need for a successfull sunday multi-cache.
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.
think of a victim's PP which ran out of batteries, is switched off or out of radio range
the victim's FP will still broadcast its identity, the RFPI (radio fixed part identifier)
the attacker takes another FP of her choice and modifies it to broadcast the victim's RFPI
the attacker modifies her FP to accept any PP without authentication
the victim's PP comes back (batteries loaded, switched on or comes into radio range)
the victim's PP will try to find its known FP by RFPI and chooses probably either the first seen, or strongest radio signal
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
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 dedected.org team.
The attack is possible due to two big fuckups:
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
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
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.
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:
impersonating a basestation, as-in: hijacking all your neighbours phones
implementation weaknesses in the random number generator of various manufactureres, as-in: doing phonecalls on you neighrbour's installation
cryptographic attacks on the key-exchange algorithm between a base-station and a handset
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:
AES, blowfish, serpent, or some other publicly worn-off robust cipher for the phonecall
RSA, ElGamal, ECC, or some other publicly worn-off robust key exchange between basestation and handset
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
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
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 ETSI.org, register by email, and download all EN 300 175-[1-8] standards.
Not all ICEs have such high quality wideband audio DECT doubleslot installations. Some announcements come in crappy telephone quality:
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 dedected.org.
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
I had designed a board for the transceiver back in last spring and am still awaiting the first samples. The CC1110 main features are:
315/433/868/915 MHz GFSK radio
8051 CPU @ 24 MHz (@1 instruction per cycle, not 12:)
128 bit AES coprocessor
32 kB flash
4 kB SRAM
5 channel DMA engine
The board I designed couples the CC1110 via a FTDI to a USB host PC. For the RF part I still need to design a power amp board, as I am targetting a small frequency slot between 869.40 and 869.65 MHz, where (atleast) in germany we're allowed to operate at 500 milliwatts ERP.
A far-in-the-future target of this spare time work will be an encrypted ad-hoc radio network layer.
If I made you curious, just wait for more to come.
If you're an enthusiastic developer, contact me, I may need your help.
you all know these flash-card readers which are being sold as 12-in-one readers or 23-in-one or even 42-in-one readers. I have one of these for a while now, which I had gotten from a flea market for 2 Euros. And for my new mobile phone I had gotten one of these tiny 2GB microSD cards.
The reader had worked fine with one of my old 32MB MMC cards, but not with the 2GB card. I was tempted to blame the linux kernel driver, but the investment of 20 Euros (what a fair price, I live in the jungle:) for a new reader proved it was a problem of the reader. Such a reader basically is a USB-based SPI-controller which translates host requests to SPI which the card understands. SPI itself has no addressing scheme, so the controller is to blame, having a limited address-space.
If you ever have trouble with a non-working flashcard, and find somthing like this in your logs:
kernel Initializing USB Mass Storage driver...
kernel scsi0 : SCSI emulation for USB Mass Storage devices
kernel usb-storage: device found at 3
kernel usb-storage: waiting for device to settle before scanning
kernel usbcore: registered new interface driver usb-storage
kernel USB Mass Storage support registered.
kernel scsi 0:0:0:0: Direct-Access IC USB Storage-CFC 301b PQ: 0 ANSI: 0 CCS
kernel scsi 0:0:0:1: Direct-Access IC USB Storage-SMC 301b PQ: 0 ANSI: 0 CCS
kernel scsi 0:0:0:2: Direct-Access IC USB Storage-MMC 301b PQ: 0 ANSI: 0 CCS
kernel scsi 0:0:0:3: Direct-Access IC USB Storage-MSC 301b PQ: 0 ANSI: 0 CCS
kernel usb-storage: device scan complete
kernel scsi.agent: disk at /devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/host0/target0:0:0/0:0:0:2
kernel scsi.agent: disk at /devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/host0/target0:0:0/0:0:0:3
kernel scsi.agent: disk at /devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/host0/target0:0:0/0:0:0:1
kernel scsi.agent: disk at /devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/host0/target0:0:0/0:0:0:0
kernel sd 0:0:0:0: Attached scsi removable disk sda
kernel sd 0:0:0:1: Attached scsi removable disk sdb
kernel sd 0:0:0:2: scsi: Device offlined - not ready after error recovery
kernel sdc : READ CAPACITY failed.
kernel sdc : status=0, message=00, host=1, driver=00
kernel sdc : sense not available.
kernel sdc: Write Protect is off
kernel sdc: Mode Sense: 00 00 00 00
kernel sdc: assuming drive cache: write through
kernel sd 0:0:0:2: Attached scsi removable disk sdc
kernel usb_id: usb_id: unable to access '/block/sda'
kernel usb_id: usb_id: unable to access '/block/sdc'
kernel usb_id: usb_id: unable to access '/block/sdb'
kernel scsi_id: scsi_id: unable to access '/block/sdb'
kernel scsi_id: scsi_id: unable to access '/block/sdc'
kernel scsi_id: scsi_id: unable to access '/block/sdc'
kernel scsi_id: scsi_id: unable to access '/block/sda'
kernel scsi_id: scsi_id: unable to access '/block/sda'
kernel scsi_id: scsi_id: unable to access '/block/sdb'
get a new reader. If you want warranty forever, don't buy in germany (as I did, not reading the fine print ;). Italians: leave the country! Warranty for your great grantchildren's 22 ExaByte cards is to get elsewhere.
Some two weeks ago I had spilled coffee over my laptop. Not too much, but I feared the desaster and immediately turned the laptop upside-down and wiped it dry. The machine kept working and I almost forgot about it, also I don't reboot very often. Until I installed the new 2.6.20 kernel yesterday. I rebooted and the BIOS splash screen sat there unusually long while the HDD-LED was blinking wildly. The harddisk wasn't recognized anymore.
To ensure I didn't fuck up the bootloader I booted a live-CD and could confirm the harddisk was still working propperly, and the bootloader was installed correctly. So the fear of dataloss (not too much but still nasty) was gone. The biggest remaining fear was that the mainboard's HDD-controller was gone. But first I removed the harddisk and found ... coffee with sugar!
I wiped the board clean with a cloth of microfiber and distilled water. Luckily the component side had no traces of the brew. Rebooted, and the BIOS talked to the drive again. Not being a chemist I am still wondering what is so conductive in completely dried coffee with sugar?
Note to self: next time do performance tests on a harddrive on caffeine ;)
linux still has no live kernel update
we're still better off drinking coffee with sugar than with salt
I was in close contact with AVM the last two days and they did a good and quick job; I had gotten that firmare this morning already but only found time now to test it. It IS fixed :)
So to AVM I need to say: thanks for all the Fritz! And for the rest of you who might still be disappointed about the long time it took from my first report to the fix, one of the remarkable statements from AVM was that because there was no remote execution vulnerability or any danger of information leakage at any time they just planned to fix the DoS condition in the next feature release. Real security threats will still be handled immediatly. Hope the day for proof doesn't come :P
Sending a zero-length UDP packet to port 5060 (SIP) of a Fritz!Box will crash the VoIP-telephony application. This works from any IP-interface, including the DSL line.
The vendor AVM was notified almost six month ago, he stated he had a fix still on that same day, but failed to release any firmware updates containing the fix. Nevertheless AVM did release a new (vulnerable) firmware version 14.04.25 in December 2006, and later they had sent me a firmware image in January to test against the DoS. I couldn't test that Jan-image as it kept bricking my 7050 whenever I configured the DSL internet interface.
I had sent a report of various tests I did with the Jan-image to AVM, and got ... no reaction. The only thing I noticed is that they have removed the December 2006 image..?!
Here's my personal DECT paranoia conspiracy theory: the kernels of the Dec. and Jan. images contain the string "DECT+AnnexA", and AVM had to remove it for license issues. AVM going DECT?
obviously the firmware images still contain a linux kernel with the respective license, so here they are. Source code to be obtained from AVM.
actually I had preferred to title this blog post "update your Fritz! box now"...
about a year ago in Jan 2006 I had discovered a very simple DoS against the telephone application in my Fritz! box 7050. It is triggered by a single UDP packet and works from the internal LAN, as well as from the internet. For the less technichally inclined reader: UDP means the packet can be even spoofed, which leaves the victim blind about who the attacker was...
The effect is that outgoing phonecalls won't work anymore.
I kept updating my Fritz! box with various firmware releases from AVM, but the bug wasn't fixed. So on July 21st 2006 I contacted AVM about the bug, and they stated were able to reproduce and fix the bug within the same day (hey, and they did that on a friday afternoon!).
I tried to be kind and told them I wanted a fix within two month, and that I will not disclose the bug within that timeframe. AVM was even kinder and sent me a T-Shirt plus some more HW bakshish (including that same vulnerability :), and the promise that the bug will be fixed with the 2nd-next firmware-release, as the subsequent release was in the next week, and it was too late to include the fix...
Then there simply were no more firmware updates for monthes. Now on December 13th 2006 a new firmware version 14.04.25 was released. I tested it this morning, but guess what? 14.04.25 is still vulnerable.
So I contacted AVM again, this time with a strict time constraint of 14 days, after that I will disclose what that UDP packet looks like.
BTW: I didn't look at the details, but it "feels" as if this bug doesn't lead to remote execution.
Read more on Jan 17th here...
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:
DECT baseband controller:
bottom side overall:
flash and EEPROM:
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.