Как удалить файл без восстановления

← →
nikfel (2008-03-22 11:03) [0]

Подскажите, пожалуйста. Как удалить файл со всем, чтобы восстановить было нельзя. Заранее спасибо.

← →
Ega23 © (2008-03-22 11:11) [1]

Затереть нулями кластеры, занимаемые файлом.

← →
tesseract © (2008-03-22 12:39) [2]

> Затереть нулями кластеры, занимаемые файлом.

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

← →
guav © (2008-03-22 14:02) [3]

В общем случае сложный вопрос, есть случаи, когда [1] и [2] не сработают.
Особенно сложно, если нужно стереть ещё имя файла.знать о том что файл должен быть потом стёрт совсем уже при создании файла.

← →
ЦУП © (2008-03-22 14:10) [4]

> В общем случае сложный вопрос, есть случаи, когда [1] и
> [2] не сработают.

А что это за случаи?

← →
guav © (2008-03-22 14:43) [5]

> [4] ЦУП © (22.03.08 14:10)

На NTFS нет строгого соотвествия между данными в файле и данными в его кластерах.
Например сжатый файл займёт кластеров меньше чем его размер, тут [2] может не сработать.
Если файл который полностью поместился в MFT, то при перезаписи методом [1] будет повреждена файловая система, при этом файл моет остатьсыя восстановимым. А при перезаписи методом [2] будет востановим. Тут Rouse_ давал ссылку на книгу "Криминалистический анализ файловых систем", там эти тонкости NTFS.

Ну и что уже применимо к любой ФС, следы файла могут быть во всяких темпах, кэшах и свопах. И, при дефрагментации, в старом расположении файла. И ещё есть флешки которые менят маппигн секторов на их физическу память, чтобы распределить "износ" флешки равномерно, тогда затираемый кластер может не совпасть с кластером файла.

← →
guav © (2008-03-22 14:48) [6]

Есть подозрение, что на NTFS поможет FSCTL_SET_ZERO_ON_DEALLOCATION, если указывать сразу при создании, не проверял. Но требует Vista.

← →
TStas © (2008-03-22 16:56) [7]

А почему нельзя получить размер файла, если он > 0, открыть его в режиме Чтение/запись и перезаписать нулями? Размер не изменится, а в файле одни нули будут. А потом просто deleteFile ему сделать. Вот и удаление без восстановления.

← →
Riply © (2008-03-22 17:21) [8]

> [7] TStas © (22.03.08 16:56)
> А почему нельзя получить размер файла, если он > 0, открыть его в режиме
> Чтение/запись и перезаписать нулями? Размер не изменится, а в файле одни нули будут.
> А потом просто deleteFile ему сделать. Вот и удаление без восстановления.

А кто тебе сказал, что "перезаписываемые нули" будут перезаписываться именно
в теже кластеры, где располагался файл ? (Sorry за тавтологию :)
Более того, если файл, например, исходно был фрагментирован, то шансов для этого
становится очень мало.

← →
guav © (2008-03-22 19:34) [9]

> [7] TStas © (22.03.08 16:56)

Уже предложено в [2]. Не будет это работать для всех файлов.
Более того писать именно нулями - идея более плохая чем писать случайными даными, если файл сжат, то "запись" почти ничего не сделает.

← →
Игорь Шевченко © (2008-03-22 22:13) [10]

Riply © (22.03.08 17:21) [8]

> Более того, если файл, например, исходно был фрагментирован,
> то шансов для этого
> становится очень мало.

Ты хочешь сказать, что при записи в файл он дефрагментируется ?

guav © (22.03.08 19:34) [9]

> Более того писать именно нулями - идея более плохая чем
> писать случайными даными, если файл сжат, то "запись" почти
> ничего не сделает.

Запись как бы скорректирует кластеры, занимаемые файлом, нет ?
Или тв хочешь сказать, что зная кластер на диске, ты гарантировано скажешь, какому файлу он принадлежал в прошлом ?

← →
Riply © (2008-03-22 22:42) [11]

