 I was not attending Congress this last year because I just moved into a new house and had lots of other things to do. And then I still wanted to take a break from all the, you know, building renovation and other things and wanted to have some fun and I decided I should do something that is not related to GSM or the other things that I do all the time. So I thought, okay, let's have a look at these deck base stations that are used now also by the POC, the phone operation center at the CCC events. So why decked? Well, because I already have some history with decked, which was about 10 years ago. There was a project called the decked.org that I was slightly involved with. I didn't really do all the technical stuff, but still at that time a group of security researchers were publishing security problems in the decked standard and in implementations of decked systems at the time. And while decked is an Etsy standard, so it's always fun to work with ITU and Etsy standards and to look at obscure communication systems, it's also still very much used today. And contrary to GSM or UMTS, we haven't really heard of anyone talking about a sunset of decked, so it's likely going to be around for quite some more time. As I said, the CCC phone operation center, the event phone guys have also switched to a one specific vendor or one specific system that implements decked. So the terminology that we are going to be using here, among other things, actually the slides were just in time production, so the terminology is not complete. So an RFP is a radio fixed part, there's also a PP, which is the portable part. So the MS, which is also called the UE in our world, is called the PP here. And the RFP is more like a VTS in our terminology. And then in the decked system by this company that we are looking here, we also have the OM, which is the open mobility manager, which is more like an MSC or something like that in our coming from a GSM, looking at this from the GSM angle. So I don't really want to talk too much about decked, just a very few things in the beginning about it. It's a TDMA system working in somewhere between 1.8 and 1.9 gigahertz range. So we have time slots like in GSM. We have carriers like Arfkens like in GSM, they're just a bit more wideband than GSM carriers, but otherwise relatively similar. So we also have some broadcast channels and some dedicated channels and things like that. Also interestingly, the DLC protocol, data link control, I think is how they call it, is very much like LabDM, but not the same. So we have a rather similar layer 2 protocol than GSM inside those dedicated channels. Interestingly they slice another protocol layer in between. So there's a MAC protocol layer between DLC and the physical layer. So LabDM is not directly on the radio channel, again looking at this from GSM point of view. And then in the end, they also have some layer 3 protocols like call control and mobility management, which are in principle doing more or less the same things like we see in GSM, but of course they are encoded completely different. So of course we also have a setup message, but the TLVs are different and the information element identifiers are different and so on. So it really looks like you tell two groups of developers develop a TDMA based radio system communication system and it should offer telephony services and all of them have some free existing knowledge about ISDN and then the two of them create GSM and DECT. And same ideas, same principles, but completely different encoding and lots of differences in the details. So one big difference though compared to GSM is that in DECT in the specs only the radio interface is specified. So in GSM we know there are all the different interfaces in the infrastructure, the radio interface and the A-Bus and A and all the network elements, the MSC, the BSC, all of that is specified in rather comprehensive detail, whereas in DECT they only specify the radio interface and they basically say well if you do anything on the infrastructure side it's up to you. In the common use case that you find in homes basically looks like this, we can of course make that larger if we remember how to do it. So we have two portable parts, we have radio interface, we have one fixed part and then there is a POTS ISDN SIP whatever connection and that's your cordless phone at home which is of course rather obvious that you don't want to specify that there is a BTS and a BSC and an MSC and what not in there and there are all kinds of protocols in there. I mean it's basically a NITB from our point of view. If we look at larger installations then the network grows and becomes more hierarchical. So we have multiple of those radio fixed parts and they have some whatever proprietary backhaul protocol to whatever proprietary core which then talks ISDN or SIP or whatever two external telephony systems out there. And that's basically the kind of system that we're looking at and we want to look at these proprietary bits and at these RFPs which are the base stations in DECT technology. So the protocol stacking looks like this if we want to look at the usual protocol stack diagrams that we know from other cellular technology, we have the physical layer here in the portable part in the phone, we have a MAC layer with the DLC layer on top and then we have the NWK layer which is basically what we know as layer 3 which contains call control and mobility management messages. In this particular implementation then we have an RFP which doesn't do anything else but implementing the FI and the MAC layer and then we have some backhaul to a central network element which is called the OM which implements basically the DLC and the NWK layers and here in between we have a TCP IP based protocol that I called AAMIDE which is the AASTA MitreDECT protocol. We don't know how this protocol is called, it's a proprietary protocol between two network elements and I had to come up with an acronym that wasn't used yet. So I came up with this rather handsome acronym. So let's look a little bit at these DECT base stations, the RFPs, there's multiple generations of those devices. I've only seen Gen 2, 3 and 4 base stations, I don't know what Gen 1 looked like. Of course we have to keep in mind that traditionally of course this proprietary interface here was probably more something like ISDN or so in older DECT installations but now in the modern days of course this is IP based and that's also the case for what I analyzed. So at least these Gen 2, 3 and 4 base stations are all IP based. So the Gen 2 RFPs have an interesting ancient TI MIPS with dual DSP processor, I only know from TI the ARM plus DSP processors but apparently they also did some MIPS CPUs some time ago and there's some NAND flash, some RAM and Ethernet PHY and an MPCI slot for, not MPCI-E, MPCI, the old four Wi-Fi cards. And next to that there is a DECT baseband processor with its own flash and RAM and some whatever ADPCM chip so some Kodak chip and an actual 16C550 UART, I haven't seen those in a long day, you know ever since I would say at least the early 90s I haven't seen a physical 16C550 yet. So those are not so exciting because basically there's entirely only proprietary software on those components and it's not as easily hackable but what becomes rather interesting is the Generation 3 RFPs which are at least two of them are RFP35 and RFP43, these are the product numbers because they contain a Marvel Kirkwood ARM SOC if you've ever played with a Shiva plug then you know these devices and they actually run an almost, I think a part, it's probably like 100 lines of patch or even less, now less than 100 lines of patch compared to mainline Linux on there, 3.2.73 kernel and the Kirkwood has two Ethernet ports, one points to the DECT baseband processor and the other one points to the backhaul. So you basically have a completely open, freely programmable mainline Linux supported Linux chip next to the DECT processor, in between the DECT processor and the backhaul of those devices. The DECT processor used is not yet known at this point, nobody has unsoldered the shielding cover yet of a device, it wasn't really necessary at this point and you have an accessible serial console for Uboot and Linux access and the root password is actually known even without spelling mistakes and it's even officially documented. So basically whatever password you configure in your OMM backend is actually pushed down to the RFPs. So all the RFPs will get the same root password set by means of A, I think they do something like there is an overlay RAM FS and then ETC password is sort of mounted from that overlay RAM FS and the ETC password file is copied from the central machine or something like that. So you cannot log in as root but you log in as a known user and then you can do sue and your root at the device and you don't need to do any hacking. That's the way how the equipment ships. So your root on this, this is how a circuit board looks like if it is not zoomed correctly. This is more like it while the Ethernet sockets we don't need to want to see. So we have the circuit board here. You see lots of shielding covers. This is where the deck basement processor is located underneath and this is some whatever RF analog chain related to it under those four shielding covers. Under this heat sink is the Marvel Kirkwood. This is the RAM next to it. This is the LAN flash next to it. Here we have the Ethernet transformer, the PoE power supply. This is the DC input. This is the Ethernet jack and this is the USB-A interface where you can attach whatever peripherals. It's quite interesting that they exposed this. And if you flip it around on the backside there's an MPCIE slot with USB so you can again put in a Wi-Fi, no it's actually sorry it's not USB. It's an actual MPCIE with PCIE on it from the Kirkwood so you can attach a Wi-Fi card. Instead you can basically deploy a combined decked access point and Wi-Fi access point in a single device. And so one of the first things I of course did is I since it runs Linux and it's an embedded device I made a test purchase. And interestingly yes it ships with the GPR and with a written offer and I made an inquiry to the address that was stated to get the source code for the Linux and so on. And the first very positive response was I got an automatic response from a request tracker I was like you somebody else uses RT that's great. And then there was apparently a person at the other end that even knew me and I also vaguely remember the name from some I don't know how many ages ago I've read this name before in the context of free software and very soon afterwards I had a CD in my hand or DVD which contained rather complete and building source code for all the free software on it. So definitely they did that part right. And it's actually a subsidiary in Berlin that's doing the development which I already suspected based on time stamps and some names that I could find in the firmware images and looking at the company history. So you get the source code. I think what did they use? Was it build route? But the build system is rather easy to figure out which one was used and you can create a matching cross compiler and so on very easily and then install your own binaries there. So the high level architecture to look at this again. We have our antenna going into the decked baseband processor and then we have the Marvel Kirkwood here. The main communication interface is this internal Ethernet. There's also a UART and some GPIOs and the fun part is the decked baseband processor apparently doesn't have any flash associated with it. It just has a ROM boot loader which makes it appear on the UART and then the actual Ethernet boot loader is downloaded over X modem or whatever into the UART into the decked baseband processor and then the remaining software is downloaded over Ethernet into the device and then they speak some proprietary internal Ethernet protocol here and you have some GPIOs to toggle power and reset and so on to control this processor. And as I said all of this is done from the rather standard Linux here on the right hand side. Yeah, U-boot is from 2013 that exposes there. So you see there's 128 megs of RAM and flash there. The kernel boot log, well I'm not going to read this to you. You see the Marvel part number and this is really exactly the same model down to the last digit that's used in those Shiva plug devices where Marvel has released the full manual for all the registers and everything without NDA or anything so it's really nice to hack with. This is the partition map of the NAND flash. So you see U-boot with persistent environment and the backup partition and flash file system and apparently VAR and they use UBFS for those file systems there. Now if you want to play with the firmware images because actually the devices they download their firmware over TFTP from the central server in the network and if you want to look at this there are these download files that are part of the official software releases IP RFP 3G, 3G is for third generation not for 3G telephony. Download and if you play with it and you find the offsets then you can get the U image, the init RD and all that stuff out and yeah I can basically investigate the root file system and so on if you don't want to do it on the live system. There's some interesting user space programs that you can find in there. The two main parts is the IP RFP program which is really the program doing all the deck related stuff which makes heavy use of a libom.so and then you see there are some .bin files which are the binary firmware images that are used on the deck baseband processor and by the way none of this seems to use any cryptographic signatures or any kind of verifications whatsoever so it's extremely hackable in a nice way. This is not criticizing, I'm very happy that one can play with it. Yeah so interestingly there is the normal firmware then there's something called macmoni.bin which yeah well it seems to be a Mac monitor firmware but it's not documented or not used by the normal code that we could find. This has no documented feature about it and there's like extremely comprehensive documentation about how you set up these systems and how you configure it and so on. Yeah and then there's the bootloader itself which is loaded over TTYS1 over this UART internally. Now if you since you have these two Ethernet interfaces what do you do? You start the TCP DOM on this internal Ethernet interface, you get a pcap file, you copy it off the box and you start to analyze that and you see there is lots of raw Ethernet frames with Ethertives A000 to A004 and then you look at some string tables and log outputs of different programs by the way all of these programs have something like a VTY that you can access so you can interactively change the debug level and get protocol traces and so on. So it's really nice to explore and you have a logging system that's at least as complicated as ours. And yeah then you see there's something interesting called audio log. Okay so you can somehow log the audio of decked calls. For sure not a documented feature in the documents that we have. There's an interestingly a separate for video. There actually is video telephony over decked and believe it or not when I was looking at the kernel strings I also saw there's V4L video for Linux. What, why do they have video for Linux on a decked base station? The point is you can attach a USB video class device to the USB A connector on the decked base station. So not only do you have a decked base station and a WiFi access point but also you have a surveillance camera all in one PoE device. And then using a video decked phone, yes they exist. You can use a video decked phone and you can see the real time video feed over decked from the USB camera attached to your deck base station. Yeah it's fun, why not? I mean, yeah, yeah. Well you can do that from phone to phone but I mean that doesn't need any video for Linux in the kernel, right? Yeah, yeah, yeah. Yeah, exactly, yeah, so you have like indeed. So yeah, so there's the firmware download and so on and the most interesting ones is really this A000 and A001, I don't really have any names but if we look at the protocols, I did some analysis. I will skip the details. There is code in this branch in wireshark.git. And so we have, yeah, there's a couple of slides in the wrong order. So let's do the wireshark demo quickly. I basically have a capture file that I'll just show quickly in wireshark. This is also not the right wireshark, there's too many wiresharks. Where did it go? Ah, there we go. This is the wireshark. These are the wiresharks you're looking for. So I'm just filtering on the A000 frames and I need to increase the font size, I guess. So if we look at the frame structure there, we basically have this, let's also open the hex dump. So we have source and destination MAC addresses, then we have this unknown whatever frame type, then we have a two byte obvious length field of 61 bytes and then we have some unknown payload in this case because I don't know this message yet. But here is a paging request, for example. So as an eight byte message with a paging request and then there's some additional data back there, which probably is the whatever the, what is it, RFPI or whatever the temporary identifier on deck is for the device that's supposed to be paged. And there is, yeah, MAC modify confirmation and whatever some other messages that are understood yet. And here we actually see then an authentication reply of the deck mobility management layer, which shows us that the stack is a bit deeper. So we have these raw Ethernet frames. At some point we have the deck DLC layer, which is like LabDM. So we have an iframe with 21 byte links and then we have the deck network layer, which is an auth reply and that is not decoded because there's no wire shark at the sector for this protocol yet. But at least the rough frame structure is understood. And so this brings us to these protocol layer messages that we see here. So there are messages and the names are mostly recovered from looking at traces. So if you enable using the debug interface, like the VTY, you can enable tracing and so on, and then you can map things. So you see there is like a connect indication, disconnect request, data request, data indication, page request, encryption key request and so on. Modify, request, modify, confirmation all sounds slightly similar, but slightly different at the same time. And then in there we actually have, this is some more, where is it? Yeah, in there we do have, in like the data request and data indication, we have the decked DLC layer, where wire shark didn't have an existing deceptor, but it was rather easy since DLC is a derivative of XDLC, like LabD and LabDM and LabSat and all these derivatives. So it was rather easy to create a deceptor for the DLC layer and then we get to the NWK layer, which is the mobility management and core control for which there's also no wire shark deceptor. That's why the decoding is rather simple, but all of these protocols are specified from this point on. So you could actually do complete protocol traces by writing some more wire shark bits. Now I wanted to look at the OMMRFP protocol in the last five minutes of this time slot. That's the protocol to remember looking at the diagram, no, not that diagram, that diagram. So right now we've basically looked at a protocol that's just purely inside here, inside the RFP between the decked and the ARM core. Now we want to look at the backhaul protocol that's between the RFP and the OMM. And this protocol has several subclasses. I try to draw a tree of how which sublayers are where. So we have this what I called ARMIDE and it has DNM and SYNC. And in DNM you have MAC and LC and RFPC and HOHO for sure is hand over. RFPC is RFP control. So basically you can control is like OML to control the base station. And these MAC and LC parts are to control the MAC layer and the logical channels in the device. Looking again at the protocol stack diagram here, we see that the DLC layer is here and the MAC layer is over there, rather here. So we want to remotely control at the layer boundary between DLC and MAC. We want to remotely control that MAC layer over here. And that's what these primitives in the protocol are made for. Now the funny part is, well, you enable all these logging and so on. And it gives you a hex thumb of the messages, but you never find those messages on Wireshark because they're actually encrypted or obfuscated. So if you look at the TCP payload, it looks completely randomized. And indeed they are using blowfish library routines from their binary. So I made a small LD preload wrapper library called LibTraceFish, which will basically give you a hex thumb of all the plain text and cipher text for each of the function calls. And also a LibNullFish, which replaces the encrypt decrypt operations with mem copy. And that you can basically switch to plain text mode and you can analyze the protocol further. And there are some people who have done more research on this and have done all kinds of interesting things, but I didn't do that, so I won't be reporting about it. But yeah, it's basically well understood now. And one can not only trace this internal Ethernet interface, but also people have already implemented a man in the middle proxy for this protocol between the RFP and the OM, where you can do modifications of messages on the fly going between the core network and the decked phones that are attached to it. And that brings me to the end of file, and I can still take a couple of questions. Yeah, we have a second microphone, which, well. So after you explain a bit, the protocol might adopt this. So what's the point of the existence of this protocol? Like it seems really similar to GSM. And GSM seems to have better specs, or yeah. So was it done before at the same time? And then, so I don't know. I'm not an expert, but I think it was created around the same time or shortly after GSM. It's definitely in the same time period. The use case is different, and I suppose the companies behind it are different. You may have seen that the GSM spec specifies something called CTM deck, the Cordless Telephony deck. Sorry, CTM GSM, Cordless Telephony GSM. And that was never deployed. So apparently also people involved with GSM have decided to extend GSM for cordless functionalities, but it was never deployed there. And in terms of bands, a deck is not an ISM band, but it's a freely licensed band in which it operates, of course. So I think it's mostly different companies wanting to have different patterns in different specs so they can monetize it. Well, the case for the band makes sense. Well, you could have just specified GSM for the same band, of course, if you wanted to. But yeah, that apparently was not. There was actually a time when GSM decked dual-mode phones existed. And there were some countries where decked local loop was used. So basically, you would have your landline telephony over decked. So basically, like every street or so, there's a pole with a decked base station, and you only have decked phones at home rather than having copper lines. I think in India they did, in some regions, they did this for some time. So it was suggested as a local loop technology also around the time that ISDN was deployed. Decked can transport more than just telephony. So decked from the beginning was, a telephony was more one application on it, which is specified in the gap in the generic access profile in decked, but there were other use cases. And even in the mid-'90s or so, you could buy Siemens, let's say 128 kilobits over decked transmitters and receivers. So you could actually do two ISDN channels over decked in your home before wireless LAN came around and so on. And now we have all these new decked IoT devices that are being pushed by some industry players, where again, they use decked only as the transport layer and have some other protocols on top. Thank you. Yeah, there's a question back there. Which band? I don't know exactly, it's somewhere 1.9 gigahertz. 1.9 gigahertz. Yeah, yeah, so it's basically it's above the GSM 1800 band. So directly above this band is where in Europe or at least in this ITU region, there is a general like reservation for decked. I think in the US, if you buy decked phones, they have been modified to work on 2.4 gigahertz because they don't have this band. So actually use the same protocol, but shifted into the normal 2.4 gigahertz ISM band because they don't have this frequency allocation. Okay, well, then that's it. So maybe a final word like, so what do we do with all of this? Well, nothing really so far. That's no big plan, but at least if anyone ever wanted to implement free software decked stuff, I think with these base stations, it's rather easy to do and there's not too many unknown factors or unknown variables anymore at this point and they are readily available. They can be bought on eBay. So if anyone wanted to implement all this protocol stuff from DLC layer upwards, it's a little bit like what we did with the BS11 back then. One could do it now without having to do much reverse engineering now. I don't think anyone will, but maybe who knows. Okay, yeah, thanks.