- baseband-devel - lists.osmocom.org

Bounce action notification
by mailman＠lists.osmocom.org 27 May '14

27 May '14

This is a Mailman mailing list bounce action notice: List: baseband-devel Member: bjoern.riemer(a)fokus.fraunhofer.de Action: Subscription disabled. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman(a)lists.osmocom.org.

1 0

R: Re: Sylvain testing branch
by Luca Bongiorni 26 May '14

26 May '14

Hi there, > Try master or jolly/testing > The sylvain/testing branch has some patches for the BTS mode that seem > to break 'normal phone' mode. It means that, at the state of art, the best branch to work with CalypsoBTS is the jolly/testing or the sylvain/testing? Cheers, Luca **************** Il 5 x mille alla nostra Università è un investimento sui giovani, sui loro migliori progetti. Sostiene la libera ricerca. Alimenta le loro speranze nel futuro. Investi il tuo 5 x mille sui giovani. Università degli Studi di Milano codice fiscale 80012650158 http://www.unimi.it/13084.htm?utm_source=firmaMail&utm_medium=email&utm_con…

1 0

Sylvain testing branch
by R M 23 May '14

23 May '14

Hi, I am trying to build the Sylvain testing branch. I am facing an issue there. What I did is as follows: 1. I got the Sylvain testing branch to my computer. 2. I tried to build it and it failed saying that it cannot find the libosmocore library. 3. I changed the top most Makefile to install libosmocore after building. 4. Again I tried to build and it built and installed libosmocore but now Its complaining about osmocom/core/talloc.h not found in sim.c in layer23 folder 6. As per the top Makefile, talloc is disabled in libosmocore but sim.c file does not have conditional include for this header file. Is this a problem or I am doing something wrong ? Regards, RM

2 3

Re: How to fix for problem -- "l1ctl.c:114 FBSB RESP: result=255"?
by warriornew 23 May '14

23 May '14

打一个补丁 patch blog.lishixin.net 自己去博客看吧 -- View this message in context: http://baseband-devel.722152.n3.nabble.com/How-to-fix-for-problem-l1ctl-c-1… Sent from the baseband-devel mailing list archive at Nabble.com.

1 0

c139/c140 jtag anyone?
by Craig Comstock 19 May '14

19 May '14

I'm at the point w/ flashing firmware where I feel like I need to use a debugger w/ JTAG. I figured I could probably use serial line logging somehow but JTAG seems better and I should learn it anyway. Has anyone pried open the shield on a c139/c140 and tried attaching to the JTAG test points that are just inside the shield next to the test points which are accessible via the battery compartment?

2 3

Re : Sylvain testing branch
by Ravi Sharan 18 May '14

18 May '14

Hi, Have you complied the libosmocore separately ? If you are using fedora based distro make sure you have set the path correctly. Regards, Ravi Sharan

1 0

Locked C139 bootloader reverse-engineered
by msokolov＠ivan.Harhan.ORG 15 May '14

15 May '14