> [10] Игорь Шевченко © (22.03.08 22:13)
> Ты хочешь сказать, что при записи в файл он дефрагментируется ?

Нет, конечно. Точнее: не такое строгое утверждение.
Но я неоднакратно наблюдала ( и воспроизводила) дефрагментацию файла при записи.

← →
Riply © (2008-03-22 22:53) [12]

> [11] Riply © (22.03.08 22:42)
> Но я неоднакратно наблюдала ( и воспроизводила) дефрагментацию файла при записи.

Имеется ввиду на NTFS

← →
Игорь Шевченко © (2008-03-22 22:58) [13]

Riply © (22.03.08 22:42) [11]

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

Он имеет возможность стать дефрагментированым ?

← →
Riply © (2008-03-22 23:07) [14]

> [13] Игорь Шевченко © (22.03.08 22:58)
> Ничего не понимаю - есть файл, у него есть N кластеров.
> Содержимое файла аккуратно заполняется произвольными данными (хотя бы и нулями).
> Он имеет возможность стать дефрагментированым ?

Да.
Я воспроизводила, примерно, такое:
Создавала файл, например, занимающий восемь кластеров с "номерами":
0..3, 128...131.
И после "обычной" записи в него его картинка становилась: 0..7.
Я не утверждаю, что это происходит всегда,
но в моих тестах это повторилось несколько раз.

← →
Riply © (2008-03-22 23:10) [15]

С заполнением нулями сжатого или разряженного файла, вообще интересно.
Такое впечатление (может и неправильное),
что система может вызвать FSCTL_SET_ZERO_DATA, если ей заблагорассудится :)
А FSCTL_SET_ZERO_DATA может не вести "реальной" записи на диск, а только "подправить" MFT :)

← →
Игорь Шевченко © (2008-03-23 00:23) [16]

Riply © (22.03.08 23:07) [14]

Пример в студию. Атрибуты файла, как открывала, как писала, расположение кластеров до, расположение кластеров после.
Или ссылки, подтверждающие подобные случаи и/или поведение.

До того момента не верю.

← →
guav © (2008-03-23 00:42) [17]

> [10] Игорь Шевченко © (22.03.08 22:13)
> Запись как бы скорректирует кластеры, занимаемые файлом,
> нет ?
> Или тв хочешь сказать, что зная кластер на диске, ты гарантировано
> скажешь, какому файлу он принадлежал в прошлом ?

Даже если считать что достаточно разрыва связи между файлом и его данными, в NTFS обновления Data Runs всегда журналируются, поэтому, возможно, связь не будет безнадёжно утеряна в этом случае.
Обычно от надёжного удаления файла хотят преде всего невостановимость самих данных, а не уничтожения информации о файле.

← →
Игорь Шевченко © (2008-03-23 00:49) [18]

guav © (23.03.08 00:42) [17]

> в NTFS обновления Data Runs всегда журналируются

И живут там вечно ? Мне просто интересно

← →
guav © (2008-03-23 01:22) [19]

> [18] Игорь Шевченко © (23.03.08 00:49)

Нет. Но часто живут там достаточно долго.
Логфайл состоит из циклического буфера страниц, т.е. всегда перезаписыватся самые старые.
В NT запись начинается сначала при каждом монтировании, в более новых (2000 и новее) цикл не обрывается и при монтировании/демонтировании.

← →
Игорь Шевченко © (2008-03-23 02:17) [20]

guav © (23.03.08 01:22) [19]

Век живи, век учись. Примерчик можно ?

← →
Riply © (2008-03-23 02:18) [21]

> [16] Игорь Шевченко © (23.03.08 00:23)
> Пример в студию. Атрибуты файла, как открывала, как писала,
> расположение кластеров до, расположение кластеров после.
> Или ссылки, подтверждающие подобные случаи и/или поведение.

