Начнем с рассмотрения простого случая — удаления обычной фотографии. Допустим, у нас есть папка с фотографиями, и мы избавляемся от одной из них. Причем удаляем по всем правилам, перезаписав нужную область диска несколько раз. По идее больше ничего не должно выдавать ее существования (если мы сами до этого не скопировали ее в другую папку и не забыли про это). Но тут-то как раз многие и забывают об одной особенности Windows — файле Thumbs.db. Это специальное хранилище, используемое операционной системой, в котором находятся эскизы изображений из текущей папки. Если в проводнике выбрать режим отображения "Эскизы страниц", то операционка будет брать уменьшенные превьюшки изображений как раз из этого файла. Он создается в каждой папке, в которой есть картинки, и содержит уменьшенные эскизы изображений в формате JPEG (вне зависимости от формата исходного изображения).

Проведем небольшой эксперимент — создадим папку и поместим туда три любых картинки. Теперь откроем эту директорию в проводнике — появился Thumbs.db (чтобы увидеть этот файл, надо включить отображение скрытых файлов). Мы можем просмотреть и проанализировать его с помощью утилиты Thumbnail Database Viewer. Программа, как и положено, показывает эскизы для всех трех файлов. А теперь удалим один из них с помощью программы SDelete или любой другой программы для безопасного удаления данных:

sdelete.exe -p 2 file1.jpg

Параметр р отвечает за количество проходов шредера, то есть указывает, сколько раз файл будет перезаписан перед удалением. В результате изображение будет безвозвратно стерто с жесткого диска. Но посмотрим, повлияло ли как-то это удаление на Thumbs.db? Заново открываем его, и что мы видим? Эскиз для удаленной картинки по-прежнему на месте! Получается, что файл легко может содержать эскизы уже удаленных изображений. И на этом, как мне рассказывали, попался не один умный человек…

Как этого избежать? Очень просто — нужно просто отключить кэширование эскизов в файлах Thumbs.db. На Windows XP необходимо установить для ключа DisableThumbnailCache в разделе HKEY_CURRENT_USER\Software\ Microsoft\Windows\CurrentVersion\Explorer\Advanced значение "1". В Windows 7 этот ключ имеет имя NoThumbnailCache и находится в HKEY_CURRENT_USER\Software\Microsoft\ Windows\CurrentVersion\Policies\Explorer. И, само собой, важно не забыть удалить все Thumbs.db.

Подставы со стороны операционной системы на одном только файле с эскизами не заканчиваются. По мере работы с документом информация о нем попадает в различные части ОС — временную папку, реестр и так далее. Поэтому очень трудно отследить и удалить все связанные с файлом данные. Вдобавок ко всему, есть места, где копия файла может оказаться совершенно случайно (иногда такая случайность может стоить очень дорого). Я говорю о файле подкачки (pagefile.sys) и свопе памяти, используемом во время режима Hibernation (hiberfil.sys). Предсказать содержимое файла подкачки заведомо невозможно, и тут никто ничего не может гарантировать. Предлагаю еще на одном эксперименте убедиться в том, что это — опасное место.

Поскольку просмотреть или скопировать файл подкачки операционная система просто так не дает, то у нас есть два варианта: задействовать специальные утилиты или же загрузиться в другую операционку и получить доступ к файлу из нее. Мне второй способ показался более простым, так как под рукой был Back Track, начиненный различными утилитами, в том числе и для восстановления файлов. Поэтому, загрузившись с LiveCD, я смонтировал виндовый раздел и пошел в раздел "BackTrack->Forensic", откуда запустил утилиту Foremost. Эта замечательная консольная прога умеет восстанавливать файлы исходя из их заголовков и внутренней структуры. Необходимо лишь передать имя входного файла, в котором будет осуществляться поиск, и указать директорию, куда будут сохранены все найденные данные:

#foremost -i /mnt/hda1/pagefile.sys -o /root/Desktop/page_file -v -q

В качестве входного файла я указал файл подкачки /mnt/hda1/pagefile.sys, а директорию для сохранения результатов — /root/Desktop/page_file. Программа начала свою работу. За короткое время Foremost сумел найти и извлечь 524 файла.

Статистика извлеченных файлов:
jpg:= 73
gif:= 4
gif:= 19
jpg:= 77
jpg:= 95
doc:= 1
pgp:= 65
pgp:= 62
pgp:= 44
pgp:= 36
dat:= 7
lnk:= 3
cookie:= 38

Утилита удобно отсортировала все файлы по типу и разложила по разным папкам. Первым делом я полез проверять, что же попало в папку jpg. Из всех восстановленных файлов около половины отказалось отображаться, зато другая — отлично просматривалась. И чего только не было среди картинок: пара фоток, которые я не так давно удалил; много мелких изображений с веб-сайтов; аватарки друзей из Facebook и прочее. Честно сказать, я не планировал обнаружить так много изображений. Кроме картинок мне хотелось еще узнать, что за единственный doc-файл, который попал в файл подкачки. Но, к сожалению, Word лишь ругнулся, что файл попорчен и не смог его открыть. Неожиданный сюрприз ждал меня в папке cookie — бегло пролистав несколько файлов, я обнаружил адреса роликов, которые я смотрел чуть ли не год назад на YouTube. Вот и еще одно доказательство, что даже удалив в браузере все куки и историю, все равно можно проколоться.

