Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Carte SD de telephone Android possiblement HS

saroumane_

C'est bien la neuve
elle est branchée sur le même adaptateur USB. J'ai présumé que c'était pour ça qu'elle avait le même ID

J'ai qd même relancé un dd dessus

Nuliel

Deux idées:
- as tu un autre adaptateur pour tester? (ce serait vraiment bête que ça vienne de l'adaptateur)
- les deux cartes font bien exactement la même taille? (regarde avec sudo fdisk -l et compare le nombre de secteurs si les secteurs font aussi 512 octets sur la nouvelle carte) J'ai un disque dur qui fait un poil moins qu'un téra, c'est très chiant

saroumane_

je laisse finir le dd et je regarde
Ce sont des cartes vendues pour 64Go chacune. la première est une Samsung, la nouvelle une Kingston.
Concernant l'adaptateur, c'est le seul qui me permet de voir qqch sur les cartes.
J'en ai 2 autres MicroSD to SD mais quand je les branches avec une µSD, rien n'est détecté dans le dmesg (ce qui est surprenant car l'un des 2 est neuf et vendu avec ma nouvelle µSD Kingston :/)

Nuliel

Quel est le modèle exact de pc? L'emplacement de sd doit pas être reconnu

saroumane_

il a pas de modèle.
C'est un PC acheté en kit, et j'ai rajouté un vieux lecteur de cartes branché sur un connecteur usb de la CM.
Je viens de tester avec une "vraie" carte SD et elle monte bien automatiquement. Ce sont les adaptateurs qui ne sont pas appréciés du lecteur.

Bonne nuit ;-)

Nuliel

Ok, bonne nuit

moko138

Nuliel,
En fin de #16, on lit :

jerome@xubuntu1:~/temporaire/Recup_Dir$ fdisk -l imageSD.iso
Disque imageSD.iso : 59,7 GiB, 64087916544 octets, 125171712 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : gpt
Identifiant de disque : D00574B8-8265-4413-B3CC-45062ADB05DE

Périphérique Début       Fin  Secteurs Taille Type
imageSD.iso1  2048     34815     32768    16M inconnu
imageSD.iso2 34816 125171678 125136863  59,7G inconnu
jerome@xubuntu1:~/temporaire/Recup_Dir$

1) saroumane_ n'a pas mis de "sudo" ; j'en ignore les conséquences.

Mais, à supposer que ce soit sans conséquences,

2) le fait que fdisk annonce "Type inconnu"
laisse présager que imageSD.iso ne serait pas directement exploitable.
Ce qui est logique, puisque imageSD.iso est un état intermédiaire, constitué à partir d'un support en défaut.
SI j'ai bien suivi, il faudrait dupliquer cette iso (histoire d'en garder un exemplaire intact),
puis tenter fsck sur la 2ème partition de sa copie.

3) Il y a quelquechose qui m'intrigue :
La 1ère partition
imageSD.iso1 2048 34815 32768 16M inconnu
avec ses 16 Mio, de type inconnu, ressemble à une partition MSR (MicroSoft Reserved, sans FS) telle que Windows 10 en fabrique sur les supports à gpt.

4) En #1, saroumane_ a décrit :
"quelques soucis avec mon Android (sous /e/OS).
J'ai mis un moment à comprendre que ça venait de la carte SD."
Quel FS emploie Android ?

saroumane_

Bonjour à vous 2
fdisk sur le nouveau support

jerome@xubuntu1:~/temporaire/Recup_Dir$ sudo fdisk -l /dev/disk/by-id/usb-MXT-USB_Storage_Device_130818v01-0:0 
[sudo] Mot de passe de jerome : 
Mauvaise concordance des tailles de partition du secteur d'amorçage GPT (125171711 != 121634815), elle seront corrigées par la commande w (écriture).
Disque /dev/disk/by-id/usb-MXT-USB_Storage_Device_130818v01-0:0 : 58 GiB, 62277025792 octets, 121634816 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x00000000

Périphérique                                                   Amorçage Début       Fin  Secteurs Taille Id Type
/dev/disk/by-id/usb-MXT-USB_Storage_Device_130818v01-0:0-part1              1 125171711 125171711  59,7G ee GPT
jerome@xubuntu1:~/temporaire/Recup_Dir$

fdisk sur l'ancien

jerome@xubuntu1:~/temporaire/Recup_Dir$ sudo fdisk -l /dev/disk/by-id/usb-MXT-USB_Storage_Device_130818v01-0:0 
Disque /dev/disk/by-id/usb-MXT-USB_Storage_Device_130818v01-0:0 : 59,7 GiB, 64087916544 octets, 125171712 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : gpt
Identifiant de disque : D00574B8-8265-4413-B3CC-45062ADB05DE

Périphérique                                                   Début       Fin  Secteurs Taille Type
/dev/disk/by-id/usb-MXT-USB_Storage_Device_130818v01-0:0-part1  2048     34815     32768    16M inconnu
/dev/disk/by-id/usb-MXT-USB_Storage_Devi

fdisk sur l'image (avec le sudo 😉)

jerome@xubuntu1:~/temporaire/Recup_Dir$ sudo fdisk -l imageSD.iso 
Disque imageSD.iso : 59,7 GiB, 64087916544 octets, 125171712 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : gpt
Identifiant de disque : D00574B8-8265-4413-B3CC-45062ADB05DE

Périphérique Début       Fin  Secteurs Taille Type
imageSD.iso1  2048     34815     32768    16M inconnu
imageSD.iso2 34816 125171678 125136863  59,7G inconnu
jerome@xubuntu1:~/temporaire/Recup_Dir$

Je ne sais pas quel FS utilise Android. il me semble que les étiquettes de partitions étaient "android_data" et Android_expand"

Nuliel

@moko138:
Le sudo n'est pas obligatoire sur les images disques, si fdisk n'avait pas eu assez de droits il aurait plus râlé je pense.

Je ne sais pas quel FS utilise Android. il me semble que les étiquettes de partitions étaient "android_data" et Android_expand"

Oui c'est ces deux types de partitions.

Il est possible que fdisk lui-même ne connaisse pas les partitions android_expand et android_data, donc ne peut pas non plus les reconnaître

Je ne pense pas qu'un fsck arrangera quelque chose (à faire sur une autre copie encore), il faudrait déjà essayer de demander à un autre outil pour voir s'il identifie les deux types de partitions
Tu peux faire

sudo apt install testdisk
testdisk imageSD.iso

puis choisir le média (imageSD.iso), ensuite intel, puis analyse, puis quick search, puis si aucune partition n'apparaît, faire une deeper search (en fait j'aimerais voir si les partitions apparaissent comme inconnues ou avec le vrai nom)

saroumane_

TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk imageSD.iso - 64 GB / 59 GiB - CHS 7792 255 63 (RO)

     Partition                  Start        End    Size in sectors

 1 * FAT32 LBA                0  32 33  7791 147 36  125169664 [NO NAME]

 [  Quit  ] >[Deeper Search]  [ Write  ]
                          Try to find more partitions

après deeper search

TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk imageSD.iso - 64 GB / 59 GiB - CHS 7792 255 63 (RO)

     Partition                  Start        End    Size in sectors

 1 * FAT32 LBA                0  32 33  7791 147 36  125169664 [NO NAME]









>[  Quit  ]  [ Write  ]
                              Return to main menu

Nuliel

Tu peux quitter (plusieurs fois la touche q)
Il faut que je me renseigne
J'ai trouvé https://nelenkov.blogspot.com/2015/06/decrypting-android-m-adopted-storage.html mais il y a certains points qui me posent question.
Tu as bien accès au fichier .key?
Il y a juste l'offset de l'IV que je ne comprends pas

saroumane_

Test disk en utilisant le type: EFI GPT

TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk imageSD.iso - 64 GB / 59 GiB - CHS 7792 255 63 (RO)
     Partition               Start        End    Size in sectors
>D MS Data                     2048  125171663  125169616 [NO NAME]
 D MS Data                     2050  125171665  125169616 [NO NAME]


Structure: Ok.  Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
                P=Primary  D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
     Enter: to continue
FAT32, blocksize=32768, 64 GB / 59 GiB

saroumane_

Nuliel a écritTu peux quitter (plusieurs fois la touche q)
.
Tu as bien accès au fichier .key?

Oui, j'ai réussi à le copier sur une autre carte µSD en utilisant TWRP

Nuliel

Nickel! C'est la clé privée qui normalement sert à déchiffrer la deuxième partition.

Alors voilà ce que je comprends de la fameuse commande:

dmsetup create crypt1 --table "0 `blockdev --getsize /dev/sdb2` crypt \
aes-cbc-essiv:sha256 00010203040506070809010a0b0c0d0e0f 0 /dev/sdb2 0"