Hello fellow hackers, Following my successful reverse eng of Tracfone "unlocking" utility mot931c.exe, I wrote a native Unix/Linux program (tfc139, based on FreeCalypso rvinterf tools) that breaks into locked-down TF C139 phones in the same fashion, with an IRAM payload that enables and jumps to the Calypso boot ROM. Doing so allowed me to run fc-loadtool against one of these Tracfones that still has its original locked-down bootloader intact (*not* overwritten with mot931c), and make a dump of the latter for examination. So here is how the bootloader lock works: the bootloader which sits in the first 0x2000 bytes of flash sector 0 is clearly built together with the main fw image as a single whole (TI's reference firmware is built the same way, so no surprise), and thus the bootloader version changes in sync with the main fw version. Most of the versions seen in the wild are almost byte-identical, the only diffs being some unused signature (?) words at 0x20 and the word at 0x964 giving the initial value to be loaded into the stack pointer - variations in the latter are a linker artifact resulting from how this bootloader is built together with the main fw. Despite the way in which they must have been compiled, the older versions of the bootloader have one good quality: if you are going to break into the bootloader serially (in our familiar way), then only the first 0x2000 bytes of the flash (in fact, even less than that) need to be good; the flash from 0x2000 onward can be blank or filled with garbage or malware or whatever - as long as the boot process is interrupted with a serial download, the jump to 0x20f8 doesn't happen and nothing from 0x2000 onward affects anything. So far, so good. But the newer versions of the bootloader that are part of the newer firmwares for both C11x/123 and C139/140 have an added malicious feature. Before sending what we call PROMPT1 out the serial port and waiting for a possible serial download, the boot code now checks the word in flash at 0x2060. This word needs to equal 0xDDDDDDDD (was it some developer's fascination with bras? - scnr); if this word contains any other value, no serial download opportunity is offered, and the code proceeds directly to the silly routine that emits that "ftmtool error" nonsense, followed by the jump to 0x20f8. All TF-branded C139 phones I've seen have fw version 8.8.17, which features the new malware bootloader. And the word at 0x2060 is zeroed out, resulting in the observed behavior of no serial download opportunity being given on boot. I speculate that perhaps the newer fw versions containing boot code with this malicious feature start out with 0xDDDDDDDD in the word at 0x2060, so that their own developers could do their job, but when shipping phones to end users, the bastards issued some ETM or whatever command to zero that word out, disabling the serial download access - remember that any NOR flash bit can be changed from 1 to 0 at any time, but going the other way around requires erasing and rewriting the whole sector. So what do we do about it? Well, at least the TF-branded C139s still have that ETM memory write command that allows us to break in by writing a little payload into IRAM and smashing the stack while the main fw is running, and we now have a free, source-enabled, Unix/Linux- based tool for performing this break-in. Not too long ago there was someone else on this list who had a newer C139 with Cingular branding (not TF) that also featured the maliciously locked bootloader. Not surprisingly, mot931c wouldn't work on that phone, as this closed source Weendoze binary does a fw version query and refuses to work with any versions other than TF's 8.8.x. But now that we have our own free tool for the hack in question, it may be worth testing if one can break into non-TF phones by the same method. The addresses for the IRAM payload download and the stack smashing may need to be tweaked experimentally, but hey... When the time comes to flash our own FreeCalypso firmware into these phones, I'm thinking of adopting one of the old bootloader versions as our "standard". In fact, the only diff between C11x/123 and C139/140 versions of this boot code is that the latter adds the check for "1003" at 0x803ce0, whereas the former has no such check. Thus we can use the more basic C11x/123 version of the boot code on all hw versions, and make our chainloading more efficient by loading 32 bytes instead of 15332. :) All of the work described above has already been pushed into the freecalypso-sw and freecalypso-reveng Hg repositories on Bitbucket. VLR, SF

1 0

Calypso-BTS: State of Art and Future Improvements
by Luca Bongiorni 14 May '14

14 May '14

Hey folks, Since I am planning to delve deeper into the Calypso-BTS... I was wondering if.... after Sylvain and Jolly's last commits into their "*/testing" branches [1][2]... - Someone else have made some (private) changes/improvements to the sources?! - Is there a TO DO list available for suggested improvements? - Is anyone working on it or it would be interested? And another question... why those branches have not been merged? Cheers, Luca [1] http://cgit.osmocom.org/osmocom-bb/commit/?h=sylvain/testing&id=1b8f488f396… [2] http://cgit.osmocom.org/osmocom-bb/commit/?h=jolly/testing&id=c1d728975f4c0… **************** Il 5 x mille alla nostra Università è un investimento sui giovani, sui loro migliori progetti. Sostiene la libera ricerca. Alimenta le loro speranze nel futuro. Investi il tuo 5 x mille sui giovani. Università degli Studi di Milano codice fiscale 80012650158 http://www.unimi.it/13084.htm?utm_source=firmaMail&utm_medium=email&utm_con…

3 3

Tracfone C139 break-in procedure
by msokolov＠ivan.Harhan.ORG 14 May '14

14 May '14

Hello fellow hackers, As has been discussed on this list a little over a month ago, Mot C139 phones sold with Tracfone branding usually have firmware version 8.8.17, which contains a bootloader in which the serial break-in and download capability has been disabled. However, this locked-down firmware version still has the **16379# keypad command that switches the headset jack back to the UART and presents a variant of TI's RVTMUX interface on this UART; and there exists a Weendoze program called mot931c.exe that: 1. connects to this RVTMUX interface; 2. does some black magic to break into the otherwise locked-down phone; 3. erases and rewrites flash sector 0, replacing the "bad" bootloader version with a "good" one. The elusive part has been step 2 above - just what does this closed source Winblows binary send to the phone to make the initial break-in? Whoever was responsible for producing the locked-down fw in these Tracfones really did close all of the well-known holes: not only have they tied the nIBOOT pin high directly underneath the BGA and disabled the serial access in their own bootloader, but TI's standard ETM_CORE commands which would normally be available over RVTMUX don't work either. Well, I have finally reverse-engineered what this mot931c.exe tool does (by running it under Wine, pointing the Wine-emulated COM port to a Unix pseudo-tty instead of a real serial port, and listening and talking back on the master side of the Unix pty), and here is the secret: Compal's firmware features some non-standard commands of their own invention in their version of TI's ETM, these non-standard commands have *not* been disabled in the TF-branded fw, and one of them is a raw memory write command. (The following description assumes that the reader is familiar with TI's standard versions of RVTMUX and ETM; if you aren't familiar with these things, read my write-up thereof in the FreeCalypso documentation.) Compal's non-standard ETM memory write command has the following format: 0x14 octet: tells the RiViera Trace MUX that the packet is for ETM 0x40 octet: non-std opcode in the place where ETM component ID would normally go 4 octets: absolute address at which the bytes are to be written, in LE bytes order remaining octets before ETM checksum: raw bytes to be written 1 octet: standard ETM command packet checksum at the end (Wrapped in the RVTMUX STX/DLE byte stuffing as usual.) The mot931c tool uses the above ETM memory write command to write 204 (0xCC) bytes at address 0x800000, at the low end of IRAM - this happens with the regular fw still running! So far, so good. How is control then transferred to this downloaded payload? Answer: by smashing the stack! After downloading its payload (in two chunks: first 120 bytes, then the remaining 84), the mot931c tool sends more ETM memory write command packets in exactly the same format, but this time each write is just 4 bytes long. The address being written into starts at 0x837C54, and increments by 4 from there. The data written with each of these commands is 00 00 80 00, i.e., 32-bit word 0x800000 in LE. It is obviously seeking to hit a return address location on the stack, in order to transfer control to the payload it just downloaded. If it keeps getting "ETM command successful" responses from the target, it keeps retrying with incrementing write addresses until it reaches 0x838BF0, at which point it gives up. If this procedure succeeds in hitting the function return address on the stack and thus transferring control to 0x800000, which will indeed succeed when run against the TF firmware in question, the code that's been downloaded into that IRAM location then provides its own very simple serial download protocol whereby the next code stage is downloaded and run. I haven't pursued the process further, as the initial break-in was/is all I'm interested in. I strongly dislike this mot931c.exe tool's Heisenbergian approach of altering the flash content without saving the original first, and my plan is to use this break-in procedure to make FreeCalypso's fc-loadtool work with these TF C139s. Once we are running fc-loadtool, all of this tool's functions will be available just like it currently offers on Openmoko and Pirelli targets: flash dump2bin, flash erase, flash program-bin etc. Put the user back in control, instead of a closed source Weendoze binary that does all of the reflashing without asking the user if she wants it or not. Viva la Revolucion, SF

1 0

Problem with connecting to network
by R M 12 May '14

12 May '14

Hi, I have recently purchased a SIM card. When I use the SIM in Nokia 3310, and try to manually select a particular cell, it says no access. SIM belongs to the same network. If I insert the same SIM in Blackberry Bold 9780, I am able to manually select the same network and even make phone calls. I have set the Network selection mode in Blackberry to Manual. I have also asked it connect only to 2G networks. To debug the issue, I connected the Nokia 3310 to my laptop and observed the messages it exchanged with the network. From the messages, I see that Nokia 3310 is getting a TIMSI assigned from the same cell. But my Nokia 3310 says, No Access. I also see a "DTAP Radio Resources Management Message Type: Channel Release (0x0d)" message from the Network to the phone. What does the above message mean ? Is there any way for me to further debug the issue ? Thanks and Regards, RM

2 5