Motorola GSM Transfer /

Motorola GSM Transfer / Clone Card

The Clone Card (also reffered to as transfer card) is used by motorola to transfer user (personality) information (phonebook, options etc.) from one phone to another. The transfer card is not a plain SIM, because the ISO CLASS is not $A0 as in a standard GSM SIM, but some sort of SAM (Security Access Module). The card is a password protected 24 kbit serial memory (EEPROM). This means that a password has to be sent to the card before the memory can be accesed. The transfer card password is " TESTCODE" (This is sent in plaintext from the MS to the SIM after the MS detects that a transfer card is inserted. The transfer card is identified by the phone from its ATR which is "3F 6C 00 00 25 A0 31 00 FF 00 00 01 80 04 90 00"

There seem to be a new situation on the new motorola phones that don't use the MC683xx platform. The M3188 and M3688 has given the most problems, and some facts have been observed: Early M3188's will not enter either test or clone mode with ASIM. Later models will enter test mode, but not clone mode. That leaves 3 options: 1) Clone mode has not been implemented in the firmware, 2) Synchronous communication which ASIM can't cope with is being used or 3) A new transfer card exists that uses another design or ATR. 3k of memory is very little by todays standards, so facts are that the "good old" transfer card is a dinosaur. However the newer m3688 will gladly enter clone mode, so that makes the last two of the above speculations invalid !

UPDATE: This procedure might be able to help get the V series (and M ?) into clone mode.

Apparently it seems necessary to power on the unit with an external power supply. Here is the procedure (thanks to Michele): 1) Insert the running emulator (the battery is not inserted); 2) Power on the unit with the external power supply (the battery is still out); 3) There should appear something like "Insert the battery" or the like; 4) NOW you can insert the battery that will set the unit into clone mode.

There are two primary uses of the transfer card:

1) Transfer of personality. If your phone fails ("Phone Fail See Supplier") and is to be exchanged, then there is a possibility to have the user data transferred from the defective phone to another one (This does require that the phone actually can be powered up). This will make the exchange phone appear like the old one, with the same menu setup, phonebook and settings. This is acomplished by transferring the areas of the EEPROM that contain the user data. The user data is far more than the 3 kb that will fit on the card and therefore the 8k phone EEPROM is divided into "transfer frames". Only one transfer frame will fit on the transfer card at a time. A transfer of the frames 1, 2 and 3 will do a total personality transfer.

2) Initialization of the EEPROM. If the phones EEPROM data become corrupted, then the configuration checksum can fail and generate a "Phone Failed See Supplier" the will result in the phone not booting up. With the transfer card *some* of the corrupted data can be replaced and the configuration block checksum can be recalculated. A transfer of frame 4 (the "Master Frame") will in many cases cure a phone that fails with a self diagnostics code "07" (interrogate with 7100# in test mode).

Mark Hawkins has this quick and dirty way of dealing with checksum failures (INFO 00 07):"There is another way to fix the 'Phone failure' problem. Get the clone card, with 'Clone' on the display type: 024# (this dumps master card info to the card) then type: 03# (this dumps it back to the phone) You must switch off the phone, remove the card & remove the battery ** VERY IMPORTANT ** Switch the phone back on & try it with a live card This works on about 90% of the phones that I have done..."This copies the corrupt EEPROM data back onto the phone, but recalculates the configuration block checksum - this should not be the method of choice if you have a backup phone to copy from.

Data CAN go bad on the transfer card. The phone will detect the error and go "Bad Data On Card" when trying to transfer the frame to the phone. It is not an actual checksum that makes the phone capable of spotting bad data. The first and last thing that is written to the clone card, is at address $40 - This address contains a register that flags the status of the frame and the frame number. The phone will initiate the transfer to the card by writing "bad data" and when everything has been transferred, it will write "good data". This way, a transfer that was stopped prematurely can be rejected. EEPROM read/write operations that go wrong (if not soldered correctly or bad) can be detected and the phone will prompt "EEPROM Rd Fail" or "EEPROM Wr Fail" .

List of Clone Card (51-04025D03) Commands: Frame (02N#) contents, description and size

02N#Read data frame N (0...5) into clone card03#Write transfer card dataframe into phone06#Locks the data on a transfer card07#Unlocks the data on a transfer card Frame 1:Phone setup (greeting,keypad,features,settings,counter) - 2880 bytesFrame2:Phonebook entries 1-75 - 3008 bytesFrame3:Phonebook entries 76-100, timers,rates & user features - 1728 bytesFrame4:Master SIM data (OEM settings,wakeup text,keypad,features) - 1248 bytesFrame5:Last 10 calls (among other things) - 896 bytes (not supported by all phones) Contents of the different transfer frames and lengths were determined on a 7500

There are some differences between phone types. The StarTAC (and Slimlite) frame 3 also contains life time meter, last 10 calls & keypress-beep setting

If you take a closer look to the frames you will notice that they have a distinct structure. Doing a little experimentation will reveal that they are composed of a header followed by numerous entries with the same basic format. The header is shown below:$0000 0000 00000000 0000 00000000 0000 0000................ $00100000 0000 00000000 0000 00000000 0000 ................ $00200000 0000 00000000 0000 00000000 0000 ................ $00300000 0000 00000000 0000 00000000 0000 ................ $00400100 0100 00000000 0000 00000000 0000 ................ $00500000 0000 00000000 0000 00000000 0000 ................
The first 64 bytes are unused. They are never read or written. This space can be used for making notes about the frame. Eg. "Backup 8700 with Eng Field Opt". At $40 you can find the frame number: Conventional frames are numbered 01 - 05. The frame number is the very last thing that is written to the card if a dump is made to the card from the phone. This enables the phone to check if the transfer was complete. Incomplete transfers will have frame number "00" and trigger a "Bad Data On Card" if attempted uploaded to the phone. At $41 is the read-only flag: 01 means locked and 00 unlocked.0000-003F Unused 0040-0040 Frame number 0041-0041 Read only flag 0042-0042 ? Doesn't seem to matter, normally 01 0043-0060 Unused This was the simple header. From $0060 and on is the data. The data field contain data as well as addressing information arranged in packets eg. header1&data1, header2&data2, etc. etc. The packets can be rearranged and the frame will still function in the correct way. However data packets are associated with certain frames and they (mostly) cannot be moved without restrictions from frame to frame. The packets are of varying length but all have the same 3 byte header stating length and target address of the packet:LLApAsD1D2D3D4D5D6D7D8The length can be from $01 to $FF bytes. The address consists of a Primary(Ap) and a Secondary(As) address field. For example the (internal)phonebook generally has address field $4B, but every single phonebook entry has it's own subfield. The address for phonebook entry #01 is 4801, #02 is 4802 etc. etc. The phonebook entry is $24 bytes long ($14 for the text and $10 for the number itself), making the complete header:244B01for phonebook entry #01. Every entry in the EEPROM or SIM memory has it's own field number. This means that the things you are manipulating here are "cooked" and not "Raw" EEPROM addresses that are written to. Generally, if the field does not have multiple sub-entries, the secondary address is always 01. The lock and security codes are single entry fields, and things like phonebook, last 10 calls, PLMN list etc. are multiple secondary entries to the same primary entry (field). The packets of header and data repeat themselves over and over again and the phone will keep processing them, until it reaches a header that is "00" bytes to address "0000". There is no dedicated "Stop". This is why your frames should be patched with "00" instead of "FF" that would give a failed transfer, repeating itself until the end of your frame buffer is reached.

Let's try to decode the first part of a frame 1: 00000060C80A 0100 00000000 0000 00000000 0000 ................ 000000700000 0000 00000000 0000 00000000 0000 ................ 000000800000 0000 00000000 0000 00000000 0000 ................ 000000900000 0000 00000000 0000 00000000 0000 ................ 000000A00000 0000 00000000 0000 00000000 0000 ................ 000000B00000 0000 00000000 0000 00000000 0000 ................ 000000C00000 0000 00000000 0100 00010200 42FF ..............B. 000000D0FF01 0203 04050607 0809 0A00F0FF FF1F ................ 000000E060F6 CEF6 FFFFFF7F 0000 00F1FFDF F6FF `............... 000000F0FFFF FFFF FFFFFFF7 FFFF 7F000000 0000 ................ 000001000000 0000 00010100 06FF 00000003 FF06 ................ 00000110FF00 0002 03000000 0133 33330003 0101 .........333.... 0000012000F0 FFFF 00000000 0101 007A0E01 6401 ...........z..d. 000001300000 9000 00000E0E 0E0E 0E0E0E0E 0E0E ................ 000001400E0E 0E0E 0E0E0E0E 0E0E 0E0E0E0E 0E0E ................ 000001500E0E 0E0E 0E0E0E0E 0E0E 0E0E0E0E 070B ................ 000001602418 0106 0032EA0E 0308 130F1702 050A $....2.......... 000001700EE0 3304 09257DFE FFFF 7FFFFFFF FFFF ..3..%}......... 00000180F6FF F139 00050000 00FF 7F000000 0000 ...9............ 000001900000 0000 00000000 0000 00000000 0000 ................ 000001A00000 0000 00000000 8110 01423720 2053 ...........B7 S 000001B05547 3130 30394245 2020 20452F49 3130 UG1009BE E/I10 000001C03630 2020 20202020 4443 535F464C 4152 60 DCS_FLAR 000001D0455F 3157 20202020 2020 20202020 3131 E_1W 11 000001E03131 2030 30303936 3036 32353131 3032 11 0009606251102 000001F02020 2020 20202020 2020 20202020 2020 000002002020 2020 20202020 2020 20202020 2020 000002102020 2020 20202020 2020 20202020 2020 000002202020 2020 20202031 3442 42008110 02FF 14BB..... 00000230FFFF FFFF FFFFFFFF FFFF FFFFFFFF FFFF ................ 00000240FFFF FFFF FFFFFFFF FFFF FFFFFFFF FFFF ................ 00000250FFFF FFFF FFFFFFFF FFFF FFFFFFFF FFFF ................This frame will start by writing $C8 (length 200 bytes) bytes to field $0A, subfield $01, so by skipping the header and counting 200 bytes forward, we find the next header: 7A0E01 (122 bytes to field 0E, subfield 01) and the next 811001 (129 bytes to field 10, subfield 01), the next 811002 (129 bytes to field 10, subfield 2) and this goes on and on until the termination sequence is encountered (a triplet of 00).

So now we need to map all these fields and subfields to their respective functions, so we truly can start to compose frames from scratch instead of modifying existing ones as we can do with medit and meditx. This will be much better than transferring frames between different phone models. Whereas the field you are interested in might be portable between the units (for example the wakeup graphic") other fields in the frame might not be (for example the menu definition).

Before we can have total freedom to compose custom frames, there is just one restriction: There is *not* freedom to put just any field into any frame. Frame 1 expects to have only a certain list of packets in it and the same with the other frames. Moving packets between frames will reveal that if a packet is not supposed to be in a certain frame, it simple will not be processed and the EEPROM is not patched. So no matter if you knew the address and length og for example the IMEI, Factory test flag or SPlock flag, the phone would not accept the packet and just ignore it.

However, if the frame number was changed to something that did not have a list of "acceptable fields" the phone would process the packlets and patch the EEPROM. Forexample the frame $FF will allow any field to be updated. This seems like a bug in the software. The field system is also used with the EMMIbox. The EMMI interface is supposed to be able to update these fields (the ones that do not appear in any transfer card frames), but the clone card interface couldn't possibly have been meant to do this. The most interesting thing, is that in October '98, every Mot phone would have this "feature" - From the ancient International 1000 to the latest StarTAC 130. So it seems like Motorola did not know about this bug until the fall of '98. Then they suddently released new software version for the cd920/cd930 (A0.04.29) and the cd520 (and probably others to come) that fixes this.

To illustrate the usefullness og this "feature", try to consider adding "Instant test mode" to your phone. If you wanted to edit the factory test flag in the EEPROM, you could manually edit the "03" at $003B in the EEPROM and clone your way out of the configuration checksum mismatch. All this involving opening the phone, desoldering the EEPROM, programming it and putting the unit back together. Alternatively, you could address the field via. the clone card. The length of the factory test flag(s) is 2 bytes, the Primary address is $0D, so making a customized frame with the frame number $FF and a single packet 02 0D 01 13 33 will do the job. The Flag is patched in seconds and you haven't opened the phone. Since this frame does not contain anything else that is phone specific, you can use it on every single unit without any danger of killing the phone, just because you used a 8700 frame on a 8400 and forgot about the display settings that also happen to be in frame 1 (Ooooops!). But it's even better yet ! : Even if you with the manual EEPROM-desoldering-programming approach could edit the SP field at $03AB (Off the top of my head), you would not be able to make it work since it is protected by the CRC style checksum. The real beauty is that the phone does not only update the configuration block checksum at 0000:0001, but also the complicated one at $03b0:$03b1 (again, off the top of my head). On newer phones with the DS2401, EEPROM cloning is suddently possible again (but why would you when you can just update the SP flag directly) - when recalculating the checksum for the SP or IMEI, the DS2401 serial number is read and used to calculate the checksum. This again shows that so much of the functionality (field to EEPROM address translation & checksums)actually is located in the phone itself - not in the EMMIbox.

Here are a few more examples:

Change of operator name- There are 3 subfields that define 3 additions to the operator list kept in the firmware. These contain MCC, MNC and two names (0A = word wrap) - one for passive mode and one for keylocked mode. Edit it to reflect your needs.
Addwind Uses the above frame to add the Italian operator WIND to the phone so it will not just display I-88 (Thanks Michele).
Permanent testmode- This sets the factory test bit, adding permanent testmode and keypad codes (on a few sw revisions)
Disable SP lock flag- This disables the provider lock that makes the phone ask for the special code unless the IMSI of the SIM is from a certain network operator. Will only work on phones with firmware before September '98