FORUMS
Remove All Ads from XDA

How can I Create a byte-for-byte image of my Internal Memory (from Recovery or ADB)

17 posts
Thanks Meter: 0
 
By waypoint.delta, Junior Member on 21st March 2017, 01:40 AM
Post Reply Email Thread
I am looking for a way to create a perfect, byte for byte, image of my internal memory so that I can recover data from the image in a safer way and from a copy where I cant destroy the original. I am really just looking to recover files I had under the /sdcard (USERDATA mount) however, since my partitions are messed up, I want to broaden the scope and capture everything. Can anyone point me in the right direction?

Help is greatly appreciated.
 
 
21st March 2017, 02:19 AM |#2  
Misterjunky's Avatar
Senior Member
Flag Bakersfield, California
Thanks Meter: 6,051
 
Donate to Me
More
Thumbs up re: byte for byte
Quote:
Originally Posted by waypoint.delta

I am looking for a way to create a perfect, byte for byte, image of my internal memory so that I can recover data from the image in a safer way and from a copy where I cant destroy the original. I am really just looking to recover files I had under the /sdcard (USERDATA mount) however, since my partitions are messed up, I want to broaden the scope and capture everything. Can anyone point me in the right direction?

Help is greatly appreciated.

You would need to develop or find a developer who knows
how to create a very specific & special application to do that.

At the present time there is no applications that can do it.

You would be way better off to simply copy whatever good
files are in your internal memory to your computer because
any other way would result in many unusable files since
you said that the partition is all messed up.

By creating a byte for byte image of your internal memory
you would simply end up with a lot of unusable files since
your partitions are messed up.

Good luck, have a great day!
21st March 2017, 03:21 AM |#3  
OP Junior Member
Thanks Meter: 0
 
More
Thanks for the response Mr Junky. I can tell you I am fairly determined, short of hopping the NSA fence and demanding justice. Anyways, The partitions only matter so much since they do not define the files, the 1's and 0's do. There's tons of recovery software already, so no need to go that far, just need to get the data off my phone so it can be analysed. Square one is I grabbing a quality snapshot of the Internal Memory and putting it on my PC. At that point I can rebuild my phone without concern.

Quote:
Originally Posted by Misterjunky

. . .

21st March 2017, 04:33 AM |#4  
OP Junior Member
Thanks Meter: 0
 
More
Does anyone know if the partition/sector offsets ever change, or are they static? I ask because I ran "Repair or Change File System" on /data which shares a mount with /sdcard (i think). If they are static, it wont matter that the partition table was rebuilt, the lost data should still reside there. I can simply use DD to capture /dev/block/sda18 to a file. As a side note, I'm really glad i had busybox installed.

Code:
~ # ←[6nbusybox fdisk -l /dev/block/sda
Note: sector size is 4096 (not 512)
Found valid GPT with protective MBR; using GPT
Disk /dev/block/sda: 62464000 sectors, 2336M
Logical sector size: 4096
Disk identifier (GUID): 52444e41-494f-2044-4d4d-43204449534b
Partition table holds up to 128 entries
First usable sector is 6, last usable sector is 7807994

Number  Start (sector)    End (sector)  Size       Code  Name
   1            1024            2047       4096K   0700  BOTA0
   2            2048            3071       4096K   0700  BOTA1
   3            3072            8191       20.0M   0700  EFS
   4            8192           10239       8192K   0700  PARAM
   5           10240           20479       40.0M   0700  BOOT
   6           20480           32255       46.0M   0700  RECOVERY
   7           32256           34303       8192K   0700  OTA
   8           34304           45055       42.0M   0700  RADIO
   9           45056           45311       1024K   0700  TOMBSTONES
  10           45312           45567       1024K   0700  DNT
  11           45568           45759        768K   0700  PERSISTENT
  12           45760           45823        256K   0700  STEADY
  13           45824           48127       9216K   0700  PERSDATA
  14           48128         1148927       4300M   0700  SYSTEM
  15         1148928         1200127        200M   0700  CACHE
  16         1200128         1238527        150M   0700  HIDDEN
  17         1238528         1239807       5120K   0700  CP_DEBUG
  18         1239808         7806719       25.0G   0700  USERDATA
~ # ←[6n
C:\adb>

