Забить 000 относительно недавно удаленные файлы

dd

cat

wipefreespace?

Хорошо, а как посмотреть оставшиеся не полностью удаленные файлы?

На CoW fs работать не будет. На SSD не имеет смысла, т.к. они по суте CoW девайсы.

PS: CoW — Copy-on-Write

sudo dd if=/dev/zero bs=1M of=/home/user/zerofile
rm /home/user/zerofile

Только лучше так:

#!/bin/bash

for i in "$(ls -sd --block-size=1 ~/./.local/share/Trash/files/*)";
 do
   size="$(echo -n $i | sed -E 's/([^ ]+).+/\1/')";
   name="$(echo -n $i | sed -E 's/([^ ]+) (.+)/\2/')";
   dd if=/dev/zero of="$name" ibs=1 count=$size;
   rm "$name";
 done;

И в этом скрипте предполагается, что в корзине нет директорий и файлов, начинающихся с точки (.) Для более общего случая надо ещё отфильтровать директории, после чего добавить в ls аргумент ./.local/share/Trash/files/.* или просто ключ -a без указания * в пути к корзине. Зато скрипт работает с пробелами в именах файлов. Ну и про cow уже сказали, что если эта корова имеется, то всё бесполезно.

Падумаеш... заменить на urandom и все в шоколаде. :) Ну реально же slvrn правильное решение написал.

Топик не читай?

на котором файлы уже удалены
уже удалены

УЖЕ Карл. :)

Топик не читай?

на котором файлы уже удалены
уже удалены

УЖЕ Карл. :)

Топик не читай?

уже удалены через корзину
через корзину

ЧЕРЕЗ КОРЗИНУ, Карл. :)

Очевидно, удалить файлы в корзине при помощи shred -uz

Вариант: переустановка системы. Восстановление нужных файлов из backup...

Если уж на то пошло, то вместо ls * надо использовать find -maxdepth 1 -type f, а велосипед с седом заменить на stat +%s.

Ну и топик я прочел, как будто бы ТС те файлы уже и из корзины снес, да.

Ну и топик я прочел, как будто бы ТС те файлы уже и из корзины снес, да.

Так, может я что-то не понимаю, подскажите, если я удаляю файл в корзину то удаляется «ссылка» на файл, дальше если очистить корзину, разве он полностью удалится с жесткого без возможности восстановления ? Я предполагаю что даже после корзины его можно восстановить, или я не прав?

sdelete.exe как специально для тебя придумали

Я предполагаю что даже после корзины его можно восстановить, или я не прав?

Теоретически можно. Практически очень сложно. Поэтому если надо надёжно удалить секретные данные, то лучше забить их 0, а ещё лучше рандомными значениями. Если же надо восстановить удалённый из корзины (и не забитый 0) файл, то сделать это можно, но сложно и ненадёжно, т. к. освободившиеся блоки частично или полностью могли перезаписаться.

А корзина — это просто каталог ~/./.local/share/Trash/files/, в который до поры до времени перемещаются «удалённые» файлы и папки. Никакие ссылки на них не удаляются, как и данные. Эти файлы можно просмотреть командой cat и узнать их размеры и др. свойства командой ls.

В моём скрипте, кстати, небольшая ошибка. Но исправлять сейчас не буду, т. к. предложили лучший вариант — команду shred, это если файлы всё ещё в корзине. А если нет, то затирать всё свободное место на диске случайными числами из /dev/urandom до исчерпания места, а потом получившийся файл удалить. Для надёжности после удаления процедуру можно провести повторно.

Я предполагаю что даже после корзины его можно восстановить, или я не прав?

Да, содержимое файла восстановить можно, если у тебя не ssd. Или если ssd, но при удалении блоки не были тримнуты. Т.к. обычно сами данные с диска не пропадают, пропадает только метаинформация из фс о том, что был вот такой файл, и что он занимал вон те блоки.

Но для восстановления какого-то определенного файла наверняка придется перелопатить половину объема жесткого диска, т.к. уже неизвестно, где именно те данные находятся.

Ну и да, если блоки с нужными данными уже перезаписаны, то они безвозвратно потеряны.

Если уж на то пошло, то вместо ls * надо использовать find -maxdepth 1 -type f, а велосипед с седом заменить на stat +%s.

