December 2010 - baseband-devel

Engagetted !
by Sébastien Lorquet 14 Oct '25

14 Oct '25

http://www.engadget.com/2010/12/29/researchers-eavesdrop-on-encrypted-gsm-c… Congrats!

7 7

Receiving on TS=1 ?
by Sylvain Munaut 20 Jul '12

20 Jul '12

Hi, I've hacked something together to quickly test non-combined CCCH. However, I've hit a problem when trying to receive anything on another timeslot than 0. The TX side seems to work fine as the BTS can see my location update request and answers with a reject, but on the MS side, I never see the reject and wireshark only shows invalid incohrent data on the RX. The frames for SDCCH/8 show really nothing valid (looks like random bytes), things like 09 80 7f 47 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 09 00 47 d5 2d 06 1e 00 00 69 7c a0 91 3d 22 ff ab fe 6c 4f 56 4f 36 ... while the frames for the associated SAACH show at least something gsm-like : 03 03 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b but that's not quite a SI5/6 ... To RX/TX on TS=1, I just delayed the RX/TX window by 625 bits (4 * 156.25) when I'm in dedicated channel mode by chaning the 'start' in l1s_tx_win_ctrl / l1s_rx_win_ctrl Is there something else that should be done ? Cheers, Sylvain

2 5

Use OsmocomBB as OpenBTS / airprobe clock generator
by Harald Welte 15 Mar '12

15 Mar '12

Hi! Recently we've had the idea of using OsmocomBB with a simple firmware that synchronizes to an existing GSM networks FCCH and use the resulting 13MHz clock to drive the USRP for airprobe or OpenBTS. Ideally, we would even use the Calypso-internal PLL (for ARM or DSP) to multiply it up to the required 52 MHz. However, neither the Openmoko nor the Compal/Motorola phones expose any of the 3 clock output pads :( So the only choice is to use something along the lines of the http://focus.ti.com/docs/prod/folders/print/cdcvf25084.html as a quad clock multiplier and attach it to the CLK13OUT signal of the phone. The chip is available for 9 USD in single quantities at digikey, and possibly cheaper at other sources. Combined with a sub-20EUR phone it might be a very cheap but still accurate frequency source for OpenBTS - at least as long as there are any commercial gsm networks available. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

8 17

Linux + u-boot port to MT6235
by Marcin Mielczarczyk 07 Jan '12

07 Jan '12

Hi All! That's true, I managed to run U-Boot on MT6235, but linux kernel is not fully functional yet (it's fresh stuff as I managed to ran it on Tuesday and then I was off to conference). For MT6235 development I chose Sciphone G2, which is pretty cheap. After some time I managed to download code to SRAM (just 64KB) using MTK's FlashTool. MTK FlashTool communicates over UART directly with MT6235 bootloader and sends its own chunk of code (about 58KB) which is executed in SRAM and communicates with FlashTool. I found on pudn.com some pack to customize code loaded by FlashTool, thanks to which I could download my own code to SRAM (without JTAG). The problem was that it had to be linked with some security libraries which occupied about 56KB and not much memory left for my own code. Then I decided to try find JTAG pins to get all control on MT6235. That took me sometime, but finally I succeeded. The other bigger issue was initializing DRAM controller to be able to download bigger code (linux kernel + uboot) to external RAM. In sciphone there is problem that all interesting chips are under metal shield which is pretty havily soldered. In this case I couldn't read what kind of RAM memory is mounted without destroying the board (I don't have such soldering machine which could unsolder so big metal shield). Thanks to JTAG I could attach to target and then dump DRAM controller registers from processor running MTK's software, but setting these values after processor start and configuration of PLL didn't work. I decided to disassemble bootloader which could show me how DRAM controller is initialized and how code fron NAND is loaded (to be able to flash U-Boot and kernel to NAND so MT6235 will start my code automatically and I will not have to use JTAG). Currently I have knowledge how internal MT6235 bootloader is loading code from memory during startup and I also extracted procedure of DRAM controller initialization. Thanks to that I'm able to run U-Boot from the very begining of processor startup. The problem is that I have just one piece of Sciphone G2 and I don't want to flash it yet to not break existing code in it. Thanks to running device I'm able to attach with JTAG and check how peripherals are configured (i.e. LCD, MMC, etc.). I have backup of flash, but I'm not 100% sure if I will flash it back, phone will startup. That's why I bought second piece of Sciphone G2 and should receive it today or on Tuesday (this Monday is holiday in Poland). In this case I'll flash U-Boot to NAND and try to make it working. Then we could load the rest of code from U-Boot (to RAM or NAND over serial). You can see how my setup looks on attached picture. The good thing about it is that the same bootloader is used in MT622x, so it should be fairly easy to do the same on phones based on that SoCs (but unfortuantely it's just ARM7). If it comes to code, of course I can share it on "git.osmocom.org". Currently it's just basic port of U-Boot and not much for linux kernel, but I'm working on this now so I'll push it when it'll be ready. Currently I'm working on driver for NAND memory for U-Boot, so we could flash linux kernel. When that will be ready I'll push the code. Then I'll switch to linux kernel and when it'll be functional I also push the code. At this stage you will not need to have JTAG and you could load the code over serial in U-Boot. If it comes to GSM I didn't work with it before. I actualy worked 6 months in L2/3 team for LTE (on RRC) but it's different story. That could be really outstanding thing if we could run first phone ever with whole code open (from BB up to APP). BR, Marcin

