[General Questions and Answers] Meowstic:
Hi all,

I'm going to make a long story short and say that my brother's phone has a cracked screen, so I tried to use TWRP to backup everything through ADB. But googling SM-J530F TWRP brings 'j5lte' as one of the first results, I went and flashed it under the wrong assumption that j5lte was SM-J530F's code name (it was not) and that caused severe bootloops.

I flashed correct TWRP, but USERDATA would not mount. I panicked and the crystal bleeding was progressing fast, so I pulled the entire mmcblk0 to dump a raw image of the phone's NAND.

This was the right move, as the phone is completely dead now. Crystal bleeding has made the screen completely dead, but the phone still works.

All I'm left with is the raw NAND backup.

The first thing I did was inspect the image with fdisk. It can recognize the GPT partition table and structure. The USERDATA partition is at the very end.

View attachment 5401009

GDISK is also recognizing it no problem. It seems like the partition table is in good condition:View attachment 5401015

GPARTED is also recognizing partitions, but it does not look good:

View attachment 5401019

Looking at more information:

View attachment 5401021

For the record, e2fsprogs is installed. It's always installed by default. GPARTED here is complaining about the superblock, but I can see that its looking to open the partition through /dev/loop0p24 which is no good. The kpartx tool is giving me access to all the partitions of the image through /dev/mapper/loop0p24, so that explains the errors.

Superblocks seem to be present in USERDATA:

View attachment 5401025

I tried mounting the partition with a backup superblock, but...

View attachment 5401027

I was at a loss at this point, so I tried mounting the SYSTEM partition just to see what happens and... it worked?

View attachment 5401041

This proves what I said: This partition is fine, GPARTED was complaining simply because its trying to target them through the wrong device path.

But this raised the question: What the heck is wrong with the USERDATA partition? Why is it ext2 (Isn't that SUPER old?) and could it be that its not corrupted at all, and I'm just trying to mount it the wrong way or something? TWRP couldn't mount it though (Why?).

Being at a loss, I tried repairing the ext2 USERDATA partition using `fsck.ext2 /dev/mapper/loop0p24` and it found so many errors (including a corrupted journal) the file I redirected stdout to (console output) ended up being 78MB. Here it is if you want it (obviously can't post here).

So anybody knows what I can do? Is there any hope? I'm positive that the recovery image couldn't have corrupted the USERDATA partition (How could it? I still can't find a possible explanation). And even if it did, it couldn't overwrite the files. The file data should STILL be in that partition completely in-tact (There's NO WAY the recovery image overwrote them) though the journal is gone, so I can't use a tool like extundelete to recover them.

I tried to flash the phone with a stock rom through download mode to reconstruct everything with a healthy structure. This was so I could flash TWRP again and pull another NAND raw dump to have as a healthy reference I could use, but this doesn't work. Odin fails and I don't know why because the screen on the phone is dead.

Is there some place where I could get this maybe?

Is there something you can suggest I do?

Thanks!