problème d'utilisation de shred

qolepam · Le 12/06/2017, à 17:40

bonjour,

Pouvant utiliser shred sur Ubuntu 14.04 LTS,ayant lu le document suivant:

https://translate.googleusercontent.com … n6UTjtbfOA

mon but était d'effacer de façon sécurisée ma clé usb.
Dans le terminal,suite à la commande:
sudo shred -v "/media/user/USB DISK"
le terminal me répond:
échec d'ouverture en écriture: est un dossier

Que dois-je maintenant faire?

merci de votre aide

Nuliel · Le 12/06/2017, à 17:55

Bonjour,

shred est à mon avis plus adapté pour déchiqueter (c'est la traduction de shred) quelques fichiers. Pour effacer totalement une clé usb, je te conseille plutôt d'utiliser dd.
https://doc.ubuntu-fr.org/dd#effacer_un_lecteur
Bien évidemment, remplace sda par ce qu'il faut (sinon, tu effaceras le disque dur, ce serait dommage), et j'ai lu qu'une passe suffisait pour qu'on ne puisse rien récupérer (là, il y en a 7)

Edit: du coup je me pose une question: y a t'il une différence entre utiliser shred (j'avais pas vu que c'était possible) sur une clé par rapport à faire dd if=/dev/urandom vers la clé?

Dernière modification par Nuliel (Le 12/06/2017, à 18:12)

nam1962 · Le 12/06/2017, à 17:58

Branche ta clef et passe :

sudo fdisk -l

pour savoir quelle est ta clef : c'est exacement ce qui est décrit sur le lien que tu donnes !

lynn · Le 12/06/2017, à 20:50

Bonjour,

Pour faire un effaçage sécurisé

Pour un fichier

shred -n 35 -z -u fichier

Pour un répertoire

wipe -r -i -f -Q 35 -q répertoire

À utiliser avec précaution ( pas possible de récupérer quoi que ce soit après... ).
Ça peut demander beaucoup de temps pour effacer en fonction du nombre d'éléments, du support à traiter et de la puissance de la machine.

qolepam · Le 13/06/2017, à 00:38

pour la commande wipe,
le terminal me réponds:
Entering directory '/media/user/USB DISK'
Going back to directory /home/user
/media/user/USB DISK: rmdir: Permission denied
Operation finished.
0 files wiped and 0 special files ignored in 1 directory, 0 symlinks removed but not followed, 1 error occured.

là,l'effaçage n'a pu s'effectuer!
Puis-je remédier à cela?

moko138 · Le 13/06/2017, à 01:11

D'abord, clef branchée et montée, montre

mount | tail -4

qolepam · Le 13/06/2017, à 01:46

résultat:
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)
/home/jerome/.Private on /home/jerome type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=5f0fa1bb4e3e6a31,ecryptfs_fnek_sig=2b94e9621cd9cf1a)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,user=jerome)
/dev/sdb1 on /media/jerome/USB DISK type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=512)

moko138 · Le 13/06/2017, à 09:34

0) Tu devrais donner des Retour utilisable de commande.
Là, il manque des infos.

1) "/media/jerome/USB DISK", avec les guillemets, ce n'est pas
"/media/user/USB DISK", avec les guillemets.

2) Quand tu lis Permission denied, utilise sudo.

Après lecture de wipe, je pense que si tu as, directement sous "USB DISK", des fichiers à détruire, tu devrais leur appliquer shred avant wipe.

Quand tu en seras à wipe, repasse le wipe que lynn t'a indiqué en tenant compte de ces points et donne le retour complet et entre balises-code.

- -

@ tous, je ne trouve pas le man de wipe ; quelqu'un a-t-il un lien ?
Merci d'avance !

nam1962 · Le 13/06/2017, à 10:52

En voilà un vieux : https://linux.die.net/man/1/wipe

moko138 · Le 13/06/2017, à 10:59

Merci nam1962 !

lynn · Le 13/06/2017, à 15:13

Je ne crois pas qu'il y ait de man plus récent que 2010...

man wipe a écrit :

