Established 5. 10. 2000
Last Changes 28.12.2001 (after a long time almost everything has been updated.)
Here you can contact me, if you like.
I wrote this site in order to give you some information about cellular phones made by Sagem of the series 9xx. These information have been obtained on one hand by disassembling parts of the phone's OS or just by fitteling somewhere around. They serve _only_ for scientific purposes. If somebody thinks that some stuff on this site is against some national or european laws, well, let me know ...
OK, enough of the bla bla ... here we go now ...
Contents:
I decided to write some preface here, since a lot of things evolved and changed after the first creation of this page. At the very beginning it has really been very interesting and exciting to discover all those hidden features and things which are put into sagem cellular phones. This was possible because the whole firmware could be read out for disassembling and people working in the field used some 'open source' philosophy. At about one year ago Sagem changed their philosophy and decided to protect their phones more and more and removed also more and more features. From a short time view this is somehow comprehensible, however, I believe all those "nice little things you could tune" were also a strong reason for people to buy a Sagem phone. So if they will continue their strategy, very soon their phones will get as boring as all the other ones and I am afraid they will completely disappear from the market. Well, I hope they will reconsider it and I think they need to understand that there will be no way at all to avoid people finding solutions to unlock their own phone. Some higher protection will just work for a longer time but not for all the time. I am writing all of this, since I am pretty sure Sagem is consulting this page from time to time, aren't you ? :-) Well, another thing that has changed during the last month is the philosophy of the people working in the field. Those working for free and publishing their results are getting less and less. I believe that all those people should reconsider the fact that they would not be that far without the open source community. I hope one can find some compromise in the future that allows sharing information without disturbing commercial interests (which I definetly do not persue).
If someone is new to the field, well I think he'll also be interested in some general information about cellular phones and what's related to it. For these purpose there are already some very nice pages on the web (all in nice colour, graphics, blinking, shining and with popping ups and all this kind of stuff - hey, I like HTTP/1.0 :) ). OK, I will just give you some links to - from my point of view - some of the best pages in this area:
OverFloh's Page: For someone who really wants to get into the details of the Sagem phones, it's all there (in german). It's a bit out of date now, but anyway still a good point to start with.
Chris922's page: Treats the "PB 3 EEPROM" problem and gives instructions to solve it.
SagemDoctor homepage: Home of the sagem doctor software which is a need for everything you ever wanted to do with your phone ;-).
Nobbis GSM Seiten: Very good information about GSM Network.
Henning Gajeks mobile Funkseiten: The name tells you all :)
You can send some commands (other as AT's) directly via a data cable to the phone. They permit several things as e.g. reading out ram or prom. There are quite some commands available. You can find a list of them together with some instructions how to use and some software on hannes' page. Hannes also wrote a *very* useful software called sagemdoctor. You can use it to backup/repair your phone or just to play around :-). On his page you also can find a mailing list, which I can recommend very much for all types of questions about sagem phones.
Here I will provide some additional information:
Command 0x78 |
(thx to Tomi, OverFloh, Dejan)
This command gives you 36 bytes of output, which you can separate into several parts. The first two bytes are giving the length of all of the data so 36 (in hex: = 0x0024). Then there are 12 bytes following which contain the encrypted phoneID (6 bytes long) followed by 8 bytes which are always (hex) "da 11 a5 da 11 a5 da 11" and after those there are either 16 times 00 or "00 00 00 00 00 00 30 00 00 00 00 00 00 00 d0 ff".
You can find the ouput of this command also in ram. The only difference are the 8 bytes after the encrypted phoneID (da 11 a5 ...). They contain "real data" in the ram. If one wants to get the output of those real data during the phone command one has to change ram address 0x00000217 to 0xFE.
In order to decrypt the encrypted phoneID I wrote some small C-programme. You can find the phoneID in its decrypted form at ram address 0x00000219 and it can be encrypted with this programme.
In newer firmwares, however, encrypted phoneID is not output anymore. Fortunately, information you get is not completely useless :-). You should get at (after the 0x0024 stuff) some 0xFF's and after them a single byte. This byte identifies the hashtable used in your phone.
Command 0x88 |
This command gives you 13 bytes of output, whereas the first one is always equal to 1, since it is some kind of a status byte of the funcitionality of some routine. After that there are 12 bytes following which contain again the encrypted phoneId just as in the case of 0x78 (see above).
Command 0x6D |
This Command is called by Sagem as "Who am I". However, one wonders what the hell is this about ? :) The output has a total length of 5 bytes and the 3rd (like in the case of 0x88) is some status byte of some routine and is always 1. The 4th byte is the 6th last byte in the OS at all (address 0x2FFFFA) and is in my firmware equal to 0x19. The 1st, 2nd and 5th correspond to some ram addresses which are following each other in data page 0x4F. Who am I now ? :)
Command 0x79/0x7A |
These commands form a pair. They are used in order to allow access to the bootstrap mode in older firmwares. This is how it works:
The 0x79 command is called without any parameters. It gives two answers. The first giving no data with 0x73 and the second giving 128 byte data with 0x74. The 128 byte data are some encrypted 32 byte large data block from the ram area which is arbitrary data since some temporary changing ram addresses are used by the algorithm. The 128 byte are internally encrypted again and a sum is made over the even and odd words of this new buffer with the same length. These sums are stored in some ram addresses and the 128 Bytes are output to the serial port where they have to be read by some interface programme. The programme uses the data to encrypt them in the same way as it is done for the 0x79 just before the summing stuff and then it sends them back as the input data of the 0x7A command. In the phone those data are taken and the same sum as in the 0x79 is taken. The result of that sum is stored again in some ram addresses and after that the difference of these ram addresses with those from the 0x79 is made and if the result is 0 the value 1 is written into some other ram address (which means the given data are correct).
Command 0x23 |
This command gives a 12 digit number followed by firmware version and other information of the OS. The latter is also found directly in the ram. The 12 digit number is also found if you look at "Version" in the 'Hotline menue'. But how are these 12 bytes created (note that every digit ouput corresponds to an ASCII value of between 0x30 and 0x39, so every digit is a byte) ? The IMEI is also found in the ram (in its form of field 0) and its address I call ADDR, the content of ADDR is [ADDR]. 8 bytes of [ADDR] are selected. With them a temporary string T is created: T(0) = [ADDR+1], T(i) = [Addr+x] AND 0x0F, T(j) = [Addr+x] / 0x10 with i odd and j even and x = 1..8. In total T contains 15 bytes (0..14). Then byte 0 to byte 7 will be overwritten by byte 6 to 13 in T, so that effectively only 5 bytes of the IMEI are really used. Then another address (ADDR2) out of data page 0x4F is chosen and 8 bytes out of it are copied to from byte 15 to T. The copying is, however, not linear but:
After that the operation T(i) = T(i) AND 0x0F with i = 0xF..0x16 is performed. Note that [ADDR2+0x0A] corresponds to byte 1 of the output of 0x6D.
From this datapool the real outputstring (OUT) is created (12 bytes). It is firstly initialised with 0xFF. Then a position P in OUT is determined the following way: P = (T(i) + P + 1) % 12 (i = 7..0), first P = 0. If the calculated P >= 12 a new calculation is performed. If the position is already allocated (not 0xFF any more) it is determined by P = (P + 2) % 12. If P in OUT is calculated the data from T(0x0F) to T(0x16) are copied sequentially to those positions in OUT. The last 4 bytes are determined in the following way:
1. T([O(i)]) = T(O[(i)]) + 1, i=0..11, if O(i) not equal to 0xFF. N.B.: a) Since O(i) does not change necessarily a field can be incremented several times by 1. b) O(i) are already numbers between 0 and 9.
2. Find in T(i), i=0..9, the smalles element and determine its position P2.
3. Find in O unallocated Fields (containing 0xFF) and write in the first found P2. Then increment this byte by 1.
4. Clear T: T(i) = 0, i=0..9
5. Go back to 1 until all fields are allocated (and the last 4 bytes are determined).
After that all the values in O are ORed with 0x30, so O(i) = O(i) OR 0x30, so that in ASCII numbers between 0 and 9 are represented.
Looks rather complicated, doesn't it ? If someone has an idea whats the sense behind it he can let me know :).
Command 0x67 |
With this command (which doesn't take any input) some prom fields are brought to 'standard' values. The values of the prom fields are found in the upper flash region in the OS and are read out with the same routine as the 'mystery' buffer for the simmlock. The standard values for these fields of the length 16/32 Bit are also in this flash region. There is however also a second sequence of fields, for which the contents are found in the lower ram region, but the flash region is giving a pointer to it.
In a first run the following fields are written. The standard values are in brackets behind. The fields are written in chronological order: Field 131(0x4C), 19(0x33), 124(0x5A), 128(0x01), 154(0x01), 130(0x38), 3(0x80), 4(0x4B), 147(0x10), 165(0x0001), 112(0x09).
The second sequence of the fields is (in brackets the ram address where their content is found): Field 2(0x8380), 7(0x8386), 10(0x8399), 11(0x839C), 12(0x839C), 13(0x83A8), 14(0x83B2), 15(0x83BC), 95(0x83C6), 142(83DE), 144(0x83E2), 178(0x83F2), 194(0x8400), 198(0x840E), 206(0x8412), 211(0x841F), 217(0x8425), 227(0x8427), 233(0x842A), 240(0x842E), 1(0x8434).
Please note, that the ram addresses do not necessarily have to be the same for all FWs but the fact that they are located in the flash area implies this. I have noticed that the content of some ram addresses, however, may change during time.
One can probably clarify all this if one knows about the usage of all of these fields.
Dynamical memory: malloc() und free()
Yes, you read it correctly ! The Sagem crew has really implemented this. Great work guys ! The malloc() function is defined as void *malloc(size_t r12) and gives a pointer to the allocated memory area which is also filled with zero. An already allocated memory area starts with 0x5834 followed by (r12 - 1) / 2 + 2, a free one starts with 0x3974. If one wants to get now some free memory area it is searched from a certain basis address until the value of 0x3974 is found. If this is the case the address is marked with 0x5834.
The free() function is defined as void *free(void *r12) and r12 is an address that has been allocated via malloc() before. In the free function just this address is marked now with 0x3974.
BTW, these memory functions always test if it is an even address.
The contents of the EEPROM are mirrored in the ram. The format is the follwing:
aa aa xxxx FF 00 00 bb bb 00 cc 00
With:
The IMEI is stored in field 0 and as well encrypted in field 1000. Just a changing of field 0 to another value is therefore not possible and results in the error message 'PB IMEI'. The encryption of field 0 uses the same routine that is also called in the phone commands 0x79 and 0x5A. I wrote some C-programme in which the algorithm is shown. I tried to keep it as general as possible. The programme takes the length of the buffer to be encrypted (9 in the case of field 0) and then the buffer itself. The encrypted output has always the same size as the input buffer. If you like you can encrypt your own field 0 and look for it in the ram. It is just behind field 999. You can find the format of the fields in the ram further up. If somebody recognizes the encryption algorithm, please tell me. It would be nice to assign it.
(thx to Tomi, DH 3000)
The IMEI (phone specifically) and the IMSI (SIM specifically) are found in field 0 and 140, respectively. The first byte in these fields is some supplementary byte and gives the total length of the data and has the value 0x08 for both fields, so that the the total field length is 9 byte. In both fields the value is saved in some permutated form. In order to get the right value one has to exchange the nibbles of one byte, that is a byte 'xy' becomes to 'yx'. Since the IMEI (with CD, see below) and IMSI have a total number of 15 digits some supplementary digit is added (in order to give 8 bytes). It is 0xA for the IMEI and 0x9 for the IMSI. The reason for exactly these two values is not really clear. In newer versions of the firmware also the checksum of the IMEI (CD, see below) is saved in field 0, in older there is just the value 0 at its place. The menue IMSI in the service mode of the telephone strangely gives just the content of field 140 and not the real IMSI, so that this has probably to be considered as a bug.
Here, I give you now an example for the saved format and the real value:
IMEI: 08 3A23218002XYXYX0 ==> 08 A 332210 82 YXYXYX 0
IMSI: 08 292620XYXYXYXYXY ==> 08 9 262 02 YXYXYXYXY
I intentionally did not write all the data, since I got the values off the net and it is possible to identify people with it.
The first 3 digits of the IMSI are the "Mobile Country Code (MCC)", the next two the "Mobile Network Code (MNC)". After that there are a maximum number of 10 digist reserved for "subscriber information" which provider are free to use. Apparently in german D-nets the 6th and the 7th digit are corresponding to the "Home Location Register (HLR)" (thx to DH 3000). Some real values for MCC, MNC, HLR are best found at Henning Gajek's .
The IMEI can be split into three parts:
Simlock, checksummed fields, etc., puh, it took quite some time to understand all of that. It is true that just the simple simlock algorithm is already known to some programmes for quite some while (and has also been published here as a source for the first time), however, there were still some things unknown, e.g. where the first byte of the fields 251, 252, 253 is coming from and how actually the phone is locked.
Well, actually Sagem implemented an algorithm to encrypt things and one to decrypt it. If one wants to calculate fields 251, 252, 253 from scratch one has to crypt certain data. For field 251, there is one byte of data and 3 bytes of checksum. It looks like the data byte depends on your provider, e.g. it can be zero (for me) or 0x41 (for D2). The crypted field obtained this way is the case of the locked phone. The unlocked case just depends on the first crypted byte that is it has to be XOR XX the locked one. In most cases XX is one but in some countries (as e.g. France) it can be equal to 4 or 5. For field 252 it is a bit more tricky, since there are 11 bytes of data and 4 bytes of checksum. The first data byte is the one used for field 251. Then there are 3 bytes of code belonging to your network and it has to be in the format as it is also stored in the RAM. That is for a network code of e.g. e-plus, 26203, the 3 bytes become 0x62 0xF2 0x30 (the first and the last digits have to be turned around and in front of the middle an 'F' has to be added). If you don't have a netlock, these bytes are just zero. Then there are 7 bytes of data, that I don't understand fully yet, but they seem to be either 0x00 or 0x10. For field 253 the plain data are not clear at all for me at the moment. I believe the first byte must be 0x00 but the rest ... Anyway there are 8 byte of data and 4 of checksum. In order to get those plain data of your fields you just have to decrypt them.
In the flash there are also some fields that correspond to each other. Some fields contain plain data and some other contain the crypted ones, so for changing some fields permanently one has to change the apropriate crypted ones as well. A list of all the fields that are protected with crypted fields is found in flash field 5250 (crypted of course). It depends on firmware. Please note that in earlier versions of this page the word 'checksum' was not used correctly. It was used for crypted fields. Please note as well that first the flash fields containing plain data don't have a checksum so that their crypted partners having it are 8 bytes longer and second that AFAIK plain data of prom fields 251/252/253 are not stored in telephone.
I assembled my earlier programmes to one together that does the crypting and decrypting of the fields. You only have to enter your encrypted phoneID and the contents of field 0 at the appropriate place. At the beginning you can chose crypt or decrypt and you can tune the length of the data and the checksum. Before I give you the link I would like to give many thanx to hannes who is responsible for the important part of the encrypt algorithm. He has also included these parts into his version of his SagemDoctor programme.
OK, enough written, here is the algorithm now.
Please note that this algorithm only works for older firmware releases. In newer ones there are two principal problems. First it is AFAIK not possible to get phoneID in a simple way. Second, the hash table (mystery) in the calculation algorithm has been changed. The first problem can be solved by using some brute force method, however, in order to get the hash table some other aproaches have to be used. The most easy way is to read it out via the bootstrap mode. In very recent firmwares, however, known methods to access this mode fail until now. Sagem uses an identification of their hashtable which is output via the 0x78 phone command in newer firmware series (see above).
To be continued ... :-)
Universal code of service mode
In oderer to extend the menues in the 'hotline menue' there you can an '*' followed by the last 8 digits of your IMEI. OK, this enables some new menues but you don't get into the service mode directly, you have to change some things in ram/prom. Another possibility to get into this service mode is sending the command 0x52 via the data cable. However, I think this is all a bit too much pain in the ... . So, by looking a bit through to the disassembled OS, I found some general code which does this directly. After its input it is crypted and then the routine which is also used by 0x52 is called. The thing to be done now was to understand the crypting algorithm and to use some brute force methode in order to crack the code. By doing so I found that there are actually several codes possible. The all have the syntax '*P25728QR'. P and Q are some digits between 0 and 9 which you can choose as you like. R is lies as well between 0 and 9, however, it is fix and depends on your firmware. Fom me R=7, so I use '*22572877' for my "universal" code (with P and Q chosen in the way, that the fingers don't have to move too much :) ). You may try it out for your firmware. In the worst case, you have to enter 10 keys ;).
Unfortunately I am obliged to say it again, that in very recent firmwares even this feature doesn't work anymore :-(.
(thx to harry)
I am describing here the way to access bootstrap mode for older firmwares. For newer ones there is another way, which will be shown in the near future, however for very recent firmwares both methods fail and I don't know another solution until this day. It should also be noted that the bootstrap mode described is some emulated one and not the real one of the processor.
To enable access to the bootstrap mode the correct key has to be given via the 0x79/0x7A phone command pair. Then a value of 0x5AA5 needs to be written to ram address 0x200 and the phone has to be reset (via 0x89 command or by writing 0x11 into ram address 0x82). The bootstrap mode is correctly entered if the display light and the red LED are permanently on. The baud rate in this mode is 57600 baud. Now some boot loader has to be loaded into the phone. This is done via some special commands (0x20 0x21 0x22 0x23) starting all with 0x06 and using some special syntax. 0x20 is used to define the start address and the length of the bootloader. Usually 0x4000 is used as start address. There is a maximum length can be taken by the 0x20 command, so a longer bootloader has to be split. The loading is done via the 0x21 command which takes segments of the code to be loaded and puts it into memory. If all the segments are loaded (specified by the length in 0x20) some checksum has to be entered via the 0x22 command. After all the different parts are loaded (usage of several sequential 0x20) some additional checksum via 0x23 has to be sent. Then a final single byte of 0x06 starts the bootloader.
Changing IMEI via 0x5a phone command
Changing IMEI is certainly interesting if you travel through countries in whose some (sucking) providers use some 'whitelisting', which means the basis stations accept only 'accepted' IMEI's (DH 3000). But also if you want to repair you phone and load another eeprom dump it could be necessary to restore your original IMEI.
The IMEI can be changed via command 0x5A. It takes 9 byte of data which is the new IMEI in the format of field 0. The telephone answers this request with 128 byte data. These data have to be encrypted and to be sent back to the phone and represent the key. The 128 byte data are created with the help of the same routine as in 0x79. However the calculation of the key is a bit different since some third encryption has to be used. If the key is correct, then 0x5A gives a second answer with 0x54 which gives the new IMEI (format of field 0) as data, otherwise 9 bytes of zero. To summarize, 0x5A gives the following answers:
None at the moment :-).
There are still some things, however, I really would like to know: what is the name of the simlock algorithm, what is the sense of the first digits of 0x23 and how are the flags in field 252 coded ... well I am afraid those questions can't be answered from the code, however, if you have an answer let me know ;-).