C:\adb>adb shell
/dev/block/platform/155a0000.ufs/by-name # ?[6nls -l
__bionic_open_tzdata: couldn't find any tzdata when looking for localtime!
__bionic_open_tzdata: couldn't find any tzdata when looking for GMT!
__bionic_open_tzdata: couldn't find any tzdata when looking for posixrules!
lrwxrwxrwx    1 root     root            15 Jan  2 12:45 BOOT -> /dev/block/sda5
lrwxrwxrwx    1 root     root            15 Jan  2 12:45 BOTA0 -> /dev/block/sda1
lrwxrwxrwx    1 root     root            15 Jan  2 12:45 BOTA1 -> /dev/block/sda2
lrwxrwxrwx    1 root     root            16 Jan  2 12:45 CACHE -> /dev/block/sda15
lrwxrwxrwx    1 root     root            15 Jan  2 12:45 CPEFS -> /dev/block/sdd1
lrwxrwxrwx    1 root     root            16 Jan  2 12:45 CP_DEBUG -> /dev/block/sda17
lrwxrwxrwx    1 root     root            16 Jan  2 12:45 DNT -> /dev/block/sda10
lrwxrwxrwx    1 root     root            15 Jan  2 12:45 EFS -> /dev/block/sda3
lrwxrwxrwx    1 root     root            16 Jan  2 12:45 HIDDEN -> /dev/block/sda16
lrwxrwxrwx    1 root     root            15 Jan  2 12:45 OTA -> /dev/block/sda7
lrwxrwxrwx    1 root     root            15 Jan  2 12:45 PARAM -> /dev/block/sda4
lrwxrwxrwx    1 root     root            16 Jan  2 12:45 PERSDATA -> /dev/block/sda13
lrwxrwxrwx    1 root     root            16 Jan  2 12:45 PERSISTENT -> /dev/block/sda11
lrwxrwxrwx    1 root     root            15 Jan  2 12:45 RADIO -> /dev/block/sda8
lrwxrwxrwx    1 root     root            15 Jan  2 12:45 RECOVERY -> /dev/block/sda6
lrwxrwxrwx    1 root     root            16 Jan  2 12:45 STEADY -> /dev/block/sda12
lrwxrwxrwx    1 root     root            16 Jan  2 12:45 SYSTEM -> /dev/block/sda14
lrwxrwxrwx    1 root     root            15 Jan  2 12:45 TOMBSTONES -> /dev/block/sda9
lrwxrwxrwx    1 root     root            16 Jan  2 12:45 USERDATA -> /dev/block/sda18
/dev/block/platform/155a0000.ufs/by-name # ?[6n
23rd March 2017, 01:41 AM |#5  
OP Junior Member
Thanks Meter: 0
 
More
I created the dd image of the USERDATA partition and saved it to the external SD card using the following command

Code:
dd if=/dev/block/sda18 of=/external_sd/dev/block/sda18.dd bs=4096
I then ran it against photorec which only returned 2 elf files. I will run it against testdisk as well, but I'm thinking either the data is gone or I did not use DD correctly.
23rd March 2017, 01:56 AM |#6  
OP Junior Member
Thanks Meter: 0
 
More
In TWRP, when you go to "Wipe" -> "Advanced Wipe" you see a list of partitions, among them are "Data" and "Internal Storage". I wiped the "Data" partition as I thought "Internal Storage" would be untouched (since it was listed seperatly). Nope. Apparently they map to the exact same partition
Code:
/dev/block/sda18 on /data type ext4 (rw,seclabel,relatime,data=ordered)
/dev/block/sda18 on /sdcard type ext4 (rw,seclabel,relatime,data=ordered)
I used "Change File System" on "Data" in order to make it usable again, I must have destroyed all the data I was trying to recover. Had I build the image before I fixed the data partition, I would probably have recovered most everything.

Thanks go out to Samsung for enabling auto update by default and for thoroughly testing the update which blew up my phone! Great job guys : )
23rd March 2017, 02:12 AM |#7  
toastido's Avatar
Senior Member
Flag Huntsville, AL
Thanks Meter: 1,233
 
Donate to Me
More
Quote:
Originally Posted by waypoint.delta

I am looking for a way to create a perfect, byte for byte, image of my internal memory so that I can recover data from the image in a safer way and from a copy where I cant destroy the original. I am really just looking to recover files I had under the /sdcard (USERDATA mount) however, since my partitions are messed up, I want to broaden the scope and capture everything. Can anyone point me in the right direction?

Help is greatly appreciated.

You need to use photorec directly on the block device, not a copy. Copies don't copy detached inodes, even with dd.

Sent from my SM-G935T using Tapatalk
24th March 2017, 01:29 AM |#8  
OP Junior Member
Thanks Meter: 0
 
More
Everything I've read online negates that statement. however, I've yet to recover anything from the images I've copied, but I believe it may be due to hardware error. As a test, I put an photo on my /system mount and deleted the image. then I cloned the system block device and attempted recovery using photorec. this test failed to recover the file. so either DD is not copying the raw bytes or I am doing something incorrectly. I will try the same test using scalpel and also on another android phone.

Quote:
Originally Posted by toastido

You need to use photorec directly on the block device, not a copy. Copies don't copy detached inodes, even with dd.

Sent from my SM-G935T using Tapatalk

Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes