Немножко про уничтожение данных.

Posted: 2010-11-14 in IT

Тут будет небольшое повествование о необратимом удалении данных. …

Итак, для начала немного ссылок:
http://www.securitylab.ru/news/399538.php
http://www.securitylab.ru/news/366929.php
http://www.securitylab.ru/news/355543.php
Казалось бы — в таких организациях должны быть внедрены наиболее жесткие регламенты по защите информации, и техотделы таких контор должны жестко держать хватку. Фича же вот в чем. Информация имеет фундаментальное свойство — бесконечная копируемость с сохранением целостности. Свойство это фундаментально для любых дискретных сигналов, и для его преодоления потребуется изменить какие-то совсем уж фундаментальные законы мироздания. Это то самое свойство, которое при современном уровне развития техники делает крайне запарным даже сохранение действительно секретной информации, а скажем создание доказуемо надежной DRM-системы — в принципе невозможным. Итак, есть ровно один способ защиты от утечки — предотвратить самое первое копирование злоумышленником. Это вполне реализуемо, если доблестные офицеры работают с изолированным ядрено защищенным сервером глубоко в бункере, и рядом с каждым принтером и системным блоком стоит офицер безопасности, проверяющий весь обмен внешними данными. Когда же носитель инфы (ноут/флешка/дискета) выносится за пределы бункера, то задача резко усложняется. Конечно, криптованные файловые системы существуют, но их почему-то мало используют даже военные, хотя сейчас технических препятствий к этому особых нет.

Но что делать, если скажем у вас есть в работе носитель, который не зашифрован, но на котором была важная инфа ? Ответ — жестко затирать. Итак, основные сценарии:

1). Секретные файлы стерты небезопасным способом, но носитель форматировать нельзя/влом/долго. Решение для файловых систем, у которых содержимое файлов не может лежать внутри служебных блоков ФС (FAT/Ext2/Ext3) — затирание пустого места.

dd if=/dev/urandom of=/media/MyDisk/00000.bin bs=512K

Имя файла — произвольное, главное не затереть что-нить важное. dd создаст новый файл и будет писать туда, пока не кончится место. Если файловая система допускает хранение мелких файлов как часть файловой системы (наиболее известный пример — ReiserFS/NTFS, способные хранить содержимое мелких файлов размером до ~ 512 байт/2К прямо в служебных структурах самой ФС), то этот метод может оказаться недостаточно надежным. Команду можно (и нужно) выполнять от обычного пользователя.

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

dd if=/dev/urandom of=/dev/sdd3 bs=512K

Самое главное тут — не ошибиться в имени блочного устройства. Утилита dd подтверждений не спрашивает, и если вы нажмете Enter при неправильно указанном устройстве, оный dd снесет вам файловую систему на разделе раньше, чем вы успеете моргнуть. Для какого-нить FAT/NTFS — номер весьма смертельный, инфа восстанавливаема, но долго, мутно и дорого. Для надежного затирания надо дождаться окончания записи и появления от dd сообщения «на устройстве кончилось место». Выполнять надо от суперпользователя и на отмонтированной ФС. Что хорошо — данный метод одинаково хорошо убивает любые файловые системы и остаточные данные.

3). Затирание всего накопителя. Применяется редко — либо при продаже/списании жесткого диска/ноута/флешки, либо в том случае, когда есть подозрение, что чувствительные данные могли оказаться в произвольном месте накопителя. Классический пример — Windows 2000 при работе с накопителями и разделами большого объема (например, винт на 250 Гб, разбитый поровну). Иногда оный виндовс повреждает второй раздел и начинает писать данные из него в начало диска. Понятно, что таблице разделов и самим разделам писец, но если скажем какой-нить утилитой произвести восстановление разметки и продолжить использовать старые разделы, тупо их отформатировав, то ценные данные могут остаться незатёртыми. В этом случае труъ-параноик должен сделать так:

dd if=/dev/urandom of=/dev/sdd bs=512K

