19 Jan
2022
19 Jan
'22
11:57 a.m.
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(a)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 :
_______________________________________________
Linux06 mailing list
Linux06(a)lists.linux-azur.org
https://lists.linux-azur.org/mailman/listinfo/linux06
Attention, les archives sont publiques
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 :
_______________________________________________
Linux06 mailing list
Linux06(a)lists.linux-azur.org
https://lists.linux-azur.org/mailman/listinfo/linux06
Attention, les archives sont publiques 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(a)lists.linux-azur.org
https://lists.linux-azur.org/mailman/listinfo/linux06
Attention, les archives sont publiques