Re: Fun with IMEI (was testing the free calypso software)
=?UTF-8?B?S2FpIEzDvGtl?= 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
Re: Fun with IMEI (was testing the free calypso software)
El día Tuesday, February 04, 2014 a las 08:34:00PM +0100, Kai Lüke escribió: > > 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. For this see the thread in our mailing list with the Subject: Subject: FR && non encrypted calls in July 2011. I.e. the FR knows perfectly well if the call is ciphered or not. We only should bring this information to the GUI with a question: Call not ciphered, should we continue yes or no? matthias -- Sent from my FreeBSD netbook Matthias Apitz, , http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fun with IMEI (was testing the free calypso software)
Hello community,
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.
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.
Also: Could the gsm module be made working without a SIM, i.e. just by
providing the necessary values like IMSI and Ki? As far as I don't know
the issue well, it's just a question ;)
Regards,
Kai
Am 04.02.2014 01:23, schrieb Michael Spacefalcon:
> Norayr Chilingarian wrote:
>
>> Does anyone know what will happen in a cellular network where there is
>> more than one device has the same IMEI. In other words, if we all
>> could change our IMEI numbers, and use one imaginary number, are there
>> technical reasons for network to not work.
> joerg Reisenweber responded:
>
> : no technical but organizational. Usually that IMEI gets an instant ban, and
> : a fat bold red alarm logline in carrier's network logs.
>
> Yup, if all of us were to use the same IMEI number, it would be far
> too easy for our enemies to ban that one single number.
>
>> I mean, MAC address is used on a physical layer, so if two network
>> cards connected to the same switch have same MAC adresses, network
>> won't work. I guess switch will down both ports connected to those
>> devices.
> The analogy between IMEIs and Ethernet MAC addresses is a good one
> from a manufacturing/management perspective, but not in terms of
> network protocol usage. Unlike MAC addresses, IMEIs are not used for
> any kind of addressing or routing anywhere in the network, only as a
> "management" identifier that is unnecessary in the strict technical
> sense.
>
> But from the perspective of a device manufacturer (which I will become
> soon, hopefully), IMEIs are just like Ethernet MAC addresses: the
> nominal requirement is that each be world-unique for all time (a rule
> that gets broken in reality with both MAC addresses and IMEIs), a
> manufacturer has to buy a range (supposedly "fresh" and unused) from a
> central registry, and then number individual produced units out of
> that range.
>
>> But I don't know how IMEI's work. Are they technically necessary so
>> that 3G/gsm network can be operational, or they are only used to
>> identify (and track) customers by devices?
> The latter.
>
> Before everyone starts changing their IMEIs just for the heck of it,
> let's analyze *rationally* how tracking works - or rather, what is the
> total set of data elements available to carriers (and their gov't
> partners etc) for tracking users, and how these data elements inter-
> relate.
>
> If you like maintaining a long-term-constant phone number at which
> your family and friends can reach you (i.e., the whole purpose for
> having a cellphone, at least for me), and you have a long-term-stable
> SIM card associated with that long-term-constant phone number, then it
> doesn't really matter if your IMEI is also constant or if you send the
> output of a PRNG (or even a TRNG) to the network as your IMEISV every
> time your phone/modem fw does the "register" operation. The constant
> SIM card with its IMSI, as well as the associated MSISDN (phone number
> for your family and friends to call you at), is what tells the network
> that "you" are still the same "you", no matter what device you use or
> what IMEISV it transmits. Yes, you can deregister from the network,
> then re-register with a different IMEI, making it look like you turned
> your phone off, moved your SIM card to another phone, then came back
> online with the latter - but what would be the point?
>
> Instead, there are only two scenarios I can think of in which it would
> make sense to change the IMEI of a GSM device:
>
> 1. If you really want to "disappear w/o trace", such that you discard
>your old SIM, get a new SIM (prepaid, presumably) with a different
>phone number (and deliberately make yourself unreachable at your
>old one), and you want to make it look like the user of the new SIM
>is a different person from the user of the old SIM - in this case
>the same IMEI would indeed give you away, so you might want to
>change it in this case.
>
> If the above applies to you (and it does *not* apply to me, as changing
> phone numbers constantly would defeat the whole purpose of a cellphone
> for me), then you need to be careful to change your IMEI *at exactly
> the same time* when you change your SIM - if there is any time skew
> between these two changes, such that a network sees {old IMEI, new SIM}
> or {new IMEI, old SIM} at any time, even just once, your anonymity
> effort will be instantly brought to naught! If you want to do this, I
> would recommend pulling your old S
Re: TIFFS in vitro analyzer tool released
Giacomo 'giotti' Mariani wrote: > It's been easier than expected: > > root@neo:~# . /opt/qtmoko/qpe.env > > root@neo:/root# /etc/init.d/qtmoko-neo stop > root@neo:/mnt/nfs/root/ModemFFS/Backup# fc-loadtool -h gta02 /dev/ttySAC0 > [...] > root@neo:/mnt/nfs/root/ModemFFS/Backup# /etc/init.d/qtmoko-neo start Nice. :-) > Now I'm looking at it with mokoffs :-) Because my sample size so far has been 1, I would like to know how the FFS content on other FR units differs from mine. I would appreciate it if you could do a mokoffs xtr on your FFS image, then do the same on the image from my FR (from my FTP site, URL posted earlier), and then let me know what diff -r between the two extracted trees shows. David Matthews wrote: > That's interesting - and it worked without a cacophony as accompaniment? I repeat: if one does not do 'echo 1 > /sys/bus/platform/devices/gta02-pm-gsm.0/download' which is not necessary when running loadtools from the AP (but is necessary for the cable method), then the cacophony cannot occur. > I just tried to confirm this myself; using the cable method it does not work > for me on Qtmoko 54. I had the same problem using SHR and following the > instructions that Norayr posted, but again using a cable rather than running > loadtools on the phone as he did. Have you ever tried troubleshooting it like I suggested earlier? I.e., take loadtools out of the equation for a moment, run a standard terminal emulator program like minicom on the PC end of the cable, then try echo'ing '1' and '0' into the 'power_on' node in sysfs and see if the RVT output appears/disappears in response? VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: TIFFS in vitro analyzer tool released
Hi David, > hi Giacomo > > >> It's been easier than expected: >> >> root@neo:~# . >> /opt/qtmoko/qpe.env >> >> > That's interesting - and it worked without a cacophony as accompaniment? I did not tried to listen at the speaker, but it looks so :-) > > I just tried to confirm this myself; using the cable method it does not work > for me on Qtmoko 54. I'm on QtMoko 58. > I had the same problem using SHR and following the instructions that Norayr > posted, but again using a cable rather than running loadtools on the phone as > he did. I put this down to different SHR versions, but maybe that was not the > issue. > > It looks like it may be easier to put a standard distro in a suitable state > for flashing the calypso using the loadtools on phone rather than loadtools > on PC method. If that's so a debian package of loadtools (to use with > qtmoko) would be a useful convenience. As far as I can see, it should be absolutely possible. PS If someone needs, I can share my files so that a simple "make install" should be enough. Cheers, Giacomo > > > -- > David Matthews > m...@dmatthews.org > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community -- ## giacomo 'giotti' mariani gpg --keyserver pool.sks-keyservers.net --recv-key 0x99bfa859 O< ASCII ribbon campaign: stop HTML mail www.asciiribbon.org ## ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Re: TIFFS in vitro analyzer tool released
hi Giacomo >It's been easier than expected: > >root@neo:~# . >/opt/qtmoko/qpe.env > > That's interesting - and it worked without a cacophony as accompaniment? I just tried to confirm this myself; using the cable method it does not work for me on Qtmoko 54. I had the same problem using SHR and following the instructions that Norayr posted, but again using a cable rather than running loadtools on the phone as he did. I put this down to different SHR versions, but maybe that was not the issue. It looks like it may be easier to put a standard distro in a suitable state for flashing the calypso using the loadtools on phone rather than loadtools on PC method. If that's so a debian package of loadtools (to use with qtmoko) would be a useful convenience. -- David Matthews m...@dmatthews.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: TIFFS in vitro analyzer tool released
Hi David, Michael, all, > Hi > >> It looks like you will need to convince the maintainer of Qtmoko to >> tell you (and the rest of us) how to get his popular distro working >> with FreeCalypso tools. Or you could try the special distro which >> David Matthews put together - the 2nd version which works without the >> special cable. > Making a general purpose distro such as Qtmoko loadtools capable is likely to > be a non starter. As well as stopping everything that's accessing the modem - > which will likely be the problem Giacomo reported - it's likely to be > advisable to rip out all the audio stuff also. > > hehe - So prepare your qtmoko (by ripping it to shreds), run loadtools to > flash your calypso, then reinstall and recover your data from backups :-) It's been easier than expected: root@neo:~# . /opt/qtmoko/qpe.env root@neo:/root# /etc/init.d/qtmoko-neo stop root@neo:/mnt/nfs/root/ModemFFS/Backup# fc-loadtool -h gta02 /dev/ttySAC0 Sending beacons to /dev/ttySAC0 Toggling /sys/bus/platform/devices/gta02-pm-gsm.0/power_on Got beacon response, attempting download flash dump2bin my-flashdump.bin Requesting initial CRC-32 of the area from target... got 95D5AB43 Requesting memory dump... Rx 4194304 out of 4194304 bytes (100%) Requesting another CRC-32 of the area from target... match, dump successful root@neo:/mnt/nfs/root/ModemFFS/Backup# /etc/init.d/qtmoko-neo start Now I'm looking at it with mokoffs :-) Thank you very much, Giacomo > > Better idea - use the "special distro" (I used Qtmoko as a starting point) > with or without the cable - or else build your own single purpose > boot_and_run_from_sdcard system. > > http://winterveldt.co.za/leo2moko-p2.html > -- > David Matthews > m...@dmatthews.org > -- > David Matthews > m...@dmatthews.org > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community -- ## giacomo 'giotti' mariani gpg --keyserver pool.sks-keyservers.net --recv-key 0x99bfa859 O< ASCII ribbon campaign: stop HTML mail www.asciiribbon.org ## ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