Ссылок разумеется нет, впрочем как и нормальной документации по NTFS.
Соответственно попытка изучить это безобразие(NTFS), в основном, строится на тестах
и изучении их результатов. Их приходиться проводить очень много.
И разумеется, у меня не сохранились ни полное описание
условий, при которых я получила данный результат, ни функций, написанных
спецально для него. Я увидела, что это возможно, сделала себе пометку, "намотала на ус" и пошла дальше :)
Но, чтобы не остаться голословной, я попробую еще раз получить условия, в которых
это воспроизводится более-менее стабильно. Но на это потребуется время.
Так что, придется подождать. Хорошо ?

> До того момента не верю.
И правильно :) Я тоже стараюсь все проверять сама :)

← →
guav © (2008-03-23 02:53) [22]

> [20] Игорь Шевченко © (23.03.08 02:17)

Примерчик чего ?
Читалку логфайла дать не могу.
Про сам логфайл можно прочитать в "Inside Windows 2000".
Опыт подтверждающий восстановимость резидентных файлов через логфайл описан в книге "Криминалистический анализ файловых систем" (там не учтена разбивка логфайла на страницы и необходимость восстановления двух последних байт каждого сектора кадой страницы, но при достаточном везении эти два фактора могут не повлиять и даные будут байт-в-байт как и были). Опыт подтверждащий восстановимость датаранов будет аналогичным. Просто создаём, меняем, ищем в логфайле старый и новый варианты и находим.

← →
guav © (2008-03-23 15:29) [23]

http://www.osronline.com/showThread.cfm?link=54720
Вот интересная ссылка по теме, там автор тоже озабочен удалением и, видимо, не нашел способа "борьбы" с журналированием.

← →
Игорь Шевченко © (2008-03-23 17:00) [24]

там автор озабочен удалением мелких файлов :)

← →
guav © (2008-03-23 17:25) [25]

> [24] Игорь Шевченко © (23.03.08 17:00)

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

← →
Denis__ © (2008-03-23 18:39) [26]

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

← →
Игорь Шевченко © (2008-03-23 19:12) [27]

guav © (23.03.08 17:25) [25]

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

Впрочем, сам понимаешь, достаточно хорошенько переписать соседние файлы и лог забьется...

← →
guav © (2008-03-23 19:37) [28]

> [27] Игорь Шевченко © (23.03.08 19:12)
> Минуточку - там же написано, что после контрольной точки
> они как бы становятся ненужными.

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

> Я вот честно не слышал, что в NTFS ведется хронология изменений
> файла...

И это есть, USN Log, но это опция, на ХР по дефолту выключена, и пишет только события, но не данные.

Данные действительно специально не журналируются. В логфайле журналируются метаданные, т.е. из нерезиднетных файлов туда специально пишутся только данные метафайлов.

> Впрочем, сам понимаешь, достаточно хорошенько переписать
> соседние файлы и лог забьется...

Да. Но если хорошенько переписать. И желательно знать, как переписывать, чтобы побыстрее его забить.
Я смотрел некоторые "стиралки", которые затирают неиспользованые MFT записи и свободное место тома, они таки затирают это всё, но в результате обработки ими тома в логфайле обычно появляется слишком мало записей, чтобы затереть значительную часть логфайла.

Я в [3] наверное плохо сформулировал свою точку зрения, повторюсь:
Если нужна возможность надёжно удалить файл, то об этом надо думать уже при создании файла. Перед удалением сложнее обеспечить надёжное удаление, а после обычного удаления - ещё сложнее.

guav © (23.03.08 19:37) [28]

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

> [30] Игорь Шевченко © (23.03.08 20:44)

Именно так, и действительно в случаях вроде pagefile.sys туда ничего не попадает.

Журналирование "из любви к искусству", т.е. не нужное для работы самой ФС - это USN Journal, см. http://msdn2.microsoft.com/en-us/library/aa363801.aspx

> диск бы сразу был забит лог-файлом

Кстати диск не может быть забит логфайлом, размер логфайла вообще не увеличивается, он цикличен. Да, есть проблема, что логфайл может "наступить себе на хвост", но она обрабатывается.

guav © (23.03.08 21:04) [32]

