Надежное удаление с последующим форматированием

← →
alumium (2013-02-07 23:21) [0]

Доброго времени суток, форумчане. Вынужден попросить у вас помощи в написании программы для надежного удаления информации.
Её суть: выделяешь checkbox"ами диски, которые нужно очистить. Программа заполняет кластеры тома нулями или случайными байтами (Т.е. не перезапись по 1 файлу, а как можно быстрее. Побайтовый перебор скорее всего медленный.). После этого быстрое форматирование тома.
Сторонние утилиты не интересуют.
Буду надеяться на вашу помощь. Спасибо.

← →
Rouse_ © (2013-02-07 23:35) [1]

Вопрос-то какой?

← →
Danko (2013-02-07 23:43) [2]

uses ShellAPI;

ShellExecute (Handle, nil, "format d: /u", nil, nil, SW_RESTORE);

(образец)

← →
Никита32 (2013-02-07 23:50) [3]

http://www.delphisources.ru/pages/faq/base/format_disk.html

← →
Никита32 (2013-02-07 23:52) [4]

http://forum.vingrad.ru/faq/topic-155950.html

← →
alumium (2013-02-08 00:55) [5]

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

← →
palva © (2013-02-08 01:48) [6]

Открыть физически том при помощи CreateFile (должны быть на это права) и расписать. Сам пробовал однажды для чтения нескольких блогов (MBR).
http://www.vsokovikov.narod.ru/New_MSDN_API/Menage_files/fn_createfile.htm

← →
KilkennyCat © (2013-02-08 03:53) [7]

> alumium

а смысл?
информация все равно восстановима. либо дорогостоящими технологиями, либо дешевым утюгом.

← →
brother © (2013-02-08 04:18) [8]

чтож всех на скрытность то тянет?
мои наброски, разбирайся!
function TProgramForm.SafeRemoval(drive: char): boolean; var sh : SHFILEOPSTRUCT; FreeBytesAvailableToCaller: TLargeInteger; FreeSize: TLargeInteger; TotalSize: TLargeInteger; f: file; NumWritten: Integer; Buf: pointer; bufSize: Integer; BytesWrite: TLargeInteger; begin result:= False; StopSafeRemoval:= False; // ShowMessage("Удаление всего содержимого диска, это может занять длительное время, ждите..."); // Удаляем ВСЕ содержимое с устройства! AddLog("Удаление всего содержимого диска, ждите..."); sh.Wnd := Application.Handle; sh.wFunc := FO_DELETE; sh.pFrom := PAnsiChar(drive + ":\*.*"); sh.pTo := nil; sh.fFlags := FOF_NOCONFIRMATION + FOF_SILENT+ FOF_NOERRORUI; sh.fAnyOperationsAborted := False; sh.hNameMappings := nil; sh.lpszProgressTitle := nil; if SHFileOperation(sh) <> 0 then begin AddLog("Не удалось(файлы/папки заняты другим приложением?)"); //Exit; end else AddLog("Ok"); // узнаем кол-во свободного места на диске if not GetDiskFreeSpaceEx(PChar(drive + ":\"), FreeBytesAvailableToCaller, Totalsize, @FreeSize) then begin AddLog("Ошибка получения свободного места: " + GetLastErrorText); exit; end else AddLog("Свободное место на диске: " + IntToStr(FreeBytesAvailableToCaller) + " байт"); // FreeBytesAvailableToCaller:= {1073741824;} 2147483648; // Создаем файл с пустым содержимым по размеру всего диска AddLog("Создание временного файла, ждите..."); BufSize := 1048576; // 1МБ GetMem(buf, BufSize); //Gauge1.MaxValue:= FreeBytesAvailableToCaller; BytesWrite:= 0; try assignfile(f, drive + ":\tmp.$$$"); rewrite(f, 1); while (BytesWrite+bufSize <= FreeBytesAvailableToCaller) and (not StopSafeRemoval) do begin BlockWrite(f, Buf^, BufSize, NumWritten); Inc(BytesWrite, NumWritten); // Gauge1.Progress:= BytesWrite; application.ProcessMessages; end; except FreeMem(Buf); CloseFile(f); end; if StopSafeRemoval then begin AddLog("Отменено пользователем!"); FreeMem(Buf); CloseFile(f); Exit; end; // если в конце не дозаписан хвост меньше bufSize дозапишем его if BytesWrite < FreeBytesAvailableToCaller then begin BufSize := FreeBytesAvailableToCaller-BytesWrite; FreeMem(Buf); GetMem(buf, BufSize); BlockWrite(f, Buf^, BufSize, NumWritten); end; FreeMem(Buf); CloseFile(f); AddLog("Ok"); { if DeleteFile(drive + ":\tmp.$$$") then AddLog("Временный файл успешно удален") else begin AddLog("Ошибка удаления временного файла"); exit; end;} result:= True; end;

