read data is full of bit flips, dying NAND or software issue? #598
Comments
|
What loader did you use? |
None, the device is unlocked and not protected in any way so I didn't think it would be needed. Device uses a MSM8916 so if you have recommendations to try feel free to let me know.
What command would it be? I'd be happy to give it a try and report back but I'm unsure what I would need to execute Thanks in advance! |
|
Well, I have no idea what it's doing then. Try explicitly using one of these: https://github.com/bkerler/Loaders/tree/main/qualcomm/factory/msm8916 https://github.com/bkerler/Loaders/tree/main/qualcomm/model_generic/msm8916 |
Obviously power cycling the device between each loader. Any other ideas? Could this be something going wrong on protocol level? |
|
Ok, all the loaders that are in MSM8916 are too old to have the CSD data. The loaders for MSM8996 are compatible with the MSM8916. There are three loaders. Try them with verbose or logs or something. Look for |
|
All of the three loaders react the same: Log for loader + printgpt looks as follows (without posting python code traces, as it seems irrelevant and noise for this use case): |
|
That's just the regular Sahara stuff. I'm looking for the Firehose legible stuff when you try to read some sectors. It should in plain English, err XML say: And through a sleight of hand we get: |
|
Sorry, my mistake. All the 8996 are 64 bit ELFs. The 8916 is 32 bit. At least this EDL client gives you helpful and pertinent error message, "Cannot receive specified number of program headers". ??? Your device is cc3153 and not Secure Boot so many loaders could work. You're in luck. There appears to be only 5 loaders that are 32 bit, support MSM8916, support eMMC_RAW_DATA. |
Both don't complete the loader upload process The others do, but all get stuck after this packet: After this the only thing returned are Timeouts Thanks for your help again, it's much appreciated. My next step might be to just desolder the NAND and read it out directly at this point.. |
Hi,
I'm trying to recover data from a bricked Wiko Pulp 4G, but although I get no errors dumping the userdata partition, the data is severely corrupted. And not just that, they are bit flips on single bit level that will change if you read the sector a couple of times.
What is going on here? Is the NAND (eMMC) just absolutely cooked, or is there something else going on?
For example
If we look at a single sector a few times:
Try 1:
Try 2:
Try 3:
Unfortunately a lot of the bit flips are more often wrong than right, which means I can't just "resolve" this by reading the partition 3 or 7 times, and write some tool that compares all files and favours the bits that were returned the most often.
A good example is "Glusen bij de Buren" (at 0000001d0). I've seen this as "GlUren bij de Buren" or "Gluren cij de Buren" as well, but out of my 7 attempts the bit flips were way more common than the correct "Gluren bij de Buren", which I've only seen once or twice.
If this is something going wrong on protocol or communication level, I might be able to recover some data, but if the NAND is just wrong this often I don't think I can really recover anything for this family member. Strings you could technically maybe recover with a dictionary, but it's JPEG's I'm after which means it's no use..
Anyways help is appreciated!
The text was updated successfully, but these errors were encountered: