LINUX.ORG.RU

shred /dev/sda
Deleted
()
Ответ на: комментарий от Deleted

ничего он не медленный

dd if=/dev/urandom of=testfile bs=4M count=256
256+0 records in
256+0 records out
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 5,03006 s, 213 MB/s

SevikL ★★★★★
()
Ответ на: комментарий от SevikL

Всем огромное спасибо если есть еще варианты напишите пожалуйста. Главное стандартными средствами. Интернета нет.

Bapen1k
() автор топика

Можно без форматирования.

fdisk /dev/твойдиск

удаляешь разделы, создаёшь новый раздел, форматируешь в fs

mkfs.ext4 /dev/твойдиск
P.S. Тему не забываем закрыть.

Deleted
()
Ответ на: комментарий от Deleted

extundelete

Ну или вообще любая тулза, которая знает наиболее распространенные графические форматы и умеет читать диск напрямую

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

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

Deleted
()
Ответ на: комментарий от Deleted

А можно как-нибудь точно с помощью стандартных linux-овых утилит определить начало и конец расположения конкретного файла? Ну, чтоб быстрее делалось

dd if=/dev/urandom of=/dev/sLX bs=<размер> skip=<чего-то там> count=<раз>

Или в linux-ах тоже файло может лежать «не подряд». А как проверить: «подряд» лежит или нет?

NewbieLinux
()
Ответ на: комментарий от legolegs

Тут небольшая проблема.

# shared --help
bash: shared: command not found

# whereis shared
shared:

# dd --help
Использование: dd [ОПЕРАНД]…
       или:    dd ПАРАМЕТР
Копирует файл, преобразует и форматирует в зависимости от операндов.
...
NewbieLinux
()

А почему везде советуют забивать накопитель именно рандомом, а не нулями? В чём разница?

Deleted
()
Ответ на: комментарий от NewbieLinux

Нео, читай внимательно, что тебе пишут.
shred, а не shared.

anonymous
()
Ответ на: комментарий от Deleted

Потому что, если нулями заполнить, то могут положить утюг на живот и потребовать архивную копию. А если там чёрт знает, то можно косить под «оно так и было» и подручные гуру у любителей нагретых утюгов не могут с уверенностью сказать, что подопытный ручки приложил для сокрытия.

NewbieLinux
()
Ответ на: комментарий от Deleted

Сквозь нули компетентные злоумышленники могут увидеть остаточную намагниченность НЖМД, а твердотельный накопитель увидев нули может вообще ничего не перезаписывать,а просто пометить блоки пустыми.

legolegs ★★★★★
()
Ответ на: комментарий от NewbieLinux

можно косить под «оно так и было»

Что было? Белый шум? Ахахах, прекрати. Косить под шланг имеет смысл, если у тебя на накопителе обычная винда, обычные фоточки с пьянок, обычные мемасики, обычная музычка. А не полный диск белого шума.

Deleted
()
Ответ на: комментарий от legolegs

Сквозь нули компетентные злоумышленники могут увидеть остаточную намагниченность НЖМД

И считать данные?

Deleted
()
Ответ на: комментарий от Deleted

Вобщето я не про «весь диск» спрашивал, а про то как один файл, не редактируя переписать. А то и

echo "бла-бла-бла" > файл-который-надо-уничтожить
вполне себе сойдёт, наверно. А почему бы и нет? Вот почему не сойдёт просто влепить в тот уничтожаемый файл чего-нибудь бо-ольшое?

NewbieLinux
()
Ответ на: комментарий от Deleted

А почему везде советуют забивать накопитель именно рандомом, а не нулями? В чём разница?

Разница в сложности восстановления данных по остаточной намагниченности дорожек.

AfterWork
()
Ответ на: комментарий от Deleted

И считать данные?

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

AfterWork
()
Ответ на: комментарий от AfterWork

Есть пруф или хотя-бы разумное объяснение почему не актуально?

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

Для дисков большого объема так вообще придумали «черепичную запись», но для ТС это, наверняка, не актуально.

anonymous
()
Ответ на: комментарий от Deleted

Данные физически на диске не перезаписались, поэтому их можно восстановить. Что у тебя ничего не получилось - это ни о чем не говорит.

Deleted
()
Ответ на: комментарий от NewbieLinux

В формате файла могут предусмотрены метаданные, по которым можно понять размер данных. То же самое разрешение для картинок, например. И на диске данные зачастую лежат подряд из-за отложенной записи.

Deleted
()

Ещё как вариант утилита wipe.

anonymous
()

dd bs=1M status=progress </dev/urandom >/dev/sdX

anonymous
()

Роняешь с высоты, запускаешь проверку.

?????????????????

PROFIT!

burato ★★★★★
()
Последнее исправление: burato (всего исправлений: 1)
Ответ на: комментарий от Deleted

urandom медленный

Ты не путаешь random и urandom?

random реально медленный, но там и энтропия выше, используются реальные источники.

urandom при недостатке энтропии (т.е. всегда при больших объёмах данных) использует генератор псевдослучайных чисел, это небезопасно для всякой криптографии, но для задачи затереть данные вполне сойдёт.

Более подробная информация, если есть вопросы, в man 4 random.

tiandrey ★★★★★
()
Последнее исправление: tiandrey (всего исправлений: 1)
Ответ на: комментарий от tiandrey

Нет, не путаю.

Раньше (на другом железе с более старым ядром) urandom выдавал мне 10 или 25 МБ/с (не помню точно) с полной загрузкой одного ядра.

Deleted
()

Если там ext4 или btrfs то средствами линукс ты и после unlink не восстановишь. R-STUDIO вроде справится, но что-то побьётся 100%. Лучше используй ntfs чтобы проще восстанавливать было.

anonymous
()
Ответ на: комментарий от NewbieLinux

Вот почему не сойдёт просто влепить в тот уничтожаемый файл чего-нибудь бо-ольшое?

потому что оно с большой вероятностью запишется на совсем другой участок диска

anto215 ★★
()
cryptsetup open --type plain -d /dev/urandom /dev/sdX crypt_sdX
cat /dev/zero > /dev/mapper/sdX
cryptsetup close crypt_sdX
gdijulsxeh
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.