Reply
Thread Tools
fragos's Avatar
Posts: 900 | Thanked: 273 times | Joined on Aug 2008 @ Fresno CA USA
#41
Originally Posted by code177 View Post
As the OP, my question, essentially, is thus:

Say: I have a website, and I have an app on the N900, and I want the app to be able to communicate with the website server. However, I want to maintain a level of stability and consistency on my platform, so I'd like to be able to maintain a database on the server which may have information pertinent to that device and that device only. For example, if a person was rating something, keeping settings, or a list of some kind, they'd need to be able to access this reliably without having to enter new information.

There are plenty of ways of doing this (generating keys, auto-registrations, keeping the information locally, etc), but those aren't what my question is about

IMEI is a good bet, but wouldn't work with non-gsm devices (right?) so that's automatically limiting. A string that you can append to an API is what i'm looking for.

Thanks again
The way this is normally done is by writing a cookie on the accessing device which you retrieve when the user returns. The user can elect you not allow cookies and has possession of their information. I frequently use this approach to store the last date of access so that I can flag items that are new to this particular user.
__________________
George Fragos
Internet Coach & Writer
Maemo Mapper HowTo
Personal Blog -- 3 Joe's Blog


N810 -- 5.2010.33-1
 
Posts: 237 | Thanked: 167 times | Joined on Feb 2007 @ Powell, OH
#42
Originally Posted by ewan View Post
The original post didn't mention FOSS, but neither did it mention using the identifier to lock down software to a particular unit, that was first brought up in this comment:



You're perfectly correct that not all software running on Maemo has to be FOSS (indeed, not all software in Maemo is FOSS), but enough of it is to ensure that this sort of game by proprietary software can be defeated - if you query an identifier from Python I can hack Python to lie to you, if you go via dbus I can modify dbus, and if you pull it from the kernel I can change the kernel.

Having free underpinnings in an OS goes a long way to defending the end users rights, which I think is a good thing. However, even if you think it's not, it's worth being aware that this sort of ad-hoc DIY DRM scheme is likely to not work on a platform like this one.
You can easily use the IMEI id as a public key but only your closed source code has the private key and when you buy the software you're provided an unlock code. Could you decrypted it given time, sure but your time would be better spent paying for the software. Navicore GPS software on the N8XX were licensed by device.

I'm sure Nokia wants commercial software on this device.
 

The Following User Says Thank You to theflew For This Useful Post:
YoDude's Avatar
Posts: 2,869 | Thanked: 1,784 times | Joined on Feb 2007 @ Po' Bo'. PA
#43
Originally Posted by theflew View Post
You can easily use the IMEI id as a public key but only your closed source code has the private key and when you buy the software you're provided an unlock code. Could you decrypted it given time, sure but your time would be better spent paying for the software. Navicore GPS software on the N8XX were licensed by device.

I'm sure Nokia wants commercial software on this device.
Exactly.

And my early reply to code177's post was to move the thread in the direction that your post has taken us... thanks again. I didn't mean to get into a debate about the meaning of life.

I do not have an N900 yet, but from the links that I provided I gathered that the IMEI should be available. The wording that I chose to explain my reasoning could have been better, but my reasoning was sound.

Last edited by YoDude; 2009-11-10 at 01:01.
 
tekojo's Avatar
Posts: 148 | Thanked: 484 times | Joined on Nov 2008
#44
Originally Posted by code177 View Post
Good idea, but kinda overkill Don't Nokia devices have a unique ID somewhere? Would be surprised if they didn't.
This is not my area of expertise, I can go and find someone tomorrow with real knowledge to answer the question.

For the N900 the unique id is the IMEI.
For the N8x0 it used to be WLAN MAC, but as said previously in this thread, it isn't the perfect thing.

On a side note, there is a mail question in the maemo-developers mailing list about asking the IMEI from the device.
 
qwerty12's Avatar
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#45
Not entirely hard to get the IMEI in C - for the N900 - at least:

Code:
/* gcc -Wall imei_example.c -o imei_example `pkg-config --cflags --libs glib-2.0 dbus-glib-1` */

#include <stdlib.h>
#include <glib.h>
#include <glib/gprintf.h>
#include <dbus/dbus-glib.h>

#define SIM_DBUS_NAME  "com.nokia.phone.SIM"
#define SIM_DBUS_IFACE "Phone.Sim.Security"
#define SIM_DBUS_PATH  "/com/nokia/phone/SIM/security"
#define SIM_IMEI_SIG  "get_imei"

static gchar* get_imei(DBusGConnection *connection)
{
  GError *error = NULL;
  DBusGProxy *proxy;
  gchar *imei = NULL;
  guint32 tmp1;

  g_return_val_if_fail(connection, imei);

  proxy = dbus_g_proxy_new_for_name(connection, SIM_DBUS_NAME, SIM_DBUS_PATH, SIM_DBUS_IFACE);
  if (!dbus_g_proxy_call(proxy, SIM_IMEI_SIG, &error, G_TYPE_INVALID, G_TYPE_STRING, &imei, G_TYPE_INT, &tmp1, G_TYPE_INVALID))
  {
    if (error->domain == DBUS_GERROR && error->code == DBUS_GERROR_REMOTE_EXCEPTION)
      g_printerr("Caught remote method exception %s: %s", dbus_g_error_get_name(error), error->message);
    else
      g_printerr("Failed to call method: %s\n", error->message);
    g_clear_error(&error);
  }
  g_object_unref(proxy);

  return imei;
}

