[Sony Cross-Device General] TheDrive:
Thank you for your addition. I didn't known about these possible issues which could occure in any various aspects while working with Qualcomm EFS/NVRAM data (e.g. fixation/recovery of the dead phones). However if one have any suspections and to be on the safe side we could backup NVRAM contents to the xQCN format. xQCN seems to be the same storage as QCN with the difference it stores QCN's binary data as a text 'codes' between the xml tags, while QCN simply stores the binary data as binary data with some proprietary Qualcomm and M$-document headers.

It is simplier to patch binary data directly neither convert text to the binary data, patch it, then revert back to the 'text codes' and write into the xml.

There is no technical problem to store NVRAM in the text file with the binary tree. You can use provided (w/QPST) QCNView utility to load QCN/xQCN and view all the contents as a binary tree of the named hives and fields and even export this text tree to the text file to process with any tools you want. In this text you will see named ITEMs and EFS files with a quoted text of binary values that is relatively much easier to understand and patch. The problem is QCNView can NOT load/import [patched/any] text files and export them to the QCN/xQCN. It can only load/import QCN/xQCN and export it to the text. It's the one direction road. Qualcomm intentionally prevents us from easy patching of the modem data.

Unlike the described text file xQCN, which in fact is also the text file, quotes the binary structures of the proprietary format QCN data but not the readable ITEMs and EFS files structure. You'll not see plain text ITEM with numbers and EFS files with name definitions there. Just an 3-times size excessive way to store binary file as xml-text.

So I just can advise you to save NVRAM backups as QCN and xQCN one by one, then export both files to the text (by QCNView) and compare to be sure all the required NVRAM/EFS data was backed up. You should then explore text and find the ITEMs you need to patch. If QCN and xQCN backups seems to be equivalent in the containing data you can patch QCN and Restore it to the device to check/use your patch targets. If xQCN seems to store more data, then QCN, you will be forced to patch xQCN. To do so you may need convert binary data twice, once from text to the unique binary sequence (you have found in the plain text backup), then revert it to the text sequence encoding the QCN binary data to the xml xQCN. The search these data in xQCN and patch as you need.

It would be nice if someone will write an app to convert data between plain text NVRAM backup and QCN/xQCN format. To be more correct we just miss the one direction converter from text to QCN (while we can export text from QCN/xQCN in the QCNView). Form some stupid reason no one have written app to deal with QCN/xQCN backups. The authors of the commercial 'box' apps prefer to read/write NVRAM/EFS directly mostly using QMI protocol ('Diag port'). Qualcomm noted a long ago that preferred way to deal with NVRAM from outside the device, is to backup/restore the whole contents neither edit particular ITEMs directly (e.g. by older RF_NV_Manager like apps). Qualcomm have added some protective techs to the NVRAM/EFS procedures (e.g. IMEI OTP feature). OEM's add their own stupid custom protections, especially related to their unlawful SIM locking techs (locking directly violates consumer right and antimonopoly laws in many countries but big-money overall any laws).

At the same moment NVRAM backup/restore protocol/procedure uses some Qualcomm-common-reference-design backup privilege rights inside of the modem FW (any QMI dealing SW, including 'miracle boxed', fully depends on the modem FW and doesn't edit any data directly, I never heard the one have decrypted EFS storage, i.e. ModemST* partitions, independently of the modem FW). This make service SW dev dependable on the modem FW, which could be easily customized in any new version to prevent 'boxes' to make a things OEM doesn't want they do. On other hand service SW dev isn't fully aware of all the internals of the modem FW. It tries to support more and more models selling more and more 'box' copies and he has no enough time to fully reverse every model and every FW version. And as a final point, many boxed SW's do NOT backup NVRAM data before they try to edit it, or DO backup, but in the proprietary encrypted format (trying to 'protect' their 'TOP Secret' techs) which is not easy or impossible to restore by the SW itself and/or common SW like QPST and partition restore using ADB. This situation leads to the multiple failures when users and/or service engineers stuck with a NVRAM-broken devices with no backups and no recovery technique and forced to participate in a long term product support dialogs (which, BTW, doesn't warrant the successfull solution)..

There are the tools in the QDART package available to make such or simular actions with NVRAM (to provide devs with ability to initially make and tune custom NVRAM image). But QDART is a monster app of 400-700MB in size. It is designed to create full cycle test environment for devs, while we need just a 10-1000KB app :) to make our narrow job most comfortable way. I will not setup QDART even too I have a few modern versions. It's too excessive. I have extracted some console QCN/xQCN related utils from the QDART package (forgot the names) and got half a way to use it but failed to finish due to the time lack. One can explore and find/make the fully working solution for the problem.

But I prefer one(s) will reverse not-so-complicated QCN/xQCN format and write an independent app (most preferred open sourced at least since the EOD) to provde the community with open technology independent of the any proprietary SW. It's a long term project of honor. Other goal is to find a common way to decrypt/encrypt-back EFS partitions (ModemST*) using/not-using internal modem FW procedures, but it seems to be much more harder tech to develop. One who will make it will be the Earth scale Hero. :) Old good RevSkills/QMAT can import (it seems to be no export there) unencrypted EFS image but just from very old devices (up to the beginning of the 201x) and someone seems to have forced the author to stop development in the 2012. You shouldn't be here, Neo!