Делать можно по-разному. Я предложил один из возможных вариантов. Там, кстати, небольшая ошибка закралась: в for in последний аргумент в кавычках, и это неправильно. Надо заменять кавычки на невстречающиеся непробельные символы, а потом восстанавливать пробелы, чтоб работало на нескольких файлах. Это несложно переделать, но т. к. уже предложили лучший вариант с shred, то не вижу в этом сейчас смысла.

Ну и топик я прочел, как будто бы ТС те файлы уже и из корзины снес, да.

Ну, мы об этом можем только догадываться. :-) Я, прочитав, понял наоборот, что файлы всё ещё в корзине.

А если нет, то затирать всё свободное место на диске случайными числами из /dev/urandom до исчерпания места, а потом получившийся файл удалить. Для надёжности после удаления процедуру можно провести повторно.

Подскажи как именно будет выглядеть эта команда при том что удалял файлы я из home и в home остались еще нужные файлы?

Нашел что-то типо: dd if=/dev/urandom of=/dev/null bs=100M count=5

if: указывает на источник, т.е. на то, откуда копируем. Указывается файл, который может быть как обычным файлом, так и файлом устройства. of: указывает на файл назначения. То же самое, писать можем как в обычный файл, так и напрямую в устройство. bs: количество байт, которые будут записаны за раз. Можно представлять этот аргумент как размер куска данные, которые будут записаны или прочитаны, а количество кусков регулируется уже следующим параметром. count: как раз то число, которое указывает: сколько кусочков будет скопировано

но пока еще не понимаю полностью как в моем случае применяется чтобы сохранить нужные файлы в home и уничтожить уже удаленные.

Да, содержимое файла восстановить можно, если у тебя не ssd. Или если ssd, но при удалении блоки не были тримнуты. Т.к. обычно сами данные с диска не пропадают, пропадает только метаинформация из фс о том, что был вот такой файл, и что он занимал вон те блоки.

У меня пока еще HDD, да, я вот об этой мета-информации и говорю что удаляется она и в теме вот пытаюсь понять как вовсе файлы уничтожать.

Если нам нужны не нули, а урандом может быть слишком медленным:

dd if=/dev/zero bs=4M count=1 status=none | tr \\000 \\377

- дает нам 4 мегабайта '0xff'

На счёт команды Shred спасибо, понял буду юзать, но вот сейчас я нужно как-то вот занять свободное место чтобы удалить уже удаленные файлы насовсем. Какой командой это сделать?

dd if=/dev/urandom of=/temp.dat - оно забьет объем жесткого по максимуму к примеру свободные 200гб, и этот файл же будет весить 200гб, после этого, этот файл просто так же удалить тем самым этот файл своими 200 гб уничтожит все ранее удаленные файлы, я правильно понял?

Если SSD, то fstrim.

Нашел что-то типо: dd if=/dev/urandom of=/dev/null bs=100M count=5

Да, всё так. Только of должен быть затираемым файлом или новым файлом, а не /dev/null. Ну и bs*count должно быть равно физическому размеру затираемого файла на диске (что обычно больше его отображаемого командой ls -l размера) или размеру свободного места на диске.

но пока еще не понимаю полностью как в моем случае применяется чтобы сохранить нужные файлы в home и уничтожить уже удаленные.

Если удалённые файлы находятся в корзине, то они ещё не удалены на самом деле. Просто затираешь их командой

shred -uz имя_файла

Stanson

Если файлы уже удалены на самом деле (в т. ч. и из корзины), то большинство людей их никогда не восстановит. Но если там была сверхсекретная информация, которую ищут все спецслужбы мира или итальянская коза ностра, то лучше забить оставшееся свободное место на разделе рандомными числами, как предложил slvrn. Он, правда, предложил использовать источник /dev/zero, но /dev/urandom надёжнее. Алгоритм простой: записывая мусор в новый файл до полного забивания раздела, ты перезаписываешь этим мусором все освободившиеся блоки, в т. ч. те, которые содержали удалённые файлы и в которых могут оставаться секретные данные. Но если нужно совсем надёжно, то сделать это лучше дважды, а некоторые параноики делают до 5 раз и больше, потому что по слухам у спецслужб есть приборчики, позволяющие прочитать даже таким способом удалённые данные, используя остаточную намагниченность.