int main(void)
{
  GError *error = NULL;
  DBusGConnection *connection;
  gchar* imei;

  g_type_init();

  connection = dbus_g_bus_get(DBUS_BUS_SYSTEM, &error);
  if (!connection)
  {
    g_printerr("Failed to open connection to system bus: %s\n", error->message);
    g_clear_error(&error);
    return EXIT_FAILURE;
  }

  imei = get_imei(connection);
  (void) g_printf("%s\n", imei ? imei : "Failed to retrieve IMEI\n");
  if (!imei)
    return EXIT_FAILURE;
  g_free(imei);

  return EXIT_SUCCESS;
}
I tried to do the same in Python, but it seems python-dbus likes to think I don't know what the types of the values returned will be and tries to introspect. No idea how to override that...

Last edited by qwerty12; 2009-11-11 at 15:14.
 

The Following 9 Users Say Thank You to qwerty12 For This Useful Post:
R-R's Avatar
Posts: 739 | Thanked: 242 times | Joined on Sep 2007 @ Montreal
#46
How is the IMSI protected ?

Carriers usually don't care about the IMEI cause they let you change your phone (my understanding) but the IMSI is your account number which links to your usage, etc...

It would probably be easy to find where the IMEI is sent and change it on the fly with some LD_PRELOAD or other techniques, but I'm guessing that the IMSI is in the smart card and has some form of crypto handshake with the provider?

Or is this just a receipt for fun^W disaster?

EDIT: http://en.wikipedia.org/wiki/IMSI-catcher
Also interesting, we should make sure the N900 show that (!) when it's not using encryption!

Also interesting: http://www.gsm-security.net

EDIT2: Uhm, of course there is a handshake, no multi-IMSI backup for multi-line use hehe (unless someone give you the key stored in the SIM, which, won't happen! ;-)
But still, changing the IMEI could be useful for those stuck with data plans tied to a specific device!

Last edited by R-R; 2009-11-10 at 19:01.
 
Posts: 13 | Thanked: 5 times | Joined on Oct 2009
#47
Originally Posted by fragos View Post
The MAC address by definition is unique and does identify a particular port network wide. Comcast in the US blocks connections to their modem of a single MAC address of the port connected to the cable modem when the the service was registered. To use a wireless router it was necessary to clone that ports MAC address into the modem. The only purpose of changing a MAC address is to appear to be a different to be a different network user, not to uniquely identify yourself.
MAC addresses are most certainly *not* unique. They *must* be unique on a single layer 1 segment - that is all. They also don't identify a "port". The identify a network hardware address for a node and work just fine in a pure-broadcast segment involving hubs.

MAC addresses are split into two chunks: 3 bytes for manufacturer identifier (OUI) and 3 bytes for "unique" identifier. That allows for 256^3 (2^24, ~16M) IDs for a single mfr ID. I can assure you that from some smaller NIC manufacturers I have received two NICs with the same MAC - in the same shipping batch even. Depending on the NIC, you either change the MAC on every boot before you bring the interface up, reflash the EEPROM or just keep the NICs on different layer 1 segments.
 

The Following User Says Thank You to devbike For This Useful Post:
Posts: 53 | Thanked: 90 times | Joined on Nov 2009 @ Manaus, Brazil
#48
Hi qwerty12,

I haven't tried with pure python-dbus, but I could make it work just fine with python-osso:

Code:
import osso
ctx = osso.Context('org.example.get_imei', '0.1', False)
rpc = osso.Rpc(ctx)
imei = rpc.rpc_run('com.nokia.phone.SIM', '/com/nokia/phone/SIM/security', 'Phone.Sim.Security', 'get_imei', (), True, True)
print imei
 

The Following 4 Users Say Thank You to lizardo For This Useful Post:
fragos's Avatar
Posts: 900 | Thanked: 273 times | Joined on Aug 2008 @ Fresno CA USA
#49
Originally Posted by devbike View Post
MAC addresses are most certainly *not* unique. They *must* be unique on a single layer 1 segment - that is all. They also don't identify a "port". The identify a network hardware address for a node and work just fine in a pure-broadcast segment involving hubs.

MAC addresses are split into two chunks: 3 bytes for manufacturer identifier (OUI) and 3 bytes for "unique" identifier. That allows for 256^3 (2^24, ~16M) IDs for a single mfr ID. I can assure you that from some smaller NIC manufacturers I have received two NICs with the same MAC - in the same shipping batch even. Depending on the NIC, you either change the MAC on every boot before you bring the interface up, reflash the EEPROM or just keep the NICs on different layer 1 segments.
When MAC addresses were 1st used they were unique. My bad for not keeping up with the times -- all numbered identification schemes will eventually exceed their numerical capacity. The MAC address is associated with a specific port, physical connection, on the network. I have two Ethernet ports on my Desktop and each has it's own MAC address. I think we're splitting hairs on terminology. As a manufacturer of telecommunications equipment our manufacturing process insured we never repeated a MAC address on any of our networking gear with Ethernet ports. Clearly your NIC provider has lousy manufacturing process control.
__________________
George Fragos
Internet Coach & Writer
Maemo Mapper HowTo
Personal Blog -- 3 Joe's Blog


N810 -- 5.2010.33-1
 
ewan's Avatar
Posts: 445 | Thanked: 572 times | Joined on Oct 2009 @ Oxford
#50
Originally Posted by fragos View Post
I have two Ethernet ports on my Desktop and each has it's own MAC address.
This is relatively novel; at one point MACs were typically used on a per device basis not a per port one, so all the interfaces on a given machine would have the same MAC. That does mean that you can't plug several ports on one node into a single network segment, but the theory was that you'd never need to.

Said theory doesn't always hold true any more, of course.
 
Reply

Tags
maemo 5, n900, python, unique id


 
Forum Jump


All times are GMT. The time now is 16:17.