So I've just gotten the infamous hardware induced boot loop and I've had my return request honoured by Amazon.
While I still have access to the bootloader (nothing else though) and have time to format the userdata partition, I wondered if there's a way to dump the userdata partition so I can retrieve some data from it later (although it's encrypted, I know the password of course).
If this is possible, how can it be done? And how could I decrypt it if there's a method known? If the method of decryption is not known, I guess I could possibly be able to flash it to my new Pixel when I order it, but I'm not entirely sure where/if there's data included within the raw dump that would specify where the partition should be placed (I've not looked into it and only have 2 days before my device MUST be shipped) maybe as an offset from partitions before it, or maybe a specific block range in the flash memory it would be written to.
If this is far from possible, then I don't mind, the only thing I really want to recover is a few meaningless pictures/videos (they're backed up anyway) and the data for my 2FA app so I can drop it in my new device without needing all the hassle of resetting all the codes my every account I have with 2FA enable...
Related
Due to my strong involvement with IT security, today I made an analysis of how effective several wipe-options are on Android phones. I tested this on an HTC Wildfire S (Marvel) running CWM-5.0.2.8 recovery and an inofficial CyanogenMod 7.2 build from 2012-07-17 as ROM.
For the test I first created a memory dump as well as a NANDroid backup of my entire phone. The memory dump was created using the following commands on an adb shell with the Recovery.
Code:
cat /dev/mtd/mtd4 > /sdcard/pre-wipe/cache.img
cat /dev/mtd/mtd5 > /sdcard/pre-wipe/userdata.img
cat /dev/mtd/mtd6 > /sdcard/pre-wipe/devlog.img
I didn't dump mtd0 to mtd3 since these should contain firmware-related data only so there should be no sensitive information here.
Then I booted the phone into CM and did a factory reset. After this was performed, I went back into recovery and created another set of dumps under "/sdcard/wipe-android/*". Afterwards I booted into CWM and restored the NANDdroid backup to prepare for the next test.
I then used the wiping options of CWM on the phone and created a set of dumps under "/sdcard/wipe-cwm/*". Then I restored the NANDroid backup to prepare for the next test.
I shut down the phone and booted it into HBOOT mode, performing a "Factory Reset". After this, HBOOT will boot the ROM, at which point I pulled the battery to prevent the ROM from writing too much to the wiped partitions.
Then I booted back into CWM, took a build of "mtdutils" and did an erasure of mtd5 (userdata) followed by a dump to "/sdcard/wipe-mtdutils/userdata.img".
Then I loaded all these images onto my computer and did a hex comparison. I went through the "pre-wipe/userdata.img" image and saw that the string "Thank you" appears lots and lots of times in several e-mails and SMS messages and so on. So I went through the other userdata dumps and searched for "Thank you" but nothing was found. Not even in the simple "Factory reset" case performed from within the ROM. I expected the ROM to run "mkfs" getting rid of the file system but not of actual data (like what happens when you "format" a drive on a PC - the operating system won't be able to find data anymore, but it's still there on the device and ready to be recovered with the appropriate tools - at least on magnetic hard drives - solid-state-drives make use of the TRIM/Discard command that newer operating systems implement that will actually erase data from the Flash memory inside the SSD, even though it's not considered "secure" and "ATA secure erase" should be used on such drives when security against remanent data is important - also beware that, unless you run Linux and massively tweak your operating system, TRIM/Discard is not used on encrypted drives) but it appears that the data is actually gone (even though some metadata was still in place).
What's interesting is that the images look different after all "wipe" methods. The wipe from within Android leaves most metadata intact, followed by the wipe from within HBOOT, then the wipe from within CWM and the wipe using "mtdutils", as we expected, actually leaves nothing on the device. All pages are cleared to either 2048 bytes of 0x00 (all zeroes) or 2048 bytes of 0xff (all ones). What's interesting is that different pages get reset to different values, so after an "mtdutils" erase there are NAND pages that are actually fully erased (2048 bytes of 0xff), while others are fully programmed (2048 bytes of 0x00). I don't really understand why this is so, but all pages get cleared to one of these two values so this shouldn't leave traces on the device.
So conclusion? Even the most basic wiping method (Factory reset from within the ROM) seems adequate when selling the phone. Chances are that there might be something recoverable with physical access to the NAND chip or the processor (e. g. JTAG access) as the processor makes use of memory virtualization and has address space that is hidden from the user. In particular, devices with eMMC memory (e. g. devices running on MSM8xxx chipsets) might hold remanent data that's invisible from the processor as a whole, since these chips are "overprovisioned" and make use of internal (integrated into the memory package) wear-levelling and bad block replacement that is transparent to the processor and therefore firmware, much like an SSD does inside a computer. So if you have somthing to hide from the CIA, you better physically destroy the phone. However, an "mtdutils"-wipe will probably make your data unrecoverable for at least 99.99 % of the population and thus should be enough for literally any case. Even a simple factory reset from within your ROM seems to dispose of most sensitive data, so this should also serve at least 98 % of all cases.
Beware that this test was performed on a HTC Wildfire S with the (currently) most recent inofficial CyanogenMod 7.2 build from 2012-07-17 installed. Other ROMs may not be as thorough, so take the information from this post only as a guideline. When in doubt, verify the erasure yourself. It's not too hard.
Hello,
I have screwed up my IMEI after some risky operations. I have a backup of EFS partition (folder), which is useless, since it doesn't contain my IMEI, which I haven't checked previously and just dumbly/blindly relied on it containing my IMEI. The big question is, where is IMEI stored on galaxy s4 mini LTE (I9195)? I tried to restore using several methods, like:
EFS Professional Qualcomm Tools, by writing my original IMEI, but it still doesn't do any changes, nor before restart of the phone, nor after.
NV Items Reader/Writer - same result as EFS Qualcomm. Same goes to QPST tools.
Tried reboot nvrestore through adb/console, but i haven't had made backup previously.
I guess it stores it in some other partition. Also, after research done, there have been claims that phone stores backup of nv_data in some partition and automatically restores it if there are differences between backup and real imei. Or phone just restores backup automatically on each phone bootup. Either way, I must've screwed really big, since on my adventures both are wiped and my nulled IMEI seems to be right for the phone.
I include a PIT file.
Seems like I am the only one unlucky in this situation, cause there are no similar topic on this forum or internet altogether concerning EFS and I9195.
.PIT FILE
any1?
well i had a i9000 before. and there was always a efs backup made when you installed cm for example. i screwed my imei also more than once on this phone and restored it by installing an factory image from samsung. i has to be a complete image with all parts for odin i think.
OT: here are less developers around. this phone isn't so much supported as i thought it would be. but i really dont want to buy a 5inch just to have developer support so i hope someone will be able to help you.
x10isrooted said:
well i had a i9000 before. and there was always a efs backup made when you installed cm for example. i screwed my imei also more than once on this phone and restored it by installing an factory image from samsung. i has to be a complete image with all parts for odin i think.
OT: here are less developers around. this phone isn't so much supported as i thought it would be. but i really dont want to buy a 5inch just to have developer support so i hope someone will be able to help you.
Click to expand...
Click to collapse
You are right, it does make a some kind of backup, which manually could be made through adb with command "reboot nvbackup", but my problem is that either I don't have that backup, or it somehow has made a backup of efs after it was corrupted. Somewhere in this forum i saw someone writing that reboot nvbackup command backups efs to fsg and backup partitions, but I through-Hex-checked it, no trace of any content of efs/nvdata.(Or it is encrypted somehow.). Also I did recieved backup and fsg partitions of healthy phone, and checked-through it. Same story.
In despair I stormed every single partition on the phone I could reach. The only partition containing contents of efs (also IMEI) was mmcblk0p24, which stores userdata and mounts on root as /data. I doubt it's legitimacy, since as far as I know, it gets wiped after factory reset, so it couldn't be the place sensitive data are stored. Now I am waiting to receive a healthy phones userdata.img.ext4 partition backup to get memory addresses of IMEI location and to be able to write my IMEI in my userdata.img.ext4 backup. Cross fingers, but doubt this will work.
Also, I didn't check loop# and ram# partitions under /dev/block/. This will be my next step, if writing and restoring userdata fails, which probably will.
farewellartist said:
Hello,
I have screwed up my IMEI after some risky operations. I have a backup of EFS partition (folder), which is useless, since it doesn't contain my IMEI, which I haven't checked previously and just dumbly/blindly relied on it containing my IMEI. The big question is, where is IMEI stored on galaxy s4 mini LTE (I9195)? I tried to restore using several methods, like:
EFS Professional Qualcomm Tools, by writing my original IMEI, but it still doesn't do any changes, nor before restart of the phone, nor after.
NV Items Reader/Writer - same result as EFS Qualcomm. Same goes to QPST tools.
Tried reboot nvrestore through adb/console, but i haven't had made backup previously.
I guess it stores it in some other partition. Also, after research done, there have been claims that phone stores backup of nv_data in some partition and automatically restores it if there are differences between backup and real imei. Or phone just restores backup automatically on each phone bootup. Either way, I must've screwed really big, since on my adventures both are wiped and my nulled IMEI seems to be right for the phone.
I include a PIT file.
Seems like I am the only one unlucky in this situation, cause there are no similar topic on this forum or internet altogether concerning EFS and I9195.
Click to expand...
Click to collapse
You've found the address of IMEI? I also did not find my IMEI in a full backup of EFS partition. I also do not believe that it is in mmcblk0p24, if it were, would lose the IMEI on a factory reset.
Sorry for bad English... :silly:
lrdslr said:
You've found the address of IMEI? I also did not find my IMEI in a full backup of EFS partition. I also do not believe that it is in mmcblk0p24, if it were, would lose the IMEI on a factory reset.
Sorry for bad English... :silly:
Click to expand...
Click to collapse
Yes, I think, that I have found it, but this is difficult. I haven't slept for over 40 hours, I'll convert this thread into research thread after I get some sleep. But for now, short version.
Using Cygwin, i have backed up healthy phones every single partition in .RAW format (which backs up not only files, but every single bit of memory) , including phones whole memory partition (mmcblk0), all 7 loop and 15 ram partitions and then hex checked them. What I've discovered is: that none of partitions contain IMEI nor in HEX or STRING format except mmcblk0p24, which contains 24 entries in my case in STRING format. BUT the whole phone memory block (mmcblk0) contains 60+ entries ..
If we weight information (considering all backups were made in .RAW format) that none of the partitions contain IMEI and IMEI is stored in whole memory block, I think we probably can conclude, that IMEI is not stored in any file on the phones memory. (And this is concluded based on information I got on backing up mmcblk0 using cygwin in .bin format. After hex checking file, it also contained around 24 entries, which is roughtly the same as userdata partition.) It is stored in phones memory not as a file, but as written bits in memory, which are not FRS recognizable.
I only I could restore .RAW format backups, this problem could easilly be solved. Damn, if I mange to solve and fill lacking information bits that spoils a big picture, I won't hesitate to spare one day of my life to actually create a tool to solve this. This has been a long and painful process,
Hi, I know this is an old topic, but I 've got same issue and I'd like to know if someone successed to re-write the IMEI on S4 mini LTE.
Thanks.
Hello,
I've done ROM flashes where instructed to perform full wipes through the recovery menu, or while in the OS. But when selling/getting rid of old Android phones (today, specifically speaking of the Note II i317 AT&T) will it make my personal data unrecoverable by methods I've used in the past to recover accidentally deleted photos/documents?
Basically, I don't want to sell my phone and Joe Blow to be able to recover all (or any) of the private pics/sensitive data of said phone (ie steal/sell my identity). How can I go about securely formatting my phone to make that data unrecoverable, yet without bricking the device?
kintamanate said:
Hello,
I've done ROM flashes where instructed to perform full wipes through the recovery menu, or while in the OS. But when selling/getting rid of old Android phones (today, specifically speaking of the Note II i317 AT&T) will it make my personal data unrecoverable by methods I've used in the past to recover accidentally deleted photos/documents?
Basically, I don't want to sell my phone and Joe Blow to be able to recover all (or any) of the private pics/sensitive data of said phone (ie steal/sell my identity). How can I go about securely formatting my phone to make that data unrecoverable, yet without bricking the device?
Click to expand...
Click to collapse
Well, consider a harddrive. It is possible to recover a lot of files after being wiped, and the wipe from the internal recovery doesn't at all (to my knowledge) remove any internal media (files). If of course the recovery doesn't have a added feature to delete partitions i suppose.
And of course, external third part software can recover the files you once deleted, like this: Enter Youtube > search for recover deleted files android. You will find lots of result of how to recover images as a example.
You would need to find a way to unrecoverably delete the files you don't want to share when you sold it, or you could take advantage of the statistics of the fact that quite many people don't know how to recover files.
http://lifehacker.com/5808280/what-should-i-do-with-my-phone-before-i-sell-it
http://www.webroot.com/us/en/home/r...ation/how-to-wipe-your-device-before-donating
http://www.makeuseof.com/tag/how-to-wipe-history-on-android/
Three good sites above..
One good tip was encrypt phone before wiping...
Hi,
Where can I find an explanation of the Nexus 5X partitions, and which of those are changed during use and are a good idea to back up?
Coming from Nexus 7 3G 2012, I see the 5X has quite a few more partitions. I've searched this site and the wider Internet for their purpose but have come up only with a parted listing without explanation.
E.g. what typically goes into "vendor", why do "system" and "vendor" have "... image" counterparts, and what exactly goes into the crucial "EFS" partition?
Following from that, it seems that an unlocked but otherwise unmodified device can be fully restored from the factory image and a data partition backup (apart from perhaps needing to restore EFS in extreme cases), right?
Or are there other partitions that may get modified during normal use and need to be backed up too?
I've come across one of the answers.
It seems the vendor partition contains the platform-specific drivers/binaries that were previously stored in the /system partition: https://plus.google.com/+JeanBaptisteQueru/posts/akHWypRNEn3.
...and according to this the "... image" selections aren't device partitions, but TWRP options to add fastboot flashable image backups of the corresponding partitions.
fvisagie said:
what exactly goes into the crucial "EFS" partition?
Click to expand...
Click to collapse
Continuing the monologue, although I haven't found a definitive source, most authorative-sounding ones like this one and this one claim it contains device-specific IDs, mostly connectivity, such as IMEI/ESN, Wi-Fi and Bluetooth MAC addresses, network unlock information etc.
fvisagie said:
Following from that, it seems that an unlocked but otherwise unmodified device can be fully restored from the factory image and a data partition backup (apart from perhaps needing to restore EFS in extreme cases), right?
Or are there other partitions that may get modified during normal use and need to be backed up too?
Click to expand...
Click to collapse
I recall from a previous experience that to be completely safe, user data/internal storage (/sdcard) needs to be backed up and restored too. Most Android apps that had been run and had created data on /sdcard before the backup will fail to run if restored without their /sdcard content.
Hello,
I have a friend that accidentally deleted her photos on her LG G4. I don't have a physical access to the phones (she lives far away), but I know this is a H815 on stock Marshmallow, locked bootloader.
While I have some experience in this kind of things, each phone has its particularities... I could:
use DiskDigger, but this requires root access, or
dump the userdata partition (with commands such as dd, cat...), but again, it requires root access.
I'm thinking about rooting the phone while minimizing writing to the userdata, in order to have a minimum loss of deleted pictures.
So I read a few topics on XDA about the LG G4. I saw it's possible to make a full backup in download mode. It it was possible to dump each byte of the partition so I could look for removed pictures, it would be awesome and my probleme would be solved! Or is it only a backup tool (that reads only existing files)? Can someone tell me about this tool?
Another way would be unlocking the bootloader in order to gain root access (for instance via a custom recovery), but it will involve a data wipe I'm afraid I could not recover anything from, if it's a low-level wipe.
I would appreciate any hint
Thanks!
a-m13 said:
Hello,
I have a friend that accidentally deleted her photos on her LG G4. I don't have a physical access to the phones (she lives far away), but I know this is a H815 on stock Marshmallow, locked bootloader.
While I have some experience in this kind of things, each phone has its particularities... I could:
use DiskDigger, but this requires root access, or
dump the userdata partition (with commands such as dd, cat...), but again, it requires root access.
I'm thinking about rooting the phone while minimizing writing to the userdata, in order to have a minimum loss of deleted pictures.
So I read a few topics on XDA about the LG G4. I saw it's possible to make a full backup in download mode. It it was possible to dump each byte of the partition so I could look for removed pictures, it would be awesome and my probleme would be solved! Or is it only a backup tool (that reads only existing files)? Can someone tell me about this tool?
Another way would be unlocking the bootloader in order to gain root access (for instance via a custom recovery), but it will involve a data wipe I'm afraid I could not recover anything from, if it's a low-level wipe.
I would appreciate any hint
Thanks!
Click to expand...
Click to collapse
No root required just check my signature for the DLM backup method
Ensure that you are using the full back-up which also takes care of user data partition
Sent from my LG-H815 using XDA Labs