13 37

Problems while building osmocomBB
by Begerad Stefan 27 Oct '11

27 Oct '11

Hi guys, I dunno if that is the right place for my concern about building the osmocomBB source. Here is what I already have done: - downloading the sources for osmocomBB and GNU toolchain for ARM, - setting the PATH for the arm-elf-* executables, - calling make in the src directory. Now, this appears as response of the make command in the terminal: cd shared/libosmocore/build-host && ../configure configure: error: cannot find install-sh, install.sh, or shtool in ".." "../.." "../../.." make: *** [shared/libosmocore/build-host/Makefile] Error 1. If you need details about my system, you can look at the following snippet from the config.log file: This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by libosmocore configure UNKNOWN, which was generated by GNU Autoconf 2.65. Invocation command line was $ ../configure ## --------- ## ## Platform. ## ## --------- ## hostname = ubuntu-stefan uname -m = x86_64 uname -r = 2.6.32-24-generic uname -s = Linux uname -v = #41-Ubuntu SMP Thu Aug 19 01:38:40 UTC 2010 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /usr/sbin PATH: /usr/bin PATH: /sbin PATH: /bin PATH: /usr/games PATH: /home/stefan/osmocomBB/gnuarm-4.0.2/bin ## ----------- ## ## Core tests. ## ## ----------- ## configure:2032: error: cannot find install-sh, install.sh, or shtool in ".." "../.." "../../..". So, I would be very glad, if someone could give me a hint to solve the problem. Thank you in advance. Regards, begy

2 2

Linux + u-boot port to MT6235
by Harald Welte 22 Mar '11

22 Mar '11

