Calypso DSP reverse engineering front ...

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.

Sylvain Munaut 246tnt at gmail.com
Thu Mar 18 20:48:16 UTC 2010


Hi everyone,

> I've been slowly working on the DSP code for some time now and I
> tought I'd post a status here in case other people are interested.

So, here we are, 8 days laters, I tought a small update would.

Now that my IDA works nicely with the code. I started really digging
into what it does.

* First, the code makes heavy use of jump tables and indirect call.
Most of the init is to copy function pointers (or a few times,
function themselves) from the ROM to the RAM and then use them from
RAM. This kinda screws with the autoanalysis of IDA and I'll have to
write a script to handle that gracefully. That also means that you can
override those jump tables with whatever you want. After the init is
done, the DSP will jump to the address set in d_grps_install_address.
Currently we point this one to 0x7002 which is just a 'ret'
instruction but we could put in the API ram a custom function that
hooks whatever we need.


* Second, I found the main demodulation routines :

 - prom0:7c27 -> Normal burst decoding :
  This starts with 190 IQ samples (16bits I, 16bits Q) at the start
and finishes with 114 bits + 2 stealing bits at the end of the array.
  At the output they are not hard bits but still 'semi-soft bits',
that is it's a 4 bits signed value between -8 -> 7, even after
deciphering. I think they keep them soft so that when applying the
error correction they can take advantage of that information somehow.
(that's unverified for now tough)

 - prom0:7c2c -> SCH burst decoding :
  This starts with 190 IQ samples as well and finishes with 78
softbits. I haven't dug much into this one yet, but the final memcpy
of 78 values makes me think this is SCH :)

It's also interesting to note that the raw IQ values should still be
in the API zone after demodulation :)


* Third, when looking at the code, it sometimes look like a mess ...
there is no calling convention that I can see, every function seem to
have it's own way of making. There is also very little stack usage for
temporary variables, they seem to use global variables for that and
the same variable can be re-used somewhere else with a completely
different meaning ...


I'll continue digging in the demodulation stuff to see how they do the
demod exactly. It's my experience that they're much better at it than
airprobe is and I want to find out what tricks they have up their
sleeves :)

I'll probably also have a look at the TX side, see if I can hook
something to TX FCCH/SCH frames somehow ...


Cheers,

    Sylvain




More information about the baseband-devel mailing list