Reprise du message précédent :
C'est le "grand problèmes" des solutions de chiffrement : en cas de problème les chances de récupérer ses données sont réduite à néant car c'est justement leur but que de les empêcher.
Je ne peut hélas pas t'aider plus que the_chosen_one
Il me semble que TC en mode disque chiffre aussi les tables des partitions et autres MBR.
Réussir une récupération des données semble hélas de l'ordre de l'impossible sans sauvegarde du header.
Après si tu avais eu une sauvegarde du header, je pense qu'une édition hexadécimale du disque aurait été peut-être possible, mais cela dépasse de loin mes compétences en cryptanalyse.
Désolé pour toi.

Merci The_chosen_one pour avoir essayé, super sympa
Merci Limdul  
 
En fait ce n'est pas le disque mais une partition qui a la taille du disque, parait cela a son importance.
"select device" et ensuite "\Device\Harddisk1\Partition1"
je transférais mes données sur un nouveau disque qui se créait pour l'occasion.  
 
Je suis allé voir un magasin informatique, le gars a essayé avec son "équipement pro" Linux et Win de voir le souci.
Sa réponse : "Erreur Smart/ Partionnement"
il m'a donné les coordonnées d'une entreprise de récupérations de données avec une chambre blanche afin d'ouvrir le disque dur.
Le prix c'est "inhumain" lol
 
que signifie : "Partition non allouée"?
 
Encore merci, je vais mieux, j'ai passé 48 heures affreuses, c'est vraiment un choc, j'avais tout dedans et j'allais juste après avoir reformat le pc, faire cette sauvegarde, je regrette

Hum ... si c'est bien une erreur SMART alors c'est un tout autre soucis, cela veut dire que c'est un problème matériel.
Tu peux vérifier que c'est un problème SMART avec des petits tools genre http://www.almico.com/speedfan.php
Est-ce que tu as tenté le recovery de EAESUS ? ça vaut le coup de tenter quand même.

Tiens, tu peux aussi tester ce tool : http://computer-forensics.sans.org [...] -version-2
Ca n'a pas l'air de faire la récupération, mais s'il detecte bien le disque, y'a de bonnes chances que les données soient toujours là.

(bien sûr après imaging )

Merci The_chosen_one des Hautes Terres
 
Je vais faire le test avec EDD et SpeedFan, bien vu.
Dommage que recovery de EAESUS soit payant.
 
Petite question stp : Erreur Smart c'est donc matériel, cela signifie aussi que seule une boite de récupération va pouvoir m'aider en sortant les disques internes.
Si "il detecte bien le disque, y'a de bonnes chances que les données soient toujours là."

J'ai une version gratuite (home) de eaesus partition manager, dedans y'a une option "recover partition", c'est de ça que je parlais

Oui, cela à de l'importance (quand on dit de donner toutes les info... en informatique on a rarement trop de renseignements)
 
Donc dans le gestionnaire de disque : la couleur de ta partition c'est noir "Non alloué" ou un kaki "raw" ou "non formaté" ?
 