Что тут можно сделать? Есть несколько вариантов. Первый — отключить вообще файл подкачки. Для этого надо зайти в "Control Panel-> System and Security-> System-> Advanced System Settings-> Performance-> Advanced-> Virtual Memory-> Change" и выбрать опцию "No paging file". Второй вариант — заставить операционную систему затирать все данные в файле подкачки перед выключением компьютера. Такой режим активируется, если установить для ключа ClearPageFileAtShutdown в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Control\Session Manager\Memory Management значение "1". К сожалению, второй метод очень медленный, и выключение системы будет занимать достаточно длительное время, так что применять его на практике или нет — решай сам. Аналогичная ситуация и с файлом hiberfil.sys. Его также можно попросту отключить, что сэкономит дополнительное место на диске.

Кстати, исследовать файл подкачки можно и под виндой. Но так как операционная система не дает его просмотреть и скопировать с помощью штатных средств, нам понадобится программка FTK Imager. Переходим в раздел "File-> Add Evidence Item" и указываем диск, где находится файл подкачки. На панели слева отобразится дерево каталогов, где необходимо выбрать pagefile.sys и воспользоваться функцией экспорта через контекстное меню. Файл подкачки без проблем скопируется в указанную нами папку, и никакие блокировки системы с этого момента не помешают его анализировать. Для анализа, кстати, можно воспользоваться DiskDigger или PhotoRec. Первая — проще, но вторая умеет восстанавливать более широкий круг различных форматов файлов.

Перейдем к следующей причине появления файлов-призраков. Чтобы было наглядней и понятней — опять же проведем небольшой эксперимент. Для него нам понадобится флешка и умение обращаться с WinHex’ом. Сначала обеспечим условия для опыта, удалив все данные с флешки. Для этого запустим WinHex, отдадим команду Open Disk и в появившемся окне выберем наш девайс. После открытия полностью выделяем все его содержимое (Ctrl+A) и забиваем нулями (Ctrl+L). Одно замечание — процесс перезаписи занимает достаточное количество времени, так что рекомендую взять флешку поменьше. С этого момента на драйве нет данных и, более того, нет файловой системы. Так что следующим шагом будет форматирование флешки в NTFS. По умолчанию Windows XP дает форматировать флешку только в FAT, но для наших манипуляций требуется NTFS. Чтобы операционная система позволила отформатировать устройство в нужную нам файловую систему, необходимо зайти в диспетчер устройств, найти там флешку и в параметрах установить опцию "Optimize for performance". После этого винда сможет отформатировать флешку в NTFS.

Цель нашего опыта — посмотреть, что происходит с файлами во время дефрагментации. Для этого создадим искусственную фрагментацию на нашем носителе информации. Возьмем три любых jpeg-файла и три каких-нибудь аудиофайла или видеоклипа (главное, чтобы их размер был больше jpeg’ов) и скопируем их на флешку в следующем порядке: 1.mp3, 1.jpg, 2.mp3, 2.jpg, 3.mp3, 3.jpg.

Интересно, как же они расположились на диске? Чтобы посмотреть это, воспользуемся тулзой DiskView от Марка Руссиновича. Она выводит графическую схему диска, на которой можно определить местоположение данных или узнать, какой файл занимает те или иные кластеры (для этого нужно щелкнуть на кластер мышью). Двойной щелчок позволяет получить более подробную информацию о файле, которому выделен кластер. Запускаем программу, выбираем нашу флешку и нажимаем . Сначала идет зеленая полосочка, обозначающая системные кластеры, а вот сразу за ней — область синих кластеров, представляющих наши файлы, записанные друг за другом. Теперь создадим фрагментацию, удалив все аудиофайлы. Снова нажимаем и видим, что перед каждым jpeg-файлом есть пустая область. Теперь ненадолго переключимся в WinHex. Чтобы еще раз убедиться, что на флешке нет никаких лишних графических файлов, проведем поиск по сигнатуре: ищем последовательность "jfif", присутствующую в заголовке любого jpeg-файла. В итоге редактор, как и ожидалось, нашел ровно три таких последовательности, по числу оставшихся файлов.

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

C:\Documents and Settings\Administrator>defrag h:
Windows Disk Defragmenter
Copyright © 2001 Microsoft Corp. and Executive Software International, Inc.

Analysis Report
7,47 GB Total, 7,43 GB (99%) Free, 0% Fragmented (0% file fragmentation)

Defragmentation Report
7,47 GB Total, 7,43 GB (99%) Free, 0% Fragmented (0% file fragmentation)