← →
alumium (2013-02-08 16:56) [9]

спасибо, друзья, пойду пробовать...

← →
Rouse_ © (2013-02-08 22:49) [10]

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

← →
Rouse_ © (2013-02-08 22:51) [11]

ЗЫ: ну а потом конечно можно и отформатировать :)

← →
Inovet © (2013-02-08 23:29) [12]

> [11] Rouse_ © (08.02.13 22:51)
> ЗЫ: ну а потом конечно можно и отформатировать :)

А сразу отформатировать?

← →
Rouse_ © (2013-02-08 23:59) [13]

> А сразу отформатировать?

А что это даст, с учетом задачи от автора?

← →
Макс Черных (2013-02-09 03:50) [14]

> Программа заполняет кластеры тома нулями или случайными
> байтами (Т.е. не перезапись по 1 файлу, а как можно быстрее.
> Побайтовый перебор скорее всего медленный.). После этого
> быстрое форматирование тома.

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

Самый быстрый, надежный и легальный способ это гоблин с ружъем. Оный при опасности просто делает "случайный" выстрел прямо в винт. Это вовсе не шутка, а реалии 90х годов. :)
Это я к чему - прежде чем играть в шпионов надо бы определиться - от кого, собственно, прячемся. Часто для надежного сокрытия информации даже стирать все не надо. Гораздо хитрее проще и быстрее подменить, скажем, базу 1С другой, набитой всякой "важной" инфой, которая на деле - мусор. Ну, т.е. создать у того, кто будет искать полное впечатление того, что все что надо он типа нашел. И щас всех комерсов поимеет за водку паленую. Ага, щас, комерсы заранее мну денежку занесли, за кое какие фокусы. :) Расцвет демократии начала 90х, однако. :)

Так что, ИМХО, перед тем как думать как? надо определиться- зачем?

← →
brother © (2013-02-09 07:14) [15]

> он ориентируется на файловую систему, которую ты и хочешь
> убить.

да хрен с ней! данные будут не восстановимы...

← →
Rouse_ © (2013-02-09 09:37) [16]

> brother © (09.02.13 07:14) [15]
> да хрен с ней! данные будут не восстановимы...

Не факт

← →
brother © (2013-02-09 10:39) [17]

все сектора с данными перезаписываем (кроме FS)? profit!

← →
Rouse_ © (2013-02-09 11:01) [18]

> brother © (09.02.13 10:39) [17]
> все сектора с данными перезаписываем (кроме FS)? profit!

EnCase Forensic (ПО для СКТЭ уполномоченными экспертными организациями) не совсем согласен с данным утверждением :)

← →
brother © (2013-02-09 11:03) [19]

можно ссылки? ибо имхо, 1 раза перезаписи достаточно

← →
Rouse_ © (2013-02-09 11:07) [20]

Поиск по EnCase Forensic.
В нашей практике данное ПО помогло собрать доказательства на некоего товарища, распространявшего наше ПО (контрафактное есесно)
http://www.grandsmeta.ru/cat82/pages/id_52
Форматирование не помогло, хранение данных в DiskCript-е тоже.

← →
Rouse_ © (2013-02-09 11:08) [21]

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

← →
brother © (2013-02-09 11:17) [22]

http://soft.sibnet.ru/soft/16096-encase-forensic/
почитал
Удаление и перезапись файлов не приводят к исчезновению всех уязвимых данных с жесткого диска. Стиранию должны подвергаться все секторы (составляющие кластер 512-байт сегменты), так как данные могут скрываться в самых неожиданных местах. Часто в последнем кластере большого файла находятся случайные данные, называемые заполнителями файлов (file slack). Когда на жестком диске записана последняя часть файла и данные не заполняют сектор целиком, он дополняется случайно выбранными данными, взятыми из памяти и называемыми заполнителями ОЗУ (RAM slack). Это может быть любая информация, сформированная, просматривавшаяся или преобразованная со времени последней загрузки компьютера. Остальные секторы, составляющие кластер, содержат остатки разных данных, ранее сохраненных в этом месте, которые называются заполнителями диска (drive slack). Многие программы безопасного удаления данных не способны должным образом стирать заполнители файлов, которые могут содержать массу конфиденциальной информации.
улыбнуло, ибо в идеале, что можно вытащить из 512-1 байт? ну итп...
копаться по остаткам перезаписанной инфы чтобы собрать менее приемлимую картину того, что там было? хм...
опять же не понимаю требование перезаписывать данные для безопастности дважды...