Если файлы уже удалены на самом деле (в т. ч. и из корзины), то большинство людей их никогда не восстановит. Но если там была сверхсекретная информация, которую ищут все спецслужбы мира или итальянская коза ностра, то лучше забить оставшееся свободное место на разделе рандомными числами, как предложил slvrn. Он, правда, предложил использовать источник /dev/zero, но /dev/urandom надёжнее. Алгоритм простой: записывая мусор в новый файл до полного забивания раздела, ты перезаписываешь этим мусором все освободившиеся блоки, в т. ч. те, которые содержали удалённые файлы и в которых могут оставаться секретные данные. Но если нужно совсем надёжно, то сделать это лучше дважды, а некоторые параноики делают до 5 раз и больше, потому что по слухам у спецслужб есть приборчики, позволяющие прочитать даже таким способом удалённые данные, используя остаточную намагниченность.

Большое спасибо за развернутую и детальную информацию, теперь я всё понял что как и почему, я не параноик но люблю чтобы было всё по полочкам и контролировать ситуацию, если информацию я стер значит она должна быть вовсе уничтожена, тем более если ноутбук - тут это необходимо как по мне. Буду юзать Shred, а так как надо подправить прошлое накасяченное удаление то забью через /dev/urandom.

Так же всем кто так или иначе подсказывал и отвечал - благодарю за грамотную помощь!

Если нам нужны не нули, а урандом может быть слишком медленным:

[skip]

- дает нам 4 мегабайта '0xff'

Имхо, это принципиально ничем не отличается от 0: так же сжимается и даже если не сожмётся, так же легко будет восстановить спец-техникой (если речь идёт о каких-то серьёзных людях, а не о соседе-хацкере). А urandom, да, медленнее, чем /dev/zero. Если свободного места на разделе много, то и ждать придётся долго.

dd if=/dev/urandom of=/temp.dat - оно забьет объем жесткого по максимуму к примеру свободные 200гб, и этот файл же будет весить 200гб, после этого, этот файл просто так же удалить тем самым этот файл своими 200 гб уничтожит все ранее удаленные файлы, я правильно понял?

Да. Для надёжности можно повторить после удаления (но это не от хацкеров, а от спецслужб). От хацкеров можно и один раз. Ну и перед удалением файла с мусором, чтоб всё наверняка записалось на диск, выполнить команду sync, иначе часть данных могут оказаться в кэше, и некоторые блоки будут содержать прежнюю информацию.

большинство людей

ты недооцениваешь хомячков. Интернет сейчас есть везде и скачать программу для восстановления осилит каждый. А там пару рад нажать «далее» и всё. Если файл не был перезаписан, он будет в том же виде (разве что метаинформация может быть утеряна).

Который раз замечаю что Ext4 любит тут же уничтожать или переиспользовать освободившиеся блоки, но для других ФС восстановление не проблема в целом, даже используя максимально примитивные инструменты и не обладая какими-либо знаниями.

Нужно отметить, что перезапись нулями в целом считается менее надёжным способом уничтожения данных, и дело как мне кажется тут даже не в том, что 3-5 раз записать новую информацию недостаточно надёжно, а в том, что какой-нибудь из компонентов может оптимизировать запись нулей непредсказуемым образом. Ну и остаточную намагниченность (хотя я бы посмотрел как они провернут этот трюк с современными 10 терабайтниками) никто не отменял.

Для SSD это всё вообще не актуально, она может удалить, может не удалить, может навсегда сохранить и ты ничего с этим не сделаешь.

Ну и остаточную намагниченность (хотя я бы посмотрел как они провернут этот трюк с современными 10 терабайтниками) никто не отменял.

Это было актуально гигабайтов до сорока.

Нужно отметить, что перезапись нулями в целом считается менее надёжным способом уничтожения данных, и дело как мне кажется тут даже не в том, что 3-5 раз записать новую информацию недостаточно надёжно, а в том, что какой-нибудь из компонентов может оптимизировать запись нулей непредсказуемым образом.

Речь о /dev/zero?

/dev/urandom - решает же эту проблему?

какой-нибудь из компонентов может оптимизировать запись нулей непредсказуемым образом.

Да. Как и запись любых других повторяющихся данных, которые легко сжать из-за их повторения. Поэтому /dev/urandom наиболее надёжен, хоть и медленнее работает.

Ну и остаточную намагниченность (хотя я бы посмотрел как они провернут этот трюк с современными 10 терабайтниками)

Понятно, что это всё теория, а на практике оно гораздо сложнее. Чего далеко ходить? Был случай, когда головки поцарапали поверхность диска, на котором была важная информация, и не было резервной копии. Обратились в специализированную фирму с просьбой восстановить хоть что-то, что получится. Они, естественно, ничего не гарантировали. Взяли несколько тыщ и нихрена с помощью своего оборудования не восстановили, ни одного байта. И диск-то был не такой уж и огромный.