Опять же очень важно не перепутать имя устройства — иначе можно легко похоронить на рабочей системе таблицу разделов, загрузчик, первый раздел и часть данных. Для надежного затирания достаточно дождаться сообщения от dd «на устройстве кончилось место».

Теперь немного о количестве проходов. Рекомендаций на эту тему много, но им почему-то никто не следует, даже те, кому это положено по уставу. Для современных жестких дисков (емкость от 20 Гб и выше) вполне достаточно одного прохода. Для более старых винтов (1Гб-20Гб) имеет смысл сделать два прохода. Большее число проходов можно сделать только для очень старых винтов с низкой плотностью записи. Винты с шаговыми двигателями я рассматривать не буду — они устарели очень давно, и вы их даже в музее найдете далеко не сразу.
Для флешек/MP3-плееров достаточно ровно одного прохода.
С дискетами сложнее — плотность записи у них низкая. Если решили все-таки именно затереть дискету — засобачьте проходов 10, с обязательным выполнением команды sync между проходами. Если же бухгалтер принесла вам умершую/плохо читающуюся дискету с ключами от Банк-Клиента/СБиСа, то не поленитесь разломать корпус, вытащить носитель, поводить по нему мощным магнитом из старого жесткого диска (там очень годные магниты из блока позиционирования, постарайтесь не защемить пальцы) [проведите по всей поверхности гибкого диска раза три-четыре с каждой стороны], после чего измельчите носитель ножницами. Это совсем несложно, защита банковского счета вполне того стоит. Просто так выбрасывать ключевые дискеты — неправильно.
Cтарые CD/DVD-RW болванки с особо ценной инфой имеет смысл мелко измельчить с помощью подхэтоодящего инструмента. Если градус паранойи не настолько высок — сгенерируйте с помощью dd файл с 700Мб/4.7Гб бинарного мусора и запишите его на болванку. Потом заполните файл новым бинарным мусором (shred -n 1) и повторите процедуру.

Вообще, практика необратимо затирать списанные/продаваемые/неиспользуемые носители должна стать хорошим тоном работы любого более-менее адекватного технического специалиста. Конечно, стирание идет довольно долго, но с другой стороны — оно не требует никакого ручного вмешательства. Если винтов для стирания много — подключите их к тестовому компутеру, загрузите там Knoppix/RIPLinux и запустите стирание дисков [имеет смысл открыть несколько терминальных сеансов ив каждом запустить команду стирания своего накопителя]. Иногда система не успевает одновременно писать бинарный мусор на несколько винтов сразу с адекватной скоростью (актуально для старых материнок и древних чипсетов) — в этом случае поможет написание простейшего мини-скрипта из трех строчек.

Требуемые для безопасного удаления данных утилиты dd и shred есть в любом Linux/BSD-дистрибутиве из коробки. Под виндовс встроенных и готовых к применению средств нету, надо ставить дополнительный софт. Есть вполне годный PGP Desktop 6.02, в котором есть тулза PGP Freespace Wipe. Естественно, пользоваться надо только открытыми решениями, исходный код которых был проверен. Защита информации — это не та область, где можно положиться на «честное пионерское слово» разработчиков утилиты. А то ради «ускорения процесса затирания» недобросовестные конторы вполне могут стирать лишь каждый 50-й блок с целью заявить в рекламе о «революционном 50-и кратном ускорении затирания всего за 29.99$». XOR вместо криптоалгоритма в закрытом коммерческом продукте уже был (см. п.3) (Шнайер не даст соврать), обычное матричное умножение — тоже, закрытый и проприетарный убер-зондер-алгоритм аппаратного шифрования от Easy Nova тоже оказался полнейшей туфтой, так что тут — также не исключено, будьте внимательны, не пользуйтесь закрытыми непроверенными криптоподелками.

