TIFFS in vitro analyzer tool released

[Michael Spacefalcon]

Giacomo 'giotti' Mariani <giacomomariani at yahoo.it> wrote:

> Here we are:
> # diff -r michael-ffs my-ffs

Thank you for these diffs; explanation follows inline.

> Binary files michael-ffs/Test/Production.bin and my-ffs/Test/Production.bin
> differ

Yup, expected - if you hexdump this file, you'll see that it contains,
among other things, the non-IMEI "serial number" which Om/FIC assigned
to each Neo unit.

Incidentally, these files under /Test (Production.bin and Teststate.bin)
are neither written nor read by the modem firmware (any version); they
were written by the factory production line and remain as decorative
relics afterward, not actually used by the fw for anything.  (Kind of
like your belly button - serves no real purpose except to remind you
how you came into being. :-)

> Binary files michael-ffs/gsm/cops/operimsi and my-ffs/gsm/cops/operimsi
> differ

This file gets frequently rewritten during normal operation of the
modem; it contains the IMSI read from your SIM card and some other
info I have yet to understand.

Regarding the flash dump on my FTP site, I read it out of my FR's
modem before I put any SIM into it, so whatever IMSI-related info is
in that image, it must be an artifact of testing or whatever by the
manufacturer/distributor/etc.

> Binary files michael-ffs/gsm/l3/rr_white_list and my-ffs/gsm/l3/rr_white_list
> differ

I have yet to learn what these files under /gsm/l3 are for, so I don't
have much to add currently.  However, I do know that these files get
rewritten by the modem quite frequently in normal operation, so they
are definitely in the "dynamic state" category, not factory-programmed
data.

> diff -r michael-ffs/gsm/rf/afcdac my-ffs/gsm/rf/afcdac
> [...]
> Binary files michael-ffs/gsm/rf/tx/levels.900 and my-ffs/gsm/rf/tx/levels.900
> differ

These are the interesting ones: all files under /gsm/rf are calibration
data recorded at the factory and never changed afterward, so the diffs
we are seeing here are the measured physical variations from one
produced unit to the next.

The next natural question here is how great or small these differences
are, i.e., the magnitude.  To answer that, we need to look at the
actual content of these RF calibration files.  They are all binary,
and are read directly into RAM data structures belonging to the Layer1
code in the firmware.  I will give these structures their deserved
scrutiny when I reach the point of deblobbing the L1 code and
integrating it into my gcc-built FC GSM fw - IOW, not yet.

In the meantime, I think it would be a good idea to collect the content
of this /gsm/rf directory subtree from as many Neo units as possible -
understanding the actual magnitude of per-unit differences in these
calibration values would help us provide the best possible recovery
for anyone unlucky enough to lose their FFS, and may also give us an
idea as to what to expect in this department when the time comes to
build new FreeCalypso phones and modems.

Because all files under /gsm/rf are written only on the factory
production line and not afterward, there is no personal information in
there: nothing read from your SIM(s), no history of network connections
or the like, and no IMEI or other identifying numbers, just measurements
of physical process variations.  Therefore, there should be no privacy
problems in publishing this data.

If you would like to contribute your RF calibration data to public
knowledge, you can make a .tar.gz from your extracted /gsm/rf subtree
(just that subtree, don't include any other directories which may
contain private personal info), send it to me, and I'll put it on
ftp.ifctf.org - I'll make a new directory for this calibration
collection.  Oh, and inside that tarball, add a note indicating
whether the unit in question is a GTA01 or a GTA02, and whether it is
the 900+etc or the 850+etc frequency band version.

To repeat: if you choose to do the above, be sure to extract the
content of your FFS with mokoffs xtr and then make a .tar.gz of just
the /gsm/rf subtree - you probably do NOT want to publish your
complete raw flash dump, as there's a lot of personal info that can be
extracted from a complete FFS image.

> Binary files michael-ffs/pcm/IMEI and my-ffs/pcm/IMEI differ

Obvious.

> Binary files michael-ffs/pcm/IMSI and my-ffs/pcm/IMSI differ

Same deal as with /gsm/cops/operimsi seen earlier.

> Binary files michael-ffs/var/dbg/dar and my-ffs/var/dbg/dar differ

This file appears to be rewritten every time the modem boots up.  But
TI's DAR component (Diagnostics And Recovery) is coming up next to be
integrated into the fledging FC GSM fw source, so we will understand
this file very soon. :-)

> Glad to help. I hope this gives you some information :-)

One part which I have yet to learn is how the SMS receiving path works.
It seems to me that when the network delivers an MT (mobile-terminated)
SMS to the mobile, the modem has to store that SMS on its own and
acknowledge receipt to the GSM network before it can pass that SMS to
the application processor, as the latter has to jump through the hoops
of first being notified of that SMS, then retrieving it via GSM 07.05
AT commands.  Where does the modem store these "waiting to be picked
up" SMS?  There are only two possibilities: either in the FFS, or on
the SIM.  Given how feature-rich TI's standard modems are, I suspect
that one can do both, probably selected by some AT command - but I have
yet to learn this part.  But if so, I don't know which of these two
configurations is chosen by the "standard" FR user distros.

> Changing the subject, I wonder if the following makes sense: would it be
> possible, through the GSM, to obtain (backup) ALL the content of the SIM
> so to be able to "fake" the SIM at software level?

While most info stored on the SIM can be retrieved (IMSI, MSISDN,
phonebook entries, saved SMS), there is one critical data item which
is stored in the SIM and normally cannot be retrieved: it is the Ki.

Ki is the secret key by which the mobile authenticates itself to the
network as the legitimate owner of its IMSI and the associated phone
number, but the key itself is never transmitted over the air or even
released to the phone/modem by the SIM - instead the SIM, acting as a
little processor in its own right, cryptographically proves the
knowledge of the Ki to the network authenticator without revealing the
shared secret itself.  (I have not yet studied the actual protocols
and crypto algorithms, but I assume they are based on the same general
principles as commonly-used public key cryptography.  In the public
key crypto analogy, the IMSI would be the public key and the Ki is the
corresponding private key.)

> This would make the phone a pseudo-dualSIM: for example, owning two SIMs
> (and their software backups) it should be possible to switch from one to
> the other at software level.

By design the Ki is not supposed to be extractable from a SIM, just to
preclude exactly what you are asking for here - and what many others
would naturally like to be able to do.  From what I understand, some
early SIMs had weaknesses which allowed the Ki to be extracted, but
supposedly all currently-issued SIMs have that hole plugged up. :-(

VLR,
SF