GSM Tech

[Dr. H. Nikolaus Schaller]

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.