| Удаление удалённого в Ext4 (03.04.2026). |
|
| 2026 - Апрель | |||
| 03.04.2026 15:00 | |||
Сраная вкладка сраного браузера упала во время сраных тестов сраной Ext4 - весь сраный текст сраной статьи потерялся в сраной куче. Поэтому кратко: как разрубить цепочку наказания быдлом самых работоспособных сотрудников (когда предприятие само себе в ногу стреляет явлением "театр безопасности" в виде бредовых запретов - и идёт соответствующий отток мозгов-специалистов со временем). Удалить самый первый триггер возбуждения ревизоров: названия удалённых файлов. И если с MFT всё просто, то с Ext4 - до сих пор не уверен, что решение 100% всегда рабочее (поэтому предпочитаю далее использовать шифрование виртуалок - раз, два, три, четыре - и данный материал развиваться дальше не будет).
Поведение Ext4 нелинейное и неоднозначное: - файлы записываются нефрагментированными - но раскидывает их по всему разделу (не быстрее ли изнашиваются головки, постоянно преодолевающие 1000 больших расстояний к нефрагментированных файлам, чем 1000+ маленьких расстояний фрагментированных файлов в одном месте); - удивлённое предположение, что Ext4 следит за удалёнными файлами: пока область с данными на диске не будет перезаписана - хранит запись в таблице раздела, перезаписана - сама удаляет запись из таблицы; - команда shred - удаляет и содержимое, и данные на диске. Но только существующего в настоящий момент (натравливать на несуществующие - не пробовал, да и смысла нет: список этот как получать - отдельный большой вопрос); - какой-то у*бок при разработке астры 1.4 - решил ограничить размер файла в Ext4 ~24ГБ, спутав тем самым результаты части тестов и чуть не похоронив правильный итоговый алгоритм; - значит, программа очистки должна быть самодельной: прикинуться системным файлом-1, найти место хранения ограничения размера файла, изменить номинал ограничения, применить номинал ограничения, создать 1 файл размером со всё свободное место (подменив им системный файл-2 тоже где-то глубоко в системных папках), напихать в него нулей (а лучше мусора, чтобы не палиться), натравить на этот файл shred с определёнными параметрами (подчищаем хвосты не просто удалением, но и мусором), натравить shred на сам файл программы, скопировать заранее сохранённые на DVD оригинальные системные файлы обратно (с выставлением прав, владельца и группы), можно ещё заморочиться с подделкой времени создания и изменения системных файлов - да и вообще похерить или заменить все логи. Для получения 100% правильного результата - тестировал на примере Fast ZeroFilling, которую заставили переписать под Linux приближающие лангольеры: дать программе будущее при принудительной бессмысленной и беспощадной замене Windows на Linux. Она прекрасно работает в астре 1.7.4 и прочих линуксах - но при запуске в самом говне, астре 1.4, она необъяснимым образом и необратимо ломает sudo (чтобы исправить sudo - нужно зайти под sudo, а root отключён по умолчанию) даже без зануления (при появлении окна программы - к вопросу защищённости этой ОС от малейшего вмешательства стороннего ПО - да и как вообще такая программа такого рода могла куда-то вмешаться?). Итак, берётся 1ГБ данных (большие и маленькие файлы) - и раскидывается гигабайтными порциями в разных местах жёсткого диска. С части мест - удаляется. Оставленные 2ГБ данных - ложатся по диагонали раздела, удалённые данные с красными крестами - успешно восстанавливаются. Делается проход Fast ZeroFilling - записи с красными крестами пропадают (остаются файлы вида $inode, $Xauthority - некритично, а самый главный скрин исчезновения - просрал). Как создать свою программу: - взять мою, запустить скриптом, она всё занулит, - попробовать натравить shred на те файлы, которые она создала и удалила в заведомо определённом месте; - встроить 2 строчки исходников в алгоритм выше. sudo dd if=/dev/urandom of=./trash.fill bs=1M status=progress (if - входящее устройство, of - исходящий файл, bs - размер блока (спорный), status - показ процесса выполнения, /dev/urandom - псевдоустройство, генерирующее мусор). sudo shred -uvn 1 ./trash.fill (u - удаление файла из таблицы разделов, v - ход выполнения, n - количество перезаписей). То есть, итоговые 2 раза мусором перезапись будет - нулями и мусором было бы быстрее. |
|||
| Обновлено ( 03.04.2026 21:00 ) |