Previously I saw someone on Bilibili flashing a portable Wi-Fi device, and it felt really strange. I clicked in and found that the thing costs less than 20 yuan, and it actually contains a Snapdragon 410 chip running Android 4.4. So I went to Coolapk and found a deal, buying two of them.

Getting root is quite troublesome. I wanted to root once, and then for the same devices bought later, I could just flash that image directly, saving time and effort. I had always wondered what the exact relationship between QCN and the brick-recovery package was. Someone online said the two have no relationship, and I believed that nonsense, casually flashing the full miko package. As a result, the baseband was lost and I couldn’t connect to the network. This shows that when using miko to save a brick-recovery package, you should also save the QCN file; copying it to another device loses the QCN… Losing the QCN means you can’t use the baseband, and you lose the IMEI. Every device’s IMEI is unique; in general, copying another device’s IMEI is not feasible. In other words, this thing was almost dead. Fortunately, I had made a full backup with miko beforehand, so no tragedy occurred. But I still wanted to know the exact relationship between QCN and the brick-recovery package. Thinking about it carefully, backing up QCN requires root, and there’s a hint that it’s saved from the NV Database, which means QCN is actually stored somewhere the system can access. So I took the full packages of two identical portable Wi-Fi devices and used a diff tool to find the differences between each file, i.e., where the QCN is stored.

Basically, all files in the brick-recovery packages cloned from the two portable Wi-Fi devices are identical, except for:

1
cache.img
2
modemst1.img
3
modemst2.img
4
persist.img
5
userdata.img

It’s quite amazing - I initially expected modem.img to differ, but it turned out to be identical. Ignore cache.img; it can be treated as the same. Analyzing persist.img, the differing file inside is [SYS]\Journal So judging by the filename, it’s probably not an important file, and persist.img can be considered identical too. So at this point, I learned that the difference between different portable Wi-Fi devices lies in modemst1.img modemst2.img. So it can be assumed that QCN is stored there.

Since these two files can’t simply be opened and inspected with 7-Zip, I don’t care exactly which file differs anymore. But since we know the QCN location, we can use Qualcomm Premium Tool to flash the specified location. This way, we can directly flash the pre-built already-rooted image on new devices, then burn the partition that saves QCN again, achieving simplified operations.

Finally, saving QCN this way by saving partitions also doesn’t require root. Compared to using Xinghai SVIP to save it, it’s more convenient and faster. After all, erasing/writing partitions is much faster than writing QCN with software. (Whether it’s Xinghai SVIP or miko, reading and writing QCN is painfully slow…)

In the final test, I wrote the rooted image, and opening the device directly showed no IMEI. After re-burning those two partitions, the IMEI appeared when opening it again.

There’s a very strange question: all the tutorials online use Miko to save a brick-recovery package, then use Qualcomm Premium Tool to save all files. Doesn’t anyone know that the brick-recovery package generated by miko can be opened as a compressed archive, and the files inside are exactly the same as those saved by Qualcomm Premium Tool? It’s definitely redundant work. Or are all the tutorials online just copy-paste?.. Qualcomm Premium Tool’s role is irreplaceable, because it can erase/write a single partition individually. But I disagree with the cookie-cutter tutorials online that say to save with miko once, then save again with Qualcomm Premium Tool - that redundant operation…