guav ©   (23.03.08 01:22) [19]

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

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

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

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

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

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

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

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

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

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

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

guav ©   (23.03.08 17:25) [25]

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

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

> [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] - пробовать на сжатом файле).