Car si la partition est existante mais non formatée où d'un type non reconnu alors là tu as plus de chance avec un éditeur héxadécimal de pouvoir éditer le début de la partition pour tenter de "réparer" ton volume (après naturellement en avoir fais une copie bit à bit pour pouvoir revenir en arrière).
Je te conseillerai de regarder la documentation officielle de TC, notamment cette page http://www.truecrypt.org/docs/volu [...] cification qui te décrit le format des entêtes. En comparant avec un volume créé de la même façon tu pourrai peut-être reconnaitre certaines zones et les réparer.
Cela à la condition que ces zones ne soient pas chiffrées (or il me semble que les entêtes sont entièrement chiffré mais je n'en suis pas sûr).
 
Toujours est-il qu'en cas de problème de disque cela te permet de réparer plus facilement les zones en dehors de ton volume si c'est une partition qui a été chiffrée et non le disque.
Sans vouloir te donner de vains espoirs tu à peut-être éventuellement une petite chandelle d'espérance qui s'est allumée sur la face cachée de Pluton

Bonsoir LimDul, merci pour ton post
Ravi que cette info aille dans le bon sens.
 
la couleur est noire
Je l'ai branché sur un autre pc, c'est noire aussi, il a été reconnu puis installé par win puis ensuite disparu aussi vite.
Hier soir je l'ai installé sur ce pc et win7 ne démarrait pas mais le pc tournait. j’espère que j'ai pas aggravé les choses.
 
Avec WinHex je peux faire la copie bit par bit?
 
Je vois les lignes Offset du DD, est ce normal d'avoir des chiffres et lettres par 2 sur 15 ieres lignes  
et ensuite que des paires de 0...  
pour ensuite bien plus bas, des chiffres et lettres?
 
là j'ai essayé de refaire Début: 32256 End: 237055:
"Incorrect password or not a TrueCrypt volume"
et maintenant : 1048576 End: 1253375  
74 minutes a attendre, ca fait un gros fichier .tc
 
J'ai appris que j'avais fait une faute classique mais qui n'est pas reportée sur le site de TrueCrypt,  
SURTOUT ne pas oublier de débrancher le disque dur encrypté lors d'une réinstallation de Windows

S'il est noir c'est très très mauvais signe.
Car il faudrait réussir à réparer le header (ce que déjà je ne sais pas faire je le rappel) mais en plus réparer le MBR et la table des partition qui sont chiffrés.
Et qui dit chiffrés...
 
"SURTOUT ne pas oublier de débrancher le disque dur encrypté lors d'une réinstallation de Windows"
J'en déduit que tu avais chiffré ton disque entièrement, lors de sa réinstallation windows à gentiment foutu le bordel.
Pour moi c'est foutu, j'espère que tu avais une sauvegarde.
Sinon il reste les services professionnels, tu vas payer une fortune (surtout si c'est chiffré) sans aucune garantie de résultat.
Et quand je dit une fortune, c'est au delà du millier d'euro...
Ya pas vraiment de limite haute dans ce domaine :-(

J'ai quand même beaucoup de mal a voir le rapport avec la reinstall de windows...
A moins qu'on ne parle d'une partition sur le même disque que le disque système, sorti de ça....

+1

Je ne m'étonne plus des bizarreries que peut faire Windows...

J'ai eu exactement le même problème il y a quelques années. Du coup je n'ai jamais utilisé TrueCrypt sérieusement de peur que ça m'arrive à nouveau. Si on ne peut pas compter sur une sauvegarde ça revient à ne pas pouvoir en faire.

Tous les programmes ont des bug.
Mais un conteneur créé sur un poste peut être ouvert sur tout les ordinateurs possibles, du moment que tu as la bonne version de TC.
J'avoue que je n'explique pas le problème avec les informations données et je n'ai pas été confronté au problème bien qu’utilisant TC sur différents PC.

Ça peut venir de l'OS, j'avais testé entre winXP et Win7 à l'époque. Comme tu le dis tous les programmes ont des bugs mais avec TrueCrypt on ne peut pas compter sur la sauvegarde.
J'avais fait des checksums pour être sûr que les 2 PC utilisaient le même conteneur, je peux donc affirmer que ça vient bien du programme lui-même mais je n'en sais pas plus car ce problème n'apparait pas à chaque fois non plus.

Et avec une versions mobile ?
(la même version mobile utilisée sur les deux PC différents)
Car il y a peut être dans l'installation eu un truc, une petite différence expliquant le bug.

Le problème est que c'est difficilement reproductible. Je tenterai cette manip la prochaine fois que ça arrive. Il va falloir que je joue un peu plus avec TrueCrypt dans ce cas.

drapal

Bonjour, je post ici car par mal de passionné de sécurité !
 
Je m’inquiète d'une chose, c'est qu'on puisse me voler les 2 ou 3 fichier de firefox qui stocke mes mots de passes, il suffit de les copier coller sur un firefox vierge et remplacer les fichier pour que le pirate puisse voir les mots de passes en clair dans les options de sécurité  ???

passionné de sécurité et stockage des mots de passe par firefox ...  
 
un peu contradictoire, non ?

 
Il parlait du topic - il y a des passionnés de la sécurité, pour qui il a une question je pense

ah ! ça peut aussi se comprendre comme ça

sinon pour tes mdp, tu désactives l'enregistrement auto dans firefox, tu installes keepass 2 et keefox.

Et là tu recrée tout tes mdp avec le générateur aléatoire.

Pour pousser le truc plus loin, tu synchronises ton fichier *.kbx avec drive/dropbox/ftp ... et tu installes l'appli android/ios qui va bien. Et comme ça tu as toujours tout tes mots de passe avec toi !

Ya une faille : Dropbox est une société soumise au patriot act et donc tes fichiers sont lisible par qui le veut du gouvernement US. Et cela même s'il te disent que les serveur sont en France.
Toute filiale dépendant d'une société de droit US même étrangère dois s'y soumettre.
Donc si tu veut sécuriser vraiment tu utilise pas Dropbox.
Je te laisse réviser Echelon, Carnivore, Prism etc etc...
Bonus : https://prism-break.org/fr/

oui c'est sur que dropbox c'est pas le plus sur  
 
mais si t'as mis un truc costaud pour en passphrase, ils vont mettre un moment à tout déchiffrer  ^^
 
après si tu veux vraiment le truc hyper sécuriser, je pense qu'il faut partir sur un serveur perso avec un transfert ssh

Ils ont d'ailleurs avoué lire les fichiers pour procéder à du dédoublement de fichier et alléger ainsi leur stockage.

On peut utiliser OwnCloud à la place de dropbox

Je ne connaissais pas encore.
C'est assez alléchant.

limdul : si t'as un accès complet au serveur, laisse tomber owncloud et essaye Seafile (www.seafile.com) c'est juste 100x plus fiable/stable :
- chiffrement local (pas distant)
- ça tient bien la charge car ça ne passe pas par webdav sur Apache mais par un service spécifique dédié à la synchro

 
 
Bon j'ai un petit problème sur l'utilisation du couple TrueCrypt / Cobian Backup.
 
Pour être sûr de toujours disposer d'une sauvegarde récente et accessible de mon container TrueCrypt, j'ai planifié une sauvegarde hebdomadaire par copie sur un emplacement réseau dans Cobian Backup. La sauvegarde se fait entre 12h et 14h, le vendredi, quand je ne suis pas devant le PC.  
 
Comme je suis flemmard, j'ai programmé le lancement d'un bat dans Cobian Backup, afin que le volume soit démonté avant copie. Mais apparemment, le script ne fonctionne pas lorsqu'il est lancé par Cobian Backup. Par contre, si je le lance manuellement, le volume en question est bien démonté.
 
Une idée sur le truc qui déconne ? Le script en question:
 

 
En outre j'ai besoin d'une confirmation : lorsque je jette un œil aux attributs du container, la date de dernière édition ne change pas : est-ce normal?
 
Merci pour vos avis éclairés

Pour le script, regarde si en mettant le chemin complet ver l'exe ça marche mieux ou pas.
Sinon teste en mettant juste /d à la place de /dt
 
 
Pour les attributs de date du conteneur c'est normal et c'est voulu (question de sécurité pour faciliter le déni plausible).
Si t'as vraiment besoin regarde dans les options ya la case a cocher/décocher qui va bien.

c'est quand même moins sécurisant de sauvegarder un container démonté plutôt que le contenu du container monté. si ton container s'est corrompu entre deux copies, la dernière copie qui sera inutilisable écrasera malheureusement l'avant dernière copie saine (dans un processus de sauvegarde simple)

C'est vrai, et j'aurai du le préciser : sauvegarder le contenu et non le conteneur.
Merci d'avoir corrigé cet oubli.

Merci pour vos réponses, je testerai les modifs de script dès demain.
 
Concernant la sauvegarde, une défaillance à la copie devrait être assez rare : en tout cas suffisamment pour moi, si on l'associe aux chances de corruption du container.  
 
Surtout que, dans mon usage, le container est une sorte de disque local sur lequel je stocke tous les documents dont j'ai besoin lorsque je suis en déplacement : il est donc tout le temps ouvert à partir du moment où j'ouvre ma session (et que je rentre le mot de passe). S'il est corrompu, je peux m'en rendre compte très rapidement.

Je viens de voir : page 100 !
Faites péter le mousseux !

Y'a pas eu de nouvelle version de truecrypt depuis un bail, c'est dommage quand même de fêter la page 100 avec une build aussi vieille :-(
 
Fêtage au café de Paris ou au Paul Rémy de pochetron alors...

J'espère qu'avec W8 un nouvelle version va sortir.
Ne serai-ce que pour l'interface tactile mais surtout pour les différences entre 7 et 8 plus grandes qu'entre Vista et 7.
 
Mais je doute qu'une nouvelle version majeures sorte (sauf pour interface tactile).
TC est pas mal stable déjà, l'AES est déjà accéléré par les proc et cela est déjà pris en charge.
 
Des versions pour téléphone mobile peut-être ?
 
Et vous qu'attendez-vous comme nouveauté ?

Rapide sans trop pousser la réflexion :
- Chiffrement des partitions SANS les bloquer pendant la procédure (il est capable de le faire pour la partition système mais pas les non systèmes : wtf ? 3 jours bloqués pour chiffrer mon raid 0 2x2To)
- une vraie version installable avec un service ou équivalent mieux intégré à l'os, capable de mieux gérer les favoris pour te demander un pass "après le boot" sans bloquer des softs qui cherchent à accéder à la partition en question (pas facile à expliquer, mais en gros si tu veux 2 pass différents entre ta partition système et d'autres ben c'est mort actuellement). Autre exemple plus clair : partition système non chiffrée + partage de dossier (local Windows) sur une partition chiffrée = à chaque reboot le partage saute, à chaque reboot les applis genre dropbox perdent les pédales si le dossier à synchro est situé sur la partition chiffrée.
- meilleure gestion des claviers non US pour la partition système et favoris : si tu fais une partition système chiffrée + une seconde non système que tu veux monter au boot, la première doit avoir un pass en clavier FR, la seconde en clavier US... wtf !?!
- interface un poil plus claire (gestion des favoris par ex)
- un backup automatique des headers juste après la création d'un volume
- une soluce (me demande pas comment, peut être via un rapprochement avec MS) pour éviter les écrasements de partitions chiffrées lors de l'install de Windows (ou un truc pour restaurer ce qui a été ecrasé)
- une soluce pour faire sauter la demande de Windows de formater la partition chiffrée sans avoir à aller manuellement désallouer la lettre de lecteur (genre tu chiffres d:\ à la fin tu veux un d:\ chiffré et non pas un d:\ inaccessible que Windows veut formater + un montage vers e:\)
- encore plus de fiabilité (j'ai jamais compris pourquoi mon HDD de 4To a pété 3 fois son chiffrement lors du transfert (massif) de données dessus puis à fonctionné quand j'ai finalement mis le hdd dans un autre ordi et fait le transfert via réseau (beaucoup plus lent)
- il y a encore probablement moyen d'accélérer les perfs, par exemple en utilisant les ressources inexploitées de la carte graphique.
- pourquoi pas une extension du système pour synchroniser des données chiffrées (pas forcément tout un container) vers un autre ordi (lan ou web), genre tu chiffres une partition, tu veux synchro un dossier de cette partition vers un container (ou une partition) chiffrée distante. Un genre de dropbox où tu es le seul à connaître les clés. Il y a des solutions (programmes tiers genre owncloud/seafile) ou encfs sur un serveur linux, mais c'est galère à installer et tu peux avoir des soucis de montage/démontage du volume chiffré à distance.
...

Bonjour, je voudrais savoir si un jour les disques ssd seront un jour pris en charge par TC pour créer un systèmes chiffrés ?

TC prend déjà en charge les SSD.
C'est la réciproque qui n'est pas faite.
Les SSD ne sont pas adaptés aux systèmes de chiffrements. Que ce soit TC, PGP Disq ou Bit locker.
Tout ces systèmes peuvent fonctionner avec un SSD mais les SSD ne sont pas adaptés.
 
Pour te donner une autre comparaison : un type de moteur diesel peut fonctionner avec de l'huile de colza mais l'huile de colza ne peut pas fonctionner avec tout les moteurs diesel.
 
Cela à cause de la gestion de l'usure principalement.
Un SSD n'aime pas être plein.
Si tu chiffre ton disque alors pour le disque il sera intégralement rempli. Et cela pose des problèmes dans la gestion des cellules usées et de performance.
Sans compter qu'une donnée chiffrée est une donnée non compressible et donc certains chipsets perdent grandement en performance.
 
Donc pour répondre à ta question : TC prend déjà en charge les SSD comme il prend en charge n'importe quel disque dur.
Mais les SSD ne sont pas adaptés.
Charge aux constructeurs de le faire.
Et là c'est pas gagné car d'un c'est pas rentable de faire un truc pour 0,01% des clients, de deux ils préfèrent promouvoir leur propres systèmes de chiffrement.
 
 
EDIT :
Il serai d'ailleurs intéressant de pouvoir faire un test (de préférence sur un vieux SSD vu les risques), je pense qu'en laissant 10 à 20% de l'espace disponible en non partitionné (en plus de l'overprovisioning) cela devrait permettre de retarder les problèmes du à l'usure.
 
 
EDIT2 :
Je précise que cela n'est valable que si le disque est entièrement chiffré (FDE). Un volume fichier ne prenant qu'une petite fraction de l'espace disque ne devrai pas poser de problème.

Salut à tous j'ai quelques questions sur trypcrypt :
 
J’utilise trucrypt depuis plusieurs année mais pas de façon régulière, et la je voudrais crypter deux disque dur de 2 To, surtout pour évité que mes donnés ne soit à la merci de nimporte qui en cas de cambriolage.
 
- J'aimerais savoir quel sont les risques de panne ou bug que je peu rencontrer sur la durée ?
sachant que ce sont juste des disques dur de stockage normaux.
 
- j'ai souvent lu qu'il fallait aussi sauvegarder l'entete du volume, dois je le faire juste après la création de ma partition crypter ou une fois que j'aurais copier toutes les données dessus ?
 
- est ce que l’entête change chaque fois que l'on rajoute des fichiers sur le disque dur ? (à priori ça ne me semble pas logique mais sait on jamais ...
 
- Je compte me faire une copie de sauvegarde en + de mes deux disques, crypter avec filevault 2, est ce une bonne idée ou faut il vraiment garder une copie totalement "non crypter"  de ses fichiers ?
 
voila je pense que c'est a peu près tout !
 
Merci d'avance pour vos réponses