Я все о другом - о том, что следы в нем недолго хранятся. И использовать его как средство доступа к удаленной информации, занятие, на мой взгляд, малоперспективное.

Кстати: "the NTFS file system maintains a change journal. When any change is made to a file or directory in a volume, the change journal for that volume is updated with a description of the change and the name of the file or directory"

Насколько я понял, старых данных там не хранится...

> [33] Игорь Шевченко © (23.03.08 23:23)
> Я все о другом - о том, что следы в нем недолго хранятся.
> И использовать его как средство доступа к удаленной информации,
> занятие, на мой взгляд, малоперспективное.

Возражать не буду, лучше расскажу как посчитать сколько в среднем хранится записи.
Читаем в логфайле DWORD по смещению 0x40. Будет где-то между 0x20 и 0x30. Отнимаем от 0x40 прочитанное. Получится значение, на которое надо сдвинуть вправо LSN, чтобы получить номер перезаписи файла. Создаём файл и смотрим его LSN, сдвигаем его на вычисленную константу, получим число равное номеру цикла перезаписи логфайла. Теперь вычитаем из даты того файла дату логфайла, мы получаем время существования тома. Разделив это время на число циклов перезаписи, получим, сколько в среднем живёт запись логфайла. Для всего этого можно взять MFT_Scan, который by Riply :-) (LSN там назван _Usn64)
Понятно, что это время зависит от того системный ли диск, включено ли обновление времени последнего доступа, и т.п. и может получится и меньше дня и больше месяца.

> Кстати: "the NTFS file system maintains a change journal.
> When any change is made to a file or directory in a volume,
> the change journal for that volume is updated with a description
> of the change and the name of the file or directory"
>
> Насколько я понял, старых данных там не хранится...

Здесь речь скорее идёт об USN Journal ($UsnJrnl) а не о логфайле ($LogFile).

В $LogFile тарые данные хранятся для отмены незавершенной операции (в "Inside Windows 2000" это названо "undo pass"), новые хранятся для возможности повтора операции ("redo pass"). Кроме случаев, когда операция - отмена или повтор по логфайлу, для кадой операции хранятся и данные для повтора и данные для отмены.

> [33] Игорь Шевченко © (23.03.08 23:23)
> Кстати: "the NTFS file system maintains a change journal.

Ну да, это по ссылке из [31]. Change Journal не имеет (почти) отношения к Log File.
Про логфайл в MSDN мало пишут, немного есть тут http://support.microsoft.com/kb/101670

guav © (24.03.08 02:34) [34]

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

Нетрудно будет набросать ?

> [36] Игорь Шевченко © (24.03.08 09:41)

К метаданным про которые пишет Руссинович (кстати он ли ? в книге "Inside Windows NT", автор которой не Руссинович, про журналирование написано в точности то же самое, что в "Inside Windows 2000") относятся все метаданные. Включая всё, что пишется в MFT.

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

Данные пользовательских нерезидентных файлов не попадают в логфайл, но датараны (пары логическийКластер-количествоКластеров) попадают, т.е. дают утвердительный ответ на [10] для прошлого в пределах времени цикла логфайла. Т.е. если действительно затереть их кластеры, то данные не будут восстановимы через логфайл, но если применить совет [7] к сжатому файлу, то могут быть (получится то, про что пишет Riply в [15] и никакого реального затирания кластеров не будет).

Кода не будет, потому что NDA.

> Т.е. если действительно затереть их кластеры, то данные
> не будут восстановимы через логфайл

Собственно, в чем были уверены большевики. Спасибо.

> [38] Игорь Шевченко © (24.03.08 11:16)

Только могут быть и другие уязвимости, не связанные с NTFS.

Ну и есть удалялки, использующие удаление путём повторной записи в файл, так они могут перезаписать не те кластеры.
(простой способ воспроизвести [14] - пробовать на сжатом файле).

> [39] guav © (24.03.08 11:36)
> (простой способ воспроизвести [14] - пробовать на сжатом файле).

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

Как удалить файл без восстановления Найти похожие ветки