Но может быть и наоборот, когда ты думаешь, что всё у тебя удалено, а нехорошие люди это всё восстанавливают и читают. По закону подлости.

Для SSD это всё вообще не актуально, она может удалить, может не удалить, может навсегда сохранить и ты ничего с этим не сделаешь.

SSD не пишет поверх существующих данных, если есть свободное место, поэтому затирать на нём данные командой shred бесполезно. И fstrim не гарантирует затирания. Она предназначена для оптимизации работы ssd, а не для сокрытия удалённых данных. Но если забить всё свободной место случайными числами на всех разделах (на ssd, если я не ошибаюсь, недостаточно забить один раздел, т. к. контроллер диска может писать данные физически куда угодно), синхронизировать кэш командой sync, а потом удалить этот файл и выполнить trim, то, имхо, ничего не должно сохраниться. Другое дело, что делать это после каждого удаления на ssd

1. очень долго;
2. чревато быстрым износом и выходом из строя ssd.

Но для какого-то одного сверх секретного файла вполне можно, имхо.

Речь о /dev/zero?

/dev/urandom - решает же эту проблему?

Да, решает. Но он медленнее, т. к. постоянно вычисляет новые числа, в отличие от /dev/zero.

Да, решает. Но он медленнее, т. к. постоянно вычисляет новые числа, в отличие от /dev/zero.

Ну это же не каждый час и не каждый день эти заниматься, так что вариант (как по мне) хороший, и если немного дольше - главное чтобы надежно.

Чисто теоретически /dev/urandom плохой источник энтропии. Практически... При многократной перезаписи качество энтропии уже менее актуально в современных условиях, а восстановление данных _затёртых_ таким образом из области фантастики, хоть и теоретически возможно. От оптимизации контроллером спасёт, да. При условии записи ровно в те же области, где были данные.

А вообще используй shred -uzfv filename и не заморачивайся. Это куда лучше dd во всех отношениях и можно даже указать источник энтропии, если очень хочется. Это всё больше про то, что условия бывают очень разные.

Это всё больше про то, что условия бывают очень разные.

Да, спасибо, я там выше писал:

Буду юзать Shred, а так как надо подправить прошлое накасяченое удаление то забью через /dev/urandom.

забить всё свободной место случайными числами на всех разделах

то-то и оно, что даже это не гарантия. Физически данные могут остаться на чипах в любое время.

специализированную фирму

у меня есть мои сомнения. Понятно что восстанавливать данные прямо с блинов это совсем другой уровень, любая коммерческая организация прогорит очень быстро если будет слишком уж серьёзно работать. Они используют готовые методы и инструменты в лучшем случае. Тут скорее потребуется более серьёзный подход и интимные связи с производителями.

А ещё данные любят сохранятся в скрытых областях (которых может быть весьма много в зависимости от условий), ну и перезапись свободного места такое себе развлечение. Как дополнительная мера сойдёт.

забить всё свободной место случайными числами на всех разделах

то-то и оно, что даже это не гарантия. Физически данные могут остаться на чипах в любое время.

А вот этого я не понимаю, как такое может быть? Ну, может, конечно, какой-то блок пометиться smart'ом как не рабочий. Но если он не рабочий, то и прочитать его нельзя. Понятно, что бывает и такое, что один или несколько раз блок не прочитался, был помечен как плохой, а потом вдруг неожиданно прочитался. Но такое и на обычных магнитных дисках может произойти. Тут от потенциального воровства информации только полная утилизация диска спасёт. :-)

интимные связи с производителями.

Это да. Но на практике такие связи есть не у многих. Был случай, когда запаролили несколько роутеров cisco и забыли пароль. Дешевле оказалось купить новые (хотя стоят они не дёшево, и запаролили несколько, а не один), чем вступать в интимный контакт с производителем. :-) Там, правда, не только деньги, но ещё и время играло свою роль.

А ещё данные любят сохранятся в скрытых областях (которых может быть весьма много в зависимости от условий)

А можно конкретнее? Интересует исключительно для общего развития.

Из доступного полная перезапись диска с последующим перемещением файлов в исходное состояние. Фича secure erase в принципе для того и существует, если ты доверяешь производителю. Очищает всё данные.

А можно конкретнее? Интересует исключительно для общего развития.

