Как же всё-таки удалить файл без "хвостов"?
Модератор: Модераторы
Как же всё-таки удалить файл без "хвостов"?
Как же всё-таки удалить файл без "хвостов"?
Этот вопрос косвенно уже поднимался в теме "Как предотвратить восстановление удалённых данных?" viewtopic.php?f=13&t=11094. Дело в том, что если заменить содержимое файла, допустим, нулями, а затем выполнить удаление (сразу же или через несколько минут), то на диске сохраняется первоначальный текст. Если же в промежуток времени, между заменой содержимого и удалением открыть этот файл, например, "Блокнотом", то на диске остаются только нули. Причём во всех секторах. Специально сделал несколько относительно больших файлов, которые OC разбросала по всему диску, и проверял WinHex-ом.
Посоветуйте, как можно решить эту задачу?
У меня есть одна идея, связанная с запуском между заменой содержимого и стиранием чего-то типа "Блокнота", но может есть лучший вариант...
Этот вопрос косвенно уже поднимался в теме "Как предотвратить восстановление удалённых данных?" viewtopic.php?f=13&t=11094. Дело в том, что если заменить содержимое файла, допустим, нулями, а затем выполнить удаление (сразу же или через несколько минут), то на диске сохраняется первоначальный текст. Если же в промежуток времени, между заменой содержимого и удалением открыть этот файл, например, "Блокнотом", то на диске остаются только нули. Причём во всех секторах. Специально сделал несколько относительно больших файлов, которые OC разбросала по всему диску, и проверял WinHex-ом.
Посоветуйте, как можно решить эту задачу?
У меня есть одна идея, связанная с запуском между заменой содержимого и стиранием чего-то типа "Блокнота", но может есть лучший вариант...
Ты флушнул записанное перед этим? Желательно через API ОС (FlushFileBuffers на TFileStream.Handle). Всё равно может не сработать, как и чтение из другого процесса: слишком много слоёв абстракции, каждый из которых норовит что-то закешировать и оптимизировать. Так, задним числом можно предположить, что да, запросы к файлу, который всё равно предполагается тут же удалить, до физического устройства не доходят.
-
MysticCoder
- постоялец
- Сообщения: 154
- Зарегистрирован: 14.09.2013 00:20:28
Ага, открыть файл повторно самому
Нет. Я открываю файл средствами FPC без прямого использования API. Надо попробовать.Ты флушнул записанное перед этим?
- debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
Да зашифруйте этот файл (ессно не блочно, а целиком) паролем например "12345" и даже опубликуйте этот пароль на весь Интернет, и забивайте нулями перед удалением - но уже без шифрования. Хоть один сектор файла затрется нулями - информация в других секторах станет полным мусором.
- Лекс Айрин
- долгожитель
- Сообщения: 5723
- Зарегистрирован: 19.02.2013 16:54:51
- Откуда: Волгоград
- Контактная информация:
debi12345 писал(а):Хоть один сектор файла затрется нулями - информация в других секторах станет полным мусором.
вообще-то не совсем так. просто трудоемкость возрастает.
- debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
вообще-то не совсем так.
Один сектор, реально принадлежавший файлу, по-любому затрется - либо при забивании нулями, либо когда будет отдан другому файлу или каталожной структуре. Поэтому думаю что 100% надежное решение.
Попробовал в интервале между затиранием и стиранием запускать другое приложение через TProcess. Эффект нулевой: в файловой системе файл удаляется, а всё содержимое остаётся на диске. Вероятно, ОС зная, что это дочерний процесс, не сбрасывает на физический диск данные.
- debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
Попробовал в интервале между затиранием и стиранием
Шифруйте файл в рабочем режиме, а перед удалением затирайте без шифрования - должно помочь!
в файловой системе файл удаляется
Это еще зависит от файловой системы - FAT, NTFS, Ext,.. - поэтому вообще нельзя закладываться на сброс буферов и т.п.
Добавлено спустя 5 минут 2 секунды:
На само деле если кому-то ну ооочень надо прочитать этот файл, то он может тупо нажать "резет" во время работы проги - чтобы прога не успела удалить файл, и после перезагрузки...
- Лекс Айрин
- долгожитель
- Сообщения: 5723
- Зарегистрирован: 19.02.2013 16:54:51
- Откуда: Волгоград
- Контактная информация:
debi12345 писал(а):Поэтому думаю что 100% надежное решение.
но данные то восстановить реально.пусть частично, но иногда и этого много.
debi12345 писал(а): то он может тупо нажать "резет"
тогда уж с розетки дернуть.
Воспользовался советом runewalsh:
Получился вот такой код:
После этой процедуры сразу идёт удаление.
В результате перед удалением файла все данные на физическом диске затираются нулями, что, в принципе, и требовалось.
Тему можно закрывать.
Ты флушнул записанное перед этим?
Получился вот такой код:
Код: Выделить всё
procedure TForm1.EraseFileDisk(Path: String);
var
bf: THandle;
n: Longint;
z: DWORD;
M: array[1..256] of Byte;
begin
for z:=1 to 256 do M[z]:=0;
n:=FileSize(UTF8ToWinCP(Path));
try
bf:=CreateFile(PChar(Path),GENERIC_READ or GENERIC_WRITE, 0, Nil, OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0);
SetFilePointer(bf,0,nil,FILE_BEGIN);
while n>1 do begin
if n>255 then z:=256
else z:=n;
WriteFile(bf,M,z,z,nil);
FlushFileBuffers(bf);
n:=n-z;
end;
finally
CloseHandle(bf);
end;
end;После этой процедуры сразу идёт удаление.
Код: Выделить всё
DeleteFileUTF8(PChar(Path));В результате перед удалением файла все данные на физическом диске затираются нулями, что, в принципе, и требовалось.
Тему можно закрывать.
- GAMER
- энтузиаст
- Сообщения: 627
- Зарегистрирован: 06.08.2008 13:41:07
- Откуда: Ужгород-Днепр, Украина
- Контактная информация:
А можно узнать о задаче более детально? Файл создается только во время работы программы, и требуется не оставлять следов? Так может лучше вообще в памяти все держать? Или файл слишком большой?
Добавлено спустя 22 минуты 51 секунду:
PS. Уже прочитал базовую тему.
Добавлено спустя 22 минуты 51 секунду:
PS. Уже прочитал базовую тему.
Как решили проблему резета-выключения питания
Момент передачи данных в центральный оффис, после чего данные уничтожаются, определить сложно. Если, допустим, сеанс связи не состоялся, то состоится позже. Чисто теоретически, если всё-таки кому-то удастся предотвратить таким образом стирание, то суточная сводка или даже статистика одной точки особой ценности не представляет. Смотрите предыдущую тему.
- debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
Момент передачи данных в центральный оффис, после чего данные уничтожаются, определить сложно
Кому (по какой-то причине) надо будет прочесывать диск посекторно в поисках хвостов файла, тот уж о "моменте" точно сумеет позаботиться. В 1-ю очередь на время заменит свич на хаб и поставит у себя сниффер вроде WireShark - который умеет выуживать траффик в promiscious-режиме (не только свои пакеты, но и бегающие по всей локалке)
Чисто теоретически, если всё-таки кому-то удастся предотвратить таким образом стирание, то суточная сводка или даже статистика одной точки особой ценности не представляет
Хм, это обессмысливает всю тему - мы-то подумали, что вопрос секьюрити стоИт реально серьезно. Такие вопросы желательно решать на все 100%, иначе вообще не решать
