Fórum Root.cz
Hlavní témata => Windows a jiné systémy => Téma založeno: David1234 12. 11. 2017, 15:41:42
-
Ahoj, pokouším se obnovit jedno smazané video z mého telefonu Samsung A3. Video bylo natočeno kamerou telefonu. Našel jsem poměrně hezký postup na https://roubert.name/joakim/androidfilerecovery/ a rozhodl se postupovat podle něho.
Získal jsem na telefonu přístup na root uživatele a provedl kopii interní paměti k sobě do notebooku pomocí adb:
adb shell su -c "dd if=/dev/block/mmcblk0" | pv > mmcblk0.raw
Soubor má velikost cca 15GB a příkaz file prozradí následující:
david@nb:~$ file mmcblk0.raw
mmcblk0.raw: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,254,63), startsector 1, 30881362 sectors, extended partition table (last)
Postoupit dále podle odkazovaného návodu se mi ale už nepovedlo - nedaří se mi udělat recover partition table. Zkoušel jsem také vytáhnout a připojit pouze jednu konkrétní partition mmcblk0p27, ale tu se mi také nepovedlo připojit:
david@nb:~$ sudo mount -t ext4 -o loop,ro 27.a3.raw /mnt/
mount: mount /dev/loop4 on /mnt failed: Structure needs cleaning
david@nb:~$ dmesg | tail
[71699.554738] EXT4-fs (loop4): ext4_check_descriptors: Checksum for group 0 failed (10591!=12032)
[71699.554741] EXT4-fs (loop4): ext4_check_descriptors: Checksum for group 1 failed (19990!=37888)
[71699.554744] EXT4-fs (loop4): ext4_check_descriptors: Checksum for group 2 failed (41016!=60672)
[71699.554746] EXT4-fs (loop4): ext4_check_descriptors: Checksum for group 3 failed (19401!=64256)
[71699.554749] EXT4-fs (loop4): ext4_check_descriptors: Checksum for group 4 failed (36542!=52224)
[71699.554751] EXT4-fs (loop4): ext4_check_descriptors: Checksum for group 5 failed (24744!=56832)
[71699.554753] EXT4-fs (loop4): ext4_check_descriptors: Checksum for group 6 failed (16095!=30208)
[71699.554755] EXT4-fs (loop4): ext4_check_descriptors: Checksum for group 7 failed (55691!=44032)
[71699.554756] EXT4-fs (loop4): ext4_check_descriptors: Inode table for group 8 not in group (block 135921664)!
[71699.554757] EXT4-fs (loop4): group descriptors corrupted!
Zkoušel na tu jednu partition také pustit fsck.ext4, ale bohužel ani po tom nelze připojit souborový systém. Poradíte mi prosím co dělám špatně? Nebo pokud znáte jiný a spolehlivý způsob jak provést obnovu tak sem s ním, budu moc vděčný.
Zde je výpis příkazu mount z telefonu:
shell@a3ulte:/ $ mount
rootfs / rootfs ro,seclabel,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,relatime,size=698708k,nr_inodes=152746,mode=755 0 0
devpts /dev/pts devpts rw,seclabel,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,seclabel,relatime 0 0
selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
none /sys/fs/cgroup tmpfs rw,seclabel,relatime,size=698708k,nr_inodes=152746,mode=750,gid=1000 0 0
tmpfs /mnt tmpfs rw,seclabel,relatime,size=698708k,nr_inodes=152746,mode=755,gid=1000 0 0
tmpfs /mnt/secure tmpfs rw,seclabel,relatime,size=698708k,nr_inodes=152746,mode=700 0 0
tmpfs /mnt/secure/asec tmpfs rw,seclabel,relatime,size=698708k,nr_inodes=152746,mode=700 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
adb /dev/usb-ffs/adb functionfs rw,relatime 0 0
/dev/block/bootdevice/by-name/system /system ext4 ro,seclabel,noatime,block_validity,norecovery 0 0
/dev/block/bootdevice/by-name/userdata /data ext4 rw,seclabel,nosuid,nodev,noatime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,data=ordered 0 0
/dev/block/bootdevice/by-name/efs /efs ext4 rw,seclabel,nosuid,nodev,noatime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,data=ordered 0 0
/dev/block/bootdevice/by-name/cache /cache ext4 rw,seclabel,nosuid,nodev,noatime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,errors=panic,data=ordered 0 0
/dev/block/bootdevice/by-name/persist /persist ext4 rw,seclabel,nosuid,nodev,noatime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,data=ordered 0 0
/dev/block/bootdevice/by-name/apnhlos /firmware vfat ro,context=u:object_r:firmware_file:s0,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=437,iocharset=iso8859-1,shortname=lower,errors=remount-ro 0 0
/dev/block/bootdevice/by-name/modem /firmware-modem vfat ro,context=u:object_r:firmware_file:s0,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=437,iocharset=iso8859-1,shortname=lower,errors=remount-ro 0 0
/dev/block/bootdevice/by-name/persdata /persdata/absolute ext4 rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0
tmpfs /storage tmpfs rw,seclabel,relatime,size=698708k,nr_inodes=152746,mode=755,gid=1000 0 0
/dev/block/loop0 /su ext4 rw,seclabel,noatime,data=ordered 0 0
/data/knox/tmp_sdcard /mnt/knox sdcardfs rw,seclabel,nosuid,nodev,relatime,mask=0077 0 0
/data/knox/sdcard /mnt/knox/default/knox-emulated sdcardfs rw,seclabel,nosuid,nodev,relatime,low_uid=1000,low_gid=1000,gid=1015,multi_user,mask=0006 0 0
/data/knox/sdcard /mnt/knox/read/knox-emulated sdcardfs rw,seclabel,nosuid,nodev,relatime,low_uid=1000,low_gid=1000,gid=9997,multi_user,mask=0027 0 0
/data/knox/sdcard /mnt/knox/write/knox-emulated sdcardfs rw,seclabel,nosuid,nodev,relatime,low_uid=1000,low_gid=1000,gid=9997,multi_user,mask=0007 0 0
/data/media /mnt/runtime/default/emulated sdcardfs rw,seclabel,nosuid,nodev,noexec,relatime,low_uid=1023,low_gid=1023,gid=1015,multi_user,mask=0006,reserved=20MB 0 0
/data/media /storage/emulated sdcardfs rw,seclabel,nosuid,nodev,noexec,relatime,low_uid=1023,low_gid=1023,gid=1015,multi_user,mask=0006,reserved=20MB 0 0
/data/media /mnt/runtime/read/emulated sdcardfs rw,seclabel,nosuid,nodev,noexec,relatime,low_uid=1023,low_gid=1023,gid=9997,multi_user,mask=0027,reserved=20MB 0 0
/data/media /mnt/runtime/write/emulated sdcardfs rw,seclabel,nosuid,nodev,noexec,relatime,low_uid=1023,low_gid=1023,gid=9997,multi_user,mask=0007,reserved=20MB 0 0
Předem všem moc děkuji za reakce.
-
Takže jsi získal obraz té paměti? V tom případě bych na něj poštval photorec, ten z toho vyždíme všechno co tam ještě zůstalo a dá se to aspoň trochu rozpoznat.
-
Ano, ten obraz jsem získal a photorec jsem vyzkoušel ale buď dělám něco špatně nebo to nefunguje tak jak má. Vím že tam jsou totiž i nesmazaná videa které by to mělo bez problémů obnovit - ale místo videí mi vypadlo cca 5 mov souborů o nesmyslné velikosti, které nejdou ničím přehrát.
Tušíte někdo kde dělám chybu?
-
Nedaří se mi ani obnovit žádné fotografie z telefonu.. photorec nic nenajde, netuším čím to může být. Klidně bych šel nějakou jinou cestou ale kromě placených pochybně fungujících aplikací jsem žádné postupy nenašel.
-
Zdravím, vyzkoušejte ještě ddrescue http://wiki.ubuntu.cz/ddrescue. Pokud photorec nic nenajde, tak bych tipoval na špatně vytvořený img.
-
Díky za reakci. To bych mohl vyzkoušet pokud do telefonu dostanu ddrescue. Zkoušel jsem obraz udělat i pomocí:
adb shell su -c "cat /dev/block/mmcblk0" | pv > mmcblk0.raw
Obraz se vytvořil, měl správnou velikost a trvalo to skoro hodinu. Ale photorec zase nic.
-
Moc díky za hint. Ten obraz byl podle všeho opravdu špatný. Pomohlo vytvoření nového obrazu pomocí postupu https://lifeinarootshell.blogspot.cz/2013/10/disaster-recovery-on-android-phones.html. Nyní se pouštím do obnovy.
-
Tak jsem úspěšně zapsal partition table. Následně jsem se dal do prohlížení dat co tam jsou - našel jsem složku kde bylo ono video, její výpis je níže.
TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
8 P MS Data 6266880 30777271 24510392
Directory /media/0/DCIM/Camera
Previous
-rw-rw-r-- 1023 1023 1593320 13-Oct-2017 08:31 20171013_083102.jpg
-rw-rw-r-- 1023 1023 4065733 15-Oct-2017 15:20 20171015_152039.jpg
-rw-rw-r-- 1023 1023 4293201 15-Oct-2017 15:20 20171015_152041.jpg
-rw-rw-r-- 1023 1023 1222836 15-Oct-2017 15:21 20171015_152112.jpg
-rw-rw-r-- 1023 1023 1198620 15-Oct-2017 15:21 20171015_152114.jpg
-rw-rw-r-- 1023 1023 1538335 15-Oct-2017 15:21 20171015_152117.jpg
-rw-rw-r-- 1023 1023 1232815 15-Oct-2017 15:21 20171015_152119.jpg
-rw-rw-r-- 1023 1023 1422173 16-Oct-2017 12:21 20171016_122150.jpg
-rw-rw-r-- 1023 1023 1927506 16-Oct-2017 12:25 20171016_122544.jpg
-rw-rw-r-- 1023 1023 1905939 16-Oct-2017 12:25 20171016_122545.jpg
-rw-rw-r-- 1023 1023 75033366 16-Oct-2017 14:30 20171016_143008.mp4
-rw-rw-r-- 1023 1023 808585 16-Oct-2017 14:31 20171016_143136.jpg
-rw-rw-r-- 1023 1023 1452571 16-Oct-2017 17:20 20171016_172035.jpg
-rw-rw-r-- 1023 1023 1423925 16-Oct-2017 17:20 20171016_172040.jpg
-rw-rw-r-- 1023 1023 1620860 19-Oct-2017 16:53 20171019_165337.jpg
-rw-rw-r-- 1023 1023 1648172 19-Oct-2017 16:53 20171019_165347.jpg
-rw-rw-r-- 1023 1023 1820898 19-Oct-2017 16:53 20171019_165349.jpg
-rw-rw-r-- 1023 1023 2088315 19-Oct-2017 16:53 20171019_165359.jpg
-rw-rw-r-- 1023 1023 2033740 19-Oct-2017 16:54 20171019_165442.jpg
-rw-rw-r-- 1023 1023 1710711 19-Oct-2017 16:54 20171019_165447.jpg
-rw-rw-r-- 1023 1023 1718046 19-Oct-2017 16:54 20171019_165449.jpg
-rw-rw-r-- 1023 1023 1362798 19-Oct-2017 16:54 20171019_165452.jpg
-rw-rw-r-- 1023 1023 1658483 19-Oct-2017 16:54 20171019_165454.jpg
-rw-rw-r-- 1023 1023 1720232 19-Oct-2017 16:55 20171019_165500.jpg
-rw-rw-r-- 1023 1023 1464693 27-Oct-2017 14:53 20171027_145319.jpg
-rw-rw-r-- 1023 1023 1890746 27-Oct-2017 14:53 20171027_145320.jpg
-rw-rw-r-- 1023 1023 1936260 4-Nov-2017 20:03 20171104_200333.jpg
-rw-rw-r-- 1023 1023 2012676 4-Nov-2017 20:03 20171104_200336.jpg
-rw-rw-r-- 1023 1023 2030174 4-Nov-2017 20:03 20171104_200342.jpg
-rw-rw-r-- 1023 1023 1959986 4-Nov-2017 20:03 20171104_200355.jpg
-rw-rw-r-- 1023 1023 2156057 4-Nov-2017 20:03 20171104_200358.jpg
-rw-rw-r-- 1023 1023 1898268 4-Nov-2017 20:04 20171104_200404.jpg
-rw-rw-r-- 1023 1023 2035605 4-Nov-2017 20:04 20171104_200406.jpg
-rw-rw-r-- 1023 1023 2137340 4-Nov-2017 20:04 20171104_200452.jpg
-rw-rw-r-- 1023 1023 1702194 4-Nov-2017 20:04 20171104_200454.jpg
-rw-rw-r-- 1023 1023 1559075 4-Nov-2017 20:04 20171104_200458.jpg
-rw-rw-r-- 1023 1023 2033958 4-Nov-2017 20:05 20171104_200503.jpg
-rw-rw-r-- 1023 1023 2160609 4-Nov-2017 20:05 20171104_200505.jpg
-rw-rw-r-- 1023 1023 2136191 4-Nov-2017 20:05 20171104_200511.jpg
-rw-rw-r-- 1023 1023 1606762 11-Nov-2017 10:35 20171111_103553.jpg
-rw-rw-r-- 1023 1023 1670128 11-Nov-2017 10:35 20171111_103554.jpg
-rw-rw-r-- 1023 1023 1747815 11-Nov-2017 10:35 20171111_103556.jpg
-rw------- 1000 1000 8760 11-Nov-2017 17:13 20171111_142031.jpg
-rw------- 1000 1000 2845 11-Nov-2017 17:35 20171111_142031(0).jpg
-rw------- 1000 1000 2865 11-Nov-2017 19:25 20171111_142033.jpg
>drwxrwx--x 1000 1012 4096 11-Nov-2017 17:37 20171111_144235.mp4
Next
Use Left arrow to go back, Right to change directory, h to hide deleted files
q to quit, : to select the current file, a to select all files
C to copy the selected files, c to copy the current file
Tyto čtyři soubory dole jsou tam označené červeně - myslím že to znamená že jsou smazané:
-rw------- 1000 1000 8760 11-Nov-2017 17:13 20171111_142031.jpg
-rw------- 1000 1000 2845 11-Nov-2017 17:35 20171111_142031(0).jpg
-rw------- 1000 1000 2865 11-Nov-2017 19:25 20171111_142033.jpg
>drwxrwx--x 1000 1012 4096 11-Nov-2017 17:37 20171111_144235.mp4
Zkusil jsem je obnovit ale ani videa ani fotky nezle obnovit - obnoví se soubor který má sice nějakou velikost ale nelze ho přehrát jako video. Mám to brát tak že je tam na ně nějaká reference, ale data jsou už nenávratně pryč?
-
Jinak nesmazané soubory z toho samozřejmě vytáhnu bez problémů ...
-
Tyto čtyři soubory dole jsou tam označené červeně - myslím že to znamená že jsou smazané:
-rw------- 1000 1000 8760 11-Nov-2017 17:13 20171111_142031.jpg
-rw------- 1000 1000 2845 11-Nov-2017 17:35 20171111_142031(0).jpg
-rw------- 1000 1000 2865 11-Nov-2017 19:25 20171111_142033.jpg
>drwxrwx--x 1000 1012 4096 11-Nov-2017 17:37 20171111_144235.mp4
Zkusil jsem je obnovit ale ani videa ani fotky nezle obnovit - obnoví se soubor který má sice nějakou velikost ale nelze ho přehrát jako video. Mám to brát tak že je tam na ně nějaká reference, ale data jsou už nenávratně pryč?
Poslední řádek není soubor, ale adresář.
-
Dobrá připomínka - to jsem také zjistil, ale je to divné - můj telefon pojmenovává právě takhle videa a seděl by i čas (hledám video z 11.11.2017 čas 14:xx). Má to nějaké jednoduché vysvětlení? :)
-
Má to nějaké jednoduché vysvětlení? :)
Dokurveny FS. Asi se mezitim nekam neco zapsalo.
-
Dobrá připomínka - to jsem také zjistil, ale je to divné - můj telefon pojmenovává právě takhle videa a seděl by i čas (hledám video z 11.11.2017 čas 14:xx). Má to nějaké jednoduché vysvětlení? :)
Těžko říct bez znalosti typu filesystému (na Androidu jich může být více typů), ale obecně třeba FAT32 a EXT4 podle mých neúplných znalostí určují, zda je uvedený soubor adresářem podle jednoho příznakového bitu. Takže se pravděpodobně při nějaké kolizi nebo porušení paměti přepsal příznakový bit a Váš film se právě stal adresářem. :-)
U FAT32 je pro ilustraci popis atributů následující, pro podrobnější info si vygooglete FAT32 specifikaci. EXT3/EXT4 je, co si tak vybavuji, poněkud složitější, takže bych se mrknul nejdříve na ten FAT32, v téhle konkrétní oblasti ten princip bude velice pravděpodobně analogický.
ATTR_READ_ONLY (0x01)
The file cannot be modified – all modification
requests must fail with an appropriate error
code value.
ATTR_HIDDEN (0x02)
The corresponding file or sub-directory must
not be listed unless a request is issued by the
user/application explicitly requesting inclusion
of “hidden files”.
ATTR_SYSTEM (0x04)
The corresponding file is tagged as a
component of the operating system. It must not
be listed unless a request is issued by the
user/application explicitly requesting inclusion
of “system files”.
ATTR_VOLUME_ID (0x08)
The corresponding entry contains the volume
label. DIR_FstClusHI and DIR_FstClusLO
must always be 0 for the corresponding entry
(representing the volume label) since no
clusters can be allocated for this entry.
Only the root directory (see Section 6.x below)
can contain one entry with this attribute. No
sub-directory must contain an entry of this type.
Entries representing long file names (see
Section 7) are exceptions to these rules.
ATTR_DIRECTORY (0x10)
The corresponding entry represents a directory
(a child or sub-directory to the containing
directory).
DIR_FileSize for the corresponding entry
must always be 0 (even though clusters may
have been allocated for the directory).
ATTR_ARCHIVE (0x20)
This attribute must be set when the file is
created, renamed, or modified. The presence
of this attribute indicates that properties of the
associated file have been modified.
Backup utilities can utilize this information to
determine the set of files that need to be
backed up to ensure protection in case of
media and other failure conditions.
-
Podle původního příspěvku vidím, že je tam EXT4, je to ta změna příznakového bitu. Ostatně můžete si Váš obraz disku pro zajímavost prohlédnout např. příkazem xxd a podívat se s pomocí dokumentace EXT4, jak daný soubor vypadá.