=?UTF-8?B?S2FpIEzDvGtl?= <kaitobiaslu...@googlemail.com> wrote:
> thanks to the recent activies I also thought about IMEI yesterday
> evening and it was fun that other's also did. Setting IMEI would still
> be a nice feature.
A general purpose FFS editing kit for GTA01/02 modems, which will
include the ability to set the IMEISV to whatever you like, is coming
soon - be patient. (Or if you are impatient, feel free to follow the
project as it happens in the Mercurial repository on Bitbucket.)
Yes, I said IMEISV, not just IMEI - if you don't know the difference,
read it up on Wikipedia etc. Even though the file in TI's device file
system is named /pcm/IMEI (at least on older modems like Om's which
don't use the so-called "IMEI protection"), the number it actually
stores is the IMEISV. The file is (or should be) exactly 8 bytes long,
storing the 16 digits of IMEISV, two digits per byte, and the GSM
protocol stack into which this number is fed (by way of a function
called cl_get_imeisv(), grep for it in the leo2moko source) treats the
last two digits (stored in the last byte) as the SV field, not the
Luhn check digit.
That being said, it looks like both Openmoko/FIC and Pirelli/Foxconn
set the SV field of their factory-programmed IMEISV numbers to x0,
where x is the Luhn check digit for the IMEI part, such that one can
"cheat": take the 16-digit IMEISV, drop the last digit, and treat the
remaining 15 digits as if they were the "classic" IMEI. (Such
"cheating" is what my current leo2moko implementation of the AT+CGSN
command does - I made it match Om's functionality before I realized
that /pcm/IMEI is really IMEISV.) A more reliable way to retrieve the
complete IMEI information on any TI-based modem is to issue an ATD*#06#
command: it will return a 17-digit number consisting of the 14 digits
of the IMEI proper, the Luhn check digit, and the 2 SV digits.
> In addition it would be interessting for me (in times of surveillance)
> whether silent sms (stealth ping) could be recognized and a report be
> dropped to the mobile phone. Also the change to non-encrypted transfer
> would be a similar event which might occure due to an IMSI catcher, so
> generating a message (SMS?) warning the user would be helpful.
Before we can implement the alerting functions you are asking for, we
need to liberate the GSM protocol stack first. The current leo2moko
fw has this protocol stack in a bunch of binary object libraries, as
that's what TI provided in the TCS211 ("Leonardo") deliverable. Full
source forms of closely related versions are available through the
TSM30 and LoCosto leaks though, the latter being more promising - hence
the current FC project plan is to try lifting the g23m* code layers
from the LoCosto version, and see what we get. But there is a bunch
of other preparatory work that needs to get done before we get to that
point.
> Also: Could the gsm module be made working without a SIM, i.e. just by
> providing the necessary values like IMSI and Ki?
Sure thing, and OsmocomBB already supports such usage. But where are
you going to get a Ki that is recognized as valid by the GSM network
you wish to use? And what would the corresponding phone number
(MSISDN) be?
VLR,
SF
_______________________________________________
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