WIPE(1) User Commands WIPE(1)
NAME
wipe - securely erase files from magnetic media
SYNOPSIS
wipe [options] path1 path2 ... pathn
CURRENT-VERSION
This manual page describes version 0.22 of wipe , released November 2010.
DESCRIPTION
Recovery of supposedly erased data from magnetic media is easier than what many people would like to believe. A technique called Magnetic Force Microscopy (MFM) allows any
moderately funded opponent to recover the last two or three layers of data written to disk; wipe repeatedly overwrites special patterns to the files to be destroyed, using
the fsync() call and/or the O_SYNC bit to force disk access. In normal mode, 34 patterns are used (of which 8 are random). These patterns were recommended in an article
from Peter Gutmann (pgut001@cs.auckland.ac.nz) entitled "Secure Deletion of Data from Magnetic and Solid-State Memory". The normal mode takes 35 passes (0-34). A quick
mode allows you to use only 4 passes with random patterns, which is of course much less secure.
NOTE ABOUT JOURNALING FILESYSTEMS AND SOME RECOMMENDATIONS (JUNE 2004)
Journaling filesystems (such as Ext3 or ReiserFS) are now being used by default by most Linux distributions. No secure deletion program that does filesystem-level calls
can sanitize files on such filesystems, because sensitive data and metadata can be written to the journal, which cannot be readily accessed. Per-file secure deletion is
better implemented in the operating system.
Encrypting a whole partition with cryptoloop, for example, does not help very much either, since there is a single key for all the partition.
Therefore wipe is best used to sanitize a harddisk before giving it to untrusted parties (i.e. sending your laptop for repair, or selling your disk). Wiping size issues
have been hopefully fixed (I apologize for the long delay).
Be aware that harddisks are quite intelligent beasts those days. They transparently remap defective blocks. This means that the disk can keep an albeit corrupted (maybe
slightly) but inaccessible and unerasable copy of some of your data. Modern disks are said to have about 100% transparent remapping capacity. You can have a look at
recent discussions on Slashdot.
I hereby speculate that harddisks can use the spare remapping area to secretly make copies of your data. Rising totalitarianism makes this almost a certitude. It is
quite straightforward to implement some simple filtering schemes that would copy potentially interesting data. Better, a harddisk can probably detect that a given file is
being wiped, and silently make a copy of it, while wiping the original as instructed.
Recovering such data is probably easily done with secret IDE/SCSI commands. My guess is that there are agreements between harddisk manufacturers and government agencies.
Well-funded mafia hackers should then be able to find those secret commands too.
Don't trust your harddisk. Encrypt all your data.
Of course this shifts the trust to the computing system, the CPU, and so on. I guess there are also "traps" in the CPU and, in fact, in every sufficiently advanced mass-
marketed chip. Wealthy nations can find those. Therefore these are mainly used for criminal investigation and "control of public dissent".
People should better think of their computing devices as facilities lended by the DHS.
IMPORTANT WARNING -- READ CAREFULLY
The author, the maintainers or the contributors of this package can NOT be held responsible in any way if wipe destroys something you didn't want it to destroy. Let's
make this very clear. I want you to assume that this is a nasty program that will wipe out parts of your files that you didn't want it to wipe. So whatever happens after
you launch wipe is your entire responsibility. In particular, no one guarantees that wipe will conform to the specifications given in this manual page.
Similarly, we cannot guarantee that wipe will actually erase data, or that wiped data is not recoverable by advanced means. So if nasties get your secrets because you
sold a wiped harddisk to someone you don't know, well, too bad for you.
The best way to sanitize a storage medium is to subject it to temperatures exceeding 1500K. As a cheap alternative, you might use wipe at your own risk. Be aware that it
is very difficult to assess whether running wipe on a given file will actually wipe it -- it depends on an awful lot of factors, such as : the type of file system the file
resides on (in particular, whether the file system is a journaling one or not), the type of storage medium used, and the least significant bit of the phase of the moon.
Wiping over NFS or over a journalling filesystem (ReiserFS etc.) will most probably not work.
Therefore I strongly recommend to call wipe directly on the corresponding block device with the appropriate options. However THIS IS AN EXTREMELY DANGEROUS THING TO DO.
Be sure to be sober. Give the right options. In particular : don't wipe a whole harddisk (eg. wipe -kD /dev/hda is bad) since this will destroy your master boot record.
Bad idea. Prefer wiping partitions (eg. wipe -kD /dev/hda2) is good, provided, of course, that you have backed up all necessary data.
COMMAND-LINE OPTIONS
-f (force; disable confirmation query)
By default wipe will ask for confirmation, indicating the number of regular and special files and directories specified on the command line. You must type "yes" for
confirmation, "no" for rejection. You can disable the confirmation query with the -f (force) option.
-r (recurse into subdirectories)
Will allow the removal of the entire directory tree. Symbolic links are not followed.
-c (chmod if necessary)
If a file or directory to be wiped has no write permissions set, will do a chmod to set the permission.
-i (informational, verbose mode)
This enables reporting to stdout. By default all data is written to stderr.
-s (silent mode)
All messages, except the confirmation prompt and error messages, are suppressed.
-q (quick wipe)
If this option is used, wipe will only make (by default) 4 passes on each file, writing random data. See option -Q
-Q <number-of-passes>
Sets the number of passes for quick wiping. Default is 4. This option requires -q.
-a (abort on error)
The program will exit with EXIT_FAILURE if a non-fatal error is encountered.
-R (set random device OR random seed command)
With this option which requires an argument you can specify an alternate /dev/random device, or a command who's standard output will be hashed using MD5-hashed. The
distinction can be made using the -S option.
-S (random seed method)
This option takes a single-character argument, which specifies how the random device/random seed argument is to be used. The default random device is /dev/random. It
can be set using the -R option.
The possible single-character arguments are:
r If you want the argument to be treated like a regular file/character device. This will work with /dev/random, and might also work with FIFOs and the like.
c If you want the argument to be executed as a command. The output from the command will be hashed using MD5 to provide the required seed. See the WIPE_SEEDPIPE envi‐
ronment variable for more info.
p If you want wipe to get its seed by hashing environment variables, the current date and time, its process id. etc. (the random device argument will not be used). This
is of course the least secure setting.
-M (select pseudo-random number generator algorythm)
During the random passes, wipe overwrites the target files with a stream of binary data, created by the following choice of algorythms:
l will use (depending on your system) your libc's random() or rand() pseudorandom generator. Note that on most systems, rand() is a linear congruential generator, which
is awfully weak. The choice is made at compile-time with the HAVE_RANDOM define (see the Makefile).
a will use the Arcfour stream cipher as a PRNG. Arcfour happens to be compatible with the well-known RC4 cipher. This means that under the same key, Arcfour generates
exactly the same stream as RC4...
r will use the fresh RC6 algorythm as a PRNG; RC6 is keyed with the 128-bit seed, and then a null block is repeatedly encrypted to get the pseudo-random stream. I
guess this sould be quite secure. Of course RC6 with 20 rounds is slower than random(); the compile-time option WEAK_RC6 allows you to use a 4-round version of RC6,
which is faster. In order to be able to use RC6, wipe must be compiled with ENABLE_RC6 defined; see the Makefile for warnings about patent issues.
In all cases the PRNG is seeded with the data gathered from the random device (see -R and -S options).
-l <length>
As there can be some problems in determining the actual size of a block device (as some devices do not even have fixed sizes, such as floppy disks or tapes), you
might need to specify the size of the device by hand; <length> is the device capacity expressed as a number of bytes. You can use K (Kilo) to specify multiplication
by 1024, M (Mega) to specify multiplication by 1048576, G (Giga) to specify multiplication by 1073741824 and b (block) to specify multiplication by 512. Thus
1024 = 2b = 1K
20K33 = 20480+33 = 20513
114M32K = 114*1024*1024+32*1024.
-o <offset>
This allows you to specify an offset inside the file or device to be wiped. The syntax of <offset> is the same as for the -l option.
-e Use exact file size: do not round up file size to wipe possible remaining junk on the last block.
-Z Don't try to wipe file sizes by repeatedly halving the file size. Note that this is only attempted on regular files so there is no use if you use wipe for cleaning a
block or special device.
-X <number>
Skip a given number of passes. This is useful to continue wiping from a given point when you have been wiping, say, a large disk and had to interrupt the operation.
Used with -x.
-x <pass1>,...,<pass35>
Specify the pass order. When wipe is interrupted, it will print the current randomly selected pass order permutation and the pass number as appropriate -x and -X
arguments.
-F Don't try to wipe file names. Normally, wipe tries to cover file names by renaming them; this does NOT guarantee that the physical location holding the old file name
gets overwritten. Furthermore, after renaming a file, the only way to make sure that the name change is physically carried out is to call sync (), which flushes out
ALL the disk caches of the system, whereas for ading and writing one can use the O_SYNC bit to get synchronous I/O for one file. As sync () is very slow, calling sync
() after every rename () makes filename wiping extremely slow.
-k Keep files: do not unlink the files after they have been overwritten. Useful if you want to wipe a device, while keeping the device special file. This implies -F.
-D Dereference symlinks: by default, wipe will never follow symlinks. If you specify -D however, wipe will consent to, well, wipe the targets of any symlinks you might
happen to name on the command line. You can't specify both -D and -r (recursive) options, first because of possible cycles in the symlink-enhanced directory graph,
I'd have to keep track of visited files to guarantee termination, which, you'll easily admit, is a pain in C, and, second, for fear of having a (surprise!!) block
device buried somewhere unexpected.
-v Show version information and quit.
-h Display help.
EXAMPLES
wipe -rcf /home/berke/plaintext/
Wipe every file and every directory (option -r) listed under /home/berke/plaintext/, including /home/berke/plaintext/.
Regular files will be wiped with 34 passes and their sizes will then be halved a random number of times. Special files (character and block devices, FIFOs...) will
not. All directory entries (files, special files and directories) will be renamed 10 times and then unlinked. Things with inappropriate permissions will be chmod()'ed
(option -c). All of this will happen without user confirmation (option -f).
wipe -kq /dev/hda3
Assuming /dev/hda3 is the block device corresponding to the third partition of the master drive on the primary IDE interface, it will be wiped in quick mode (option
-q) i.e. with four random passes. The inode won't be renamed or unlinked (option -k). Before starting, it will ask you to type ``yes''.
wipe -kqD /dev/floppy
Since wipe never follows symlinks unless explicitly told to do so, if you want to wipe /dev/floppy which happens to be a symlink to /dev/fd0u1440 you will have to
specify the -D option. Before starting, it will ask you to type ``yes''.
wipe -rfi >wipe.log /var/log/*
Here, wipe will recursively (option -r) destroy everything under /var/log, excepting /var/log. It will not attempt to chmod() things. It will however be verbose
(option -i). It won't ask you to type ``yes'' because of the -f option.
wipe -kq -l 1440K /dev/fd0
Due to various idiosyncracies of the operating system, it's not always easy to obtain the number of bytes a given device might contain (in fact, that quantity can be
variable). This is why you sometimes need to tell wipe the amount of bytes to destroy. That's what the -l option is for. Plus, you can use b,K,M and G as multipliers,
respectively for 2^9 (512), 2^10 (1024 or a Kilo), 2^20 (a Mega) and 2^30 (a Giga) bytes. You can even combine more than one multiplier !! So that 1M416K = 1474560
bytes.
BUGS/LIMITATIONS
Wipe should work on harddisks and floppy disks; however the internal cache of some harddisks might prevent the necessary writes to be done to the magnetic surface. It
would be funny to use it over NFS. Under CFS (Cryptographic File System) the fsync() call has no effect; wipe has not much use under it anyway - use wipe directly on the
corresponding encrypted files. Also, under Linux, when using a device mounted thru a loopback device, synchronous I/O does not get propagated cleanly.
For wiping floppy disks, at least under Linux, there is no way, besides obscure floppy-driver specific ioctl's to determine the block size of the disk. In particular, the
BLKGETSIZE ioctl is not implemented in the floppy driver. So, for wiping floppies, you must specify the size of the floppy disk using the -l option, as in the last exam‐
ple. This option is normally not needed for other fixed block devices, like IDE and SCSI devices.
File name wiping is implemented since version 0.12. I don't know how efficient it is. It first changes the name of the file to a random- generated name of same length,
calls sync (), then changes the name to a random-generated name of maximal length.
File size wiping is implemented by repeatedly truncating the file to half of its size, until it becomes empty; sync () is called between such operations.
Note that it is still not possible to file creation date and permission bits portably. A wipe utility working at the block device level could be written using the ext2fs
library.
AUTHOR AND LICENCE
Wipe was written by Berke Durak (to find my email address, just type echo berke1ouvaton2org|tr 12 @. in a shell).
Wipe is released under the conditions of the GNU General Public License.
FILES
/dev/random is used by default to seed the pseudo-random number generators.
ENVIRONMENT VARIABLES
WIPE_SEEDPIPE If set, wipe will execute the command specified in it (using popen()), and will hash the command's output with the MD5 message-digest algorythm to get a
128-bit seed for its PRNG. For example, on systems lacking a /dev/random device, this variable might be set in /etc/profile to a shell script which contains various com‐
mands such as ls, ps, who, last, etc. and which are run asynchronously in order to get an output as less predictable as possible.
SEE ALSO
open(2), fsync(2), sync(8), bdflush(2), update(8), random(3)
Linux Sun Nov 7 09:41:23 EST 2010

qolepam · Le 15/06/2017, à 16:43

bonjour,

L'on m'a expliqué qu'au delà de 5 couches de suppression des données d'un support amovible,aucun logiciel ni dd ne pouvait récupérer les données supprimées sur ce support.
J'ai encore quelques détails à comprendre:
0)est-ce que c'est vrai?
1)avec dd,puis-je choisir le nombre(<5) couches à supprimer?
2)y a-t-il un autre paquet ou logiciel d'Ubuntu pouvant faire cette suppression?
3)cherche tuto concernant ce sujet

merci de votre aide

moko138 · Le 15/06/2017, à 20:55

On dit qu'il faut faire sept passes de shred (déchiquetage des fichiers).
Ce qui implique de ne pas commencer par supprimer les fichiers !

qolepam · Le 15/06/2017, à 21:18

j'ai trouvé sur internet la bonne syntaxe de dd:
for n in $(seq 7); do dd if=/dev/urandom of=/dev/sdc bs=8b; done

Mon support amovible à réecrire de données aleatoires(7 fois) est /media/home/nombre
Comment dois-je insérer ce chemin dans la commande unix ci-dessus?

moko138 · Le 15/06/2017, à 21:58

Je ne sais pas.
Fais attention avec dd : une erreur de cible est vite arrivée, aux conséquences catastrophiques.

Watael · Le 15/06/2017, à 22:17

salut,

comme tu peux le voir dans la commande que tu donnes, c'est le chemin du périphérique qui est utilisé, et pas son point de montage.
pour utiliser dd le périphérique doit d'ailleurs ne pas être monté.

et merci de mettre le code entre balise code (le bouton <> ) dans la petite barre d'outils.

qolepam · Le 15/06/2017, à 22:21

...et comment faire pour démonter le périphérique?

moko138 · Le 15/06/2017, à 23:05

Merci lynn !

Rufus T. Firefly · Le 15/06/2017, à 23:27

Ce qu'il convient surtout de savoir c'est qu'à peu près personne n'a le matériel indispensable pour récupérer quoi que ce soit après 1 seul passage de dd (ou autre). Et à moins que tu héberges des données ultra-confidentielles, tu ne risques rien...
Tu peux d'ailleurs vérifier : tu fais 1 passage de dd et tu essayes de récupérer quelque chose avec testdisk ou photorec...

Dernière modification par Rufus T. Firefly (Le 15/06/2017, à 23:41)

cqfd93 · Le 16/06/2017, à 09:48

Modération

Bonjour,

Inutile de créer 3 discussions pour le même problème. Je fusionne tout ça.

MicP · Le 16/06/2017, à 11:25

qolepam a écrit :

…mon but était d'effacer de façon sécurisée ma clé usb.…
…sudo shred -v "/media/user/USB DISK"…

#20Rufus T. Firefly a écrit :

…pour récupérer quoi que ce soit après 1 seul passage de dd (ou autre).…

D'autant que le principe sur lequel est basé shred ne concerne que les disques magnétiques => pas les SSD ni les clefs USB

EDIT : Pour cette dernière citation, le N° du message était bon,
mais je m'étais trompé sur le nom de l'auteur => je viens de corriger ça dans ce message.

Dernière modification par MicP (Le 18/06/2017, à 10:03)

cqfd93 · Le 16/06/2017, à 11:33

MicP a écrit :

cqfd93 a écrit :
…pour récupérer quoi que ce soit après 1 seul passage de dd (ou autre).…
D'autant que le principe sur lequel est basé shred ne concerne que les disques magnétiques => pas les SSD ni les clefs USB

Ah non, c'est pas moi, c'est Rufus T. Firefly

qolepam · Le 17/06/2017, à 23:57

1)si je comprends bien,je dois démonter ma clé usb(dev/sdb1) puis la remonter sur un point de montage avant d'appliquer dd?

2)après avoir fait un df -h,j'obtiens:
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/sdb1 58G 88M 58G 1% /media/jerome/98BC63F3BC63C9F8

Dois-je alors démonter /dev/sdb1 de /media/jerome/98BC63F3BC63C9F8?
puis ensuite,à quel endroit dois-je remonter /dev/sdb1 ?

Ensuite j'applique la ligne de commande dd

xinu · Le 18/06/2017, à 00:30

Dois-je alors démonter /dev/sdb1 de /media/jerome/98BC63F3BC63C9F8?

Oui.

ensuite,à quel endroit dois-je remonter /dev/sdb1 ?

Nul part, la laisser démontée.

Ensuite j'applique la ligne de commande dd

C'est bien ça.

Dernière modification par xinu (Le 18/06/2017, à 00:32)

qolepam · Le 18/06/2017, à 01:02

l'on m'a expliqué que pour faire en sorte
-que les données supprimées soit irrécupérables
-de ne pas supprimer les données existantes sur dev/sdb1
il faut:
a)déterminer la capacité de l'espace vide de dev/sdb1
b)dans cet espace vide,y créer un gros fichier bigzero contenant que des bits nuls
Ensuite,on fait:
c)dd if=/dev/zero of=bigzero bs=<nombre d'octets de l'espace vide> count=<nombre de secteurs affectés>

1)Est-ce bien cela?

2)quelle est la syntaxe avec dd permettant de créer bigzero de taille=nombre octets de l'espace vide?

merci

Dernière modification par qolepam (Le 18/06/2017, à 01:04)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 12/06/2017, à 17:40

problème d'utilisation de shred

#2 Le 12/06/2017, à 17:55

Re : problème d'utilisation de shred

#3 Le 12/06/2017, à 17:58

Re : problème d'utilisation de shred

#4 Le 12/06/2017, à 20:50

Re : problème d'utilisation de shred

#5 Le 13/06/2017, à 00:38

Re : problème d'utilisation de shred

#6 Le 13/06/2017, à 01:11

Re : problème d'utilisation de shred

#7 Le 13/06/2017, à 01:46

Re : problème d'utilisation de shred

#8 Le 13/06/2017, à 09:34

Re : problème d'utilisation de shred

#9 Le 13/06/2017, à 10:52

Re : problème d'utilisation de shred

#10 Le 13/06/2017, à 10:59

Re : problème d'utilisation de shred

#11 Le 13/06/2017, à 15:13

Re : problème d'utilisation de shred

#12 Le 15/06/2017, à 16:43

Re : problème d'utilisation de shred

#13 Le 15/06/2017, à 20:55

Re : problème d'utilisation de shred

#14 Le 15/06/2017, à 21:18

Re : problème d'utilisation de shred

#15 Le 15/06/2017, à 21:58

Re : problème d'utilisation de shred

#16 Le 15/06/2017, à 22:17

Re : problème d'utilisation de shred

#17 Le 15/06/2017, à 22:21

Re : problème d'utilisation de shred

#18 Le 15/06/2017, à 23:05

Re : problème d'utilisation de shred

#19 Le 15/06/2017, à 23:27

Re : problème d'utilisation de shred

#20 Le 16/06/2017, à 09:48

Re : problème d'utilisation de shred

#21 Le 16/06/2017, à 11:25

Re : problème d'utilisation de shred

#22 Le 16/06/2017, à 11:33

Re : problème d'utilisation de shred

#23 Le 17/06/2017, à 23:57

Re : problème d'utilisation de shred

#24 Le 18/06/2017, à 00:30

Re : problème d'utilisation de shred

#25 Le 18/06/2017, à 01:02

Re : problème d'utilisation de shred

Pied de page des forums