[dev][info] imei 0

Search This thread

rachitrawat

Inactive Recognized Developer
Jul 12, 2012
1,000
3,439
IMEI 0 after flashing stock firmware is due to modem not being able to recreate EFS (modemst1-2) since persist is compromised. Motorola has removed dedicated dhob & hob partitions (which used to store IMEI info in earlier moto g's) and moved them to persist. Pure persist backup is therefore NECESSARY before flashing anything. See here for persist backup instructions.

Note: persist is unique to device. Flashing someone else's persist will NOT restore your IMEI. Instead, it'll PERMANENTLY wipe dhob bin holding your IMEI.

Edit: Confirmed. Persist is unique to device. I restored my pure persist backup and got IMEI & VOLTE.
Please go through the entire thread carefully.

Edit: Problem is caused by incorrect user id for rfs. Can be fixed if you have your own persist. See here

hey,
As you all know, fastbooting stock 7.0 over custom 8.1 corrupts our QCN. However, if you first restore a twrp 7.0 system.img and boot.img, the problem doesn't occur.
Numerous guides exist on XDA but they are very bad hacky workarounds with no explanation given.
I'm making a non-hacky fix for imei0/volte/other baseband problems since it is unlikely that upcoming official 8.1 will fix the issue. Moto service center also doesn't know how to fix this.
To achieve this, I need some files from people with stock 7.0 (preferably indian variant) who satisfy the following criteria:
1. never flashed custom 8.1
or
2. successfully reverted to 7.0 from 8.1 without flashing any hacks from xda (i.e, restored twrp system/boot backup instead of fastbooting whole fw)
If everything goes through, I'll release a detailed guide for this.
I urge the volunteers to PM me asap. Note that root/unlock is not necessary for this.
 
Last edited:

rachitrawat

Inactive Recognized Developer
Jul 12, 2012
1,000
3,439
TL;DR: IMEI 0 is most likely a firmware bug. Our best hope is the upcoming oreo firmware.

Hey all,
After spending hours on the IMEI 0 problem, here are my findings:

1. IMEI is stored in nv 550 variable in QCN. However, this variable is write protected. This means all IMEI write programs such as QCOM Write IMEI tool will fail.
2. Interestingly, only IMEI 1 is stored in the nv. IMEI 2 is derived by performing some fixed hex arithmetic on IMEI 1.
3. IMEI also seems encrypted since the nv 550 in QCN never has a correct hex notation of IMEI. For example, Only half of the IMEI is correct.
4. Any attempt to restore the QCN backup of someone else will successfully write all nv variables except nv 550. Means you cannot rewrite your factory IMEI.
5. The above is true even if you hexedit the QCN with your own IMEI. NV 550 is write protected.
6. modemst1 and modemst2 are sort of some baseband cache which are created by radio/bootloader using fsg. fsg seems to be some sort of backup partition for modemst.
7. After downgrading and erasing modemst1-2, these modemst are not recreated successfully by the modem. The nv 550 variable goes missing.
8. My guess is that modem has some checksum mechanism wherein if any discrepancy is found, the modemst cache recreation fails. Not sure.
9. Our IMEI is most likely intact somewhere (not talking about fastboot IMEI). Just not interpreted properly.
10. People who restored their efs after IMEI 0 are essentially restoring working cached modemst1-2. However, if fastboot erase modemst is done, it'll likely result in IMEI 0 again because modem cannot recreate modemst correctly.
 
Last edited:

tuxattack80

Senior Member
Nov 29, 2012
1,204
701
Covington Kentucky
TL;DR: IMEI 0 is most likely a firmware bug. Our best hope is the upcoming oreo firmware.

Hey all,
After spending hours on the IMEI 0 problem, here are my findings:

1. IMEI is stored in nv 550 variable in QCN. However, this variable is write protected. This means all IMEI write programs such as QCOM Write IMEI tool will fail.
2. Interestingly, only IMEI 1 is stored in the nv. IMEI 2 is derived by performing some fixed hex arithmetic on IMEI 1.
3. IMEI also seems encrypted since the nv 550 in QCN never has a correct hex notation of IMEI. For example, Only half of the IMEI is correct.
4. Any attempt to restore the QCN backup of someone else will successfully write all nv variables except nv 550. Means you cannot rewrite your factory IMEI.
5. The above is true even if you hexedit the QCN with your own IMEI. NV 550 is write protected.
6. modemst1 and modemst2 are sort of some baseband cache which are created by radio/bootloader using fsg. fsg seems to be some sort of backup partition for modemst.
7. After downgrading and erasing modemst1-2, these modemst are not recreated successfully by the modem. The nv 550 variable goes missing.
8. My guess is that modem has some checksum mechanism wherein if any discrepancy is found, the modemst cache recreation fails. Not sure.
9. Our IMEI is most likely intact somewhere (not talking about fastboot IMEI). Just not interpreted properly.
10. People who restored their efs after IMEI 0 are essentially restoring working cached modemst1-2. However, if fastboot erase modemst is done, it'll likely result in IMEI 0 again because modem cannot recreate modemst correctly.

Even though I'm sure it's not the news we all wanted to hear I still want to say thanks for spending the time to try and figure it out:good::good:

---------- Post added at 02:36 AM ---------- Previous post was at 02:31 AM ----------


Also I feel that you are correct about IMEI still being present somewhere just not being relayed correctly because if you select the barcode option in fastboot it will correctly display the imei number but once booted the imei is back to zero unless it's very possible the barcode images are just static images
 

karthik4601

Member
May 28, 2015
7
1
Great work dev

Man you are doing an awesome work which is in need I have a motog5plus untouched stock (maybe some updates of stock) so i can obtain the required files needed for you to solve this
Just leave a reply @Sid_Karthik #telegram so that I can know how to obtain those files :good::good:
 

rachitrawat

Inactive Recognized Developer
Jul 12, 2012
1,000
3,439
Some more update:
1. falcon had partitions dhob and hob which contained device specific information about the IMEI, ESN etc.
2. potter doesn't have these partitions. However, I've found some dhob & shob related binaries after mounting persist img.
3. persist acts as a bridge in properly interpreting device specific info like IMEI.
4. Most contents of persist including hob, shob are write protected.
4. Since modem updates nv items on the fly, you can get imei 0 after fiddling with persist.
5. A compromised persist can easily be detected by checksum mechanism.
6. Custom ROMs most likely fiddled with persist. After downgrade and erasing modemst1-2, the bridge broke and modem cannot initialize modemst1-2 properly. Thus, imei 0.
 

Abhineet m25

Member
Feb 28, 2014
26
15
Yes i can confirm it .


I have a Moto g5 plus XT1686 which was on stock & is my daily driver. But as i completed one year with this device and lost my warranty I unlocked my bootloader flashed twrp recovery took a backup. Then installed an Oreo rom (android 8.1) . That rom had some serious volte issues. So i went back to stock through Twrp backup. As this is my daily driver i couldn't take any chances so i fastbooted flashed stock rom of January security patch & locked my bootloader. But during fastboot i didn't use earse modemst1, earse modemst2 commands. And every thing was fine, i didn't lost my imei or volte. Even i took March security patch & April security patch ota without any issues.
The only difference i saw in fastboot mode was when i fastbooted to stock (January security patch) my software status was unofficial. But with March security patch Ota it became official. But my baseband changed to 47e which was 47r on pure stock.
 
Last edited:

Jrhotrod

Senior Member
Nov 30, 2016
655
331
United States
Yes i can confirm it .


I have a Moto g5 plus XT1686 which was on stock & is my daily driver. But as i completed one year with this device and lost my warranty I unlocked my bootloader flashed twrp recovery took a backup. Then installed an Oreo rom (android 8.1) . That rom had some serious volte issues. So i went back to stock through Twrp backup. As this is my daily driver i couldn't take any chances so i fastbooted flashed stock rom of January security patch & locked my bootloader. But during fastboot i didn't use earse modemst1, earse modemst2 commands. And every thing was fine, i didn't lost my imei or volte. Even i took March security patch & April security patch ota without any issues.
The only difference i saw in fastboot mode was when i fastbooted to stock (January security patch) my software status was unofficial. But with March security patch Ota it became official. But my baseband changed to 47e which was 47r on pure stock.
So I guess that your stock backup had your IMEI and VoLTE intact. Interesting. If yours was an XT1687 I would ask if you could post that backup, sans account info and sensitive stuff.

Maybe a TWRP backup for every model of the phone could save everyone, as long as the backup was taken before flashing an 8.1 ROM.
 

rachitrawat

Inactive Recognized Developer
Jul 12, 2012
1,000
3,439
Yes i can confirm it .


I have a Moto g5 plus XT1686 which was on stock & is my daily driver. But as i completed one year with this device and lost my warranty I unlocked my bootloader flashed twrp recovery took a backup. Then installed an Oreo rom (android 8.1) . That rom had some serious volte issues. So i went back to stock through Twrp backup. As this is my daily driver i couldn't take any chances so i fastbooted flashed stock rom of January security patch & locked my bootloader. But during fastboot i didn't use earse modemst1, earse modemst2 commands. And every thing was fine, i didn't lost my imei or volte. Even i took March security patch & April security patch ota without any issues.
The only difference i saw in fastboot mode was when i fastbooted to stock (January security patch) my software status was unofficial. But with March security patch Ota it became official. But my baseband changed to 47e which was 47r on pure stock.

You saved yourself by not erasing working modemst cache.
However, if you erase it now, you'll likely get imei 0 since your persist is compromised by flashing custom ROM. Unless of course you took a pure persist dump before flashing anything.
My guess about the baseband letters:
R: persist ok, efs ok
e: persist not ok, efs ok
u: persist not ok, efs not ok

So I guess that your stock backup had your IMEI and VoLTE intact. Interesting. If yours was an XT1687 I would ask if you could post that backup, sans account info and sensitive stuff.

Maybe a TWRP backup for every model of the phone could save everyone, as long as the backup was taken before flashing an 8.1 ROM.

If you've erased your modemst and your persist is modified, his persist/efs backup won't restore your imei/volte. The modem has checksum mechanism to verify imei. So no cheating.
 

Tech_Savvy

Senior Member
May 8, 2014
1,500
681
watertown
You saved yourself by not erasing working modemst cache.
However, if you erase it now, you'll likely get imei 0 since your persist is compromised by flashing custom ROM. Unless of course you took a pure persist dump before flashing anything.
My guess about the baseband letters:
R: persist ok, efs ok
e: persist not ok, efs ok
u: persist not ok, efs not ok



If you've erased your modemst and your persist is modified, his persist/efs backup won't restore your imei/volte. The modem has checksum mechanism to verify imei. So no cheating.

Would it work for other ppl to use my presist image with them getting my imei...i have the single sim xt1687 abd have a backed up presist via twrp and also pulled the image via root and adb...was on stock January build when i backed.both up before flash aosp
 

rachitrawat

Inactive Recognized Developer
Jul 12, 2012
1,000
3,439
Would it work for other ppl to use my presist image with them getting my imei...i have the single sim xt1687 abd have a backed up presist via twrp and also pulled the image via root and adb...was on stock January build when i backed.both up before flash aosp

No. Persist is unique to each device.
 
  • Like
Reactions: hashroot

svapre

Member
Jun 17, 2014
26
7
I was on Lineage 15 when after trying to flash Magisk and DolbyAtmos my signal was gone. I have xt1686 which is dua sim and on both the sims there was no siggnal but the sims were detected. So i tried reflashing the Rom but it didnt help . I fasboot flashed stock with erase modem cmds and lost IMEI . Then I tried some work around ang got signal back on debloated ROM , but made a mistake by going back to stock again. Now I have tried every ROM but no signal in any. I had made a TWRP backup before installing 8.1 ROM so i have efs but even then I can only get my IMEI back but not the signal. Also when I try restoring the backup it says no OS , so there is something wrong with it.
 

rachitrawat

Inactive Recognized Developer
Jul 12, 2012
1,000
3,439
Attention.
Before flashing anything, backup your unique persist and save it for your life.

How to backup::
1. Boot and not flash twrp
Code:
 fastboot boot twrp.img
2. do
Code:
adb shell
dd if=/dev/block/mmcblk0p30 of=/sdcard/persist.img

When you revert to stock, restore persist.img:
Code:
adb shell
dd if=/sdcard/persist.img of=/dev/block/mmcblk0p30

Note: efs backup is not required at all.

Those who don't have their persist backup and have flashed custom are stuck with IMEI 0 forever. Including me.
 
Last edited:

Badshah deep

Member
Mar 1, 2015
32
7
Attention.
Before flashing anything, backup your unique persist and save it for your life.

How to backup::
1. flash twrp
2. do


When you revert to stock, restore persist.img:


Note: efs backup is not required at all.

Those who don't have their persist backup and have flashed custom are stuck with IMEI 0 forever. Including me.
Forever ? Seriously bro? Nopes hopes even after Oreo?
 
  • Like
Reactions: Arunxyz

rachitrawat

Inactive Recognized Developer
Jul 12, 2012
1,000
3,439
Did some more digging.
1. IMEI is likely stored in /persist/rfs/msm/mpss/dhob.bin
You can't view this dir in root browser as it is locked. You need to mount it (linux in my case) and give admin permission.
dhob is encrypted by default. There is also a HMAC (keyed hash) to verify its integrity. So you can't use someone else's persist dump.
You can check your dhob log with this: (taken on LOS 15.1)
Code:
cat /data/vendor/tombstones/rfs/modem/dhob_report.txt

mot_d_hob_stg_ram.c, 547: initializing dynamic hob...
mot_d_hob_stg_ram.c, 570: Failed to read DHOB file, err = 3
mot_d_hob_stg_ram.c, 446: [COLOR="Red"]couldn't verify hmac[/COLOR]
mot_d_hob_stg_ram.c, 447: status   = 2
mot_d_hob_stg_ram.c, 448: verified = 0
mot_d_hob_stg_ram.c, 618: dhob in trusted boot
mot_d_hob_crypto.c, 291: [COLOR="Red"]FATAL: decryption failed with st 20[/COLOR]
mot_d_hob_crypto.c, 292: in size  = 16320
mot_d_hob_crypto.c, 293: dec size = 16320
mot_d_hob_stg_ram.c, 666: FATAL: blank dhob in trusted mode
mot_d_hob_stg_ram.c, 779: FATAL: dhob functionality blocked

mot_d_hob_stg_ram.c, 860: dHOB DB recover
mot_d_hob_stg_ram.c, 898: dHOB recover failed

mot_d_hob_stg_ram.c, 1250: comparing dynamic hob...
mot_d_hob_stg_ram.c, 1253: DHOB ops not allowed

mot_d_hob_stg_ram.c, 1081: refreshing dynamic hob...
mot_d_hob_stg_ram.c, 1085: dhob ops not allowed
2. To check hob's log (also related to imei):

Code:
cat /data/vendor/tombstones/rfs/modem/hob_report.txt

mot_s_hob_stg.c, 197: RFS read finished - in 1272 ms
mot_s_hob_stg.c, 326: ERR: Can't access HOB file, errno = 3
mot_s_hob_stg.c, 327: ERR: read -2025043604 bytes

mot_s_hob_amss.c, 825: s_hob_phase_check
mot_s_hob_amss.c, 590: ERR: HOB NV 540 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 1864 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 3691 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 5459 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 5461 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 5464 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 6683 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 6684 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 6735 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 6736 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 20309 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 20310 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 20825 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 20826 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 20883 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 20884 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 22982 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 24226 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 24228 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 24230 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 24233 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 24250 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 24252 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 24255 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 24256 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 24964 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 24965 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 24966 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 24967 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 24972 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 24973 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 24974 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 24975 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 27779 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 27781 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 27783 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 27786 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 27812 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 28329 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 28333 inactive
mot_s_hob_amss.c, 590: ERR: HOB NV 28334 inactive
mot_s_hob_amss.c, 852: ERR: Found 41 NV items from HOB list that are not populated

Forever ? Seriously bro? Nopes hopes even after Oreo?
Likely no if you have flashed someone else's persist.
Maybe yes if you have your own but flashed custom ROMs. Currently, modem fails to initialize efs even if you modify just 1 bit of persist because of hash check.
 
Last edited:

caiquejd

Member
Dec 5, 2011
33
18
São Paulo
I flashed a Oreo ROM without doing backup, later I flashed stock ROM, and got IMEI 0. Now, after multiples trys I got my IMEI and signal back, with stock ROM (Deodexed zip).
Doing a backup of "persist" will help?
 

rachitrawat

Inactive Recognized Developer
Jul 12, 2012
1,000
3,439
I flashed a Oreo ROM without doing backup, later I flashed stock ROM, and got IMEI 0. Now, after multiples trys I got my IMEI and signal back, with stock ROM (Deodexed zip).
Doing a backup of "persist" will help?
Interesting. If you've intact persist, your device will not loose imei even after full fastboot factory flash.

Ive noticed that twrp adds is configuration file ".twrps" in persist partition,that is ok?
Likely yes. But flashing custom ROM triggers hash mismatch for sure. When I took my persist backup (which I lost damn), I fastboot boot twrp and not flash. Before reverting to stock, I simply restored my persist. The baseband letter in stock changed to R from e and it'd detect imei even after fastboot erase modemsts.
 
Last edited:
  • Like
Reactions: Abhineet m25

cubermax

Member
Jun 13, 2013
16
5
Kramatorsk
Interesting. If you've intact persist, your device will not loose imei even after full fastboot factory flash.


Likely yes. But flashing custom ROM triggers hash mismatch for sure. When I took my persist backup (which I lost damn), I fastboot boot twrp and not flash. Before reverting to stock, I simply restored my persist. The baseband letter in stock changed to R from e and it'd detect imei even after fastboot erase modemsts.
If I understand you correctly, people who do not have the original persist file have no chance to restore IMEI?
 

Top Liked Posts

  • There are no posts matching your filters.
  • 18
    IMEI 0 after flashing stock firmware is due to modem not being able to recreate EFS (modemst1-2) since persist is compromised. Motorola has removed dedicated dhob & hob partitions (which used to store IMEI info in earlier moto g's) and moved them to persist. Pure persist backup is therefore NECESSARY before flashing anything. See here for persist backup instructions.

    Note: persist is unique to device. Flashing someone else's persist will NOT restore your IMEI. Instead, it'll PERMANENTLY wipe dhob bin holding your IMEI.

    Edit: Confirmed. Persist is unique to device. I restored my pure persist backup and got IMEI & VOLTE.
    Please go through the entire thread carefully.

    Edit: Problem is caused by incorrect user id for rfs. Can be fixed if you have your own persist. See here

    hey,
    As you all know, fastbooting stock 7.0 over custom 8.1 corrupts our QCN. However, if you first restore a twrp 7.0 system.img and boot.img, the problem doesn't occur.
    Numerous guides exist on XDA but they are very bad hacky workarounds with no explanation given.
    I'm making a non-hacky fix for imei0/volte/other baseband problems since it is unlikely that upcoming official 8.1 will fix the issue. Moto service center also doesn't know how to fix this.
    To achieve this, I need some files from people with stock 7.0 (preferably indian variant) who satisfy the following criteria:
    1. never flashed custom 8.1
    or
    2. successfully reverted to 7.0 from 8.1 without flashing any hacks from xda (i.e, restored twrp system/boot backup instead of fastbooting whole fw)
    If everything goes through, I'll release a detailed guide for this.
    I urge the volunteers to PM me asap. Note that root/unlock is not necessary for this.
    16
    The solution

    I'll break this post down into two sections - 1) How to 'fix' your persist, and 2) What happened

    1) Fixing your persist
    • For this to work properly, YOU MUST BE ON STOCK ROM, and you must have ROOT access within STOCK ROM.
    • The following commands must be run in a root shell. I have only tested this through adb, so have the commands as run from the PC
    Code:
    adb shell
    su
    chown -R rfs:rfs /persist/rfs
    chown -R rfs:rfs_shared /persist/hlos_rfs
    reboot

    The last command will reboot your phone and when it comes back, if you had lost your IMEI, you will have it back again now (fingers crossed!).

    2) What happened
    To understand what happened, you need to know a few things about filesystem permissions in Linux. Files and folders have user and group ownership, and permissions. Examples of owners are the system, root, user, etc. Examples of permissions are read access, write access, execute access. The permissions are applied at three levels 1) the user, 2) the group, 3) everyone else.

    The OP's investigation into the failures showed that the issue was relating to the persist partition, specifically some files dhob.bin etc that are under the rfs sub folder in this partition. Under stock, these files/folders are owned by a user called rfs, and have group ownership under a group also called rfs. Additionally, the permissions on these files/folders are limited - only the rfs user can read/write/execute these files. Other users, groups, or everyone else, cannot access the files.

    So something happened in the Oreo roms. If you flash and boot into an Oreo rom, and you look at the permissions/ownership, you will see exactly the same ownership patterns as stock. But there's a catch!

    In Linux, all users and groups are assigned an ID, i.e. a number. So for example, on my phone, the rfs user has ID 3012 under stock. In lineage oreo, the rfs user has ID 2951. So something happened in lineage that changed the user IDs.

    If you look at the ownership of persist files/folders within TWRP, you will see that a STOCK PERSIST has the owner of the rfs folder as rfs_old. Similarly in TWRP, a LINEAGE PERSIST has the owner of the rfs folder as rfs. So TWRP is seeing owners in a similar way to Lineage does. Trying to run the above commands in TWRP will not fix the issue, as it will use ID 2951 for the user rfs, but we need it to be 3012 in stock (which TWRP sees as rfs_old).

    In addition to the rfs folder, there is also another folder that is impacted - hlos_rfs. Its user owner is rfs, but its group owner if rfs_shared. A stock rfs_shared is shown as rfs_shared_o in TWRP.

    You can modify the commands above to work in TWRP, but to keep things simple, I'm only posting the commands as they are run from within stock.

    Hope this helps out some of you!
    12
    TL;DR: IMEI 0 is most likely a firmware bug. Our best hope is the upcoming oreo firmware.

    Hey all,
    After spending hours on the IMEI 0 problem, here are my findings:

    1. IMEI is stored in nv 550 variable in QCN. However, this variable is write protected. This means all IMEI write programs such as QCOM Write IMEI tool will fail.
    2. Interestingly, only IMEI 1 is stored in the nv. IMEI 2 is derived by performing some fixed hex arithmetic on IMEI 1.
    3. IMEI also seems encrypted since the nv 550 in QCN never has a correct hex notation of IMEI. For example, Only half of the IMEI is correct.
    4. Any attempt to restore the QCN backup of someone else will successfully write all nv variables except nv 550. Means you cannot rewrite your factory IMEI.
    5. The above is true even if you hexedit the QCN with your own IMEI. NV 550 is write protected.
    6. modemst1 and modemst2 are sort of some baseband cache which are created by radio/bootloader using fsg. fsg seems to be some sort of backup partition for modemst.
    7. After downgrading and erasing modemst1-2, these modemst are not recreated successfully by the modem. The nv 550 variable goes missing.
    8. My guess is that modem has some checksum mechanism wherein if any discrepancy is found, the modemst cache recreation fails. Not sure.
    9. Our IMEI is most likely intact somewhere (not talking about fastboot IMEI). Just not interpreted properly.
    10. People who restored their efs after IMEI 0 are essentially restoring working cached modemst1-2. However, if fastboot erase modemst is done, it'll likely result in IMEI 0 again because modem cannot recreate modemst correctly.
    8
    Some more update:
    1. falcon had partitions dhob and hob which contained device specific information about the IMEI, ESN etc.
    2. potter doesn't have these partitions. However, I've found some dhob & shob related binaries after mounting persist img.
    3. persist acts as a bridge in properly interpreting device specific info like IMEI.
    4. Most contents of persist including hob, shob are write protected.
    4. Since modem updates nv items on the fly, you can get imei 0 after fiddling with persist.
    5. A compromised persist can easily be detected by checksum mechanism.
    6. Custom ROMs most likely fiddled with persist. After downgrade and erasing modemst1-2, the bridge broke and modem cannot initialize modemst1-2 properly. Thus, imei 0.
    7
    Attention.
    Before flashing anything, backup your unique persist and save it for your life.

    How to backup::
    1. Boot and not flash twrp
    Code:
     fastboot boot twrp.img
    2. do
    Code:
    adb shell
    dd if=/dev/block/mmcblk0p30 of=/sdcard/persist.img

    When you revert to stock, restore persist.img:
    Code:
    adb shell
    dd if=/sdcard/persist.img of=/dev/block/mmcblk0p30

    Note: efs backup is not required at all.

    Those who don't have their persist backup and have flashed custom are stuck with IMEI 0 forever. Including me.
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone