GSM Tech

[Torsten Schlabach]

Dr. H. Nikolaus Schaller wrote:

 > * The code might be individual for each IMEI (Mobile Equipment
 > Identifier), i.e. your specific device.

It is! There is no "universal" unlocking code.

 > * It is NOT stored on the SIM.
 > So, the phone is locked for a specific  SIM.

Well, it's called SIM lock, but it's the phone which is locked, not the 
SIM. The network operator does not care what terminal equipment you use 
to make him earn money, they just don't want to you create revenue for a 
different operator with a terminal (phone) they subsidized.

 > * It is NOT stored in the Network (Home Location Register)

That wouldn't make any sense either. All other operators (not the one 
who locked the phone) would have to ban it. But they couldn't care less. 
They don't even care to block stolen phones any more AFAIK.

 > * So, the only remaining location can be the EEPROM/Flash of the GSM
 > module.

Sorry, but I cannot follow you here. How do you come to that conclusion?

It could as well be stored in the phone's memory. The phone's memory is 
not the same as the GSM module's memory. (If that even has any.)

In other words: I'd expect SIM lock to be a feature of the phone's 
operating system, not of the GSM module. I might be wrong, though ...

The interesting question is: How much software and how much hardware is 
in a GSM module's chipset.

Regards,
Torsten

Dr. H. Nikolaus Schaller schrieb:
> 
> Am 15.12.2007 um 16:28 schrieb Joe Pfeiffer:
> 
>> Steve writes:
>>
>>>
>>> I'd agree with the statement about the AT commands, but I do think  its
>>> probably possible to get unintended functionality out of the GSM  modem
>>> without resorting to decapping the chip.  After all that is  exactly 
>>> what
>>> the unlockers are doing.
>>>
>>> The unlockers are probably a major reason why TI is so paranoid about
>>> the workings of their chipset since that is where the SIM and  provider
>>> locks are usually implemented.  I wish I could give you more  
>>> information
>>> about the techniques they use, but I don't know what they are.  It  
>>> would
>>> be interesting to find out, but FIC may not appreciate the  
>>> discussion on
>>> their mailing list either.
>>
>>
>> I hadn't thought of that -- now I do find myself wondering where and
>> how the locks are really implemented....
>>
> 
> If you look here (which is an official T-Mobile page in German):
> 
> http://www.t-mobile.de/vertrag/0,11547,17655-_,00.html?WT.srch=1
> 
> it is described as follows:
> 
> 1. you purchase an unlock code within 24 months or get it for free.
> 
> 2. how the unlock code is operated depends on the device model, i.e.
> they have a set of different PDF files describing it.
> 
> 3. for example on a Siemens phone, you switch on the device without
> the SIM card and type in the unlocking code. Then, you switch off
> and can install an arbitrary SIM card since it is unlocked.
> 
> So, what can we deduce from it?
> 
> * There is no "timer" for the 24 months
> * The code might be individual for each IMEI (Mobile Equipment  
> Identifier), i.e. your specific device.
> * It is NOT stored on the SIM. So, the phone is locked for a specific  SIM.
> * It is NOT stored in the Network (Home Location Register)
> * So, the only remaining location can be the EEPROM/Flash of the GSM  
> module.
> 
> Basically it is the same as a login on a computer. There is a user  name 
> (IMEI)
> and a password (IMSI). Passwords are stored in encrypted form  somewhere 
> in the internals
> of the operating system (/etc/passwd). And there is a second password  
> which can be
> used to enable "guest" login, i.e. remove the standard password.
> 
> Unlocking a module could therefore be securely provided by an AT  "UNLOCK"
> command where the user must provide an unlocking code that the
> network operator has issued.
> 
> Now, if it is stored in the module, the module's hard- and software  
> manufacturer
> must make sure that it can be unlocked only by providing the correct  
> unlock
> code through AT commands and that there is nothing like directly  
> writing to
> memory etc. Well, if the software of the module would be open source,
> they simply cannot assure this.
>