Related
Update 9/1/2012: A user has successfully restored with this method! Continue to "Testimonials" for more info!
Update 9/2/2012: TrevE has now come up with a way to leverage Samsung's built-in restore to your advantage! Read below for more!
Update 9/3/2012: Changed adb commands to reduce Operation not permitted problems.
Thanks to the efforts of some great developers, there is now *possibly* a more comprehensive method to backup your IMEI. While I have not personally tested a restore using this method, a user in IRC has done a manual NVRAM wipe and restored it using this method, without the roaming issues caused by a occasionally-bungled QPST restore or manual IMEI injection. In addition, posts in this thread indicate a successful restore from an actual occurrence of the problem, all without the use of QPST and also without any roaming issues!
Before I go any further, the same old disclaimer still applies; you accept all responsibility for what you do to your own device!
Theory:
The theory is that the S3 has, in the boot process, a routine which is "tripped" when it detects an error condition. This routine is designed to "save" your IMEI by restoring images from two built-in backup blocks. The problem is, it actually does the opposite; for whatever boneheaded reason, the default backup blocks contain dummy images with an IMEI of 0 and no carrier identification. This is why your phone forgets what carrier it's on and what its IMEI number is; the restore routine actually overwrites the phone's only copy of the IMEI data with a dummy. Because much more data is lost than just the IMEI, this is also why a QPST injection (not a QCN restore) persistently leaves you on roaming.
In an initial attempt to solve this problem, users have attempted to "dd", or create an image of, a single block supposedly containing the IMEI when the phone is still in a good state. This is the efs.sbn method that you may have seen. However, upon further inspection, it turns out the IMEI data is actually spread across five different block devices, hence why the efs.sbn method is either ineffective or leaves you on roaming! After the block devices were identified, a SynergyROM team member created an easy-to-use recovery zip that allows you to image these five blocks, allowing you to reflash them should the Samsung boot process overwrite your IMEI! Re-flashing these blocks after they've been crapped up virtually ensures your phone has been fully restored to its pre-IMEI-loss condition, thereby preventing roaming or data issues seen consistently with a manual injection, or intermittenly with a QPST restore. You do not need SynergyROM to use this tool; I've done it from full stock.
But wait: there's more. About a week after the development of this tool, several unused boot entry points were discovered that revealed a way to control Samsung's built-in "safety" feature and actually make it work properly! Two backup blocks were put in by Samsung themselves; "fsg" and "backup". The great news is that, although these images may contain dummies by default, you can instruct the bootloader to write your good NVRAM data to them so that the good data is what's written to NVRAM in the event of an error. That is, instead of restoring a dummy image over your good IMEI...it restores a good backup instead and you don't lose a thing! How awesome is that?
Developers are now recommending a new IMEI backup regimen, leveraging Samsung's built-in IMEI backup and SynergyROM's manual backup, together with an optional QCN backup you can do for good measure. Of course I can't make any guarantees, but doing this backup should leave you in such a good spot that almost nothing can total your IMEI or leave you in a roaming state. Here are the new instructions on how to backup your IMEI, iron-clad. Do Parts A and B, in order, C is optional but will give you added peace of mind.
Backup:
Part A (Samsung's built-in backup):
1. If your phone does not have Terminal Emulator installed, you will need to use ADB. Download and install the Android SDK platform-tools for your platform. This is a bit non-trivial as it requires the installation of the Android SDK, however, you can find a guide for installing adb here. After installing, open a command prompt and navigate to the "platform-tools" folder within the SDK, where adb is stored. If you need additional help on this, simply ask in this thread.
If your phone is rooted and has Terminal Emulator installed, you don't need to do any of this. Simply open up the Terminal Emulator and go to step 2.
2. For ADB: Connect your phone to the computer and ensure it is in "Debug Mode" (Settings->Developer Options->USB debugging). Then. in the command prompt, type the following:
Code:
adb reboot nvbackup
For Terminal Emulator: The actual "beef" of the command is the "reboot nvbackup" line. Therefore, if you have Terminal Emulator installed, you can just run the command straight off your phone. Enter these two commands from the app:
Code:
su
reboot nvbackup
3. Your phone will reboot and copy the contents of two IMEI partitions to the two built-in backup blocks. You may see tiny blue text on the bootloader screen indicating that it is copying.
4. Allow it to finish and then reboot back into Android. The "fsg" and "backup" block devices now contain your IMEI information as they should have in the first place.
Part B (SynergyROM's "Plan B" manual backup):
1. Download the attachment at the bottom of this post. This is an update ZIP you can run right from recovery.
2. Reboot into recovery. On stock this can be done by turning off the phone and then turning it back on while holding UP and HOME.
3. CWM: Use VOL UP and VOL DOWN together with HOME to select "install zip from sdcard" then "choose zip from sdcard". Navigate to the folder you downloaded it to (most likely Download/). Select the zip you just downloaded to "flash".
TWRP: Touch "install" and navigate to the folder you downloaded the zip to (most likely Download/). Swipe to confirm flash.
4. Allow the backup to complete successfully. "Flash" is a bit of a misnomer; this is actually just a script that will safely backup your EFS and radio information to /sdcard/synergyrom/backup without touching your ROM at this point. When the script completes, reboot.
Part C: Backup with QPST:
Once the gold standard of IMEI backup, this method (in my opinion) should now be done only in the event of an unlikely complete catastrophe where neither Samsung's built-in restore nor SynergyROM's restore works. Simply follow the instructions here for extreme peace of mind; you don't need to do this if you don't want to, but I personally did.
Restore:
Do not do this unless your IMEI has been lost!
Performing Part A of the backup should ensure that you never lose your IMEI in the first place; the theory being that the Samsung built-in backup now has a good image to restore itself, as opposed to a dummy image. However, things may still happen. If you've still lost your IMEI, perform each of these methods in order of priority, "A" being the first.
Restore Plan A:
Run the following command from adb, just like when you backed up (have Android SDK installed, connect phone, and ensure USB debugging is enabled):
Code:
adb reboot nvrestore
This method triggers Samsung's built-in IMEI restore; except this time, you got good images on your side. Simply allow the phone to restore and reboot itself when completed. NEVER PERFORM THIS COMMAND WITHOUT DOING PART A OF "BACKUP" FIRST; THIS WOULD RESTORE THE DUMMY IMAGES INSTEAD AND WIPE YOUR IMEI!
Restore Plan B:
Sometimes a fluke happens and the nvrestore does not work. That's why this one is Plan B and not Plan A. Good thing you did Part B of "Backup"! Rather than instructing Samsung's bootloader to restore your NVRAM, this method will do so manually from recovery using a manually done backup.
It's just like when you backed up, except now you want to flash the zip containing your NVRAM info that the other zip built for you. This zip is located in /sdcard/synergyrom/backup. Simply navigate to this path and flash the zip beginning with "keybackup"; this will write images to 5 block devices from a time when your IMEI was all good. Reboot the phone; if all went well, you now have your IMEI back with no roaming!
Restore Plan C:
Both methods above may fail you in extremely unlikely circumstances. At this point, you'll need to try using QPST to get your IMEI back. If you did Part C in "Backup", you can follow instructions in that same thread to get you back up and running. In most QPST restores, you shouldn't have any issues with data or roaming.
Restore Plan D:
The planets have lined up, the Cubs have won the World Series, and all three above methods have failed you in what is surely a sign of the apocalypse. Far more likely, though, is that you didn't have a backup of anything and your IMEI is gone for good. The good news is that you can still get your phone working; the bad news is that you'll be stuck on roaming and may have problems with data. You'll need to perform an "IMEI injection" which is a kludgy last-resort restore method that manually writes the IMEI to NVRAM; the link I provided in Part C of "Backup" will tell you how to do it.
Testimonials:
This method has been tested good by the following users in this thread!
amaury48 said:
Just flashed CM10 09-01 nightly and lost data, confirmed I lost my IMEI. I had used the process in the OP a while ago to backup my IMEI. Just would like to confirm that I just flashed the backup it created and happy to report all is well again. Thanks for the post of this tool........saved my butt......
Click to expand...
Click to collapse
alee said:
I'll join the club. Lost my IMEI while doing the latest CM10 nightly. Restored and was back in action in no time.
Click to expand...
Click to collapse
Nght12 said:
Hey, used your backup method and ended up having to use it later in the day. It works. I'd reply but I can't yet due to being a new member here
Click to expand...
Click to collapse
Please continue to let everyone know if this restore has worked for you after an IMEI loss!
Happy flashing!
TrevE said:
The other trickery we ran into is partitions do not like to be written to for whatever reason outside of package_extract_file right outa the zip. dd'ing directly back failed over and over, I have no clue why, poor esc must have flashed 100 zips before I gave up looking into it. So the updater zip restore uses only package_extract_file, actually writing partitions out properly. I have high hopes that it will actually work, but until tested otherwise do as many types of backups as you can
Click to expand...
Click to collapse
Your restore dd commands won't work.
con247 said:
Your restore dd commands won't work.
Click to expand...
Click to collapse
Good catch. I'll revise the guide appropriately.
So will this work on any ROM?
Sent from my SCH-I535 using xda app-developers app
Yeah I'm on stock rom just rooted an cwm. Can I flash this zip an since I don't have synergy, where will the backup be stored?
Sent from my SCH-I535 using xda app-developers app
Worked on CM10.
I'm all for redundancy of backups, so here's hoping this method fully works when restoring. I have not experience a loss of IMEI myself, but I definitely want to be safe. I know the original efs backup method was proven to be an incomplete backup, but I thought the QPST NV backup method was proven to work? Are you saying that restoring with tthe QPST method (where you have an NV backup before you lose IMEO) does not work and will still having roaming issues?
At any rate, it will be interesting to see if this is the "one true backup" to rule them all for IMEI. So basically, you flash the zip in recovery and it creates another zip with the backed up contents. And in the event of an IMEI loss, you just flash the new zip and should be good to go? At least, that's the theory, right?
Travisimo said:
I'm all for redundancy of backups, so here's hoping this method fully works when restoring. I have not experience a loss of IMEI myself, but I definitely want to be safe. I know the original efs backup method was proven to be an incomplete backup, but I thought the QPST NV backup method was proven to work? Are you saying that restoring with tthe QPST method (where you have an NV backup before you lose IMEO) does not work and will still having roaming issues?
At any rate, it will be interesting to see if this is the "one true backup" to rule them all for IMEI. So basically, you flash the zip in recovery and it creates another zip with the backed up contents. And in the event of an IMEI loss, you just flash the new zip and should be good to go? At least, that's the theory, right?
Click to expand...
Click to collapse
You nailed it!
Nice, I'm assuming this is similar to what the Synergy ROM team is now including?
nyjumpman said:
Nice, I'm assuming this is similar to what the Synergy ROM team is now including?
Click to expand...
Click to collapse
Its the same. Just a standalone version.
Sent from my SCH-I535 using Tapatalk 2
Confirmed successful backup using CWM.
I can confirm this backup method works using CWM.
I first tried it with TWRP via Goo Manager and the script didn't execute properly.
I tried flashing the file while still in TWRP and I couldn't even find the zip file anywhere, user error I'm guessing.. lol.
So I flashed CWM over TWRP via ROM Manager PRO and flashed the zip file with CWM via ROM Manager PRO and the zip script executed nicely. I found the backed up zip file where the OP said it would be.
Here's to hoping I never have to use the backed up file, but it's good to know I have it there if needed.
Thanks again OP!
xCHPx said:
So will this work on any ROM?
Sent from my SCH-I535 using xda app-developers app
Click to expand...
Click to collapse
This should work regardless of ROM as it is a recovery zip. I've tested it with CWM: I've never used TWRP so I don't know how well it would work in TWRP.
tu3218 said:
Yeah I'm on stock rom just rooted an cwm. Can I flash this zip an since I don't have synergy, where will the backup be stored?
Sent from my SCH-I535 using xda app-developers app
Click to expand...
Click to collapse
I've tested a backup successfully on full stock, rooted. The backup will be stored in a folder called "synergyrom" but this just the name the tool gives to the directory (as the tool was created by the Synergy team) and has no impact on function or dependency on SynergyROM.
Travisimo said:
I'm all for redundancy of backups, so here's hoping this method fully works when restoring. I have not experience a loss of IMEI myself, but I definitely want to be safe. I know the original efs backup method was proven to be an incomplete backup, but I thought the QPST NV backup method was proven to work? Are you saying that restoring with tthe QPST method (where you have an NV backup before you lose IMEO) does not work and will still having roaming issues?
Click to expand...
Click to collapse
QPST method is not perfect; it is better than a simple IMEI injection, but the boot bug writes crap over much more than just the IMEI. This is why either method may leave you on roaming (althogh a QPST restore only sporadically causes roaming). In addition, various DRM keys may be erased as well, leaving you potentially unable to play back HDCP/PlayReady titles; QPST does not restore these.
At any rate, it will be interesting to see if this is the "one true backup" to rule them all for IMEI. So basically, you flash the zip in recovery and it creates another zip with the backed up contents. And in the event of an IMEI loss, you just flash the new zip and should be good to go? At least, that's the theory, right?
Click to expand...
Click to collapse
That's correct. When you "flash" the backup zip, nothing actually is written to the ROM as far as I can tell; it runs just like a script/batch file and saves your backup zip to /sdcard/synergyrom. The tool itself creates a new flashable zip in this directory, one that does modify your unit, which you can then use only in the event that the bootloader craps up the NVRAM.
Just did this on cm10. Backed up without issue and I see the folder it created. Thank you. I've done qpst as well so now I feel very safe
Sent from my SCH-I535 using Tapatalk 2
hopesrequiem said:
Just did this on cm10. Backed up without issue and I see the folder it created. Thank you. I've doneSame. Thanks for the info.ll so now I feel very safe
Sent from my SCH-I535 using Tapatalk 2
Click to expand...
Click to collapse
Same
Sent from my SCH-I535 using Xparent Blue Tapatalk 2
So this requires an unlocked bootloader? I just did this but it skipped because my bootloader is still locked. Is that correct in that it needs to be unlocked for this backup process to work?
Sent from my SCH-I535 using xda app-developers app
Just did this, thanks!
I now have 3 different types of backups. I feel safe now if I ever lose it.
Safe-r, I should clarify.
Sent from my SCH-I535 using Tapatalk 2
Made my back up on unofficial cm10 0816. Thanks.
Sent from my SCH-I535 using xda premium
tu3218 said:
So this requires an unlocked bootloader? I just did this but it skipped because my bootloader is still locked. Is that correct in that it needs to be unlocked for this backup process to work?
Sent from my SCH-I535 using xda app-developers app
Click to expand...
Click to collapse
There is no excuse to not be unlocked at this point.
Sent from my SCH-I535 using Tapatalk 2
tu3218 said:
So this requires an unlocked bootloader? I just did this but it skipped because my bootloader is still locked. Is that correct in that it needs to be unlocked for this backup process to work?
Sent from my SCH-I535 using xda app-developers app
Click to expand...
Click to collapse
lol ur still locked???
here. http://forum.xda-developers.com/showthread.php?t=1839791
enjoy bro. now you got no excuces
Stryker1297 said:
lol ur still locked???
here. http://forum.xda-developers.com/showthread.php?t=1839791
enjoy bro. now you got no excuces
Click to expand...
Click to collapse
i know i know lol I've been hesitant because of the IMEI issue and the phone is pretty damn good as is. But I'm slowly leaning towards flashing custom roms to get rid of the bloat, and since there are more ways now to hopefully restore the IMEI in case its deleted.
So I tried my first Nandroid backup today using TWRP and a howtogeek - "How to Back Up and Restore Your Android Phone with TWRP" guide I found off a quick google search.
Basically TWRP, backup(boot,system,data), reboot to android, shut down, twrp-restore then reboot.
When I would reboot after TWRP-restore, it shows the typical bootloader corrupt error msg.
Shuts down again, shows the bootloader msg, then goes into TWRP, asks for my decrypt password, then begins to run an openrecovery script (I think?) of some sort. I then go to reboot my phone again, bang factory reset mode.
I hope I'm not alone here.:cyclops: I'd just really love to be able to backup/image my phone entirely so I can try out a few custom roms, and for general knowledge sake.
thanks!:silly:
mark7807 said:
So I tried my first Nandroid backup today using TWRP and a howtogeek - "How to Back Up and Restore Your Android Phone with TWRP" guide I found off a quick google search.
Basically TWRP, backup(boot,system,data), reboot to android, shut down, twrp-restore then reboot.
When I would reboot after TWRP-restore, it shows the typical bootloader corrupt error msg.
Shuts down again, shows the bootloader msg, then goes into TWRP, asks for my decrypt password, then begins to run an openrecovery script (I think?) of some sort. I then go to reboot my phone again, bang factory reset mode.
I hope I'm not alone here.:cyclops: I'd just really love to be able to backup/image my phone entirely so I can try out a few custom roms, and for general knowledge sake.
thanks!:silly:
Click to expand...
Click to collapse
What version of TWRP have you been using? I understand, RC2 has issues with properly restoring a backup. (RC is release candidate and is not considered fully stable, however, works well enough to flash custom roms and such).
The partitions on the pixel are set up in a more complex way than previously seen on many android phones, which is why there's no perfectly stable version of TWRP yet. You could try using RC1 to see if you get better luck backing up and restoring, however, you should assume that you may run into other issues and be prepared to deal with them should they arise.
exad said:
What version of TWRP have you been using? I understand, RC2 has issues with properly restoring a backup. (RC is release candidate and is not considered fully stable, however, works well enough to flash custom roms and such).
The partitions on the pixel are set up in a more complex way than previously seen on many android phones, which is why there's no perfectly stable version of TWRP yet. You could try using RC1 to see if you get better luck backing up and restoring, however, you should assume that you may run into other issues and be prepared to deal with them should they arise.
Click to expand...
Click to collapse
I'm running 3.1.0-0RC2 so maybe I'll try RC1. Normally I'd just go off and try everything but unfortunately I'm not in a situation I can simply play with my Pixel and potentially brick it leaving me without a phone for who knows how long.
I don't think there would be any harm with playing with RC1 but I'll research a little bit more into it and see what I can find out first. I heard the partitions are split for redundancy(?) for firmware upgrades and dual-booting. That's something all else on it's own as I've REALLY wanted to get my phone ultimately on a Multi-Rom setup but it seems way too complicated for me at the moment to try on my own even though I'm generally good with this stuff..
Thanks exad for the insight. Any other help is greatly appreciated.
mark7807 said:
I'm running 3.1.0-0RC2 so maybe I'll try RC1. Normally I'd just go off and try everything but unfortunately I'm not in a situation I can simply play with my Pixel and potentially brick it leaving me without a phone for who knows how long.
I don't think there would be any harm with playing with RC1 but I'll research a little bit more into it and see what I can find out first. I heard the partitions are split for redundancy(?) for firmware upgrades and dual-booting. That's something all else on it's own as I've REALLY wanted to get my phone ultimately on a Multi-Rom setup but it seems way too complicated for me at the moment to try on my own even though I'm generally good with this stuff..
Thanks exad for the insight. Any other help is greatly appreciated.
Click to expand...
Click to collapse
I would say use RC1 too. I've used it and never had a problem with it other than the occasional failure to decrypt which is no big deal. Just reboot back into recovery. I would add though, instead of backing up system, backup system image. Also vendor image. If you back up system instead of system image you'll more than likely run into battery drain problems. I'm not sure what causes it but it'll cut your battery life down to only several hours. Using system image doesn't cause that problem.
If you should happen to accidentally backup system instead of system image it's not a huge deal to fix it though. If you're on stock just download the factory image that you are currently on, extract the system.img file and flash it using fastboot. If you're on a custom rom, a dirty flash of the rom will fix it.
mark7807 said:
I'm running 3.1.0-0RC2 so maybe I'll try RC1. Normally I'd just go off and try everything but unfortunately I'm not in a situation I can simply play with my Pixel and potentially brick it leaving me without a phone for who knows how long.
I don't think there would be any harm with playing with RC1 but I'll research a little bit more into it and see what I can find out first. I heard the partitions are split for redundancy(?) for firmware upgrades and dual-booting. That's something all else on it's own as I've REALLY wanted to get my phone ultimately on a Multi-Rom setup but it seems way too complicated for me at the moment to try on my own even though I'm generally good with this stuff..
Thanks exad for the insight. Any other help is greatly appreciated.
Click to expand...
Click to collapse
RC1 and backup system image, vendor image, data and boot.
robocuff said:
I would say use RC1 too. I've used it and never had a problem with it other than the occasional failure to decrypt which is no big deal. Just reboot back into recovery. I would add though, instead of backing up system, backup system image. Also vendor image. If you back up system instead of system image you'll more than likely run into battery drain problems. I'm not sure what causes it but it'll cut your battery life down to only several hours. Using system image doesn't cause that problem.
If you should happen to accidentally backup system instead of system image it's not a huge deal to fix it though. If you're on stock just download the factory image that you are currently on, extract the system.img file and flash it using fastboot. If you're on a custom rom, a dirty flash of the rom will fix it.
Click to expand...
Click to collapse
TheBurgh said:
RC1 and backup system image, vendor image, data and boot.
Click to expand...
Click to collapse
Thanks again guys,
I ran a
fastboot boot twrp.zip to boot to what I thought was like a "live cd" version of twrp
with the rc1 .img and .zip in the sdcard directory I installed the .zip
booted my phone and it forces to recovery everytime now.
did I upset something?
I mean at this point, I could factory reset the google pixel all from the very beginning of time. boot/system the whole shabang, but I think this could be a good lesson from me if I could boot back to system out of this..
Okay. I have RC1 on here and have backed up to USB. I'm extremely tired and going to bed. I'll report back on how the restore goes. THANK YOU ALL!!!
mark7807 said:
Thanks again guys,
I ran a
fastboot boot twrp.zip to boot to what I thought was like a "live cd" version of twrp
with the rc1 .img and .zip in the sdcard directory I installed the .zip
booted my phone and it forces to recovery everytime now.
did I upset something?
I mean at this point, I could factory reset the google pixel all from the very beginning of time. boot/system the whole shabang, but I think this could be a good lesson from me if I could boot back to system out of this..
Okay. I have RC1 on here and have backed up to USB. I'm extremely tired and going to bed. I'll report back on how the restore goes. THANK YOU ALL!!!
Click to expand...
Click to collapse
Okay so, I stayed up a little late and tried a restore. I got this error near the end of the restore "extractTarFork() process ended with error: 255" in which resulted in corruption of files and a failed restore. Was I supposed to unmount data? Is there any reason I can't backup all partitions?
mark7807 said:
Okay so, I stayed up a little late and tried a restore. I got this error near the end of the restore "extractTarFork() process ended with error: 255" in which resulted in corruption of files and a failed restore. Was I supposed to unmount data? Is there any reason I can't backup all partitions?
Click to expand...
Click to collapse
Not sure where to direct you at this point. I have always used RC1 and backed up system image, vendor image, data and boot and never had a problem restoring. Someone with better knowledge will come around.
TheBurgh said:
Not sure where to direct you at this point. I have always used RC1 and backed up system image, vendor image, data and boot and never had a problem restoring. Someone with better knowledge will come around.
Click to expand...
Click to collapse
Yeah very strange I did exactly what you told me to do as well. Any changes to partitions I backup if my phone is rooted by chance??
mark7807 said:
Yeah very strange I did exactly what you told me to do as well. Any changes to partitions I backup if my phone is rooted by chance??
Click to expand...
Click to collapse
Not that I am aware of. Mine is rooted and backups have been smooth sailing.
I recently attempted creating a nandroid backup via TWRP on my rooted Pixel and I'm consistently getting an error: 'cannot create [path]\backup file" message from TWRP. Is there a permission issue that I've overlooked here or does anyone have any thoughts as to why my rooted Pixel would be denying TWRP authority to create the backup?
Thanks
What version of twrp ?
I only use rc1, never seen this.
Yep- RC1. I'm thinking it's in 'read only' mode or something because as soon as it attempts to create the folder/file- no-go.
pstgh said:
Yep- RC1. I'm thinking it's in 'read only' mode or something because as soon as it attempts to create the folder/file- no-go.
Click to expand...
Click to collapse
When you boot into TWRP did it ask for your unlock PIN? If it doesn't/didn't, either keep rebooting into recovery or turn the phone off and go back into recovery until TWRP does ask for your encryption PIN. Sometimes TWRP doesn't ask, and without the PIN being entered, it can't write to the internal storage.
If you click "Install" in TWRP and see a bunch of gobbledygook it's because the internal storage is still encrypted so TWRP can't do anything with it.
You could probably use USB OTG through the USB-C connector, though, to do a backup to it, if you need to.
Tried it again and it worked flawlessly.... it seems sort of buggy in that sometimes it presents the 'pattern' security lock that I use and sometimes it doesn't. After booting up in the bootloader and fastbooting the TWRP boot image slowly and methodically, the security pattern came up and all is perfect- thanks.
---------- Post added at 08:37 PM ---------- Previous post was at 08:36 PM ----------
Now I'm wondering how to best move that backup folder (or a copy of it) over to Google Drive? I have root explorer, but not sure if it is capable of mounting to Google Drive.. any thoughts on best practices here would be appreciated.
Thanks
pstgh said:
Tried it again and it worked flawlessly.... it seems sort of buggy in that sometimes it presents the 'pattern' security lock that I use and sometimes it doesn't. After booting up in the bootloader and fastbooting the TWRP boot image slowly and methodically, the security pattern came up and all is perfect- thanks.
---------- Post added at 08:37 PM ---------- Previous post was at 08:36 PM ----------
Now I'm wondering how to best move that backup folder (or a copy of it) over to Google Drive? I have root explorer, but not sure if it is capable of mounting to Google Drive.. any thoughts on best practices here would be appreciated.
Thanks
Click to expand...
Click to collapse
I can't confirm since I've yet to do a successful backup but... Flashify Pro version looks like an option???
also
Anyone know when TWRP 3.1.0-0 will be out for Pixel? Looks like it addresses boot slots which off first glance seems like quite a fundamental feature no?
Thanks... I'm thinking I'll just adb pull the file over to my desktop... not sure.
pstgh said:
Thanks... I'm thinking I'll just adb pull the file over to my desktop... not sure.
Click to expand...
Click to collapse
Root Explorer does have support for Google Drive. In Root Explorer touch the plus sign in the lower right corner and in the menu that opens choose Google Drive tab.
Can get Root Explorer to connect to Google Drive, but when I select all of the backup files from my Pixel's TWRP backup folder, my only choices are to cut or copy them- so I tried both and then RE creates this little clipboard icon that you presumably click on to paste them once you've opened the proper GD folder.... so I tried that and in both cases (cut and copy) it says 'fail'.... ? Thoughts? I've given RE permission to manage folders and files in GD.
pstgh said:
Can get Root Explorer to connect to Google Drive, but when I select all of the backup files from my Pixel's TWRP backup folder, my only choices are to cut or copy them- so I tried both and then RE creates this little clipboard icon that you presumably click on to paste them once you've opened the proper GD folder.... so I tried that and in both cases (cut and copy) it says 'fail'.... ? Thoughts? I've given RE permission to manage folders and files in GD.
Click to expand...
Click to collapse
It sounds like you've got the right idea. Cut will move the files, copy will do just that. You choose one of the two and browse to the Google Drive tab, find the folder you want to use and then use the little clipboard thing to transfer the files to that folder. If that's what you're doing, the only thing I can think of right off the top of my head would be that you don't have enough space left on Google Drive for the size of the files you're trying to transfer. Try a picture or something and see if it takes that. If so, I'd suspect lack of Drive space is the reason it fails.
Hi,
I have a note 3 neo, 7505 and i updated the firmware. It was all working good for a week then i was listening to soundcloud to sleep and the phone restarted, since then the phone doesn't have an imei and says to insert sim card, and of course unknown modem..
Anyway, i created a backup of the efs using twrp, i have tried gazillion ways to restore the backup and gazillion manual ways too. Going to stock recovery... trying to copy manually the nvdata and all but it doesnt resolve. The files are placed there, i can see it in the shell but the thing just wont work!
i don't know how to proceed to this, i don't know if its a hardware fault, had it been that, shouldnt have i gotten the efs corrupted or some issue? could it be that the hardware itself is damaged all of a sudden? i dont think so, i pretty much think its the efs and yet i cant restore it?
should i attach my efs folder if someone can look through hex editor or logs to suggest a possible solution?
Thanks a lot and also i have search through and proceeded with many solutions and after that created a thread. hope someone can help.
P.S. I just noticed the serial number can be seen in phone status, so apparently its reading NVdata? or is it getting it from elsewhere? how to test if its a hardware fault?
penandweb said:
Hi,
I have a note 3 neo, 7505 and i updated the firmware. It was all working good for a week then i was listening to soundcloud to sleep and the phone restarted, since then the phone doesn't have an imei and says to insert sim card, and of course unknown modem..
Anyway, i created a backup of the efs using twrp, i have tried gazillion ways to restore the backup and gazillion manual ways too. Going to stock recovery... trying to copy manually the nvdata and all but it doesnt resolve. The files are placed there, i can see it in the shell but the thing just wont work!
i don't know how to proceed to this, i don't know if its a hardware fault, had it been that, shouldnt have i gotten the efs corrupted or some issue? could it be that the hardware itself is damaged all of a sudden? i dont think so, i pretty much think its the efs and yet i cant restore it?
should i attach my efs folder if someone can look through hex editor or logs to suggest a possible solution?
Thanks a lot and also i have search through and proceeded with many solutions and after that created a thread. hope someone can help.
P.S. I just noticed the serial number can be seen in phone status, so apparently its reading NVdata? or is it getting it from elsewhere? how to test if its a hardware fault?
Click to expand...
Click to collapse
The point is that TWRP creates faulty EFS backups on many devices which can't be restored properly.
There are different backup solutions (e.g. EFS Pro) confirmed working which may help you prevent future issues. I prefer the manual backup using adb shell or terminal emulator:
dd if=/dev/block/mmcblk0pXX of=/storage/SdCard/efs.img bs=4096
(XX needs to be replaced with the model specific partition number as they use different partition tables)
Restore:
dd if=/storage/SdCard/efs.img of=/dev/block/mmcblk0pXX bs=4096
thanks LS.xd, but i guess i have a pretty solid backup as i did create backup various ways, some were corrupt, but one that i working with has nvdata and every other file along with imei pretty intact....
i can open it up with winrar, and open the nvdata with hexeditor, i was wondering if i could confirm some way that the back up is actually 100% solid?
wondering if the partition's aren't aligned. I don't know for sure if EFS folder in the root directory is the same as being pointed by /mmcblkp03/platform/by-name/EFS ?
i mean they should be the same thing, its just a redirection right?
what should i be doing now? the baseband is unknown and the imei wont just work, waste the phone? or it could be done via some boxes or some other process?
there must be a starting point? isn't there some way i could use a generic imei and just any modem? then i could replace nvdata may be? right now, i'm installing various versions of stock firmware and repeatedly placing old efs data in various ways and i kind of turning hopeless. first i lost a nexus then i bought a g4 last month, gave me a bootloop just a week after, gone dead. then i bought the n3n and now this..... i mean 3 phones in a row..... i really hope this could work..
penandweb said:
there must be a starting point? isn't there some way i could use a generic imei and just any modem? then i could replace nvdata may be? right now, i'm installing various versions of stock firmware and repeatedly placing old efs data in various ways and i kind of turning hopeless. first i lost a nexus then i bought a g4 last month, gave me a bootloop just a week after, gone dead. then i bought the n3n and now this..... i mean 3 phones in a row..... i really hope this could work..
Click to expand...
Click to collapse
So you got some non TWRP made EFS backup, too? You can list your partitions using shell:
[email protected]:/ # cat /proc/emmc
You can use the dd command once you know the layout. Backups not generated manually may only be restored with the specific app/version and are probably not compatible using other restore methods. For my OnePlus 3 EFS backup can generated fine using TWRP but restoring it screws up the partition. Manually created image works fine. As I don't have a Note 3 Neo I don't know how it behaves for your device.
any idea how would i go on about inspecting the nvdata.bin? i'm in hex editor trying to see something resembling imei but its just so much garbage except a few lines.
i can't be sure whether its corrupt or not...
in efs -> imei -> a file called mps_code.dat i open it up in hex editor, and it has only 3 characters.....
is it possible i could initially use a generic imei and modem and later on populate it with actual somehow or just keep using generic one for now until i find a better solution, using hex editor or something...?
there are some tutorials on qualcom.. none for exynos but it should happen the same way, somewhere in nvdata, you place the imei ... and it would be generic method for most exynos devices...
i wish someone could guide me to that...
also can it be restored via "boxes"?
penandweb said:
any idea how would i go on about inspecting the nvdata.bin? i'm in hex editor trying to see something resembling imei but its just so much garbage except a few lines.
i can't be sure whether its corrupt or not...
in efs -> imei -> a file called mps_code.dat i open it up in hex editor, and it has only 3 characters.....
is it possible i could initially use a generic imei and modem and later on populate it with actual somehow or just keep using generic one for now until i find a better solution, using hex editor or something...?
there are some tutorials on qualcom.. none for exynos but it should happen the same way, somewhere in nvdata, you place the imei ... and it would be generic method for most exynos devices...
i wish someone could guide me to that...
also can it be restored via "boxes"?
Click to expand...
Click to collapse
After 3 years I had to retire my HTC One S. I flashed roms and firmwares up to 3-4 times a week without having any issues. One sunny day some update bricked then nvdata. I spent a bunch of hours trying to restore it in different ways, extracted data from stock firmware as well as using dumps from other user's phones, as some users reported this error fixed doing so. Even when the files was identical it just did not work for me. Changing the mainboard was the only possible solution so I decided to get a new device.
All I want to say is try to restore a valid backup in a way confirmed working. If you don't have a usable backup ask in your device's forum for somebody may upload it. Or spend 100 hours messing around with hex editors until you reach then point where you realize its cheaper to switch the device as wasting a year's holidays browsing the internet for some solution.
Alright, so i have an OP5T and it is encrypted. I decided to disable one magisk module, op5t gcam dot issue patch, i think thats is what it was called, and then then i couldnt unlock the phone. It was running LOS for microg android 9, and the encryption from oxygenos to los passed no problem (just enter the same lock screen pattern) (also why i think this doesnt belong in some op5t forums because it shouldnt be op5t specific, judging by how i was able to use los with an encrypted phone no problem). Now i deleted something like /data/system/gatekeeper.{password,pattern}.key, and /data/system/lockssettings.db (moved it to a different folder). That kind of worked, but then my phone was stuck on 'starting phone'. Even when getting the files back, it was still stuck. Trying to decerypt it via twrp gave like a 2 second try when using the wrong pattern, and a 5-7 second try when using the correct pattern, although still failed.
When looking at the twrp logs trying to backup /data:
failed to lookup tar policy for '/data/misc_ce/0' - 'cba6a56b3cad5706'
I:Error adding file '/data/misc_ce/0' to '/usbstorage/TWRP/BACKUPS/ab5cbcf1/2020-09-06--05-12-48_lineage_dumpling-userdebug_9_PQ3A190801002/data.ext4.win000'
Error creating backup.
I:ERROR tarList for thread ID 0
Error creating backup.
I:InfoManager saving '/usbstorage/TWRP/BACKUPS/ab5cbcf1/2020-09-06--05-12-48_lineage_dumpling-userdebug_9_PQ3A190801002/data.info'
createTarFork() process ended with ERROR: 255
I also removed magisk via a zip, and reinstalled LOS for microg to no avail.
So, im now copying the internal storage stuff over mtp to my pc, and hoping there would be a way to decrypt them. I have the gatekeeper and lockscreensettings files and i know my pattern, so is there any way i could decrypt them on my pc?
Also, could it be done by wiping /data, booting up android and then setting up a lock screen pattern, enabling encryption, or just copying the files to /data/system/...?
Im typing this really rushed, sorry for any misunderstanding you may encounter.
Alright so another update, gatekeeper.password.key is empty, while gatekeeper.pattern contains some characters. I did use a pattern based lockscreen only, this normal for gatekeeper.password.key to be empty, right?
Ive reflashed the whole thing, now the only thing that could help me would be if i could somehow decrypt the files i have downloaded. I know my pattern and have the gatekeeper.pattern.key file, if that can help?
constatinus said:
Ive reflashed the whole thing, now the only thing that could help me would be if i could somehow decrypt the files i have downloaded. I know my pattern and have the gatekeeper.pattern.key file, if that can help?
Click to expand...
Click to collapse
if you didn't unencrypt the files before resetting the device. the files are now useless. no recovery options unless you know someone who works for the NSA (sarcasm) but true.
I know the feeling. i lost recovery keys for online storage for porn....all lost, but not forgotten.
Nope, you cant.
Sent from my BASIC using Tapatalk
I have a Moto G7 Power XT1955-5 . I recently went on a ROM flashing spree to try out CrDroid, Havoc, Pixel Experience Plus, and LineageOS for the G7 Power.
During the course of installing/ fooling around I ended up formatting my persist. I have a backup on TWRP, but it looks like TWRP touch-screen is inaccessible when persist gets trashed... or one of the random things I have done to the poor phone in the last week.
Fortunately, Orange Fox works just fine. Other than no mobile network, I am currently running LineageOS without issue.
I am already aware of this solution: https://forum.xda-developers.com/showpost.php?p=81805225&postcount=15
I am more interested in learning about persist & how to use TWRP backups with Orange Fox.
Here are my questions:
OrangeFox lists the partitions as /persist1 and /persist2, but TWRP backup lists as /persist and /persist2... does this represent incompatible partition naming conventions? If so, fixing seems as easy as changing the name in a copy of the backup (WIN/ .tar) file, or in worst case just push the archive contents to the partition via adb.
What is the format for OrangeFox backups? Are they also .tars? So should I just be selecting restore backup from a zip archive, or do I need to extract/ compress to .zip?
What is the purpose of /persist vs /persist2 - I can see the contents are different, but can someone explain functional differences? It feels like boot slots so maybe I can just restore one, then copy over?
If anyone has any good reading on /persist I would appreciate it. There's no way that persist isn't programmatically generated, but I can imagine manufacturers and carriers don't want people to start messing with it. This is the stuff I did find (not including outside links from Motorola).
https://forum.xda-developers.com/g5-plus/how-to/dev-fixing-baseband-t3806064
https://forum.xda-developers.com/g5-plus/how-to/fix-persist-resolve-imei0-explanation-t3825147
humanWithAPhone said:
I have a Moto G7 Power XT1955-5 . I recently went on a ROM flashing spree to try out CrDroid, Havoc, Pixel Experience Plus, and LineageOS for the G7 Power.
During the course of installing/ fooling around I ended up formatting my persist. I have a backup on TWRP, but it looks like TWRP touch-screen is inaccessible when persist gets trashed... or one of the random things I have done to the poor phone in the last week.
Fortunately, Orange Fox works just fine. Other than no mobile network, I am currently running LineageOS without issue.
I am already aware of this solution: https://forum.xda-developers.com/showpost.php?p=81805225&postcount=15
I am more interested in learning about persist & how to use TWRP backups with Orange Fox.
Here are my questions:
OrangeFox lists the partitions as /persist1 and /persist2, but TWRP backup lists as /persist and /persist2... does this represent incompatible partition naming conventions? If so, fixing seems as easy as changing the name in a copy of the backup (WIN/ .tar) file, or in worst case just push the archive contents to the partition via adb.
What is the format for OrangeFox backups? Are they also .tars? So should I just be selecting restore backup from a zip archive, or do I need to extract/ compress to .zip?
What is the purpose of /persist vs /persist2 - I can see the contents are different, but can someone explain functional differences? It feels like boot slots so maybe I can just restore one, then copy over?
If anyone has any good reading on /persist I would appreciate it. There's no way that persist isn't programmatically generated, but I can imagine manufacturers and carriers don't want people to start messing with it. This is the stuff I did find (not including outside links from Motorola).
https://forum.xda-developers.com/g5-plus/how-to/dev-fixing-baseband-t3806064
https://forum.xda-developers.com/g5-plus/how-to/fix-persist-resolve-imei0-explanation-t3825147
Click to expand...
Click to collapse
Go here and ask your question. https://t.me/joinchat/TQ2SyFRyFn7uJe_DLANr_A