This story began with the fact that as a result of unsuccessful experiments with the Samsung Galaxy Ace 2 smartphone core (aka GT-I8160, aka codina), leading to the device reboots, it turned out that the EFS section was no longer readable. Actually, the experiments themselves have nothing to do with this issue - perhaps, somehow, I will come to them, but this is beyond the scope of this article. Although the EFS section is one of the most important on this smartphone, killing this section does not in itself lead to catastrophic consequences, since it can still be restored, for example, from another phone, after which, if desired, change the WIFI MAC and BT MAC. On this device, IMEI is not stored on the EFS partition, but CSPSA (Crash Safe Parameter Storage Area, literally translated as “Crash Resistant Parameter Storage Area”). Now, if something goes wrong with this section, it will not be so fun anymore, this will be discussed further. Who are interested, please under the cat.

After the failure of the EFS partition, I, first of all, took its dump and tried to raise it with the help of e2fsck. Failure - the EXT4 superblock is damaged, and indeed everything looked as if the contents of the section had turned into stuffing. It was time to look for a backup, but, what a carelessness (!), At the most inopportune moment it was not found either on the computer or on the flash drive. All further sufferings could have been avoided only if I had timely backups. It was late in the evening, having begun to look for dumps of this section on the Internet and having found one on a foreign resource, I immediately began to flash it. Probably one of the worst things that can happen when using the dd utility is a typo or an error when typing the path to the partition. Now I can only wonder at my own carelessness (or curvature, call it what you want), but this is exactly what happened ... The EFS partition on this device is / dev / block / mmcblk0p7, but for some reason I didn’t have any doubt at that moment that it supposedly should be / dev / block / mmcblk0p6. Actually, the further does not require special explanations, I already understood about the catastrophicity of what happened only when dd brought out a message stating that the end of the section had been reached during the recording. It seems that not the first year I have been using the device and am one of the few remaining developers for this god-forgotten device. How could I find myself in such a way I didn’t look at the stupid situation? Do not ask me, I would like to know myself ... So the phone with a light hand became, if not a “brick”, then an “invalid” for sure.

CSPSA Section Study

So, the EFS partition was killed by the crash during the active recording on the disk, while the CSPSA partition, which is resistant to crashes, did not stand up to my rashness. If I went to the SC, even there they probably would have shrugged. CSPSA firmware from another device will also not fix the case, because IMEI, obviously, is stored somewhere besides this section and is compared with what is in CSPSA. Yes, and the article is not about changing IMEI, but about its restoration.
')
The situation is hopeless, no matter how you look, I thought. I found myself embroiled in something I clearly did not plan to do, pick up the insides of the CSPSA section. It turned out that among the sources for the ST-Ericsson Novathor U8500 chipset in 2014 there are source codes for utilities that allow working with this section:

 root@:/ # cd ramdisk root@:/ramdisk # ./cspsa-cmd [CSPSA]: open CSPSA0 [CSPSA]: <CSPSA_Open('CSPSA0').> [CSPSA]: <Result 'T_CSPSA_RESULT_OK'> [CSPSA]: ls Key Size 0 4 1 96 2 96 3 96 1000 38 66048 497 -8192 41 -4 4 -3 4 -2 4 -1 4 Number of keys in CSPSA : 11 Total size of all values: 884 [CSPSA]: read_to_file 3e8 /sdcard/1000.bin [CSPSA]: <Read (000003e8) to file '/sdcard/1000.bin'> [CSPSA]: CSPSA_GetSizeOfValue(000003e8): T_CSPSA_RESULT_OK [CSPSA]: <CSPSA_Read(000003e8).> [CSPSA]: <CSPSA_ReadValue(000003e8, 38): T_CSPSA_RESULT_OK> [CSPSA]: <38 bytes written to file '/sdcard/1000.bin'.> [CSPSA]: write_from_file 3e8 /sdcard/1000.bin [CSPSA]: <Write (000003e8) from file '/sdcard/1000.bin'> [CSPSA]: <38 bytes read from file '/sdcard/1000.bin'.> [CSPSA]: <CSPSA_WriteValue(000003e8, 38).> [CSPSA]: <CSPSA_WriteValue(000003e8, 38): T_CSPSA_RESULT_OK> 

The “open CSPSA0” command opens the CSPSA0 socket, thus connecting to the cspsa-server process. As you can see, the ls command displays the parameters stored in CSPSA and their size.

Further, using the read_to_file command, you can write a parameter (here it is 1000, specified in HEX, - 3e8) to a file, and also write a parameter from a file to a section with the command write_from_file.

It is of course great that I managed to find such a utility, but did not give me any clues as to what was supposed to be in these parameters in order for IMEI to read normally again. In fact, the utility could "hide" part of the truth, giving out not all the parameters, and hiding the one in which the IMEI is stored. In order to understand what could be in these parameters, it was necessary to have several such different sections of the CSPSA, but in fact, I can’t ask someone to merge the section with such private information. On the Internet, there were two different sections of CSPSA, but a comparison of parameters read through cspsa-cmd produced too much difference, about 512-768 bytes in total when comparing them with each other. Even with all the sources, it could have been a while before I figured it out (if I figured it out at all). The idea of ​​rebuilding CSPSA "in the forehead" had to be abandoned, looking at other parts of the merged source that could help restore the phone.

I stumbled upon another utility that looked promising.