Дефрагментация прошла, посмотрим, что изменилось на флешке. Жмем на в программе DiskView, и что мы видим? Файлы, которые располагались на расстоянии друг от друга, аккуратно перенесены в начало диска, и располагаются строго последовательно. А теперь внимание! Дефрагментация скопировала файлы в начало диска, расположив их последовательно, но перезаписала ли она их предыдущую копию нулями? Чтобы ответить на этот вопрос, опять обратимся к мощному шестнадцатиричному редактору. Снова проведем поиск по "jfif". Оп-па, теперь вместо трех найденных строк получаем целых шесть! И это может означать только одно — теперь каждый файл представлен в двух экземплярах. Любой из них легко восстанавливается с помощью DiskDigger’a или Photorec’a. А теперь представь, что вместо графических файлов у нас были какие-то конфиденциальные документы или файлы с данными по кредиткам. Даже если бы мы использовали утилиты типа Sdelete и переписали перед удалением эти три файла сотни раз, их призраки все равно остались бы на диске и существовали там неопределенно долгое время. До тех пор, пока не будут перезаписаны чем-либо еще. И все это время их можно будет восстановить!

Очень часто люди впадают в две крайности. Одни откровенно забивают на свою безопасность и хранят на винте всю компрометирующую информацию, будучи уверенными, что их спасет. Другие же, наоборот, каждый день затирают винт и заново устанавливают операционку. Быть может, я утрирую. Тем не менее, довольно часто приходится читать в Сети споры о том, сколько же раз надо перезаписать винт, чтобы информацию невозможно было восстановить. Предлагаю опытным путем выяснить, хватит ли одной полной перезаписи, чтобы безвозвратно удалить все данные. Итак, опять возьмем нашу подопытную флешку и полностью перезапишем ее нулями, после чего отформатируем в NTFS. Для проверки закинем на нее какой-нибудь файл: пусть это будет опять же JPEG. Его легко можно найти в WinHex’е по сигнатуре "jfif". У меня он расположился по смещению 274432. Ну что ж, запустим шредер (я юзал HDD Wipe Tool) и затрем весь диск. Теперь, если посмотреть в WinHex, что расположилось по смещению 274432, то мы увидим только нули. Для успокоения и большей уверенности можно попробовать восстановить данные с помощью DiskDigger, Photorec, Foremost и прочих утилит. Но это заведомо пустая трата времени — ничего у них не выйдет.

"Хорошо, — скажешь ты, — а как же насчет серьезных приборов, имеющихся у компетентных органов, которые умеют восстанавливать данные?" Ну что ж, давай поговорим о магнитной микроскопии. Суть метода в том, чтобы определить состояние каждого бита до его перезаписи. То есть, был ли он равен единице или нулю. Возьмем текст в кодировке ASCII. Каждый символ кодируется восемью битами таким образом, что если даже всего один бит восстановлен неверно — получается совсем другой символ. Например, есть последовательность символов "anti", выглядящая в бинарном виде следующим образом: 01100001011011100111010001101001. Предположим, что магнитная микроскопия правильно определила все биты, кроме последнего — в результате такого восстановления мы получаем последовательность "anth". Неувязочка получается. И это мы говорим о простейшем текстовом файле. Представь, что будет в случае со структурированными форматами — такими как архивы, файлы БД, исполняемые файлы и так далее. Вдобавок к этому метод достаточно медленный и дорогой. Так что во многих случаях использование магнитной микроскопии дает такой же точный результат, как и восстановление путем подбрасывания монетки на "орел-решка". Поэтому нет никакой необходимости по три раза перезаписывать диск.

Что можно сделать, чтобы усложнить жизнь людям, к которым может попасть для экспертизы твой компьютер? Тут есть несколько вариантов. В случае, если на компьютере нашли "интересный" файл, время его создания будет веским доказательством против его владельца. Чтобы проследить цепь событий, эксперты опираются также на время создания/доступа/модификации файла. Так почему бы не запутать следы? На сайте metasploit.com есть такая замечательная утилита, как Timestomp, которая позволяет менять время создания, модификации или доступа для заданного файла. Основные опции для ее использования:

-m задает дату последней модификации файла
-a задает дату последнего доступа к файлу
-c задает время создания файла
-e задает время модификации файла, хранящееся в MFT
-z задает четыре вышеперечисленных параметра

Дата задается в следующем виде: DayofWeek Month\Day\Year HH:MM:SS [AM|PM].

Есть еще очень интересная опция -b, которая устанавливает вышеперечисленные атрибуты таким образом, что известная в кругах компьютерных криминалистов программа EnCase их не видит и отображает пустыми .

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

c:\>timestomp.exe boot.ini -z "sunday 1/12/2099 10:00:00 pm"

Легко можно набросать скриптик, который будет рекурсивно менять временные атрибуты файлов. Простейший вариант выглядит так:

for /R c:\tools\ %i in (*) do timestomp.exe %i -z "monday 3/12/2009 10:00:00 pm"

Есть и другие способы подпортить жизнь товарищам-исследователям чужих HDD. В своей работе они используют программы, написанные обычными людьми, а потому — содержащими ошибки. Да-да, мы можем использовать уязвимости программного обеспечения, применяемого для поиска улик. Подробней об этом можно почитать в одном из докладов с конференции DefCon.

лучший метод-100 %- это электромагнит(достаточно мощьный) выдающий переменное электромагнитное поле! кнопочку нажал- и УСЕ!