Giacomo 'giotti' Mariani <giacomomari...@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 _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