The link is a list of commands supported by this utility.

 (...) static const struct { const char *str; cops_return_code_t (*func)(cops_context_id_t *ctx, int *argc, char **argv[]); } api_funcs[] = { {"read_imei", cmd_read_imei}, {"bind_properties", cmd_bind_properties}, {"read_data", cmd_read_data}, {"get_nbr_of_otp_rows", cmd_get_nbr_of_otp_rows}, {"read_otp", cmd_read_otp}, {"write_otp", cmd_write_otp}, {"authenticate", cmd_authenticate}, {"deauthenticate", cmd_deauthenticate}, {"get_challenge", cmd_get_challenge}, {"modem_sipc_mx", cmd_modem_sipc_mx}, {"unlock", cmd_simlock_unlock}, {"lock", cmd_simlock_lock}, {"ota_ul", cmd_ota_simlock_unlock}, {"get_status", cmd_simlock_get_status}, {"key_ver", cmd_verify_simlock_control_keys}, {"get_device_state", cmd_get_device_state}, {"verify_imsi", cmd_verify_imsi}, {"bind_data", cmd_bind_data}, {"verify_data_binding", cmd_verify_data_binding}, {"verify_signed_header", cmd_verify_signed_header}, {"calcdigest", cmd_calcdigest}, {"lock_bootpartition", cmd_lock_bootpartition}, {"init_arb_table", cmd_init_arb_table}, {"write_secprofile", cmd_write_secprofile}, {"change_simkey", cmd_change_simkey}, {"write_rpmb_key", cmd_write_rpmb_key}, {"get_product_debug_settings", cmd_get_product_debug_settings} }; (...) 

As in the previous case, with cspsa-cmd, cops_cmd is connected to the server process, copsdaemon (COPS stands for COre Platform Security).

This very copsdaemon binary on the device turned out to be different from the fact that in the source code (or I didn’t manage to configure Android.mk correctly), anyway, collected from the source code refused to work. However, it seems that the cops_cmd utility was compatible with the rest of the proprietary software and ran normally.

The first thing I tried to do was to run the cops_cmd read_imei — I don’t remember exactly now, it cops_cmd read_imei something like “error 13, device is tampered”. Yeah, of course, what else could you expect, with a bogus section of the CSPSA. A short reading of the source led to the “bind_properties” command:

 static cops_return_code_t cmd_bind_properties(cops_context_id_t *ctx, int *argc, char **argv[]) { cops_return_code_t ret_code; cops_imei_t imei; (...) usage: (...) fprintf(stderr, "Usage: bind_properties imei <imei> (15 digits)\n" "Usage: bind_properties keys <k1 k2 k3 k4 k5> (keys are space delimited)\n" "Usage: bind_properties auth_data <auth_number> <auth data file name>\n" "Usage: bind_properties data <data file name> <optional don't merge flag 0, otherwise merge will occur>\n"); return COPS_RC_ARGUMENT_ERROR; } 

As you can see from the sources, the function is intended to write IMEI to the device. But here's the ill luck, just before the recording, it is necessary to perform authentication using the private key, which I obviously do not have. It remained only to continue to pick copsdaemon, in order to try to avoid the need for authentication, fortunately, everything went without it.

Looking for ideas

It took several days in search and reflection. After talking with one of my acquaintances with xda-developers, I learned that for the GT-I8160 variant with the NFC chip, the GT-I8160P, there is a firmware with some default, “semi-empty” section of the CSPSA, and that firmware of this ROM on this device the fact that IMEI is “reset”, that is, all 15 digits of IMEI become zeros (I don’t remember exactly if this happens in the case of a CSPSA partition or whether or not it is). First of all I downloaded this firmware and flashed the CSPSA section - to no avail. A colleague offered partial firmware (i.e., firmware of separate partitions, not including such “dangerous” ones as bootloader and others) of this ROM. A rather unpromising activity, it could finally “wry” the device. Finally, after a couple more days, while I was busy with the source code above, a colleague with the XDA made a truly incredible and priceless find:

 #TA Loader to write default IMEI service ta_load /system/bin/ta_loader recovery user root group radio oneshot 

This is a clipping of the contents of the ramdisk init.samsungcodina.rc file from the stock firmware Android 4.1.2, where it is directly stated in the comments that this is a service for restoring IMEI to default.
Without thinking, I launched from the terminal:

 /system/bin/ta_loader recovery 

The device rebooted into recovery mode, then another manual reboot into the system, and voila! IMEI is not already displayed as “null”, but set to zero, online registration is available, progress, however. The mystery of the "zeroed" IMEI has been revealed.

But, of course, it’s not at all cool to walk here with such a default IMEI. It was enough just a short search to look at the ta_loader binary in the HEX editor (there were no more sources for this tool) and replace the zero IMEI with your command of the type:

 sed -i "s,<15_zeroes>,<IMEI>," /ramdisk/ta_loader sed -i "s,<IMEI>0,<16_zeroes>," /ramdisk/ta_loader 

Why is the sed command called twice? In the binary there is a sequence of more than 15 zeros, not related to IMEI, therefore, to return an undesired change, you must call the command a second time. I hasten to assure you, trying to write down the “left” IMEI in this way is useless, the utility works in such a way that you can only write IMEI from the box (or default). Another reboot in the recovery, then to the system, and, lo and behold - IMEI is in place! I described the recovery process in more detail on the XDA Developers forum . Such are the cases, lucky that the manufacturer left a loophole to restore the original IMEI. If there were no misadventures above, it would probably have occurred to me not to poke around in all this, but on the other hand, there would not be the whole story.