- комментарии
  1. xztque:

    1 не подходит для flash-памяти. Чтобы надёжно затереть данные, нужно тереть всю флешку. Учитывая тот факт, что некоторые флеши не сохраняют сами нули, а лишь начало и размеры последовательностей — /dev/zero не использовать! Я писал вообще одни единицы. Пример:

    #include <unistd.h>
    int main()
    {
        unsigned char writeme = 0xFF;
        while(1){
            write(0x01, &writeme , sizeof(writeme));
        }
        return 0;
    }
    ...
    ./put_one | dd of=/dev/sdX 

    И ещё. Религия запрещает писать не-побайтово? Для той же флеши — уверяю тебя — запись будет быстрее, если писать помногу — по 96кб, например. Инфа затрётся точно также, но быстрее.dd if=/dev/urandom of=/dev/sdX bs=96k — вот так будет лучше.Для SSD, насколько я знаю, методика та же. Только писать лучше кусками поздоровее. И, да, тоже не нули.

  2. GenrihMuller:

    Немного не в тему, но: если нужно гарантировано уничтожить HDD, то принцип тот же, что и с дискетой: Берётся дюбель-гвоздь от строительного пистолета и молотком вбивается в крышку. Процидурку повторить пару раз. Крышку снять, и убедится, что блины расколоты. Варварство, но с гарантией, оправдано в том случае, если инфа с HDD (сомнительная бухгалтерия например) ну ни в каком случае не должна попасть в "недружественные" руки.

  3. xztque:

    Так, совмещу два вопроса в один ответ :)На флешах используется NAND-память, которая имеет некоторые особенности.Первая особенность — мы не можем писать побитно! 512 байт — это размер логического сектора: минимум, который может записать хост (не юзер!). Для хоста флеш выглядит, как линейный массив из таких 512-байтных секторов. Внутри флеша же структура гооооораздо сложнее, чем даже на обычном HDD (уж поверьте :)), поэтому писать надо блоками. Во-первых, сам хост не пошлёт на устройство буфер меньше 512 байт (см.выше) — поэтому смысл заставлять его буферизировать поток от dd? А потом, даже если хост и отправит 512 байт — флеш внутри не запишет его в блок. Ну, то есть, запишет, конечно, но не совсем удачным образом.Во-вторых, NAND-память не перезаписывается. Изначально линия памяти хранит единицы — и контроллеры флеша лишь устанавливают нули в нужных местах. Именно поэтому последовательности нулей не записываются реально, т.к. выгодно: не надо программировать память. Отсюда же следует, что перезапись файла ничего не даст — инфа уйдёт в новые блоки, а старые будут просто помечены, как "кандидаты на стирание". Инфу восстановить, ессно, сложно — но реально. Особенно тому, кто имеет на руках спецификации железа и протоколов.В-третьих, маленькие записи — типа сектора, или нескольких секторов — кэшируются внутри флеша. В итоге флеш быстрее убивается — там внутри ещё гоняют много процессов (сборка мусора, дампы управляющих структур), которые юзают саму память внутри. Большие записи быстрее расходуют свободные блоки (целиком затирают их), а значит, эти блоки быстрее будут помечены как кандидаты на очистку, быстрее очищены; и физически меньше уничтожается флэш.В-четвёртых, программировать мы можем только страницу (не бит, и не байт!), а вот стереть страницу не получится — стирается полностью блок. Поэтому выгодней записью покрывать несколько блоков за раз — тут особенности с отношением «логика ←→ TLC структура» (транзисторы кодируют 3 бита на ячейку).Ты может удивишься, но внутри флешек гоняется самая настоящая ОС :)Очень хорошие и годные статьи по сабжу — в английской вики:

    http://en.wikipedia.org/wiki/Garbage_collection_(SSD)

    http://en.wikipedia.org/wiki/Write_amplification

    http://en.wikipedia.org/wiki/TRIM_(SSD_command)

    http://en.wikipedia.org/wiki/Page_cache

    http://en.wikipedia.org/wiki/Flash_memory

    http://www.ixbt.com/storage/flash-tech.shtml

  4. Aminux:

    Вах, про замену последовательностей нулей на флешах не знал, спасибо Alexandr !Я использую для затирания только /dev/urandom как быстрый и достаточно надежный. Кроме того, в первом методе затирается *свободное место*.Команды поправил.С чем связан такой гигантский размер блока — 96К ? ЕМНИП, сектор на всех жестких дисках — 512 байт, на флешах вроде аналогично, и только для новых винтов вроде планируется в будущем размер сектора увеличить.Или такой размер блока связан с логикой работы управляющих контроллеров флешей/HDD и более оптимален ?

  5. xztque:

    Так, подумал.. Заполнение свободного места в принципе имеет смысл. Если данные помечены как невалидные, то в ходе сборки мусора блоки с невалидными данными будут гарантированно стёрты.А большой размер bs — да он всегда хорош!!! Это не размер блока в устройстве, это размер "блока инфы", буфера, который будет послан на запись.Элементарно: сравните скорость записи в оперативку с bs=1 и bs=8192.

  6. Aminux:

    Все, прояснил. Что винт/флешка не могут писать порциями меньше чем 512 байт — это мне известно. Просто я все время как-то забываю указывать параметр bs, хотя параметр вне всякого сомнения важный.Кстати, насчет того, что запись при не указанном параметре bs будет *побайтной*, я с вами решительно несогласен ! И вот почему:

    [Amin@AminCave tmp]$ mkdir 1 && cd 1
    [Amin@AminCave 1]$ dd if=/dev/urandom of=./1.bin count=1
    1+0 записей считано
    1+0 записей написано скопировано
    512 байт (512 B), 0,000208776 c, 2,5 MB/c
    [Amin@AminCave 1]$ dd if=/dev/urandom of=./10.bin count=10
    10+0 записей считано10+0 записей написано скопировано
    5120 байт (5,1 kB), 0,00150434 c, 3,4 MB/c
    [Amin@AminCave 1]$ ls -l
    -rw-rw-r--. 1 Amin Amin 5120 Ноя 15 19:57 10.bin
    -rw-rw-r--. 1 Amin Amin 512 Ноя 15 19:57 1.bin

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

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

    :eyes: Ебать !!! Я немного читал про внутреннюю структуру HDD, и скажу честно — я охуел малость. Служебки, прошивки, куча местечковых проприетарных "фич", везде своя внутренняя структура — это пиздец кромешный. Я на это посмотрел … и закрыл. Не моё это, слишком уж жутко и запарно выглядит. А если на флешах внутренняя кухня *ещё* кривее — то я вам искренне сочувствую ! Я вообще всегда фигел с ремонтников-железячников, способных влезть с программатором и паяльником в такой адъ.

  7. Aminux:

    Еще тогда вопрос вам как к профи — во флешках и SSD-винтах служебная зона и зона пользовательских данных разделены также же жестко, как и в обычных HDD ? Интересует вот с какой точки зрения — если я очищаю флеху до упора, можно ли быть уверенным, что все данные затерлись начисто ? Во флешах есть remap, поскольку ячейки памяти могут дохнуть, и есть резерв.Есть ли какие-нить *стандартизированные* методы просмотра состояния а-ля S.M.A.R.T. ? А то чего-то мой smartctl про флешку говорит "/dev/sdd: Unknown USB bridge [0x058f:0x6387 (0x142)]".

  8. xztque:

    Видимо, dd юзает bs=512 по дефолту 🙂

  9. xztque:

    Внутренние структуры юзают тот же модуль памяти, что и юзерские данные. Так что, в прицнипе, можно быть уверенным в том, что при полной забивке флеша твои "удалённые" данные уничтожатся механизмом стирания.Во флешах есть объединение физических блоков в логические. Блоки объединяются с учётом быстродействия: память делится на несколько уровней (несколько чипов, несколько планок, и т.д.). Каждая планка, к примеру, работает со своим контроллером, следовательно, если я логически объединю два блока с разных планок, то при записи такого логического блока инфа уйдёт на две планки, и за счёт параллельности получим плюс к скорости.Так вот есть механизм — wear levelling, который и следит в фоне, чтобы в логическом блоке были физические блоки с небольшим значением счётчика hot counter. Счётчик этот увеличивается после каждой вспышки (стирания), и плохо, когда он большой — ибо если один и тот же блок много раз стирать — он станет плохим, и нам его лучше из схемы линковки выбросить к чертям свинячим, а заместо его включить блок из списка spare-блоков.Но это общая доступная теория, а на практике, ессно, каждый вендор пихает свою firmware, у каждого своя диагностика, свои алгоритмы wear levelling-а и сборки мусора, всё это проприетарно, закрыто и … и вот :)Диагностика — попробуй hdparm.P.S. и не называй меня на "вы" 🙂 господа все в Париже!И я совсем не профи… Только год с этим работаю.

  10. gb12335:

    AlexanderИ я совсем не профи… Только год с этим работаю.часом не на Flash Reader от софт-центер?

  11. gb12335:

    > Решение для файловых систем, у которых содержимое файлов не может лежать> внутри служебных блоков ФС (FAT/NTFS/Ext2/Ext3/Ext4) — затирание пустого > места. incorrect! В случае NTFS _МАЛЫЕ_ (один или несколько кластеров, т.е. 512 байт — 2KB) файлы могут хранится в самой MFT (запись, описывающая файлы и их расположение, продвинутый аналог FAT). Соответственно, удаление файла и очистка пустого места вряд ли поможет. Потребуется еще или активное перефигачивание самой MFT, или придется активно поработать с накопителем (понасоздавать всяких разных файлов на ФС).Учитывая, что NTFS с каждым годом все популярнее и популярнее — fail, нужна правка.> Для какого-нить FAT/NTFS — номер весьма смертельный, инфа восстанавливаема,> но долго, мутно и дорогоR-studio восстанавливает, в случае, если а) сохранилась копия файловых структур или б) повреждения не слишком большие (затерто чуть-чуть с начала диска, т.к., например, пользователь быстро опомнился, что затирает не то).> Для современных жестких дисков (емкость от 20 Гб и выше) вполне достаточно> одного проходапо современным забугорным ГОСТам требуется то ли от 5, то ли 10 циклов прохода. Товарищи явно страдают паранойей. Я лично считаю, что и после одного прохода там по остаточной намагниченности уже ничего не восстановишь. А такая процедура (если вообще возможна) нифига не бюджетна.> Иногда система не успевает одновременно писать бинарный мусор на несколько винтов> сразу с адекватной скоростью (актуально для старых материнок и древних чипсетов)> — в этом случае поможет написание простейшего мини-скрипта из трех строчек.есть УБЕР-халявен методен. Основан на наличии в накопителях парольной системы защиты (подсистема SECURITY).1) подключаем накопитель к ИДЕ-каналу или САТА-каналу в режиме PATA (compatible т.е.)2) запускаем DOS->Victoria/MHDD или Windows->Victoria for Windows, в этом случае диски лучше в диспетчере устройств отключить.3) а теперь фокус! делаем накопителю SECURITY ERASE. Один из способов — поставить известный master/user-пароли, затем дать эту команду. ПЛЮСЫ:- никаких данных по интерфейсу не прогоняется. Т.е. максимальная возможная скорость- как только процесс запущен, его нельзя остановить без знания пароля. И интерфейс ему не нужен. Т.е. можно рубануть питание накопителя, отключить его от интерфейса, подключить затем к отдельному БП и он будет себе продолжать процесс SECURITY ERASE.- не требуется никаких дополнительных аппаратных средств- можно стирать столько накопителей, сколько у пользователя PATA/SATA-контроллеровМИНУСЫ:- завязываетесь на качество микрокода накопителя (некоторые накопителя как только видят бэд-сектор, скидывают процесс security erase)- необходимо понимание происходящих процессов, т.к. легко накопитель так запаролить, что потом придется тащить его ремонтникам- стирает весь накопитель целиком, нельзя стереть его часть.- необходим спецализированный софт.- ремонтники (но не обычные юзеры!!!) УМЕЮТ снимать пароли с практически любых накопителей. Так что не полностью почищенный накопитель представляет собой потенциальную возможность для утечки.> не подходит для flash-памяти. Чтобы надёжно затереть данные,> нужно тереть всю флешку. флэшку (относится и к SSD) всю нельзя затереть. Проблема в том, что физическая структура данных скрыта от глаз пользователя микросхемой контроллера. Т.е. там всегда что-то, да останется. ddшкой вы только сотрете логический раздел. Ремонтник при необходимости (даже не очень дорого) вытянет данные со стертой флэшки. Убедительно прошу прочитать статью "Forensic Data Recovery from Flash Memory" [1]> Есть ли какие-нить *стандартизированные* методы просмотра состояния> а-ля S.M.A.R.T. ? НЕТ.В ЛЮБОМ СЛУЧАЕ ЗАМЕТКА ГОДНАЯ И ОЧЕНЬ НУЖНАЯ!!!СПАСИБА!!![1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.135.5697&rep=rep1&type=pdf

  12. Aminux:

    1. За замечание про NTFS спасибо. Пофиксил.2. Боюсь, что при современной скорости записи в ~80-100 Мб/сек при ошибочно введенном dd будет снесно вовсе не "чуть-чуть в самом начале диска".Даже в самом лучшем случае среагировать удастся не быстрее, чем за 150-200 мс (предел человеческой реакции), а за это время будет снесено не менее 12Мб в начале диска. Для FAT это повреждение отнюдь не косметическое.3. Про парольную систему ATA я не стал упоминать специально по ряду причин.- во-первых, система закрытая. То есть никак не узнать, чего и как он там стирает. Пишет ли оно туда нули/мусор или еще что-либо. Понятно, что спецификации на внутренние реализации механизма Security Erase есть только у производителей и ну совсем уж маньячных ремонтников. Если там схалявят (например, будут стирать каждый 3-й сектор), то это будет непросто отловить. Стандарт ATA описывает лишь то, что механизм должен быть. Запросто может выйти как с "аппаратным шЫфрованием".- во-вторых, для работы Victoria/MHDD нужен ребут с DOS-дискетки. Кстати, кроме MHDD/Victoria, работать с парольной системой накопителя можно прямо из теплого лампового линукса с помощью того же hdparm, но эта часть помечена как VERY DANGEROUS && "can KILL your drive". Оно мне надо ?- в-третьих, емнип, пароль обязательно должен быть 32 символа. Иначе потом может возникнуть вопрос о символе-заполнителе до 32-х.Конечно, когда надо стереть много жестких дисков одновременно, такой метод стоит иметь ввиду, но он слишком стрёмен, малейшая ошибка чревата потерей накопителя и визитом в сервис-центр. Слишком рискованно для широкого применения.4. Епт, придется флешку жарить в микроволновке 😀 😀 :D5. Отсутствие стандартизированных средств диагностики флешей удручает.

  13. gb12335:

    4. Епт, придется флешку жарить в микроволновке 😀 😀 😀Я бы предпочел разобрать накопитель, отковырять микросхему, а потом оторвать им все ноги. Предварительно пройдясь пьезиком или контактом-метелкой от блока питания.5. Отсутствие стандартизированных средств диагностики флешей удручает.у SSDшек СМАРТ есть. Только проблема в том, что как трактовать отдаваемые SSDхой параметры не очень ясно. Сделано это явно для совместимости с классическими НЖМД.— в-третьих, емнип, пароль обязательно должен быть 32 символа. Иначе потом может возникнуть вопрос о символе-заполнителе до 32-х.да, есть такой момент. Весьма существенен. Обычно программы заполняют или , или пробелами

  14. xztque:

    Gaál George

    Т.е. можно рубануть питание накопителя, отключить его от интерфейса, подключить затем к отдельному БП и он будет себе продолжать процесс SECURITY ERASE.

    а если отрубить питание, снять винт, раскрутить и переставить блины в другой винт с «хорошим» контроллером?

    флэшку (относится и к SSD) всю нельзя затереть. Проблема в том, что физическая структура данных скрыта от глаз пользователя микросхемой контроллера. Т.е. там всегда что-то, да останется.

    Конечно, останется. Но что? Я вам немного расскажу: там останутся дампы указателей на управляющие структуры, и сами структуры. Типа списка свободных блоков, и указателя на него. Много ли вы сможете восстановить, имея только эту инфу? Если я запишу блок, а потом «удалю» данные — блок будет помечен для очистки. И когда он понадобится — а он понадобится, если я забиваю флешку — контроллер сделает ему «пыщь», или flash, или стирание импульсом — и всё, бай-бай данные. Очень может быть, что мне не удастся так затереть удалённую инфу, если я буду заполнять только свободное место — потому что тут да, работа на уровне файловой системы. Но если я буду слать /dev/urandom прямо в /dev/sdb ( не в раздел /dev/sdb1, а именно на устройство) — инфа пойдёт напрямую к хост-контроллеру.Статью вашу прочитал 🙂 Познавательно, теперь буду знать, что я могу разглашать (что уже известно), а что нет.И работаю не там, где вы сказали 🙂 учавствую в разработке firmware для одного из производителей флешей.Aminux2. учти ещё, что dd может и не отреагировать на Ctrl+C. Я так вчера sd-карту запорол :)4. имхо, если нужно носители вообще уничтожить — то лучше в огонь/под каток. Флеш, если в микроволновку сунешь, — если не сгорит, то прошивкам контроллера придёт пиздец. То же самое уничтожение будет :)5. А что ж ты хотел — ёбаная проприетарь и патенты…

  15. Aminux:

    Не-е-е, dd как раз на Ctrl-C реагирует нормально и корректно. Проблема только в том, что уже сгенеренные данные, еще висящие в памяти, но не записанные на диск (кэш), по нажатию Ctrl-C будут все равно сброшены на накопитель. Выглядит это так: в уж0се нажимаешь Crtl-C (несколько раз и быстро), а dd выходит только через пару секунд. Как я понимаю, ситуация такая: по получению сигнала dd прекращает чтение из if=/…, но всё что поставлено в очередь на запись в of=/… — будет записано. Учитывая, что скорость чтения из /dev/urandom заметно больше скорости записи. становится понятно, чем опасен неверно указанный параметр. Ну и под большой нагрузкой сигнал может быть обработан с задержкой.Статью прочитал с большим интересом. Вообщем, для задач уничтожения инфы нам важно следующее: а) одного прохода более чем достаточно б) для FAT/Ext2/Ext3 достаточно стереть критическу инфу и забить флешку до упора в) для ReiserFS/NTFS надо затирать раздел целиком.За патентование софта и идей надо кипятить в разбавленной серной кислоте. Медленно. Прав, прав был Вербицкий…

  16. gb12335:

    AlexanderИ работаю не там, где вы сказалия не говорил, что ТАМ, а говорил С или НА (каком оборудовании).а если отрубить питание, снять винт, раскрутить и переставить блины в другой винт с «хорошим» контроллером?не рассматриваем случай "безумного ремонтника".Хотя при таких раскладах:а) фирмварь в банке не совпадет с фирмварем в ПЗУ на контроллере -> винт не выйдет в готовностьб) если подкорректировать фирмварь -> винт может продолжить стирание дальше, т.к. у всех винчестеров флаги по SECURITY SUBSYSTEM сидят на блинах.в) если уж ремонтник докопался до накопителя, то он его все равно может считать по физике ТАК ИЛИ ИНАЧЕ. Даже если сервометкам и головам ппц. Правда, стоимость операции взлетает в космос. Но те данные, которые были затерты (а стирание начинается с начала накопителя и идет весьма-весьма шустро) уже не восстановить (байки про остаточную намагниченность не рассматриваем).г) для аццких параноиков — сектора, которые заремаплены. Про них тоже нужно помнить. Чистится только юзерария (лог. пространство, доступное юзеру). Сектора, которые были заремаплены, исключены из трансляции и несмотря на то что они битые из них можно вынуть обрезки информации. И не дай Бог там пароли или прочая конфид. инфа…Поэтому имеют смысл физические методы уничтожения данных.Но если я буду слать /dev/urandom прямо в /dev/sdb ( не в раздел /dev/sdb1, а именно на устройство) — инфа пойдёт напрямую к хост-контроллеру.в случае флэш это вообще значения не имеет. На них практически никогда не бывает более одного раздела.

  17. xztque:

    Gaál George> я не говорил, что ТАМ, а говорил С или НА (каком оборудовании). FlashReader с софт центра?снова нет 🙂 Работаю в Eclipse с Python, и на Visual Studio с Си.> в случае флэш это вообще значения не имеет. На них практически никогда не бывает более одного раздела.пожалуйста:

    bio ~ # fdisk /dev/sdb
    
    Команда (m для справки): p
    
    Диск /dev/sdb: 253 МБ, 253362176 байт
    1 heads, 16 sectors/track, 30928 cylinders, всего 494848 секторов
    Units = секторы of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0xa1cc2039
    
    Устр-во Загр     Начало       Конец       Блоки   Id  Система
    /dev/sdb1              16       97663       48824   83  Linux
    /dev/sdb2           97664      195327       48832   83  Linux
    /dev/sdb3          195328      292991       48832   83  Linux
    /dev/sdb4          292992      494847      100928   83  Linux 
  18. gb12335:

    пожалуйста:извращенец (в хорошем смысле). Таких юзеров полтора человека на тысячу.

  19. xztque:

    Это какбе не важно: dd of=/dev/sdb или dd of=/dev/sdb1 всё равно будет писать инфу прямо на устройство, а не в файл в файловой системе.

  20. gb12335:

    http://ru.wikipedia.org/wiki/TRIM_%28%D0%BA%D0%BE%D0%BC%D0%B0%D0%BD%D0%B4%D0%B0_SSD%29обратить вниманиеAlexanderв общем, Вы сказали то, что сказал я. Феноменально :-)Мир, дружба, жвачка.

  21. xztque:

    После вдумчивого вкуривания манов могу невозбранно намекнуть, что большие последовательности нулей нигде не кешируются, а сразу уничтожают блоки целиком. Быстро и надёжно 🙂

  22. anonymous:

    ivan writes:Доброго времени суток уважаемые.в большинстве ssd дисков есть поддержка TRIMнекоторые обзоры дают понять что восстановление данных на винтах с включенной поддержкой TRIM невозможно.даже после простейших операций типа ctrl+A и shift+DELпример такого обзора:http://www.nix.ru/computer_hardware_news/hardware_news_viewer.html?id=162031сейчас пользуюсь уничтожителем данных который создвет сильное магнитное поле одномоментно. после этого разрушаются данные не только на блинах но и перестает функционировать контроллер диска.решение громоздкое мягко говоря и дорогое.хочу понять можно ли доверить уничтожение данных технологии TRIM? точнее воспользоваться побочным эффектом невозможности восстановления их при ее использовании )) на то чтобы просто взять и дать команду на удаление данных с ssd времени хватит — за это я не переживаю.

  23. Aminux:

    >> сейчас пользуюсь уничтожителем данных>> который создает сильное магнитное поле одномоментно.Это типа аццкой машинки а-ля "Прибой" ??Эта машинка совершенно бесчеловечна. Кроме того, если машинка установлена и смонтирована криво, то у нее могут быть ложные срабатывания.Винт после этого неремонтопригоден, и спасать там нечего. Но жесткий диск придется купить новый.