Brief Discussion on Flashing Portable Wi-Fi Devices with Snapdragon 410 Chip
之前在b站看到有人弄随身wifi刷机，感觉好奇怪。点进去一看发现这东西才不到20块钱，而且里面居然是晓龙410的芯片，跑着安卓4.4，然后去酷安找了个车买了俩。
刷root挺麻烦，我想只做一次root，然后之后买的同样的机器都可以直接刷进去就可以了，省时省力。
之前一直好奇QCN和救砖包到底是什么样的关系，网上有人说两者没有关系，然后我就信了那个鬼话，随便刷了miko全量包，结果基带丢了，联不了联网。。
这就说明，再使用miko保存救砖包的时候，把QCN文件也一起保存下来，所以在复制到其他机器会丢失QCN。。。
丢失QCN会导致无法使用基带，丢失IMEI。每个设备IMEI是独特的，一般来讲复制其他设备IMEI不可行。也就是说这玩意差点废了。
好在我事先用miko全量备份了，没酿成惨案。。
但是我一直想知道QCN和救砖包到底是什么样的关系。仔细想了想，备份QCN需要root，而且有提示是从NV Database里保存的，这说明QCN其实保存在系统可以访问的地方。。
所以我把两个型号一样的随身wifi全量包的每个文件，去用差异计算，寻找不同的地方，也就是保存QCN的位置。
两个随身wificlone下来的救砖包里基本所有文件都是一样的，有差异的是
1 | |
很神奇，一开始我预想的是modem.img会有差异，结果居然是一样的。
cache.img不管他，可以当成一样的。
对persist.img分析，里面差异文件是[SYS]\Journal
所以根据文件名推测，里面应该不是重要文件，可以认为persist.img也是一致的。
所以到这里，知道了随身wifi不同设备不同的地方在于modemst1.img modemst2.img不同。所以可以认为QCN保存在这里。
由于这两个文件无法继续使用7zip简单的打开进行查看，所以不管他到底是哪个文件不同了。
不过我们知道QCN位置，所以可以通过Qualcomm Premium Tool刷写指定位置，这样就通过达到在新机器上直接flash预先做好的已经root的镜像，然后再烧一遍保存QCN的分区来达到简化操作的目的。
最后，通过这样保存分区来保存QCN，也不需要root，相较使用星海SVIP保存更加方便，速度也更加快。毕竟擦写分区可比用软件写QCN快多了。（不管是星海SVIP还是miko，读写QCN都好慢…）
最后测试一下，写了root的镜像，然后直接打开没有IMEI。重新烧录那两个分区，再打开就出现IMEI了。
有个很奇怪的问题，网上的教程都是使用Miko保存救砖包，然后再用Qualcomm Premium Tool保存全部文件。难道没有人知道miko生成的救砖包可以打开为压缩包，里面文件和用Qualcomm Premium Tool保存的一模一样吗，绝对是重复操作。或者说网上都是复制粘贴的吗。。
Qualcomm Premium Tool的作用无法替代，因为它可以单独擦写某个分区，但是我不认同网上千篇一律教程所说的miko保存一遍，Qualcomm Premium Tool再保存一遍的重复操作…
I previously saw people flashing portable Wi-Fi devices on Bilibili and felt quite curious. After clicking in, I found that this thing costs less than 20 yuan, and it actually has a Snapdragon 410 chip inside, running Android 4.4. Then I went to Coolapk and joined a group buy, purchasing two of them.
Gaining root access is quite troublesome. I wanted to only root it once, so that any identical machines I buy later can be flashed directly with the rooted image, saving both time and effort.
I had always been curious about the exact relationship between QCN files and brick recovery packages. Some people online said there was no relationship, and I actually believed that nonsense. I casually flashed the miko full firmware package, and as a result, the baseband was lost, making it unable to connect to the network…
This shows that when using miko to save a brick recovery package, the QCN file is also saved within it. Therefore, copying it to another device will cause the QCN to be lost…
Losing the QCN will result in the baseband being unusable and the IMEI being lost. Each device’s IMEI is unique, and generally, copying another device’s IMEI is not feasible. In other words, this device was almost rendered useless.
Fortunately, I had backed up a full image with miko beforehand, so no disaster occurred…
However, I always wanted to know the exact relationship between QCN files and brick recovery packages. After thinking carefully, backing up QCN requires root, and there’s a prompt saying it’s saved from the NV Database. This indicates that QCN is actually stored in a place accessible by the system…
So, I used difference calculation on every file from the full firmware packages of two identical portable Wi-Fi models to find the differences, i.e., the location where the QCN is stored.
The brick recovery packages cloned from the two portable Wi-Fi devices were basically identical in all files. The ones with differences were:
cache.img
modemst1.img
modemst2.img
persist.img
userdata.img
Interestingly, I initially expected modem.img to have differences, but it turned out to be the same.
Ignore cache.img; it can be considered the same.
Analyzing persist.img, the differing file inside was [SYS]\Journal.
Based on the filename, it probably doesn’t contain important files, so persist.img can be considered consistent as well.
So, at this point, I realized that the differences between different portable Wi-Fi devices lie in modemst1.img and modemst2.img. Therefore, it can be assumed that QCN is saved here.
Since these two files cannot be simply opened with 7zip for further inspection, it’s left aside which specific file contains the differences.
However, now that we know the QCN location, we can use the Qualcomm Premium Tool to flash specifically to these positions. This achieves the goal of simplifying operations by first flashing a pre-made rooted image onto a new device, and then burning the partitions containing the saved QCN.
Finally, by saving partitions to preserve QCN, root access is not required. This method is more convenient and faster compared to using Xinghai SVIP. After all, erasing and writing partitions is much quicker than using software to write QCN (whether it’s Xinghai SVIP or miko, reading/writing QCN is really slow…).
As a final test, after flashing the rooted image, opening the device showed no IMEI. After re-flashing those two partitions, the IMEI appeared upon opening again.
One weird thing: online tutorials all use Miko to save brick recovery packages, then use Qualcomm Premium Tool to save all files again. Doesn’t anyone know that the brick recovery package generated by miko can be opened as a compressed file, and the files inside are exactly the same as those saved with Qualcomm Premium Tool? It’s definitely a redundant operation. Or are all these tutorials just copy-pastes online?..
The role of Qualcomm Premium Tool is irreplaceable because it can erase/write individual partitions separately, but I don’t agree with the repetitive operation described in all those uniform online tutorials—saving once with miko and then again with Qualcomm Premium Tool…