`blockdev --getsize /dev/sdb2` -> peut être remplacé par 125136863, sachant que c'est bizarre d'avoir un trou entre les deux partitions
00010203040506070809010a0b0c0d0e0f -> à remplacer par ta clé privée, à récupérer par

od -t x1 cle.key

Je pense que c'est le même chiffrement, sinon il faudra trouver ce qui est utilisé (dans l'exemple, du AES en mode CBC)
Je ne sais pas à quoi servent les deux autres zéros, l'un doit correspondre à l'offset de l'IV, qui j'espère ne sera pas à deviner, l'autre je sais pas

C'est une bonne idée d'avoir installé TWRP!

saroumane_

Nuliel a écritNickel! C'est la clé privée qui normalement sert à déchiffrer la deuxième partition.

Alors voilà ce que je comprends de la fameuse commande:
dmsetup create crypt1 --table "0 `blockdev --getsize /dev/sdb2` crypt \
aes-cbc-essiv:sha256 00010203040506070809010a0b0c0d0e0f 0 /dev/sdb2 0"
`blockdev --getsize /dev/sdb2` -> peut être remplacé par 125136863, sachant que c'est bizarre d'avoir un trou entre les deux partitions

d'où tu sors cette séquence 125136863 ?
et le /dev/sdb2 en fin de commande, je le remplace par quoi ?

Nuliel a écritC'est une bonne idée d'avoir installé TWRP!

J'étais obligé pour installer /e/OS, mais effectivement c'est une bonne boite à outils bas niveau.

Nuliel

125136863 c'est théoriquement le nombre de secteurs de la deuxième partition, cela vient de la dernière commande du #28
Je pense qu'il faut remplacer /dev/sdb2 par imagsSD.iso suivi de l'offset de la deuxième partition, mais j'en suis pas sûr.
Le man de dmsetup annonce le format de commande

dmsetup create device_name [-u|--uuid uuid]
                [--addnodeoncreate|--addnodeonresume] [-n|--notable|--table
                table|table_file] [--readahead [+]sectors|auto|none]

et pour l'option table:

--table table
              Specify a one-line table directly  on  the  command  line.   See
              below for more information on the table format.

le format des tables est renseigné en dessous:

logical_start_sector num_sectors target_type target_args

Donc je dirais qu'il faut passer un truc dans le genre de

dmsetup create crypt1 --table "34816 125136863 crypt aes-cbc-essiv:sha256 LaClePrivée 0 imageSD.iso 0"

Il reste toujours les deux derniers zéros que je ne comprends pas, j'ai le droit à

To find out more about the various targets and their table formats  and
       status  lines, please read the files in the Documentation/device-mapper
       directory in the kernel source tree.  (Your distribution might  include
       a  copy  of  this  information  in  the documentation directory for the
       device-mapper package.)

reste à trouver le bon fichier

HS: j'ai l'impression qu'on peut joindre deux disques ensemble avec dmsetup, c'est visiblement un outil à tout faire

saroumane_

ça me dépasse un peu :p

jerome@xubuntu1:~/temporaire/Recup_Dir$ sudo dmsetup create crypt1 --table "34816 125136863 crypt aes-cbc-essiv:sha256 327[...]db 0 imageSD.iso 0"
[sudo] Mot de passe de jerome : 
device-mapper: reload ioctl on crypt1  failed: Argument invalide
Command failed
jerome@xubuntu1:~/temporaire/Recup_Dir$

je sais pas si j'ai bien tout récupéré de la clef ni si j'ai bien fait de supprimer les espaces:

jerome@xubuntu1:~/temporaire/Recup_Dir$ od -t x1 expand_963ec607b8c543fa96ddef69971e7782.key 
0000000 32 7[...] db
0000020
jerome@xubuntu1:~/temporaire/Recup_Dir$

Nuliel

Normalement ta clé fait fait 128 bits, soit 16 octets, donc 16x2 chiffres ou lettres
Si tu n'avais pas supprimé les espaces, les différents morceaux auraient été considéré comme des paramètres à la commande
Je continue mes recherches

Nuliel

Trouvé! https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-crypt.html
Bon, du coup je peux bien comprendre la commande, je vais proposer une autre version

Nuliel

Juste pour être sûr, avec le retour

# od -t x1 expand_8838e738a18746b6e435bb0d04c15ccd.key
0000000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0000020

la clé est donc 000102030405060708090a0b0c0d0e0f
C'est bien ce que tu as fait?

« Page précédente Page suivante »