Hi All! At my OpenBSC / OsmocomBB talk here at the Embedded Linux Conference Europe, one of the attendees (Marcin, see Cc) came to me after the talk and told me he had recently done a u-boot and Linux kernel port to the MT6235 (that's the ARM926 based chipsets found in the touchscreen MTK phones). He said he has no understanding of GSM or the existing MTK firmware, but is interested in working together with us to try to make the GSM part work. I think that chipset is very intesting, as we could implement the layer1 inside the Linux kernel (and submit that mainline, yay!) and run our layer2 and layer3 implementations as userspace processes on the Linux system, together with the user interface. The performance of those devices should be somewhere between the Openmoko GTA01 and GTA02, and the GSM stack is certainly not going to eat away a lot of the CPU either. I have asked Marcin to write mail to the OsmocomBB mailing list on where we can find the code. He has so far downloaded the code using JTAG. Combining his code with our ramloader might remove that JTAG dependency... Marcin: if you want to push your u-boot / kernel to git.osmocom.org, or want a separate trac installation for your mtk-linux work, pleaes let me know, I'd be happy to host that. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 1

Re: Trouble building Osmocom
by Holger Freyther 26 Jan '11

26 Jan '11

On 06/08/2010 09:41 PM, Huseyin Turan wrote: > root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# ls -l arm-elf-gcc > -rwxrwxrwx 1 name1 name1 112344 2006-02-17 23:59 arm-elf-gcc > root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# ./arm-elf-gcc > bash: ./arm-elf-gcc: cannot execute binary file > root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# uname -a > Linux name1-desktop 2.6.28-19-generic #61-Ubuntu SMP Wed May 26 23:35:15 > UTC 2010 i686 GNU/Linux > please try b.) again (you miss the file part) and also please reply to the mailinglist.

6 10

TODO: OsmocomBB to continually iterate over all cells and dump SI
by Harald Welte 14 Jan '11

14 Jan '11

Hi! A number of people want to do some long-term evaluation of their cellular environment and would be interested in an 'app' for OsmocomBB that continuously scans the spectrum and dumps the cell parameters such as * ARFCN, Signal Level, SNR * frequency synch offset * SCH info (BCC/NCC) * SI (at least 1-4) from BCCH I would love to do it, but I simply don't have the time. I thought maybe somebody on this list is looking for a relatively simple task and has some time. I think this is a great project to work with OsmocomBB without having to go into the details. The algorithm would look something like STATE 1: Power Scan * do power measurement over all supported bands * pick strongest N carriers and iterate over them STATE 2: FCCH/SCH acquisition * try to get lock on the carrier * if not, go back to next carrier from power scan * if yes, continue with STATE 3 STATE 3: Wait until all relevant SI have been received * generate GSMTAP output for the SI messages (or timeout) * go back to STATE 2 for next strongest ARFCN * after last ARFCN, re-start from STATE 1 This is basically the initial step of the GSM 03.22 cell (re)selection that we already have as part of the 'mobile' program. So all the code is there, but what's needed is a separate rady-made app, not requiring any user interaction. It should also include some e.g. shell script that automatically generates a new pcap file every N minutes/hours, and make sure to never overwrite any existing PCAP file. In the end, having this running for an extended period of time should simply produce a large number of PCAP files without any manual interaction. Lock-ups in any state should be detected by timers, singalling a proper L1_RESET to make sure it continues. Unplugging / re-plugging the phone should also not require any re-start of the program. Optional extensions: * software to aggregate info from the pcap files (remove duplicate entries, e.g.) * optional logging of GPS coordinates from a GPS receiver If anyone has some time to give this some work, I'd most appreciate it. Please inform the mailing list to ensure no duplicate work is created. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

4 3

Newbie: C123 + layer1.compalram.bin + layer23
by Nicolas Bareil 07 Jan '11

07 Jan '11

Hello, I try to use the 'host23/mobile' application on a C123 but without success. I followed Steve's instructions[1] with today's git tree (d95eddad): 1. osmocon -p /dev/ttyS0 -m c123xor layer1.compalram.bin 2. ./host/layer23/src/mobile/mobile 3. Power on the phone (output of theses commands is thereafter) But I'm not sure it really works: the firmware seems to freeze (not responding to the power button anymore) and the last output of 'mobile' is: <0003> gsm322.c:257 Sync to ARFCN=104 rxlev=-65 (No sysinfo yet, ccch mode NONE) Based on the low rxlevel, I guess it is not acquiring any meaningful signal? In [2], Steve said the internal antenna was switched off when the cable is plugged in, is it still true? I tried to RTFM but I am stuck here. Thanks for your patience, Footnotes: [1] http://baseband-devel.722152.n3.nabble.com/Running-osmocombb-on-a-Motorol-C… [2] http://lists.osmocom.org/pipermail/baseband-devel/2010-May/000435.html ,---- | % osmocon -p /dev/ttyS0 -m c123xor layer1.compalram.bin | ... | Received DOWNLOAD ACK from phone, your code is running now! | | OSMOCOM Layer 1 (revision osmocon_v0.0.0-598-gd95edda) | ====================================================================== | Device ID code: 0xb4fb | Device Version code: 0x0000 | ARM ID code: 0xfff3 | cDSP ID code: 0x0128 | Die ID code: ebd8283cba021198 | ====================================================================== | REG_DPLL=0x2413 | CNTL_ARM_CLK=0xf0a1 | CNTL_CLK=0xff91 | CNTL_RST=0xfff3 | CNTL_ARM_DIV=0xfff9 | ====================================================================== | | THIS FIRMWARE WAS COMPILED WITHOUT TX SUPPORT!!! | Assert DSP into Reset | Releasing DSP from Reset | Setting some dsp_api.ndb values | Setting API NDB parameters | DSP Download Status: 0x0001 | DSP API Version: 0x0000 0x0000 | Finishing download phase | DSP Download Status: 0x0002 | DSP API Version: 0x3606 0x0000 | LOST 7478! | L1CTL_RESET_REQ: FULL!L1CTL_PM_REQ start=0 end=124 | PM MEAS: ARFCN=0, 27 dBm at baseband, -110 dBm at RF | PM MEAS: ARFCN=0, 26 dBm at baseband, -112 dBm at RF | PM MEAS: ARFCN=1, 30 dBm at baseband, -107 dBm at RF | PM MEAS: ARFCN=2, 29 dBm at baseband, -108 dBm at RF | PM MEAS: ARFCN=3, 43 dBm at baseband, -94 dBm at RF | PM MEAS: ARFCN=4, 32 dBm at baseband, -105 dBm at RF | ../.. | PM MEAS: ARFCN=1023, 33 dBm at baseband, -104 dBm at RF | L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=104, flags=0x7) | Starting FCCH RecognitionFB0 (1748:10): TOA=11712, Power=-106dBm, Angle=-22058Hz | FB0 (1775:11): TOA=12528, Power= -65dBm, Angle=-3818Hz | FB0 (1796:5): TOA= 5280, Power= -68dBm, Angle=-16117Hz | FB0 (1799:1): TOA= 96, Power=-109dBm, Angle= 7082Hz `---- ,---- | % ./host/layer23/src/mobile/mobile | ... | Failed to connect to '/tmp/osmocom_sap'. | Failed during sap_open(), no SIM reader | <000e> sim.c:1206 init SIM client | <0005> gsm48_cc.c:61 init Call Control | <0001> gsm48_rr.c:5330 init Radio Ressource process | <0004> gsm48_mm.c:1220 init Mobility Management process | <0004> gsm48_mm.c:971 Selecting PLMN SEARCH state, because no SIM. | <0002> gsm322.c:3466 init PLMN process | <0003> gsm322.c:3467 init Cell Selection process | <0003> gsm322.c:3521 No stored BA list | VTY available on port 4247. | Mobile initialized, please start phone now! | <0002> gsm322.c:3093 (ms 1) Event 'EVENT_SWITCH_ON' for automatic PLMN selection in state 'A0 null' | <000d> gsm322.c:1055 SIM is removed | <0002> gsm322.c:1056 SIM is removed | <0002> gsm322.c:511 new state 'A0 null' -> 'A6 no SIM inserted' | <0003> gsm322.c:3313 (ms 1) Event 'EVENT_SWITCH_ON' for Cell selection in state 'C0 null' | <0003> gsm322.c:2986 Switch on without SIM. | <0003> gsm322.c:540 new state 'C0 null' -> 'C6 any cell selection' | <0003> gsm322.c:2404 Getting PM for frequency 0 twice. Overwriting the first! Please fix prim_pm.c | <0003> gsm322.c:2415 Found signal (frequency 3 rxlev -94 (16)) | <0003> gsm322.c:2415 Found signal (frequency 8 rxlev -86 (24)) | <0003> gsm322.c:2415 Found signal (frequency 16 rxlev -93 (17)) | ... | <0003> gsm322.c:2415 Found signal (frequency 819 rxlev -97 (13)) | <0003> gsm322.c:2404 Getting PM for frequency 955 twice. Overwriting the first! Please fix prim_pm.c | <0003> gsm322.c:2415 Found signal (frequency 982 rxlev -98 (12)) | ... | <0003> gsm322.c:2415 Found signal (frequency 1004 rxlev -91 (19)) | <0003> gsm322.c:2415 Found signal (frequency 1007 rxlev -89 (21)) | <0003> gsm322.c:2415 Found signal (frequency 1009 rxlev -97 (13)) | <0003> gsm322.c:2415 Found signal (frequency 1010 rxlev -86 (24)) | <0003> gsm322.c:2415 Found signal (frequency 1011 rxlev -67 (43)) | <0003> gsm322.c:2415 Found signal (frequency 1012 rxlev -86 (24)) | <0003> gsm322.c:2415 Found signal (frequency 1013 rxlev -80 (30)) | <0003> gsm322.c:2415 Found signal (frequency 1014 rxlev -87 (23)) | <0003> gsm322.c:2415 Found signal (frequency 1021 rxlev -82 (28)) | <0003> gsm322.c:2415 Found signal (frequency 1022 rxlev -98 (12)) | <0003> gsm322.c:2348 Found 97 frequencies. | <0003> gsm322.c:257 Sync to ARFCN=104 rxlev=-65 (No sysinfo yet, ccch mode NONE) `----

4 7

IMPORTANT clarifications about 27C3 GSM Sniff Talk
by Sylvain Munaut 31 Dec '10

31 Dec '10

Hi, Since a lot of people are asking the same questions and there seems to be a rush on the C123 on ebay I tought some clarification is needed. Short version: - The exact tools I used on stage are _not_ and will _not_ be released (or sold ... several people asked ...) - Any one willing to re-code them without any apriori knowledge of GSM would most likely need months to read/understand both the specifications and the way the code works. (That's thousands of page of GSM spec and thousands of line of code) - Osmocom-BB project is not designed to be a sniffer, it's a baseband implementation, I just used part of it as a base. So basically, unless you are really interested in GSM and are willing to dedicate time to understand it deeply and to contribute the various projects, there is not much point in you buying phones, or hanging out in the ml/irc or whatever ... For those who are still reading and interested here's a little more detail: * The HLR query step: -> Go watch the awesome 25C3 talk about it * The TMSI recovering step - Won't be published - If you know how paging works, you know what to do anyway and it's trivial. Method is in the talk, there is nothing to it. * The targeted sniffing application - Won't be published either - Some improvements to the layer23 app frame work will be done but these are generic framework stuff, not app-specific - Again, if you know how L2 works and have looked at several traces, it's obvious what to do. - The 'DSP' part of the sniffer is public for a while with a small demo app (single phone and doesn't exploit the full potential of the DSP patch) and it's perfectly sufficient to debug things on your o wn controlled network. (This is basically what I showed at Deepsec 2010). * The tool to generate the input to Kraken - Won't be published either - Making the guesses is easy for anyone that knows what he's doing. * The improved Kraken - No idea about it, see with Karsten / Sacha / Frank, I only got access to it 1 hour or so before the talk :) * Conversion from burst to audio - This was a hacked software mostly with airprobe code. - The exact app will not be released but I'd like to see the capability put in some clean library we can re-use from airprobe and other application without having to multiply the code each time. - ... But since I'd like it to support AMR and viterbi softoutput before that happens, it could take some time. - Anyone familiar with GSM, airprobe and C could re-hack the same thing in an hour ... As you can see, everything you need to analyze your own network / your own traffic, even at the burst level is already published and has been for more than a month. The other tools have been written only so that we could demonstrate that what we _say_ is possible for about year, we can now do it _practically_. It's apparently needed to get people attentions, "theoretical" attacks are not enough to get the operators / gsma to react. We'll see if that did it ... A few advices that are always good: - Make sure to checkout the a5/1 project ML and airprobe project ML and try to ask your questions in the proper mailing list as much as possible. - Check the wiki and mailing list archives toroughly before asking questions. Cheers, Sylvain Munaut PS: I only posted on this list because it seems a lot of people were pointed here while in fact airprobe would probably be more appropriate to discuss attack scenarios and such, so make sure to answer / start new discussion on the right list.

1 0