Hello Vincent,
J'arrive sur le sujet un peu après la bataille.
Tu veut copier ta carte interne ailleurs afin d'utiliser photorec, tu as un émulateur de terminal et un téléphone rooté ? Tu peut effectivement écraser ta sd non formaté avec un dd mais tu ne pourra le faire que pour un dd. ( parce que dd va repartir du début de la sd a chaque fois ) Si tu la formates et que android la monte rien ne t'empêche de faire un dd vers un fichier iso sur ta sd montée et récupérer sur ton linux cette ( ou ces iso ) de partition afin de les traiter ( voir le formatage réel et les diverses options qui pourrais être mise sur les partitions android ). Du coup tu pourra avoir des iso de toutes les partitions et pseudo partitions de ton android et chercher partout tes données ( dés fois qu'ils les planquent mais vu que c'est un téléphone rooté il est peut-être moins farfelu qu'un android totalement propriétaire. )
Patrick. De : "Vincent" A : linux06@lists.linux-azur.org Envoyé: mercredi 19 Janvier 2022 11:33 Objet : [HELP] deboires sous Android -> monter une SD card en ext4 Re,
en fait, ayant un émulateur terminal sur ce téléphone, il ne reste 'plus' qu'à monter une micro SD card en ext4 et faire un dd dessus...
Ce qui suppose de créer un point de montage hors /data le temps de faire un dd...
Mais peut-être me fais-je des noeuds au cerveau, et que je peux simplement écraser le contenu de la SD card (non formatée pour que Android ne la monte pas) avec un dd? Question subsidiaire, commen tla voir alors (pas de lsblk de mémoire sur adb et je ne crois pas non plus sous termux)
Merci, Vincent.
Le 19/01/2022 à 11:00, Vincent a écrit :
Bonjour Christophe,
J'ai quand même bien tenté une APK toxique (qui t'impose des pub), mais en fait, comme souvent, c'est bidon : il te retrouve les photos égarées et éventuellement fait une récupération sur les partitions vfat. Cela a été une pure perte de temps, surtout que c'est une boite noire dont il m'a fallu essayer de surveiller les actions, notamment en basculant en mode avion...
Pour ton lien, outre que c'est complexe, cela s'adresse aux données sur la carte SD, pas sur la mémoire interne en ext4.
Je regarde pour activer le support UMS et ainsi pouvoir monter en Read-Only la partition /data, ce qui serait nettement plus simple pour faire un dd...
qui est cité dans :
Je crois qu'il va me falloir faire le deuil, d'autant que j'ai besoin de rallumer mon téléphone, et qu'à chaque fois que je le fais, je perds un peu plus mes chances de récupération.
Bon, cela m'apprendra à laisser traîner les choses : je n'ai toujours pas mis en place un vrai système d'archivage.
Vincent.
Le 19/01/2022 à 10:38, CgX (Christophe) a écrit :
Bonjour, je ne saurais non plus répondre à ton problème.
Il semble exister des applications permettant de récupérer les fichiers effacés, mais ils sont sur le "play store" ce qui n'est pas acceptable selon tes/mes critères :)
Sinon, y'a un type qui s'est amusé à compiler ddrescue pour android, mais c'est du haut-vol : https://ncrmnt.org/2017/05/12/data-recovery-sd-ddrescue-and-android/
-- Christophe
Le 19/01/2022 à 09:51, Vincent a écrit :
Bonjour,
mon message ne semble pas avoir franchi le filtre anti-spam...
Même si je prends toute piste, ma question est surtout : comment monter sous Android un carte SD temporaire en ext4? Pour pouvoir faire une image complète de 25 Go avec une commande dd.
Merci, Vincent
-------- Message transféré -------- Sujet : [HELP] deboires sous Android Date : Wed, 19 Jan 2022 01:39:52 +0100 Pour : Liste principale de Linux Azur
Bonsoir,
ce soir, en mode boulet distrait, j'ai voulu nettoyer ma galerie photos... et j'ai en fait supprimé un dossier complet!!! Du coup, je me prends la tête pour retrouver où sont elles planquées...
Pas de corbeille visiblement dans cette application - c'est balot.
Le téléphone est rooté, j'ai un accès complet via adb shell
Je m'apprête à remplacer la carte micro SD par une plus grosse et vierge et faire un dd de la partition qui va bien pour ensuite la monter sur mon PC et lancer un photorec...
Question : c'est quoi donc que la partition qui va bien?
C'est de l'android 6.0.1, et :
ls -al /dev/block/platform/msm_sdcc.1/by-name/ < lrwxrwxrwx root root 1970-01-20 08:57 DDR -> /dev/block/mmcblk0p4 lrwxrwxrwx root root 1970-01-20 08:57 aboot -> /dev/block/mmcblk0p5 lrwxrwxrwx root root 1970-01-20 08:57 boot -> /dev/block/mmcblk0p8 lrwxrwxrwx root root 1970-01-20 08:57 cache -> /dev/block/mmcblk0p15 lrwxrwxrwx root root 1970-01-20 08:57 dbi -> /dev/block/mmcblk0p3 lrwxrwxrwx root root 1970-01-20 08:57 fsc -> /dev/block/mmcblk0p18 lrwxrwxrwx root root 1970-01-20 08:57 fsg -> /dev/block/mmcblk0p17 lrwxrwxrwx root root 1970-01-20 08:57 modem -> /dev/block/mmcblk0p1 lrwxrwxrwx root root 1970-01-20 08:57 modemst1 -> /dev/block/mmcblk0p11 lrwxrwxrwx root root 1970-01-20 08:57 modemst2 -> /dev/block/mmcblk0p12 lrwxrwxrwx root root 1970-01-20 08:57 pad -> /dev/block/mmcblk0p10 lrwxrwxrwx root root 1970-01-20 08:57 persist -> /dev/block/mmcblk0p14 lrwxrwxrwx root root 1970-01-20 08:57 recovery -> /dev/block/mmcblk0p16 lrwxrwxrwx root root 1970-01-20 08:57 rpm -> /dev/block/mmcblk0p7 lrwxrwxrwx root root 1970-01-20 08:57 sbl1 -> /dev/block/mmcblk0p2 lrwxrwxrwx root root 1970-01-20 08:57 splash -> /dev/block/mmcblk0p6 lrwxrwxrwx root root 1970-01-20 08:57 ssd -> /dev/block/mmcblk0p19 lrwxrwxrwx root root 1970-01-20 08:57 system -> /dev/block/mmcblk0p13 lrwxrwxrwx root root 1970-01-20 08:57 tz -> /dev/block/mmcblk0p9 lrwxrwxrwx root root 1970-01-20 08:57 userdata -> /dev/block/mmcblk0p20
comme : mount | grep block /dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,seclabel,relatime,discard,data=ordered 0 0 /dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 rw,seclabel,nosuid,nodev,relatime,discard,noauto_da_alloc,data=ordered 0 0 /dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0 /dev/block/platform/msm_sdcc.1/by-name/persist /persist ext4 rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0 /dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat ro,context=u:object_r:firmware_file:s0,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=cp437,iocharset=iso8859-1,shortname=lower,errors=remount-ro 0 0 /dev/block/vold/public:179,65 /mnt/media_rw/70C9-1D12 vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
et : df Filesystem Size Used Free Blksize /dev 923.1M 96.0K 923.0M 4096 /sys/fs/cgroup 923.1M 12.0K 923.1M 4096 /mnt 923.1M 0.0K 923.1M 4096 /system 2.0G 503.8M 1.5G 4096 /data 25.0G 9.5G 15.5G 4096 /cache 629.5M 10.0M 619.5M 4096 /persist 4.9M 4.8M 92.0K 4096 /firmware 64.0M 56.2M 7.8M 16384 /storage 923.1M 0.0K 923.1M 4096 /mnt/runtime/default/emulated 25.0G 9.5G 15.5G 4096 /storage/emulated 25.0G 9.5G 15.5G 4096 /mnt/runtime/read/emulated 25.0G 9.5G 15.5G 4096 /mnt/runtime/write/emulated 25.0G 9.5G 15.5G 4096 /mnt/media_rw/70C9-1D12 7.3G 1.6G 5.7G 32768 /mnt/runtime/default/70C9-1D12 7.3G 1.6G 5.7G 32768 /storage/70C9-1D12 7.3G 1.6G 5.7G 32768 /mnt/runtime/read/70C9-1D12 7.3G 1.6G 5.7G 32768 /mnt/runtime/write/70C9-1D12 7.3G 1.6G 5.7G 32768
Et que j'ai lu que ce serait /data qui contiendrait les fichiers supprimés (et à priori bien plus au vu de la taille, je me dis qu'un : dd if=/dev/block/platform/msm_sdcc.1/by-name/userdata of=/storage/nom_de_la_SD_externe/SOS
Devrait le faire si je trouve une micro SD assez grosse... sauf qu'il me semble que c'est du vfat...
Une idée?
Merci, Vincent / boulet
Linux06 mailing list Linux06@lists.linux-azur.org https://lists.linux-azur.org/mailman/listinfo/linux06 Attention, les archives sont publiques
Linux06 mailing list Linux06@lists.linux-azur.org https://lists.linux-azur.org/mailman/listinfo/linux06 Attention, les archives sont publiques
_______________________________________________ Linux06 mailing list Linux06@lists.linux-azur.org https://lists.linux-azur.org/mailman/listinfo/linux06 Attention, les archives sont publiques
Salut Patrick,
oui, je viens de lancer la commande en supposant que c'était bien dans la seule partition /data. J'ai préféré ne pas monter la carte SD, simplement car je n'ai pas réussi à m'assurer que le point de montage ne se trouverait pas aussi dans /data...
Du coup, je me suis limité à un dd if=/dev/block/mmblk0p20 of=/dev/block/mmkbl1
Et aléa jacta est!
Là, je ne vois plus l'avancée... mais en busybox, il ne faut pas trop le lui en demander...
Je vais manger et faire autre chose en attendant!
A+ Vincent.
Le 19/01/2022 à 11:57, oliviero@club-internet.fr a écrit :
Hello Vincent,
J'arrive sur le sujet un peu après la bataille.
Tu veut copier ta carte interne ailleurs afin d'utiliser photorec, tu as un émulateur de terminal et un téléphone rooté ? Tu peut effectivement écraser ta sd non formaté avec un dd mais tu ne pourra le faire que pour un dd. ( parce que dd va repartir du début de la sd a chaque fois ) Si tu la formates et que android la monte rien ne t'empêche de faire un dd vers un fichier iso sur ta sd montée et récupérer sur ton linux cette ( ou ces iso ) de partition afin de les traiter ( voir le formatage réel et les diverses options qui pourrais être mise sur les partitions android ). Du coup tu pourra avoir des iso de toutes les partitions et pseudo partitions de ton android et chercher partout tes données ( dés fois qu'ils les planquent mais vu que c'est un téléphone rooté il est peut-être moins farfelu qu'un android totalement propriétaire. )
Patrick. De : "Vincent" A : linux06@lists.linux-azur.org Envoyé: mercredi 19 Janvier 2022 11:33 Objet : [HELP] deboires sous Android -> monter une SD card en ext4 Re,
en fait, ayant un émulateur terminal sur ce téléphone, il ne reste 'plus' qu'à monter une micro SD card en ext4 et faire un dd dessus...
Ce qui suppose de créer un point de montage hors /data le temps de faire un dd...
Mais peut-être me fais-je des noeuds au cerveau, et que je peux simplement écraser le contenu de la SD card (non formatée pour que Android ne la monte pas) avec un dd? Question subsidiaire, commen tla voir alors (pas de lsblk de mémoire sur adb et je ne crois pas non plus sous termux)
Merci, Vincent.
Le 19/01/2022 à 11:00, Vincent a écrit :
Bonjour Christophe,
J'ai quand même bien tenté une APK toxique (qui t'impose des pub), mais en fait, comme souvent, c'est bidon : il te retrouve les photos égarées et éventuellement fait une récupération sur les partitions vfat. Cela a été une pure perte de temps, surtout que c'est une boite noire dont il m'a fallu essayer de surveiller les actions, notamment en basculant en mode avion...
Pour ton lien, outre que c'est complexe, cela s'adresse aux données sur la carte SD, pas sur la mémoire interne en ext4.
Je regarde pour activer le support UMS et ainsi pouvoir monter en Read-Only la partition /data, ce qui serait nettement plus simple pour faire un dd...
qui est cité dans :
Je crois qu'il va me falloir faire le deuil, d'autant que j'ai besoin de rallumer mon téléphone, et qu'à chaque fois que je le fais, je perds un peu plus mes chances de récupération.
Bon, cela m'apprendra à laisser traîner les choses : je n'ai toujours pas mis en place un vrai système d'archivage.
Vincent.
Le 19/01/2022 à 10:38, CgX (Christophe) a écrit :
Bonjour, je ne saurais non plus répondre à ton problème.
Il semble exister des applications permettant de récupérer les fichiers effacés, mais ils sont sur le "play store" ce qui n'est pas acceptable selon tes/mes critères :)
Sinon, y'a un type qui s'est amusé à compiler ddrescue pour android, mais c'est du haut-vol : https://ncrmnt.org/2017/05/12/data-recovery-sd-ddrescue-and-android/
-- Christophe
Le 19/01/2022 à 09:51, Vincent a écrit :
Bonjour,
mon message ne semble pas avoir franchi le filtre anti-spam...
Même si je prends toute piste, ma question est surtout : comment monter sous Android un carte SD temporaire en ext4? Pour pouvoir faire une image complète de 25 Go avec une commande dd.
Merci, Vincent
-------- Message transféré -------- Sujet : [HELP] deboires sous Android Date : Wed, 19 Jan 2022 01:39:52 +0100 Pour : Liste principale de Linux Azur
Bonsoir,
ce soir, en mode boulet distrait, j'ai voulu nettoyer ma galerie photos... et j'ai en fait supprimé un dossier complet!!! Du coup, je me prends la tête pour retrouver où sont elles
planquées...
Pas de corbeille visiblement dans cette application - c'est balot.
Le téléphone est rooté, j'ai un accès complet via adb shell
Je m'apprête à remplacer la carte micro SD par une plus grosse et vierge et faire un dd de la partition qui va bien pour ensuite la monter sur mon PC et lancer un photorec...
Question : c'est quoi donc que la partition qui va bien?
C'est de l'android 6.0.1, et :
ls -al /dev/block/platform/msm_sdcc.1/by-name/ < lrwxrwxrwx root root 1970-01-20 08:57 DDR -> /dev/block/mmcblk0p4 lrwxrwxrwx root root 1970-01-20 08:57 aboot -> /dev/block/mmcblk0p5 lrwxrwxrwx root root 1970-01-20 08:57 boot -> /dev/block/mmcblk0p8 lrwxrwxrwx root root 1970-01-20 08:57 cache -> /dev/block/mmcblk0p15 lrwxrwxrwx root root 1970-01-20 08:57 dbi -> /dev/block/mmcblk0p3 lrwxrwxrwx root root 1970-01-20 08:57 fsc -> /dev/block/mmcblk0p18 lrwxrwxrwx root root 1970-01-20 08:57 fsg -> /dev/block/mmcblk0p17 lrwxrwxrwx root root 1970-01-20 08:57 modem -> /dev/block/mmcblk0p1 lrwxrwxrwx root root 1970-01-20 08:57 modemst1 -> /dev/block/mmcblk0p11 lrwxrwxrwx root root 1970-01-20 08:57 modemst2 -> /dev/block/mmcblk0p12 lrwxrwxrwx root root 1970-01-20 08:57 pad -> /dev/block/mmcblk0p10 lrwxrwxrwx root root 1970-01-20 08:57 persist -> /dev/block/mmcblk0p14 lrwxrwxrwx root root 1970-01-20 08:57 recovery -> /dev/block/mmcblk0p16 lrwxrwxrwx root root 1970-01-20 08:57 rpm -> /dev/block/mmcblk0p7 lrwxrwxrwx root root 1970-01-20 08:57 sbl1 -> /dev/block/mmcblk0p2 lrwxrwxrwx root root 1970-01-20 08:57 splash -> /dev/block/mmcblk0p6 lrwxrwxrwx root root 1970-01-20 08:57 ssd -> /dev/block/mmcblk0p19 lrwxrwxrwx root root 1970-01-20 08:57 system -> /dev/block/mmcblk0p13 lrwxrwxrwx root root 1970-01-20 08:57 tz -> /dev/block/mmcblk0p9 lrwxrwxrwx root root 1970-01-20 08:57 userdata -> /dev/block/mmcblk0p20
comme : mount | grep block /dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,seclabel,relatime,discard,data=ordered 0 0 /dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 rw,seclabel,nosuid,nodev,relatime,discard,noauto_da_alloc,data=ordered 0 0 /dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0 /dev/block/platform/msm_sdcc.1/by-name/persist /persist ext4 rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0 /dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat
ro,context=u:object_r:firmware_file:s0,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=cp437,iocharset=iso8859-1,shortname=lower,errors=remount-ro
0 0 /dev/block/vold/public:179,65 /mnt/media_rw/70C9-1D12 vfat
rw,dirsync,nosuid,nodev,noexec,relatime,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro
0 0
et : df Filesystem Size Used Free Blksize /dev 923.1M 96.0K 923.0M 4096 /sys/fs/cgroup 923.1M 12.0K 923.1M 4096 /mnt 923.1M 0.0K 923.1M 4096 /system 2.0G 503.8M 1.5G 4096 /data 25.0G 9.5G 15.5G 4096 /cache 629.5M 10.0M 619.5M 4096 /persist 4.9M 4.8M 92.0K 4096 /firmware 64.0M 56.2M 7.8M 16384 /storage 923.1M 0.0K 923.1M 4096 /mnt/runtime/default/emulated 25.0G 9.5G 15.5G 4096 /storage/emulated 25.0G 9.5G 15.5G 4096 /mnt/runtime/read/emulated 25.0G 9.5G 15.5G 4096 /mnt/runtime/write/emulated 25.0G 9.5G 15.5G 4096 /mnt/media_rw/70C9-1D12 7.3G 1.6G 5.7G 32768 /mnt/runtime/default/70C9-1D12 7.3G 1.6G 5.7G 32768 /storage/70C9-1D12 7.3G 1.6G 5.7G 32768 /mnt/runtime/read/70C9-1D12 7.3G 1.6G 5.7G 32768 /mnt/runtime/write/70C9-1D12 7.3G 1.6G 5.7G 32768
Et que j'ai lu que ce serait /data qui contiendrait les fichiers supprimés (et à priori bien plus au vu de la taille, je me dis qu'un : dd if=/dev/block/platform/msm_sdcc.1/by-name/userdata of=/storage/nom_de_la_SD_externe/SOS
Devrait le faire si je trouve une micro SD assez grosse... sauf qu'il me semble que c'est du vfat...
Une idée?
Merci, Vincent / boulet
Bon, sur le PC, après avoir monté la partition en lecture seule.
sudo mount -o ro /dev/mmcblk0 /media/dubsv/data sudo extundelete --restore-all --after 1642525000 /dev/mmcblk0
Mais il ne retrouve quasiment rien... 494Mo, très loin de l'attendu!
Du coup, il me reste à investiguer photorec...
Vincent.
Le 19/01/2022 à 13:52, Vincent a écrit :
Salut Patrick,
oui, je viens de lancer la commande en supposant que c'était bien dans la seule partition /data. J'ai préféré ne pas monter la carte SD, simplement car je n'ai pas réussi à m'assurer que le point de montage ne se trouverait pas aussi dans /data...
Du coup, je me suis limité à un dd if=/dev/block/mmblk0p20 of=/dev/block/mmkbl1
Et aléa jacta est!
Là, je ne vois plus l'avancée... mais en busybox, il ne faut pas trop le lui en demander...
Je vais manger et faire autre chose en attendant!
A+ Vincent.
Le 19/01/2022 à 11:57, oliviero@club-internet.fr a écrit :
Hello Vincent,
J'arrive sur le sujet un peu après la bataille.
Tu veut copier ta carte interne ailleurs afin d'utiliser photorec, tu as un émulateur de terminal et un téléphone rooté ? Tu peut effectivement écraser ta sd non formaté avec un dd mais tu ne pourra le faire que pour un dd. ( parce que dd va repartir du début de la sd a chaque fois ) Si tu la formates et que android la monte rien ne t'empêche de faire un dd vers un fichier iso sur ta sd montée et récupérer sur ton linux cette ( ou ces iso ) de partition afin de les traiter ( voir le formatage réel et les diverses options qui pourrais être mise sur les partitions android ). Du coup tu pourra avoir des iso de toutes les partitions et pseudo partitions de ton android et chercher partout tes données ( dés fois qu'ils les planquent mais vu que c'est un téléphone rooté il est peut-être moins farfelu qu'un android totalement propriétaire. )
Patrick. De : "Vincent" A : linux06@lists.linux-azur.org Envoyé: mercredi 19 Janvier 2022 11:33 Objet : [HELP] deboires sous Android -> monter une SD card en ext4 Re,
en fait, ayant un émulateur terminal sur ce téléphone, il ne reste 'plus' qu'à monter une micro SD card en ext4 et faire un dd dessus...
Ce qui suppose de créer un point de montage hors /data le temps de faire un dd...
Mais peut-être me fais-je des noeuds au cerveau, et que je peux simplement écraser le contenu de la SD card (non formatée pour que Android ne la monte pas) avec un dd? Question subsidiaire, commen tla voir alors (pas de lsblk de mémoire sur adb et je ne crois pas non plus sous termux)
Merci, Vincent.
Le 19/01/2022 à 11:00, Vincent a écrit :
Bonjour Christophe,
J'ai quand même bien tenté une APK toxique (qui t'impose des pub), mais en fait, comme souvent, c'est bidon : il te retrouve les photos égarées et éventuellement fait une récupération sur les partitions
vfat.
Cela a été une pure perte de temps, surtout que c'est une boite noire dont il m'a fallu essayer de surveiller les actions, notamment en basculant en mode avion...
Pour ton lien, outre que c'est complexe, cela s'adresse aux données sur la carte SD, pas sur la mémoire interne en ext4.
Je regarde pour activer le support UMS et ainsi pouvoir monter en Read-Only la partition /data, ce qui serait nettement plus simple pour faire un dd...
qui est cité dans :
Je crois qu'il va me falloir faire le deuil, d'autant que j'ai besoin de rallumer mon téléphone, et qu'à chaque fois que je le fais, je perds un peu plus mes chances de récupération.
Bon, cela m'apprendra à laisser traîner les choses : je n'ai toujours pas mis en place un vrai système d'archivage.
Vincent.
Le 19/01/2022 à 10:38, CgX (Christophe) a écrit :
Bonjour, je ne saurais non plus répondre à ton problème.
Il semble exister des applications permettant de récupérer les fichiers effacés, mais ils sont sur le "play store" ce qui n'est pas acceptable selon tes/mes critères :)
Sinon, y'a un type qui s'est amusé à compiler ddrescue pour android, mais c'est du haut-vol : https://ncrmnt.org/2017/05/12/data-recovery-sd-ddrescue-and-android/
-- Christophe
Le 19/01/2022 à 09:51, Vincent a écrit :
Bonjour,
mon message ne semble pas avoir franchi le filtre anti-spam...
Même si je prends toute piste, ma question est surtout : comment monter sous Android un carte SD temporaire en ext4? Pour pouvoir faire une image complète de 25 Go avec une commande dd.
Merci, Vincent
-------- Message transféré -------- Sujet : [HELP] deboires sous Android Date : Wed, 19 Jan 2022 01:39:52 +0100 Pour : Liste principale de Linux Azur
Bonsoir,
ce soir, en mode boulet distrait, j'ai voulu nettoyer ma galerie photos... et j'ai en fait supprimé un dossier complet!!! Du coup, je me prends la tête pour retrouver où sont elles
planquées...
Pas de corbeille visiblement dans cette application - c'est balot.
Le téléphone est rooté, j'ai un accès complet via adb shell
Je m'apprête à remplacer la carte micro SD par une plus grosse et vierge et faire un dd de la partition qui va bien pour ensuite la monter sur mon PC et lancer un photorec...
Question : c'est quoi donc que la partition qui va bien?
C'est de l'android 6.0.1, et :
ls -al /dev/block/platform/msm_sdcc.1/by-name/ < lrwxrwxrwx root root 1970-01-20 08:57 DDR -> /dev/block/mmcblk0p4 lrwxrwxrwx root root 1970-01-20 08:57 aboot -> /dev/block/mmcblk0p5 lrwxrwxrwx root root 1970-01-20 08:57 boot -> /dev/block/mmcblk0p8 lrwxrwxrwx root root 1970-01-20 08:57 cache -> /dev/block/mmcblk0p15 lrwxrwxrwx root root 1970-01-20 08:57 dbi -> /dev/block/mmcblk0p3 lrwxrwxrwx root root 1970-01-20 08:57 fsc -> /dev/block/mmcblk0p18 lrwxrwxrwx root root 1970-01-20 08:57 fsg -> /dev/block/mmcblk0p17 lrwxrwxrwx root root 1970-01-20 08:57 modem -> /dev/block/mmcblk0p1 lrwxrwxrwx root root 1970-01-20 08:57 modemst1 -> /dev/block/mmcblk0p11 lrwxrwxrwx root root 1970-01-20 08:57 modemst2 -> /dev/block/mmcblk0p12 lrwxrwxrwx root root 1970-01-20 08:57 pad -> /dev/block/mmcblk0p10 lrwxrwxrwx root root 1970-01-20 08:57 persist -> /dev/block/mmcblk0p14 lrwxrwxrwx root root 1970-01-20 08:57 recovery -> /dev/block/mmcblk0p16 lrwxrwxrwx root root 1970-01-20 08:57 rpm -> /dev/block/mmcblk0p7 lrwxrwxrwx root root 1970-01-20 08:57 sbl1 -> /dev/block/mmcblk0p2 lrwxrwxrwx root root 1970-01-20 08:57 splash -> /dev/block/mmcblk0p6 lrwxrwxrwx root root 1970-01-20 08:57 ssd -> /dev/block/mmcblk0p19 lrwxrwxrwx root root 1970-01-20 08:57 system -> /dev/block/mmcblk0p13 lrwxrwxrwx root root 1970-01-20 08:57 tz -> /dev/block/mmcblk0p9 lrwxrwxrwx root root 1970-01-20 08:57 userdata -> /dev/block/mmcblk0p20
comme : mount | grep block /dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,seclabel,relatime,discard,data=ordered 0 0 /dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4
rw,seclabel,nosuid,nodev,relatime,discard,noauto_da_alloc,data=ordered
0 0 /dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0 /dev/block/platform/msm_sdcc.1/by-name/persist /persist ext4 rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0 /dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat
ro,context=u:object_r:firmware_file:s0,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=cp437,iocharset=iso8859-1,shortname=lower,errors=remount-ro
0 0 /dev/block/vold/public:179,65 /mnt/media_rw/70C9-1D12 vfat
rw,dirsync,nosuid,nodev,noexec,relatime,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro
0 0
et : df Filesystem Size Used Free Blksize /dev 923.1M 96.0K 923.0M 4096 /sys/fs/cgroup 923.1M 12.0K 923.1M 4096 /mnt 923.1M 0.0K 923.1M 4096 /system 2.0G 503.8M 1.5G 4096 /data 25.0G 9.5G 15.5G 4096 /cache 629.5M 10.0M 619.5M 4096 /persist 4.9M 4.8M 92.0K 4096 /firmware 64.0M 56.2M 7.8M 16384 /storage 923.1M 0.0K 923.1M 4096 /mnt/runtime/default/emulated 25.0G 9.5G 15.5G 4096 /storage/emulated 25.0G 9.5G 15.5G 4096 /mnt/runtime/read/emulated 25.0G 9.5G 15.5G 4096 /mnt/runtime/write/emulated 25.0G 9.5G 15.5G 4096 /mnt/media_rw/70C9-1D12 7.3G 1.6G 5.7G 32768 /mnt/runtime/default/70C9-1D12 7.3G 1.6G 5.7G 32768 /storage/70C9-1D12 7.3G 1.6G 5.7G 32768 /mnt/runtime/read/70C9-1D12 7.3G 1.6G 5.7G 32768 /mnt/runtime/write/70C9-1D12 7.3G 1.6G 5.7G 32768
Et que j'ai lu que ce serait /data qui contiendrait les fichiers supprimés (et à priori bien plus au vu de la taille, je me dis
qu'un :
dd if=/dev/block/platform/msm_sdcc.1/by-name/userdata of=/storage/nom_de_la_SD_externe/SOS
Devrait le faire si je trouve une micro SD assez grosse... sauf qu'il me semble que c'est du vfat...
Une idée?
Merci, Vincent / boulet
Linux06 mailing list Linux06@lists.linux-azur.org https://lists.linux-azur.org/mailman/listinfo/linux06 Attention, les archives sont publiques
Alors photorec... très rapide, 7Go de fichiers récupérés... Mais je n'ai pas l'impression qu'il ait récupéré mes 3600 grosses photos...
Il me semblait qu'il fallait faire plusieurs passes avec photorec, je m'attendais à quelque chose de plus complexe, mais moins boite noire. De même, il me semblait qu'on pouvait lui spécifié de ne chercher que les *.jpg
Ma mémoire me fait défaut, si l'un d'entre vous est encore au niveau sur cet utilitaire
Le 19/01/2022 à 14:49, Vincent a écrit :
Bon, sur le PC, après avoir monté la partition en lecture seule.
sudo mount -o ro /dev/mmcblk0 /media/dubsv/data sudo extundelete --restore-all --after 1642525000 /dev/mmcblk0
Mais il ne retrouve quasiment rien... 494Mo, très loin de l'attendu!
Du coup, il me reste à investiguer photorec...
Vincent.
Le 19/01/2022 à 13:52, Vincent a écrit :
Salut Patrick,
oui, je viens de lancer la commande en supposant que c'était bien dans la seule partition /data. J'ai préféré ne pas monter la carte SD, simplement car je n'ai pas réussi à m'assurer que le point de montage ne se trouverait pas aussi dans /data...
Du coup, je me suis limité à un dd if=/dev/block/mmblk0p20 of=/dev/block/mmkbl1
Et aléa jacta est!
Là, je ne vois plus l'avancée... mais en busybox, il ne faut pas trop le lui en demander...
Je vais manger et faire autre chose en attendant!
A+ Vincent.
Le 19/01/2022 à 11:57, oliviero@club-internet.fr a écrit :
Hello Vincent,
J'arrive sur le sujet un peu après la bataille.
Tu veut copier ta carte interne ailleurs afin d'utiliser photorec, tu as un émulateur de terminal et un téléphone rooté ? Tu peut effectivement écraser ta sd non formaté avec un dd mais tu ne pourra le faire que pour un dd. ( parce que dd va repartir du début de la sd a chaque fois ) Si tu la formates et que android la monte rien ne t'empêche de faire un dd vers un fichier iso sur ta sd montée et récupérer sur ton linux cette ( ou ces iso ) de partition afin de les traiter ( voir le formatage réel et les diverses options qui pourrais être mise sur les partitions android ). Du coup tu pourra avoir des iso de toutes les partitions et pseudo partitions de ton android et chercher partout tes données ( dés fois qu'ils les planquent mais vu que c'est un téléphone rooté il est peut-être moins farfelu qu'un android totalement propriétaire. )
Patrick. De : "Vincent" A : linux06@lists.linux-azur.org Envoyé: mercredi 19 Janvier 2022 11:33 Objet : [HELP] deboires sous Android -> monter une SD card en ext4 Re,
en fait, ayant un émulateur terminal sur ce téléphone, il ne reste 'plus' qu'à monter une micro SD card en ext4 et faire un dd dessus...
Ce qui suppose de créer un point de montage hors /data le temps de faire un dd...
Mais peut-être me fais-je des noeuds au cerveau, et que je peux simplement écraser le contenu de la SD card (non formatée pour que Android ne la monte pas) avec un dd? Question subsidiaire, commen tla voir alors (pas de lsblk de mémoire sur adb et je ne crois pas non plus sous termux)
Merci, Vincent.
Le 19/01/2022 à 11:00, Vincent a écrit :
Bonjour Christophe,
J'ai quand même bien tenté une APK toxique (qui t'impose des pub), mais en fait, comme souvent, c'est bidon : il te retrouve les photos égarées et éventuellement fait une récupération sur les partitions
vfat.
Cela a été une pure perte de temps, surtout que c'est une boite noire dont il m'a fallu essayer de surveiller les actions, notamment en basculant en mode avion...
Pour ton lien, outre que c'est complexe, cela s'adresse aux données sur la carte SD, pas sur la mémoire interne en ext4.
Je regarde pour activer le support UMS et ainsi pouvoir monter en Read-Only la partition /data, ce qui serait nettement plus simple
pour
faire un dd...
qui est cité dans :
Je crois qu'il va me falloir faire le deuil, d'autant que j'ai besoin de rallumer mon téléphone, et qu'à chaque fois que je le fais, je perds un peu plus mes chances de récupération.
Bon, cela m'apprendra à laisser traîner les choses : je n'ai toujours pas mis en place un vrai système d'archivage.
Vincent.
Le 19/01/2022 à 10:38, CgX (Christophe) a écrit :
Bonjour, je ne saurais non plus répondre à ton problème.
Il semble exister des applications permettant de récupérer les fichiers effacés, mais ils sont sur le "play store" ce qui n'est pas acceptable selon tes/mes critères :)
Sinon, y'a un type qui s'est amusé à compiler ddrescue pour android, mais c'est du haut-vol : https://ncrmnt.org/2017/05/12/data-recovery-sd-ddrescue-and-android/
-- Christophe
Le 19/01/2022 à 09:51, Vincent a écrit :
Bonjour,
mon message ne semble pas avoir franchi le filtre anti-spam...
Même si je prends toute piste, ma question est surtout : comment monter sous Android un carte SD temporaire en ext4? Pour pouvoir faire une image complète de 25 Go avec une commande
dd.
Merci, Vincent
-------- Message transféré -------- Sujet : [HELP] deboires sous Android Date : Wed, 19 Jan 2022 01:39:52 +0100 Pour : Liste principale de Linux Azur
Bonsoir,
ce soir, en mode boulet distrait, j'ai voulu nettoyer ma galerie photos... et j'ai en fait supprimé un dossier complet!!! Du coup, je me prends la tête pour retrouver où sont elles
planquées...
Pas de corbeille visiblement dans cette application - c'est balot.
Le téléphone est rooté, j'ai un accès complet via adb shell
Je m'apprête à remplacer la carte micro SD par une plus grosse et vierge et faire un dd de la partition qui va bien pour ensuite la monter sur mon PC et lancer un photorec...
Question : c'est quoi donc que la partition qui va bien?
C'est de l'android 6.0.1, et :
ls -al /dev/block/platform/msm_sdcc.1/by-name/ < lrwxrwxrwx root root 1970-01-20 08:57 DDR -> /dev/block/mmcblk0p4 lrwxrwxrwx root root 1970-01-20 08:57 aboot -> /dev/block/mmcblk0p5 lrwxrwxrwx root root 1970-01-20 08:57 boot -> /dev/block/mmcblk0p8 lrwxrwxrwx root root 1970-01-20 08:57 cache -> /dev/block/mmcblk0p15 lrwxrwxrwx root root 1970-01-20 08:57 dbi -> /dev/block/mmcblk0p3 lrwxrwxrwx root root 1970-01-20 08:57 fsc -> /dev/block/mmcblk0p18 lrwxrwxrwx root root 1970-01-20 08:57 fsg -> /dev/block/mmcblk0p17 lrwxrwxrwx root root 1970-01-20 08:57 modem -> /dev/block/mmcblk0p1 lrwxrwxrwx root root 1970-01-20 08:57 modemst1 -> /dev/block/mmcblk0p11 lrwxrwxrwx root root 1970-01-20 08:57 modemst2 -> /dev/block/mmcblk0p12 lrwxrwxrwx root root 1970-01-20 08:57 pad -> /dev/block/mmcblk0p10 lrwxrwxrwx root root 1970-01-20 08:57 persist -> /dev/block/mmcblk0p14 lrwxrwxrwx root root 1970-01-20 08:57 recovery -> /dev/block/mmcblk0p16 lrwxrwxrwx root root 1970-01-20 08:57 rpm -> /dev/block/mmcblk0p7 lrwxrwxrwx root root 1970-01-20 08:57 sbl1 -> /dev/block/mmcblk0p2 lrwxrwxrwx root root 1970-01-20 08:57 splash -> /dev/block/mmcblk0p6 lrwxrwxrwx root root 1970-01-20 08:57 ssd -> /dev/block/mmcblk0p19 lrwxrwxrwx root root 1970-01-20 08:57 system -> /dev/block/mmcblk0p13 lrwxrwxrwx root root 1970-01-20 08:57 tz -> /dev/block/mmcblk0p9 lrwxrwxrwx root root 1970-01-20 08:57 userdata -> /dev/block/mmcblk0p20
comme : mount | grep block /dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,seclabel,relatime,discard,data=ordered 0 0 /dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4
rw,seclabel,nosuid,nodev,relatime,discard,noauto_da_alloc,data=ordered
0 0 /dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0 /dev/block/platform/msm_sdcc.1/by-name/persist /persist ext4 rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0 /dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat
ro,context=u:object_r:firmware_file:s0,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=cp437,iocharset=iso8859-1,shortname=lower,errors=remount-ro
0 0 /dev/block/vold/public:179,65 /mnt/media_rw/70C9-1D12 vfat
rw,dirsync,nosuid,nodev,noexec,relatime,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro
0 0
et : df Filesystem Size Used Free Blksize /dev 923.1M 96.0K 923.0M 4096 /sys/fs/cgroup 923.1M 12.0K 923.1M 4096 /mnt 923.1M 0.0K 923.1M 4096 /system 2.0G 503.8M 1.5G 4096 /data 25.0G 9.5G 15.5G 4096 /cache 629.5M 10.0M 619.5M 4096 /persist 4.9M 4.8M 92.0K 4096 /firmware 64.0M 56.2M 7.8M 16384 /storage 923.1M 0.0K 923.1M 4096 /mnt/runtime/default/emulated 25.0G 9.5G 15.5G 4096 /storage/emulated 25.0G 9.5G 15.5G 4096 /mnt/runtime/read/emulated 25.0G 9.5G 15.5G 4096 /mnt/runtime/write/emulated 25.0G 9.5G 15.5G 4096 /mnt/media_rw/70C9-1D12 7.3G 1.6G 5.7G 32768 /mnt/runtime/default/70C9-1D12 7.3G 1.6G 5.7G 32768 /storage/70C9-1D12 7.3G 1.6G 5.7G 32768 /mnt/runtime/read/70C9-1D12 7.3G 1.6G 5.7G 32768 /mnt/runtime/write/70C9-1D12 7.3G 1.6G 5.7G 32768
Et que j'ai lu que ce serait /data qui contiendrait les fichiers supprimés (et à priori bien plus au vu de la taille, je me dis
qu'un :
dd if=/dev/block/platform/msm_sdcc.1/by-name/userdata of=/storage/nom_de_la_SD_externe/SOS
Devrait le faire si je trouve une micro SD assez grosse... sauf qu'il me semble que c'est du vfat...
Une idée?
Merci, Vincent / boulet
Bon, je confirme l'impression :
find . -iname '*.jpg' -size +2M | wc -l 162
162 fichiers au lieu de 3600... ce ne sont pas les bons! P'tet d'abord un testdisk avant?
Des pistes?
Le 19/01/2022 à 15:26, Vincent a écrit :
Alors photorec... très rapide, 7Go de fichiers récupérés... Mais je n'ai pas l'impression qu'il ait récupéré mes 3600 grosses photos...
Il me semblait qu'il fallait faire plusieurs passes avec photorec, je m'attendais à quelque chose de plus complexe, mais moins boite noire. De même, il me semblait qu'on pouvait lui spécifié de ne chercher que les *.jpg
Ma mémoire me fait défaut, si l'un d'entre vous est encore au niveau sur cet utilitaire
Le 19/01/2022 à 14:49, Vincent a écrit :
Bon, sur le PC, après avoir monté la partition en lecture seule.
sudo mount -o ro /dev/mmcblk0 /media/dubsv/data sudo extundelete --restore-all --after 1642525000 /dev/mmcblk0
Mais il ne retrouve quasiment rien... 494Mo, très loin de l'attendu!
Du coup, il me reste à investiguer photorec...
Vincent.
Le 19/01/2022 à 13:52, Vincent a écrit :
Salut Patrick,
oui, je viens de lancer la commande en supposant que c'était bien dans la seule partition /data. J'ai préféré ne pas monter la carte SD, simplement car je n'ai pas réussi à m'assurer que le point de montage ne se trouverait pas aussi dans /data...
Du coup, je me suis limité à un dd if=/dev/block/mmblk0p20 of=/dev/block/mmkbl1
Et aléa jacta est!
Là, je ne vois plus l'avancée... mais en busybox, il ne faut pas trop le lui en demander...
Je vais manger et faire autre chose en attendant!
A+ Vincent.
Le 19/01/2022 à 11:57, oliviero@club-internet.fr a écrit :
Hello Vincent,
J'arrive sur le sujet un peu après la bataille.
Tu veut copier ta carte interne ailleurs afin d'utiliser photorec, tu as un émulateur de terminal et un téléphone rooté ? Tu peut effectivement écraser ta sd non formaté avec un dd mais tu ne pourra le faire que pour un dd. ( parce que dd va repartir du début de la sd a chaque fois ) Si tu la formates et que android la monte rien ne t'empêche de faire un dd vers un fichier iso sur ta sd montée et récupérer sur ton linux cette ( ou ces iso ) de partition afin de les traiter ( voir le formatage réel et les diverses options qui pourrais être mise sur les partitions android ). Du coup tu pourra avoir des iso de toutes les partitions et pseudo partitions de ton android et chercher partout tes données ( dés fois qu'ils les planquent mais vu que c'est un téléphone rooté il est peut-être moins farfelu qu'un android totalement propriétaire. )
Patrick. De : "Vincent" A : linux06@lists.linux-azur.org Envoyé: mercredi 19 Janvier 2022 11:33 Objet : [HELP] deboires sous Android -> monter une SD card en ext4 Re,
en fait, ayant un émulateur terminal sur ce téléphone, il ne reste 'plus' qu'à monter une micro SD card en ext4 et faire un dd dessus...
Ce qui suppose de créer un point de montage hors /data le temps de faire un dd...
Mais peut-être me fais-je des noeuds au cerveau, et que je peux simplement écraser le contenu de la SD card (non formatée pour que Android ne la monte pas) avec un dd? Question subsidiaire, commen tla voir alors (pas de lsblk de mémoire sur adb et je ne crois pas non plus sous termux)
Merci, Vincent.
Le 19/01/2022 à 11:00, Vincent a écrit :
Bonjour Christophe,
J'ai quand même bien tenté une APK toxique (qui t'impose des pub), mais en fait, comme souvent, c'est bidon : il te retrouve les photos égarées et éventuellement fait une récupération sur les
partitions vfat.
Cela a été une pure perte de temps, surtout que c'est une boite
noire
dont il m'a fallu essayer de surveiller les actions, notamment en basculant en mode avion...
Pour ton lien, outre que c'est complexe, cela s'adresse aux données sur la carte SD, pas sur la mémoire interne en ext4.
Je regarde pour activer le support UMS et ainsi pouvoir monter en Read-Only la partition /data, ce qui serait nettement plus simple
pour
faire un dd...
qui est cité dans :
Je crois qu'il va me falloir faire le deuil, d'autant que j'ai
besoin
de rallumer mon téléphone, et qu'à chaque fois que je le fais, je perds un peu plus mes chances de récupération.
Bon, cela m'apprendra à laisser traîner les choses : je n'ai
toujours
pas mis en place un vrai système d'archivage.
Vincent.
Le 19/01/2022 à 10:38, CgX (Christophe) a écrit :
Bonjour, je ne saurais non plus répondre à ton problème.
Il semble exister des applications permettant de récupérer les fichiers effacés, mais ils sont sur le "play store" ce qui n'est
pas
acceptable selon tes/mes critères :)
Sinon, y'a un type qui s'est amusé à compiler ddrescue pour
android,
mais c'est du haut-vol :
https://ncrmnt.org/2017/05/12/data-recovery-sd-ddrescue-and-android/
-- Christophe
Le 19/01/2022 à 09:51, Vincent a écrit : > Bonjour, > > mon message ne semble pas avoir franchi le filtre anti-spam... > > Même si je prends toute piste, ma question est surtout : comment > monter sous Android un carte SD temporaire en ext4? > Pour pouvoir faire une image complète de 25 Go avec une
commande dd.
> > Merci, > Vincent > > -------- Message transféré -------- > Sujet : [HELP] deboires sous Android > Date : Wed, 19 Jan 2022 01:39:52 +0100 > Pour : Liste principale de Linux Azur > > > > > Bonsoir, > > ce soir, en mode boulet distrait, j'ai voulu nettoyer ma galerie > photos... et j'ai en fait supprimé un dossier complet!!! > Du coup, je me prends la tête pour retrouver où sont elles
planquées...
> > Pas de corbeille visiblement dans cette application - c'est balot. > > Le téléphone est rooté, j'ai un accès complet via adb shell > > Je m'apprête à remplacer la carte micro SD par une plus grosse et > vierge et faire un dd de la partition qui va bien pour ensuite la > monter sur mon PC et lancer un photorec... > > Question : c'est quoi donc que la partition qui va bien? > > C'est de l'android 6.0.1, et : > > ls -al /dev/block/platform/msm_sdcc.1/by-name/ < > lrwxrwxrwx root root 1970-01-20 08:57 DDR -> > /dev/block/mmcblk0p4 > lrwxrwxrwx root root 1970-01-20 08:57 aboot -> > /dev/block/mmcblk0p5 > lrwxrwxrwx root root 1970-01-20 08:57 boot -> > /dev/block/mmcblk0p8 > lrwxrwxrwx root root 1970-01-20 08:57 cache -> > /dev/block/mmcblk0p15 > lrwxrwxrwx root root 1970-01-20 08:57 dbi -> > /dev/block/mmcblk0p3 > lrwxrwxrwx root root 1970-01-20 08:57 fsc -> > /dev/block/mmcblk0p18 > lrwxrwxrwx root root 1970-01-20 08:57 fsg -> > /dev/block/mmcblk0p17 > lrwxrwxrwx root root 1970-01-20 08:57 modem -> > /dev/block/mmcblk0p1 > lrwxrwxrwx root root 1970-01-20 08:57 modemst1 -> > /dev/block/mmcblk0p11 > lrwxrwxrwx root root 1970-01-20 08:57 modemst2 -> > /dev/block/mmcblk0p12 > lrwxrwxrwx root root 1970-01-20 08:57 pad -> > /dev/block/mmcblk0p10 > lrwxrwxrwx root root 1970-01-20 08:57 persist -> > /dev/block/mmcblk0p14 > lrwxrwxrwx root root 1970-01-20 08:57 recovery -> > /dev/block/mmcblk0p16 > lrwxrwxrwx root root 1970-01-20 08:57 rpm -> > /dev/block/mmcblk0p7 > lrwxrwxrwx root root 1970-01-20 08:57 sbl1 -> > /dev/block/mmcblk0p2 > lrwxrwxrwx root root 1970-01-20 08:57 splash -> > /dev/block/mmcblk0p6 > lrwxrwxrwx root root 1970-01-20 08:57 ssd -> > /dev/block/mmcblk0p19 > lrwxrwxrwx root root 1970-01-20 08:57 system -> > /dev/block/mmcblk0p13 > lrwxrwxrwx root root 1970-01-20 08:57 tz -> > /dev/block/mmcblk0p9 > lrwxrwxrwx root root 1970-01-20 08:57 userdata -> > /dev/block/mmcblk0p20 > > comme : > mount | grep block > /dev/block/platform/msm_sdcc.1/by-name/system /system ext4 > ro,seclabel,relatime,discard,data=ordered 0 0 > /dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 >
rw,seclabel,nosuid,nodev,relatime,discard,noauto_da_alloc,data=ordered
> 0 0 > /dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 > rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0 > /dev/block/platform/msm_sdcc.1/by-name/persist /persist ext4 > rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0 > /dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat >
ro,context=u:object_r:firmware_file:s0,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=cp437,iocharset=iso8859-1,shortname=lower,errors=remount-ro
> 0 0 > /dev/block/vold/public:179,65 /mnt/media_rw/70C9-1D12 vfat >
rw,dirsync,nosuid,nodev,noexec,relatime,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro
> 0 0 > > et : > df > Filesystem Size Used Free Blksize > /dev 923.1M 96.0K 923.0M 4096 > /sys/fs/cgroup 923.1M 12.0K 923.1M 4096 > /mnt 923.1M 0.0K 923.1M 4096 > /system 2.0G 503.8M 1.5G 4096 > /data 25.0G 9.5G 15.5G 4096 > /cache 629.5M 10.0M 619.5M 4096 > /persist 4.9M 4.8M 92.0K 4096 > /firmware 64.0M 56.2M 7.8M 16384 > /storage 923.1M 0.0K 923.1M 4096 > /mnt/runtime/default/emulated 25.0G 9.5G 15.5G 4096 > /storage/emulated 25.0G 9.5G 15.5G 4096 > /mnt/runtime/read/emulated 25.0G 9.5G 15.5G 4096 > /mnt/runtime/write/emulated 25.0G 9.5G 15.5G 4096 > /mnt/media_rw/70C9-1D12 7.3G 1.6G 5.7G 32768 > /mnt/runtime/default/70C9-1D12 7.3G 1.6G 5.7G 32768 > /storage/70C9-1D12 7.3G 1.6G 5.7G 32768 > /mnt/runtime/read/70C9-1D12 7.3G 1.6G 5.7G 32768 > /mnt/runtime/write/70C9-1D12 7.3G 1.6G 5.7G 32768 > > Et que j'ai lu que ce serait /data qui contiendrait les fichiers > supprimés (et à priori bien plus au vu de la taille, je me dis
qu'un :
> dd if=/dev/block/platform/msm_sdcc.1/by-name/userdata > of=/storage/nom_de_la_SD_externe/SOS > > Devrait le faire si je trouve une micro SD assez grosse... sauf > qu'il me semble que c'est du vfat... > > Une idée? > > Merci, > Vincent / boulet > _______________________________________________
Linux06 mailing list Linux06@lists.linux-azur.org https://lists.linux-azur.org/mailman/listinfo/linux06 Attention, les archives sont publiques
Salut à toutes et tous,
J'ai fait une récupération de jpg avec testdisk en mode non destructif depuis une carte sd il y a 1 an et demi et j'ai le souvenir que j'ai pu sélectionner le type de fichiers (extension) à récupérer. https://www.jng-web.com/labo/recuperer-des-fichiers-avec-testdisk/
Je me souviens aussi que j'ai dû mentionner le système de fichiers facilement identifiable avec gpart ou gparted si on a un doute.
Gnument vôtre, Sylvio
Le 19 janvier 2022 15:42:31 GMT+01:00, Vincent dubsv@free.fr a écrit :
Bon, je confirme l'impression :
find . -iname '*.jpg' -size +2M | wc -l 162
162 fichiers au lieu de 3600... ce ne sont pas les bons! P'tet d'abord un testdisk avant?
Des pistes?
Le 19/01/2022 à 15:26, Vincent a écrit :
Alors photorec... très rapide, 7Go de fichiers récupérés... Mais je n'ai pas l'impression qu'il ait récupéré mes 3600 grosses photos...
Il me semblait qu'il fallait faire plusieurs passes avec photorec, je m'attendais à quelque chose de plus complexe, mais moins boite noire. De même, il me semblait qu'on pouvait lui spécifié de ne chercher que les *.jpg
Ma mémoire me fait défaut, si l'un d'entre vous est encore au niveau sur cet utilitaire
Le 19/01/2022 à 14:49, Vincent a écrit :
Bon, sur le PC, après avoir monté la partition en lecture seule.
sudo mount -o ro /dev/mmcblk0 /media/dubsv/data sudo extundelete --restore-all --after 1642525000 /dev/mmcblk0
Mais il ne retrouve quasiment rien... 494Mo, très loin de l'attendu!
Du coup, il me reste à investiguer photorec...
Vincent.
Le 19/01/2022 à 13:52, Vincent a écrit :
Salut Patrick,
oui, je viens de lancer la commande en supposant que c'était bien dans la seule partition /data. J'ai préféré ne pas monter la carte SD, simplement car je n'ai pas réussi à m'assurer que le point de montage ne se trouverait pas aussi dans /data...
Du coup, je me suis limité à un dd if=/dev/block/mmblk0p20 of=/dev/block/mmkbl1
Et aléa jacta est!
Là, je ne vois plus l'avancée... mais en busybox, il ne faut pas trop le lui en demander...
Je vais manger et faire autre chose en attendant!
A+ Vincent.
Le 19/01/2022 à 11:57, oliviero@club-internet.fr a écrit :
Hello Vincent,
J'arrive sur le sujet un peu après la bataille.
Tu veut copier ta carte interne ailleurs afin d'utiliser photorec, tu as un émulateur de terminal et un téléphone rooté ? Tu peut effectivement écraser ta sd non formaté avec un dd mais tu ne pourra le faire que pour un dd. ( parce que dd va repartir du début de la sd a chaque fois ) Si tu la formates et que android la monte rien ne t'empêche de faire un dd vers un fichier iso sur ta sd montée et récupérer sur ton linux cette ( ou ces iso ) de partition afin de les traiter ( voir le formatage réel et les diverses options qui pourrais être mise sur les partitions android ). Du coup tu pourra avoir des iso de toutes les partitions et pseudo partitions de ton android et chercher partout tes données ( dés fois qu'ils les planquent mais vu que c'est un téléphone rooté il est peut-être moins farfelu qu'un android totalement propriétaire. )
Patrick. De : "Vincent" A : linux06@lists.linux-azur.org Envoyé: mercredi 19 Janvier 2022 11:33 Objet : [HELP] deboires sous Android -> monter une SD card en ext4 Re,
en fait, ayant un émulateur terminal sur ce téléphone, il ne reste 'plus' qu'à monter une micro SD card en ext4 et faire un dd dessus...
Ce qui suppose de créer un point de montage hors /data le temps de faire un dd...
Mais peut-être me fais-je des noeuds au cerveau, et que je peux simplement écraser le contenu de la SD card (non formatée pour que Android ne la monte pas) avec un dd? Question subsidiaire, commen tla voir alors (pas de lsblk de mémoire sur adb et je ne crois pas non plus sous termux)
Merci, Vincent.
Le 19/01/2022 à 11:00, Vincent a écrit :
Bonjour Christophe,
J'ai quand même bien tenté une APK toxique (qui t'impose des pub), mais en fait, comme souvent, c'est bidon : il te retrouve les photos égarées et éventuellement fait une récupération sur les
partitions vfat.
Cela a été une pure perte de temps, surtout que c'est une boite
noire
dont il m'a fallu essayer de surveiller les actions, notamment en basculant en mode avion...
Pour ton lien, outre que c'est complexe, cela s'adresse aux données sur la carte SD, pas sur la mémoire interne en ext4.
Je regarde pour activer le support UMS et ainsi pouvoir monter en Read-Only la partition /data, ce qui serait nettement plus simple
pour
faire un dd...
qui est cité dans :
Je crois qu'il va me falloir faire le deuil, d'autant que j'ai
besoin
de rallumer mon téléphone, et qu'à chaque fois que je le fais, je perds un peu plus mes chances de récupération.
Bon, cela m'apprendra à laisser traîner les choses : je n'ai
toujours
pas mis en place un vrai système d'archivage.
Vincent.
Le 19/01/2022 à 10:38, CgX (Christophe) a écrit : > Bonjour, je ne saurais non plus répondre à ton problème. > > Il semble exister des applications permettant de récupérer les > fichiers effacés, mais ils sont sur le "play store" ce qui n'est
pas
> acceptable selon tes/mes critères :) > > Sinon, y'a un type qui s'est amusé à compiler ddrescue pour
android,
> mais c'est du haut-vol : >
https://ncrmnt.org/2017/05/12/data-recovery-sd-ddrescue-and-android/
> > -- > Christophe > > > Le 19/01/2022 à 09:51, Vincent a écrit : >> Bonjour, >> >> mon message ne semble pas avoir franchi le filtre anti-spam... >> >> Même si je prends toute piste, ma question est surtout : comment >> monter sous Android un carte SD temporaire en ext4? >> Pour pouvoir faire une image complète de 25 Go avec une
commande dd.
>> >> Merci, >> Vincent >> >> -------- Message transféré -------- >> Sujet : [HELP] deboires sous Android >> Date : Wed, 19 Jan 2022 01:39:52 +0100 >> Pour : Liste principale de Linux Azur >> >> >> >> >> Bonsoir, >> >> ce soir, en mode boulet distrait, j'ai voulu nettoyer ma galerie >> photos... et j'ai en fait supprimé un dossier complet!!! >> Du coup, je me prends la tête pour retrouver où sont elles
planquées...
>> >> Pas de corbeille visiblement dans cette application - c'est balot. >> >> Le téléphone est rooté, j'ai un accès complet via adb shell >> >> Je m'apprête à remplacer la carte micro SD par une plus grosse et >> vierge et faire un dd de la partition qui va bien pour ensuite la >> monter sur mon PC et lancer un photorec... >> >> Question : c'est quoi donc que la partition qui va bien? >> >> C'est de l'android 6.0.1, et : >> >> ls -al /dev/block/platform/msm_sdcc.1/by-name/ < >> lrwxrwxrwx root root 1970-01-20 08:57 DDR -> >> /dev/block/mmcblk0p4 >> lrwxrwxrwx root root 1970-01-20 08:57 aboot -> >> /dev/block/mmcblk0p5 >> lrwxrwxrwx root root 1970-01-20 08:57 boot -> >> /dev/block/mmcblk0p8 >> lrwxrwxrwx root root 1970-01-20 08:57 cache -> >> /dev/block/mmcblk0p15 >> lrwxrwxrwx root root 1970-01-20 08:57 dbi -> >> /dev/block/mmcblk0p3 >> lrwxrwxrwx root root 1970-01-20 08:57 fsc -> >> /dev/block/mmcblk0p18 >> lrwxrwxrwx root root 1970-01-20 08:57 fsg -> >> /dev/block/mmcblk0p17 >> lrwxrwxrwx root root 1970-01-20 08:57 modem -> >> /dev/block/mmcblk0p1 >> lrwxrwxrwx root root 1970-01-20 08:57 modemst1 -> >> /dev/block/mmcblk0p11 >> lrwxrwxrwx root root 1970-01-20 08:57 modemst2 -> >> /dev/block/mmcblk0p12 >> lrwxrwxrwx root root 1970-01-20 08:57 pad -> >> /dev/block/mmcblk0p10 >> lrwxrwxrwx root root 1970-01-20 08:57 persist -> >> /dev/block/mmcblk0p14 >> lrwxrwxrwx root root 1970-01-20 08:57 recovery -> >> /dev/block/mmcblk0p16 >> lrwxrwxrwx root root 1970-01-20 08:57 rpm -> >> /dev/block/mmcblk0p7 >> lrwxrwxrwx root root 1970-01-20 08:57 sbl1 -> >> /dev/block/mmcblk0p2 >> lrwxrwxrwx root root 1970-01-20 08:57 splash -> >> /dev/block/mmcblk0p6 >> lrwxrwxrwx root root 1970-01-20 08:57 ssd -> >> /dev/block/mmcblk0p19 >> lrwxrwxrwx root root 1970-01-20 08:57 system -> >> /dev/block/mmcblk0p13 >> lrwxrwxrwx root root 1970-01-20 08:57 tz -> >> /dev/block/mmcblk0p9 >> lrwxrwxrwx root root 1970-01-20 08:57 userdata -> >> /dev/block/mmcblk0p20 >> >> comme : >> mount | grep block >> /dev/block/platform/msm_sdcc.1/by-name/system /system ext4 >> ro,seclabel,relatime,discard,data=ordered 0 0 >> /dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 >>
rw,seclabel,nosuid,nodev,relatime,discard,noauto_da_alloc,data=ordered
>> 0 0 >> /dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 >> rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0 >> /dev/block/platform/msm_sdcc.1/by-name/persist /persist ext4 >> rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0 >> /dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat >>
ro,context=u:object_r:firmware_file:s0,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=cp437,iocharset=iso8859-1,shortname=lower,errors=remount-ro
>> 0 0 >> /dev/block/vold/public:179,65 /mnt/media_rw/70C9-1D12 vfat >>
rw,dirsync,nosuid,nodev,noexec,relatime,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro
>> 0 0 >> >> et : >> df >> Filesystem Size Used Free Blksize >> /dev 923.1M 96.0K 923.0M 4096 >> /sys/fs/cgroup 923.1M 12.0K 923.1M 4096 >> /mnt 923.1M 0.0K 923.1M 4096 >> /system 2.0G 503.8M 1.5G 4096 >> /data 25.0G 9.5G 15.5G 4096 >> /cache 629.5M 10.0M 619.5M 4096 >> /persist 4.9M 4.8M 92.0K 4096 >> /firmware 64.0M 56.2M 7.8M 16384 >> /storage 923.1M 0.0K 923.1M 4096 >> /mnt/runtime/default/emulated 25.0G 9.5G 15.5G 4096 >> /storage/emulated 25.0G 9.5G 15.5G 4096 >> /mnt/runtime/read/emulated 25.0G 9.5G 15.5G 4096 >> /mnt/runtime/write/emulated 25.0G 9.5G 15.5G 4096 >> /mnt/media_rw/70C9-1D12 7.3G 1.6G 5.7G 32768 >> /mnt/runtime/default/70C9-1D12 7.3G 1.6G 5.7G 32768 >> /storage/70C9-1D12 7.3G 1.6G 5.7G 32768 >> /mnt/runtime/read/70C9-1D12 7.3G 1.6G 5.7G 32768 >> /mnt/runtime/write/70C9-1D12 7.3G 1.6G 5.7G 32768 >> >> Et que j'ai lu que ce serait /data qui contiendrait les fichiers >> supprimés (et à priori bien plus au vu de la taille, je me dis
qu'un :
>> dd if=/dev/block/platform/msm_sdcc.1/by-name/userdata >> of=/storage/nom_de_la_SD_externe/SOS >> >> Devrait le faire si je trouve une micro SD assez grosse... sauf >> qu'il me semble que c'est du vfat... >> >> Une idée? >> >> Merci, >> Vincent / boulet >> > _______________________________________________
Linux06 mailing list Linux06@lists.linux-azur.org https://lists.linux-azur.org/mailman/listinfo/linux06 Attention, les archives sont publiques
Linux06 mailing list Linux06@lists.linux-azur.org https://lists.linux-azur.org/mailman/listinfo/linux06 Attention, les archives sont publiques
Salut
(c'est terrible ce top-post...) J'ai tenté testdisk, Testdisk voit que j'ai écrasé 2 partitions sur ma carte SD en dupliquant l'image /data avec dd... De ma compréhension, il faut l'appliquer sur le périphérique initial, pas sur une copie / image dd... Hors, le stockage interne du téléphone n'est pas accessible via le port USB sans monter le système Android (qui gère le port USB), et le seul moyen aurait été de passer en mode UMS (USB Mass Storage) qui n'existe plus sur Android depuis la version 3... Il faudrait donc le réinstaller... ce qui suppose de reécrire dessus!
C'est beaucoup plus simple avec une carte SD... Même si souvent moins fiable, elle permet un transfert plus simple et dans mon cas une analyse complète.
A la réflexion, c'est certainement l'utilisation de l'APK grand public qui a ruiné mes chances de récupération, simplement car elle ne te permet pas d'écrire ailleurs que sur le stockage interne... et recopie donc tout ce qu'elle trouve comme image sur l'arborescence et les duplique dans un nouveau dossier : une véritable merde!!
En conclusion (car je n'y crois plus) : - faire des sauvegardes (ce que je répète à tout le monde... hum), - choisir une application qui permet d'écrire sur la carte SD (oui, en VFAT sur Android... du moins pour l'instant),
Dernier point : faire des sauvegardes!
A+ Vincent.
Le 20/01/2022 à 05:01, Sylvio DESJARDINS a écrit :
Salut à toutes et tous,
J'ai fait une récupération de jpg avec testdisk en mode non destructif depuis une carte sd il y a 1 an et demi et j'ai le souvenir que j'ai pu sélectionner le type de fichiers (extension) à récupérer. https://www.jng-web.com/labo/recuperer-des-fichiers-avec-testdisk/ https://www.jng-web.com/labo/recuperer-des-fichiers-avec-testdisk/
Je me souviens aussi que j'ai dû mentionner le système de fichiers facilement identifiable avec gpart ou gparted si on a un doute.
Gnument vôtre, Sylvio
Le 19 janvier 2022 15:42:31 GMT+01:00, Vincent dubsv@free.fr a écrit :
Bon, je confirme l'impression : find . -iname '*.jpg' -size +2M | wc -l 162 162 fichiers au lieu de 3600... ce ne sont pas les bons! P'tet d'abord un testdisk avant? Des pistes? Le 19/01/2022 à 15:26, Vincent a écrit : Alors photorec... très rapide, 7Go de fichiers récupérés... Mais je n'ai pas l'impression qu'il ait récupéré mes 3600 grosses photos... Il me semblait qu'il fallait faire plusieurs passes avec photorec, je m'attendais à quelque chose de plus complexe, mais moins boite noire. De même, il me semblait qu'on pouvait lui spécifié de ne chercher que les *.jpg Ma mémoire me fait défaut, si l'un d'entre vous est encore au niveau sur cet utilitaire Le 19/01/2022 à 14:49, Vincent a écrit : Bon, sur le PC, après avoir monté la partition en lecture seule. sudo mount -o ro /dev/mmcblk0 /media/dubsv/data sudo extundelete --restore-all --after 1642525000 /dev/mmcblk0 Mais il ne retrouve quasiment rien... 494Mo, très loin de l'attendu! Du coup, il me reste à investiguer photorec... Vincent. Le 19/01/2022 à 13:52, Vincent a écrit : Salut Patrick, oui, je viens de lancer la commande en supposant que c'était bien dans la seule partition /data. J'ai préféré ne pas monter la carte SD, simplement car je n'ai pas réussi à m'assurer que le point de montage ne se trouverait pas aussi dans /data... Du coup, je me suis limité à un dd if=/dev/block/mmblk0p20 of=/dev/block/mmkbl1 Et aléa jacta est! Là, je ne vois plus l'avancée... mais en busybox, il ne faut pas trop le lui en demander... Je vais manger et faire autre chose en attendant! A+ Vincent. Le 19/01/2022 à 11:57, oliviero@club-internet.fr a écrit : Hello Vincent, J'arrive sur le sujet un peu après la bataille. Tu veut copier ta carte interne ailleurs afin d'utiliser photorec, tu as un émulateur de terminal et un téléphone rooté ? Tu peut effectivement écraser ta sd non formaté avec un dd mais tu ne pourra le faire que pour un dd. ( parce que dd va repartir du début de la sd a chaque fois ) Si tu la formates et que android la monte rien ne t'empêche de faire un dd vers un fichier iso sur ta sd montée et récupérer sur ton linux cette ( ou ces iso ) de partition afin de les traiter ( voir le formatage réel et les diverses options qui pourrais être mise sur les partitions android ). Du coup tu pourra avoir des iso de toutes les partitions et pseudo partitions de ton android et chercher partout tes données ( dés fois qu'ils les planquent mais vu que c'est un téléphone rooté il est peut-être moins farfelu qu'un android totalement propriétaire. ) Patrick. De : "Vincent" A : linux06@lists.linux-azur.org Envoyé: mercredi 19 Janvier 2022 11:33 Objet : [HELP] deboires sous Android -> monter une SD card en ext4 Re, en fait, ayant un émulateur terminal sur ce téléphone, il ne reste 'plus' qu'à monter une micro SD card en ext4 et faire un dd dessus... Ce qui suppose de créer un point de montage hors /data le temps de faire un dd... Mais peut-être me fais-je des noeuds au cerveau, et que je peux simplement écraser le contenu de la SD card (non formatée pour que Android ne la monte pas) avec un dd? Question subsidiaire, commen tla voir alors (pas de lsblk de mémoire sur adb et je ne crois pas non plus sous termux) Merci, Vincent. Le 19/01/2022 à 11:00, Vincent a écrit : Bonjour Christophe, J'ai quand même bien tenté une APK toxique (qui t'impose des pub), mais en fait, comme souvent, c'est bidon : il te retrouve les photos égarées et éventuellement fait une récupération sur les partitions vfat. Cela a été une pure perte de temps, surtout que c'est une boite noire dont il m'a fallu essayer de surveiller les actions, notamment en basculant en mode avion... Pour ton lien, outre que c'est complexe, cela s'adresse aux données sur la carte SD, pas sur la mémoire interne en ext4. Je regarde pour activer le support UMS et ainsi pouvoir monter en Read-Only la partition /data, ce qui serait nettement plus simple pour faire un dd... qui est cité dans : Je crois qu'il va me falloir faire le deuil, d'autant que j'ai besoin de rallumer mon téléphone, et qu'à chaque fois que je le fais, je perds un peu plus mes chances de récupération. Bon, cela m'apprendra à laisser traîner les choses : je n'ai toujours pas mis en place un vrai système d'archivage. Vincent. Le 19/01/2022 à 10:38, CgX (Christophe) a écrit : Bonjour, je ne saurais non plus répondre à ton problème. Il semble exister des applications permettant de récupérer les fichiers effacés, mais ils sont sur le "play store" ce qui n'est pas acceptable selon tes/mes critères :) Sinon, y'a un type qui s'est amusé à compiler ddrescue pour android, mais c'est du haut-vol : https://ncrmnt.org/2017/05/12/data-recovery-sd-ddrescue-and-android/ <https://ncrmnt.org/2017/05/12/data-recovery-sd-ddrescue-and-android/> -- Christophe Le 19/01/2022 à 09:51, Vincent a écrit : Bonjour, mon message ne semble pas avoir franchi le filtre anti-spam... Même si je prends toute piste, ma question est surtout : comment monter sous Android un carte SD temporaire en ext4? Pour pouvoir faire une image complète de 25 Go avec une commande dd. Merci, Vincent -------- Message transféré -------- Sujet : [HELP] deboires sous Android Date : Wed, 19 Jan 2022 01:39:52 +0100 Pour : Liste principale de Linux Azur Bonsoir, ce soir, en mode boulet distrait, j'ai voulu nettoyer ma galerie photos... et j'ai en fait supprimé un dossier complet!!! Du coup, je me prends la tête pour retrouver où sont elles planquées... Pas de corbeille visiblement dans cette application - c'est balot. Le téléphone est rooté, j'ai un accès complet via adb shell Je m'apprête à remplacer la carte micro SD par une plus grosse et vierge et faire un dd de la partition qui va bien pour ensuite la monter sur mon PC et lancer un photorec... Question : c'est quoi donc que la partition qui va bien? C'est de l'android 6.0.1, et : ls -al /dev/block/platform/msm_sdcc.1/by-name/ < lrwxrwxrwx root root 1970-01-20 08:57 DDR -> /dev/block/mmcblk0p4 lrwxrwxrwx root root 1970-01-20 08:57 aboot -> /dev/block/mmcblk0p5 lrwxrwxrwx root root 1970-01-20 08:57 boot -> /dev/block/mmcblk0p8 lrwxrwxrwx root root 1970-01-20 08:57 cache -> /dev/block/mmcblk0p15 lrwxrwxrwx root root 1970-01-20 08:57 dbi -> /dev/block/mmcblk0p3 lrwxrwxrwx root root 1970-01-20 08:57 fsc -> /dev/block/mmcblk0p18 lrwxrwxrwx root root 1970-01-20 08:57 fsg -> /dev/block/mmcblk0p17 lrwxrwxrwx root root 1970-01-20 08:57 modem -> /dev/block/mmcblk0p1 lrwxrwxrwx root root 1970-01-20 08:57 modemst1 -> /dev/block/mmcblk0p11 lrwxrwxrwx root root 1970-01-20 08:57 modemst2 -> /dev/block/mmcblk0p12 lrwxrwxrwx root root 1970-01-20 08:57 pad -> /dev/block/mmcblk0p10 lrwxrwxrwx root root 1970-01-20 08:57 persist -> /dev/block/mmcblk0p14 lrwxrwxrwx root root 1970-01-20 08:57 recovery -> /dev/block/mmcblk0p16 lrwxrwxrwx root root 1970-01-20 08:57 rpm -> /dev/block/mmcblk0p7 lrwxrwxrwx root root 1970-01-20 08:57 sbl1 -> /dev/block/mmcblk0p2 lrwxrwxrwx root root 1970-01-20 08:57 splash -> /dev/block/mmcblk0p6 lrwxrwxrwx root root 1970-01-20 08:57 ssd -> /dev/block/mmcblk0p19 lrwxrwxrwx root root 1970-01-20 08:57 system -> /dev/block/mmcblk0p13 lrwxrwxrwx root root 1970-01-20 08:57 tz -> /dev/block/mmcblk0p9 lrwxrwxrwx root root 1970-01-20 08:57 userdata -> /dev/block/mmcblk0p20 comme : mount | grep block /dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,seclabel,relatime,discard,data=ordered 0 0 /dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 rw,seclabel,nosuid,nodev,relatime,discard,noauto_da_alloc,data=ordered 0 0 /dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0 /dev/block/platform/msm_sdcc.1/by-name/persist /persist ext4 rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0 /dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat ro,context=u:object_r:firmware_file:s0,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=cp437,iocharset=iso8859-1,shortname=lower,errors=remount-ro 0 0 /dev/block/vold/public:179,65 /mnt/media_rw/70C9-1D12 vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0 et : df Filesystem Size Used Free Blksize /dev 923.1M 96.0K 923.0M 4096 /sys/fs/cgroup 923.1M 12.0K 923.1M 4096 /mnt 923.1M 0.0K 923.1M 4096 /system 2.0G 503.8M 1.5G 4096 /data 25.0G 9.5G 15.5G 4096 /cache 629.5M 10.0M 619.5M 4096 /persist 4.9M 4.8M 92.0K 4096 /firmware 64.0M 56.2M 7.8M 16384 /storage 923.1M 0.0K 923.1M 4096 /mnt/runtime/default/emulated 25.0G 9.5G 15.5G 4096 /storage/emulated 25.0G 9.5G 15.5G 4096 /mnt/runtime/read/emulated 25.0G 9.5G 15.5G 4096 /mnt/runtime/write/emulated 25.0G 9.5G 15.5G 4096 /mnt/media_rw/70C9-1D12 7.3G 1.6G 5.7G 32768 /mnt/runtime/default/70C9-1D12 7.3G 1.6G 5.7G 32768 /storage/70C9-1D12 7.3G 1.6G 5.7G 32768 /mnt/runtime/read/70C9-1D12 7.3G 1.6G 5.7G 32768 /mnt/runtime/write/70C9-1D12 7.3G 1.6G 5.7G 32768 Et que j'ai lu que ce serait /data qui contiendrait les fichiers supprimés (et à priori bien plus au vu de la taille, je me dis qu'un : dd if=/dev/block/platform/msm_sdcc.1/by-name/userdata of=/storage/nom_de_la_SD_externe/SOS Devrait le faire si je trouve une micro SD assez grosse... sauf qu'il me semble que c'est du vfat... Une idée? Merci, Vincent / boulet ------------------------------------------------------------------------ ------------------------------------------------------------------------
On 20/01/2022 09:31, Vincent wrote:
Salut
(c'est terrible ce top-post...) J'ai tenté testdisk, Testdisk voit que j'ai écrasé 2 partitions sur ma carte SD en dupliquant l'image /data avec dd... De ma compréhension, il faut l'appliquer sur le périphérique initial, pas sur une copie / image dd... Hors, le stockage interne du téléphone n'est pas accessible via le port USB sans monter le système Android (qui gère le port USB), et le seul moyen aurait été de passer en mode UMS (USB Mass Storage) qui n'existe plus sur Android depuis la version 3... Il faudrait donc le réinstaller... ce qui suppose de reécrire dessus!
C'est beaucoup plus simple avec une carte SD... Même si souvent moins fiable, elle permet un transfert plus simple et dans mon cas une analyse complète.
A la réflexion, c'est certainement l'utilisation de l'APK grand public qui a ruiné mes chances de récupération, simplement car elle ne te permet pas d'écrire ailleurs que sur le stockage interne... et recopie donc tout ce qu'elle trouve comme image sur l'arborescence et les duplique dans un nouveau dossier : une véritable merde!!
En conclusion (car je n'y crois plus) :
- faire des sauvegardes (ce que je répète à tout le monde... hum),
- choisir une application qui permet d'écrire sur la carte SD (oui, en
VFAT sur Android... du moins pour l'instant),
Dernier point : faire des sauvegardes!
A+ Vincent.
Salut Vincent,
J'ai suivi tes déboires et cela me conforte dans mon utilisation de nextcloud pour la sauvegarde des photos.
Mon mobile précédent n'a jamais redémarré et je n'ai donc pu accéder à mes données dessus, mais je n'ai pas perdu mes photos.
A chaque fois que je me connecte en wifi, l'application nextcloud sauvegarde mes photos en les organisant dans des sous répertoire par date sur mon serveur nextcloud autohebergé. Je préfère ce mode à la synchronisation complète que je deteste franchement, avec sa propension à remplir mon téléphone avec les photos archivées il y a des lustres...
Ceci dit cela repousse le problème de sauvegarde un cran plus loin : il faut que je sauvegarde régulièrement mes données nextcloud de mon raspberry pi...
Salut Philippe,
Le 20/01/2022 à 14:50, philippe lhardy a écrit :
En conclusion (car je n'y crois plus) :
- faire des sauvegardes (ce que je répète à tout le monde... hum),
- choisir une application qui permet d'écrire sur la carte SD (oui, en
VFAT sur Android... du moins pour l'instant),
Dernier point : faire des sauvegardes!
Ce que j'ai omis : ne JAMAIS faire confiance à des applications propriétaires grand public! je suis plus que certain que c'est son utilisation qui a tué la récupération.
Salut Vincent,
J'ai suivi tes déboires et cela me conforte dans mon utilisation de nextcloud pour la sauvegarde des photos.
Mon mobile précédent n'a jamais redémarré et je n'ai donc pu accéder à mes données dessus, mais je n'ai pas perdu mes photos.
Car certainement sur la carte SD... configuration qui n'a pas fonctionné sur mon FairphoneOPEN...
A chaque fois que je me connecte en wifi, l'application nextcloud sauvegarde mes photos en les organisant dans des sous répertoire par date sur mon serveur nextcloud autohebergé. Je préfère ce mode à la synchronisation complète que je deteste franchement, avec sa propension à remplir mon téléphone avec les photos archivées il y a des lustres...
Oui, c'est ce que je souhaitais, mais il y a un bug avec l'application Nextcloud de F-Droid sur mon OS
Ceci dit cela repousse le problème de sauvegarde un cran plus loin : il faut que je sauvegarde régulièrement mes données nextcloud de mon raspberry pi...
Oui, mais c'est déjà nettement moins fragile.
A propos, je viens de retenter un réputé simple système de sauvegarde : Syncthing. Bon, évidemment, cela ne fonctionne pas avec mon fairphoneOPEN...
A+ Vincent.
Le 20/01/2022 à 15:19, Vincent a écrit :
Salut Philippe,
Le 20/01/2022 à 14:50, philippe lhardy a écrit :
En conclusion (car je n'y crois plus) :
- faire des sauvegardes (ce que je répète à tout le monde... hum),
- choisir une application qui permet d'écrire sur la carte SD (oui, en
VFAT sur Android... du moins pour l'instant),
Dernier point : faire des sauvegardes!
Ce que j'ai omis : ne JAMAIS faire confiance à des applications propriétaires grand public! je suis plus que certain que c'est son utilisation qui a tué la récupération.
Salut Vincent,
J'ai suivi tes déboires et cela me conforte dans mon utilisation de nextcloud pour la sauvegarde des photos.
Mon mobile précédent n'a jamais redémarré et je n'ai donc pu accéder à mes données dessus, mais je n'ai pas perdu mes photos.
Car certainement sur la carte SD... configuration qui n'a pas fonctionné sur mon FairphoneOPEN...
A chaque fois que je me connecte en wifi, l'application nextcloud sauvegarde mes photos en les organisant dans des sous répertoire par date sur mon serveur nextcloud autohebergé. Je préfère ce mode à la synchronisation complète que je deteste franchement, avec sa propension à remplir mon téléphone avec les photos archivées il y a des lustres...
Oui, c'est ce que je souhaitais, mais il y a un bug avec l'application Nextcloud de F-Droid sur mon OS
Ceci dit cela repousse le problème de sauvegarde un cran plus loin : il faut que je sauvegarde régulièrement mes données nextcloud de mon raspberry pi...
Oui, mais c'est déjà nettement moins fragile.
A propos, je viens de retenter un réputé simple système de sauvegarde : Syncthing. Bon, évidemment, cela ne fonctionne pas avec mon fairphoneOPEN...
A+ Vincent.
Salut Philippe et Vincent
Je confirme et atteste que l'utilisation de NextCloud pour le système de sauvegarde est une très bonne solution, je l'utilise également en auto-hébergement, pour mes photos de téléphone, mes papiers, toute mon administration, etc...
Mais même Nextcloud n'est pas parfait et on est jamais à l'abri d'un bug ou d'une erreur humaine.
Je complète donc avec une sauvegarde journalière et automatique de l'ensemble de mon Nextcloud dans un dépôt BorgBackup incrémental. J'y garde les données des 7 derniers jours + 4 snapshots du mois précédent + 12 snapshots des 12 derniers mois.
BorgBackup faisant de la compression et de la déduplication, le stockage de tout ça représente environ 4x le volume de données utilisées par mon instance Nextcloud. Pas si énorme.
Ça m'a bien servi récemment, car après une erreur humaine de ma part, j'avais perdu récemment 500Mo de données importantes sur mon instance, que j'ai pu récupérer en remontant un snapshot d'il y a deux mois !
Depuis je chante les louanges de la sauvegarde incrémentale :-)
PS : Et comme je suis parano et que j'aime mettre ceinture et bretelles, je fais en plus une sauvegarde annuelle (et chiffrée) du dépôt borg sur un disque dur externe, que je range éteint, dans un tiroir se trouvant à un autre endroit physique que chez moi (en cas d'incendie par exemple)
-- Christophe