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 nor...@arnet.am 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 jo...@openmoko.org 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 SIM out first, throwing it away, then
doing the IMEI changing
Re: The open hardware phone project that's had the most interest
Hi, GTAx is allready more extensible than normal smartphones because of usb host mode. And any different fast data connector I think about might allow an attacker to get access to your system, like the hacks with firewire. I also think it would be nice to have modular phone, but this is a huge goal and seems to need serious research and many iterations of practise before you are happy with it. Regards, Kai ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About the future of the freesmartphone.org middleware
Hello, I think these all together will be fine. The only thing I have in my mind beside these is something I ever wanted to try but never did: redirecting sound (e.g. a sound file with pause melody or answerphone) to the call input. But just an idea, thanks! Kai Am 21.07.2012 21:44, schrieb Thamos: Hi all. I've never seen someone using the conference-feature. I think selecting the provider is more important. (this one really annoys me, since i am near an border and simply can't phone until i get out auf alien range, if the phone switched one time, even reboot doesn't help...). I also miss the possibility to choose loudness of the ringtone reasonably. Most other phones are even able to choose a ringtone based of the caller! Apart from that i comply with you. kind regards, Thamos Am 21.07.2012 20:45, schrieb Simon Busch: Hey everybody, as a lot of you may have noticed we did two releases in the past months of the FSO stack. Both were related to bring stability and consistence to the stack. Now I want to talk with you about the future of the stack. In the past we were only concentrating on getting new hardware supported and lost our real focus on creating a middleware suitable for embedded/specific-purpose devices. This is where I want to go back to and get into development again. In the last weeks I looked over several parts we have in our stack and tried to find out where we can improve and get into development of new features again. A lot of you have stability in mind as you want to use something with FSO on your daily phone. Thats the second peace which should be part of the core development focus of the Freesmartphone.org middleware. Getting new features is fast said but I have several things on my list where I want to improve FSO in the next weeks and months. Everything is focused on the core stack which is formed by our framework libraries and the three daemons fsodeviced, fsogsmd and fsousaged. We have other daemons like fsotdld as well but that will be not on my focus. If someone wants to step up with further development of these just go on and get in contact. But please don't get me wrong: I will support all other daemons like fsoaudiod and fsotdld in the next releases too but just not doing any development related work for them. For fsogsmd there are the following things on my list: 1. Get the last peaces of not implemented things in like conference or emergency calls 2. Several API cleanups 3. Get several bugs fixed 4. Do integration testing with a remote controlled phonesim so we can simulate incoming calls etc. This will also included integration testing with a remote controlled fsogsmd on another device 5. Multi device support: While working in HFP HF support in fsogsmd I discovered that things would be easier if we can control more than one modem with the same daemon at the same time. Think about phone with support for more than one SIM card. Work has already started for this in the morphis/multi-device branch of the cornucopia repository. 6. Cleanup of the modem status handling: right now the modem status and SIM/network status are too much tight together. We have cleanly separate them. 7. Internally we don't separate a modem from a AT based modem; that needs to be fixed 8. A lock-down mechanism to keep anyone out when doing a firmware upgrade. When doing a firmware upgrade of a modem we have the problem that nobody should access the modem while this is in progress. The idea is now to implement a dbus API to lock the modem by requesting a lock and only the requesting program can unlock the modem again. While the modem is locked nobody else can access the modem via fsogsmd. fsousaged: - nothing right now fsodeviced: - nothing right now lib*: - I am thinking about grouping all libraries together so just have one single framework library and don't need to maintain several small libraries which increases the complexity of release testing, ABI refinements, etc. Just one libfsoframework; this is only a thought in my head right and nothing concrete. That are some of my toughs were I want to go with FSO in the next months. So no focus on concrete devices but getting the stack itself forward to be ready for every kind of a device. I would be really happy to hear what other people are thinking about the idea behind FSO since it was started back in 2008. What are your missing features? What do you like and what not? regards, Simon ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Discussion: what are your dreams for the Openmoko Community
* a user interface based on GNOME Shell with integrated FSO dialer and onscreen keyboard * a good finger friendly browser (best would be Epiphany, because of the great web app support) * Network Manager or Conman? Which GPSd and what about bluetooth * systemd and Wayland, best would be a Debian based system * WAC support (Tizen) or compatibility to B2G Am 28.04.2012 14:37, schrieb Timo Juhani Lindfors: Dr. H. Nikolaus Schaller h...@goldelico.com writes: What would you like as future hardware? What to see in software distros? I'd like to have an open source calendar application, please :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] Keyboard for GTA04
Hey, I would like to have it rather swinging out than sliding. Then you could lock it at ca. 180° (with a bar or something) and by using the full back area of the case, it would be big enough for a expanded layout. As connector I would like USB more than bluetooth, but don't know how thin a cable can be. Regards, Kai ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About QtMoko future
Btw, I've been thinking about integrating qtmoko to Debian. Perhaps as a Debian Pure Blend, or even building single packages. I didn't go deeper yet, but will try to share this ideia during Debconf. Actually, pabs mentioned it once to me in some debian irc channel, so strictly speaking it's his idea :) Had anyone here thought the same? It wouldn't change the current upstream development model, so radek and qtmoko contributors don't need to worry. Updating the system would be much easier for users having official Debian packages for qtmoko. This sounds nice! I coundn't try qtmoko till now because I have a normal Debian installation with FSO-Stack, Matchbox and Zhone. Being able to use qtmoko aside would be cool. Greets and thanks for your work, Kai ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ventura Debian package? [Re: ventura upgrades]
Hey, I just copied the compiled files and made a deb-archive using debreate. I anybody could compile and link it to the unstable/testing-debian-libs, it would be great. Kai c_c schrieb: Hi, @ Kai : How do you compile packages for debian on FR? Using a toolchain or a bitbake recipe? I don't have debian on my FR - or a build system for debian on my PC. What needs to be done is to build ewebkit and ventura using the debian build system. My understanding is that if you can get ewebkit to compile (using whatever packages debian has - new or old or just differently named) then compiling ventura should not be an issue. You can check out the code from the repo at elm-browser.googlecode.com, change the Makefile.am to use the names of packages as existing in debian and run autogen.sh. ventura mainly depends on elementary and ewebkit. HTH ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ventura Debian package? [Re: ventura upgrades]
Hi, I tried to port ventura and libewebkit packages to debian, but SHR uses some really old packages (libicui for example) which are difficult to install in debian, because there are much newer packages installed. This is one site, but at the other side, debian does not have libecore-input-evas-svn05, only libecore-input-svn-05 is there. When I had copied and installed all files, there was an error caused by the different library versions, I think. The best thing to bring it running would be a new compile to link it with newer versions, I think. I send the little-bit-not-working-packages link ( http://ur1.ca/xx4m ). So you can see the dependencies (I think, I found the right packages on debian - SHR-names are different). Greetings, Kai c_c schrieb: Hi, Mikael Berthe wrote: Do you know if somebody has built a Debian package for Ventura? It looks like ewebkit is missing as well on Debian. I don't know. Though I'm willing to help if someone attempts this. I tried making a deb for intone, but it didn't quite work out right. ewebkit is a requirement, as is ca-certs for https pages. It seems to me that debian lags when it comes to EFL related packages - though there have been attempts to get EFL going on debian. I'm not current with my information though - so things could have changed. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Two queries about Android installation
Hey, does this flashing work without SD? http://code.google.com/p/android-on-freerunner/wiki/FrequentlyAskedQuestions See #1. Greetings, Kai Christian Rüb schrieb: Neil Jerram wrote: On 24 April 2010 21:59, James Ancona j...@anconafamily.com wrote: The installer puts all of Android in NAND. After installation the SD card is only used for extra storage (web downloads, media, etc.) Any FAT formatted SD card will do. You can run with no SD card in there, but as I recall, some things don't work. It should boot other distributions from SD. The modification is because Andoid uses a different NAND partition layout. If you want to replace Android with a different distribution in NAND, you should reflash Qi. Hope that helps! Yes thanks, it does. It tells me that I can't switch between Debian and Android completely seamlessly - but that I can at least do it by swapping SD cards. Which is probably OK for now. FWIW, my reason for asking is that I'm now hoping to find something a bit more swishy and impressive than just basic phone function. Debian has been fine for me for basic phone function for some time now, and I expect to keep that as my mainstay. But I'd love to be able to demonstrate how cool the FR is by saying but look, it can also run Android, here Regards, Neil I had similar reasons to try Android - another being is the browser ;-) You can use an SD only version, which is documented in this thread [1] and mirrored here [2]. I have _normal_ Qi as bootloader and Android + SHR on my SD which looks like this: p[FAT, for Android data] p[ext3, Androit rootfs] p[ext3, SHR rootfs] e[ext3 data] e[swap] NAND holds an SHR-U of known state that is functional for basic calling - just in case... What I really miss though are easy updates for Android on SD. Cheers, Christian [1] http://code.google.com/p/android-on-freerunner/issues/detail?id=7 [2] http://openmoko.senfdax.de/android/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Two queries about Android installation
Yeah, it works with 0.2.0 RC1: Download the zip-file unzip the contents. Run the following dfu-util commands: dfu-util -a kernel -R -D kernel.img dfu-util -a rootfs -R -D system.img dfu-util -a u-boot -R -D qi.img I have no inserted SD. The first boot does not work, so restart. Great thanks! Kai Kai Lüke schrieb: Hey, does this flashing work without SD? http://code.google.com/p/android-on-freerunner/wiki/FrequentlyAskedQuestions See #1. Greetings, Kai Christian Rüb schrieb: Neil Jerram wrote: On 24 April 2010 21:59, James Ancona j...@anconafamily.com wrote: The installer puts all of Android in NAND. After installation the SD card is only used for extra storage (web downloads, media, etc.) Any FAT formatted SD card will do. You can run with no SD card in there, but as I recall, some things don't work. It should boot other distributions from SD. The modification is because Andoid uses a different NAND partition layout. If you want to replace Android with a different distribution in NAND, you should reflash Qi. Hope that helps! Yes thanks, it does. It tells me that I can't switch between Debian and Android completely seamlessly - but that I can at least do it by swapping SD cards. Which is probably OK for now. FWIW, my reason for asking is that I'm now hoping to find something a bit more swishy and impressive than just basic phone function. Debian has been fine for me for basic phone function for some time now, and I expect to keep that as my mainstay. But I'd love to be able to demonstrate how cool the FR is by saying but look, it can also run Android, here Regards, Neil I had similar reasons to try Android - another being is the browser ;-) You can use an SD only version, which is documented in this thread [1] and mirrored here [2]. I have _normal_ Qi as bootloader and Android + SHR on my SD which looks like this: p[FAT, for Android data] p[ext3, Androit rootfs] p[ext3, SHR rootfs] e[ext3 data] e[swap] NAND holds an SHR-U of known state that is functional for basic calling - just in case... What I really miss though are easy updates for Android on SD. Cheers, Christian [1] http://code.google.com/p/android-on-freerunner/issues/detail?id=7 [2] http://openmoko.senfdax.de/android/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Literki problem
Hi, I used the git-file: http://git.senfdax.de/?p=literki;a=blob_plain;f=literki_conf.html;hb=HEAD Just wrote this in the openmoko-wikipage, but only in discussion. Kai Martin Hagwall schrieb: Thanks. Also the instructions for Literki (http://pvtrace.com/literki_conf.html) taken from the Literki-page (http://www.opkg.org/package_232.html) are down. Are they available somewhere else? Martin Date: Sun, 11 Apr 2010 14:01:12 +0200 From: vfeb...@easter-eggs.com To: community@lists.openmoko.org Subject: Re: Literki problem Martin Hagwall wrote: For being able to install Literki on my FR i need *libfakekey*, but I can't find it anywhere online. I was guided to the latest Grid Pad release (http://www.opkg.org/package_143.html) but it seems to be down :( Any tips? It is available in SHR-Unstable repo http://build.shr-project.org/shr-unstable/ipk/armv4t/libfakekey0_0.2+svnr1455-r1.4_armv4t.ipk -- Valéry ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Sign up now. https://signup.live.com/signup.aspx?id=60969 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