Я думаю на открытых форумах такие вопросы и подымаются для общего развития и понимания, а не планирования чего-то противозаконного )

Метаинформация может хранить и сами данные. И журнал может хранить данные. Если пометить область как бэд блоки, потом их можно будет прочесть. Это так, на вскидку. Кроме того контроллер может делать разные интересные вещи.

Буду юзать Shred

Юзай FDE, а не эти нерабочие костыли.

Я думаю на открытых форумах такие вопросы и подымаются для общего развития и понимания, а не планирования чего-то противозаконного )

Почему обязательно противозаконного? Можно для восстановления собственной потерянной информации. А м. б. и противозаконное. На форумы ведь разные люди ходят. :-)

Метаинформация может хранить и сами данные. И журнал может хранить данные. Если пометить область как бэд блоки, потом их можно будет прочесть. Это так, на вскидку.

Понял. Спасибо.

Кроме того контроллер может делать разные интересные вещи.

Вот это самое интересное.

Понятно, что это всё теория, а на практике оно гораздо сложнее. Чего далеко ходить? Был случай, когда головки поцарапали поверхность диска, на котором была важная информация, и не было резервной копии. Обратились в специализированную фирму с просьбой восстановить хоть что-то, что получится. Они, естественно, ничего не гарантировали. Взяли несколько тыщ и нихрена с помощью своего оборудования не восстановили, ни одного байта. И диск-то был не такой уж и огромный.

Это действительно как повезет. У нас были истории успеха при аналогичной ситуации. (сдаем в рлаб).

Насчет ssd реально очень хорошее замечание. Я конечно диванный теоретик, не настолько силен. Как мне видеться ситуация, вылетает один блок, второй и т.д. используем резервные (считай аналог реалока на hdd) но старые-то данные не потеряли и считать с них можно. Вроде и за уши притянуто, но с другой стороны ведь вероятность существует. Т.е. говорить, что с ssd со 100% гарантией безопасно удалить файло - нельзя.

тем более если ноутбук - тут это необходимо как по мне

Немного не в тему, но: Используйте шифрование дисков.

то-то и оно, что даже это не гарантия. Физически данные могут остаться на чипах в любое время.

А вот этого я не понимаю, как такое может быть? Ну, может, конечно, какой-то блок пометиться smart'ом как не рабочий.

Читать или писать две большие разницы для ssd. Именно поэтому ынтерпрайзные ssd в случае смерти переходят в ro.

Насчет ssd [skip] вылетает один блок, второй и т.д. используем резервные (считай аналог реалока на hdd)

Там всё ещё хитрее. Даже когда ничего не сыпется, контроллер всё равно пишет в разные места, чтоб уменьшить износ. Соответственно, при попытке физически что-то затереть, затираются на самом деле какие-то левые блоки, если только не затирать всё свободное место на всех разделах диска, включая не размеченное пространство. Некоторые даже рекомендуют оставить процентов 10 — 20 места на ssd не размеченным, чтоб независимо от того, как работает trim и работает ли (а это зависит и от контроллера, и от ОС), контроллер всё равно мог распределять данные, используя не размеченное пространство. Я у себя так и сделал. Конечно, современные диски и современный Linux должны нормально работать с trim (по крайней мере, если речь не идёт о raid), но в любом случае для его работы должно быть ещё и свободное место на диске. Так зачем мне самому следить, чтоб на разделах оставалось не меньше 10-20% места, если я могу просто оставить это место не размеченным?

но старые-то данные не потеряли и считать с них можно. Вроде и за уши притянуто, но с другой стороны ведь вероятность существует. Т.е. говорить, что с ssd со 100% гарантией безопасно удалить файло - нельзя.

Да. Но если говорить о bad-блоках, то то же верно и для hdd. Читал когда-то страшные истории о том, что в некоторых левых конторах, имеющих основания бояться внезапного появления ОМОНа, у сервера стоит вооружённый охранник, единственная обязанность которого в случае подозрительного шума, сопровождаемого маски-шоу в вестибюле, — выстрелить в жёсткий диск. Но это всё журналистские байки, а вот про невооружённого охранника, который должен был выдернуть hdd из работающего сервера в случае чего (и сделал это в нужный момент), знаю точно от очевидцев. А все эти затирания информации не надёжны, если речь идёт о жизни и смерти или хотя бы о свободе.

Читать или писать две большие разницы для ssd. Именно поэтому ынтерпрайзные ssd в случае смерти переходят в ro.

Понял. Буду знать. Спасибо.