> хранение данных в DiskCript-е тоже.

постучали дубинками по голове и узнали пароль?)

← →
brother © (2013-02-09 11:18) [23]

> возьми утилиту типа UnErase (детская поделка) и попробуй
> вытащить данные после форматирования. Даже она сможет немного
> но вытянуть, что уж говорить об экспертном комплексе.

ща на флеше потренеруемся...

← →
brother © (2013-02-09 11:24) [24]

вообще, давно хотел провести подобный анализ, надо будет заняться на досуге...

← →
brother © (2013-02-09 11:32) [25]

> После этого быстрое форматирование тома.

я даже знаю зачем это требование ;) дабы FS с нуля не городить)

← →
Rouse_ © (2013-02-09 11:40) [26]

> brother © (09.02.13 11:17) [22]

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

> постучали дубинками по голове и узнали пароль?)

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

← →
brother © (2013-02-09 11:42) [27]

> но скорее на остаточной намагниченности

вот этого я не понимаю, как можно это прочитать, ведь при этом считаем, что один сектор содердит как бы двойные данные (что сейчас есть, и что были и остались в виде остаточной)

← →
Rouse_ © (2013-02-09 11:45) [28]

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

> Знаю что дорожки широкие и запись данных не всегда идет
> по ее центру (головка плавает).

опять же, значит местами сможем что-то прочесть, и опять копаться в мусоре

После небольшого анализа:
1. Флешка с данными отформатирована полным форматированием (ФС до и после формата одинаковые - НТФС)
2. Попытка восстановить данные спомощью Handy Recovery 5.5 - результат 0.
3. При просмотре диска через WinHex.16.3.SR-2 - видна ФС, остальное забито нулями.
Предв. выводы:
1. При условии, что данные должны быть удалены с гарантией не восстановления, нужно использовать свои дрова работающие с контроллером диска напрямую + скорее всего вынимать блины дисков ид корпуса и ставить на спец стенд), ибо штатными средствами ОС достучаться до данных, возможно находящихся не в центре дорожки невозможно.
2. О какой программе (гарантирующей не восстановления данных) может идти речь, если все мы работаем через ОС?

> местами сможем что-то прочесть

обычно этого достаточно

Забыл главный вывод:
3. Удаление всех файлов и папок на устройстве и запись на него мусорного файла размером с объем накопителя достаточно, чтобы говорить о невосстановлении данных штатными средствами и утилитами
примечание: список старых имен файлов останется в ФС, но и хрен с ними)

> чтобы говорить о невосстановлении данных штатными средствами
> и утилитами

дык про штатные средства никто и не говорил.

а не штатные никто не озвучивал)

> попросить у вас помощи в написании программы для надежного
> удаления информации.

Я думаю этого достаточно чтобы не рассматривать штатные средства :)
Собственно я весь свой спичь на базе данной фразы и строит :)

тогда - термограната!

← →
Макс Черных (2013-02-09 15:37) [37]

> ща на флеше потренеруемся...

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

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

Саня, не позорь контору. :) Если блины не крутить, то ничего не прочитать, це же физика!
Там все проще, сигнал на блинах - аналоговый модулированный. Стирающей головки, как на магнитофонах нету. При перезаписи происходит перемагничивание магнитных доменов в месте текущего действия головки. Упрощенно - оное может как совпадать с тем что есть в данный момент, так и быть обратным. Управляя диском напрямую можно поиграть с настройками уровней компаратора для конкретного места. Т.е. именно за счет остаточной намагниченности прочитать то, что было до перезаписи.
Это долго, нудно, не 100%, но вполне возможно.

> Макс Черных (09.02.13 15:37) [37]

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

← →
alumium (2013-02-09 19:16) [39]

слушайте, а если просто пройтись быстрым форматированием из 1 фс в другую и в третью?

> alumium (09.02.13 19:16) [39]
> слушайте, а если просто пройтись быстрым форматированием
> из 1 фс в другую и в третью?

Заголовки потрешь и всего делов, причем только в начале диска.

Надежное удаление с последующим форматированием Найти похожие ветки