Comments 55
date +%s | sha256sum | base64 | head -c 8; echo
И что в этом пароле случайного?
dUsF7BcA8QgQYw==
dd if=/dev/urandom bs=1 count=10 2>/dev/null | base64 | head -c 8;echo
rj9+C0bm
Я предпочитаю такой вариант как более smartphone friendly:
cat /dev/urandom | tr -dc a-z0-9 | head -c 10; echo
Набирать 10-символьный пароль из букв в нижнем регистре и цифр сильно быстрее, чем 8-символьный из букв разного регистра, цифр и спецсимволов, а комбинаций больше 36¹⁰ > 64⁸.
На практике это не важно.
https://habr.com/ru/company/vk/blog/273147/
Кстати cat в вашем случае бесполезен полностью, можно еще сократить: base64 /dev/urandom | head -c N
Тоже хотел написать, что это очень вредная команда. Лучше использовать команду apg, она все-таки делалась специально для генерации паролей.
Да и есть же pwgen
хм. а все ли bash?
[root@noname-hp:/mnt/c/temp] > mtr google.com
-bash: mtr: command not found
А причем здесь bash?
Что в других оболочках эти команды не работают?
Напомню, что при наличии правильного инструмента вернуть данные после форматирования диска трудностей не составит.
Сказки.
Такие инструменты, вероятно, существовали для древних MFM-дисков (впрочем, достоверно подтверждённых фактов восстановления мне лично не попадалось, равно как и сообщений о них - только не заслуживающие доверия сообщения типа "а вот у спецслужб..."). Но на более-менее современных накопителях это совершенно нереально.
После обычного форматирования как раз восстановить не проблема. Речь не про низкоуровневое форматирования или перезапись всех секторов.
На SSD есть нюансы из-за trim'ов всяких, а на обычном механическом диске это вообще не проблема.
Сам несколько раз восстанавливал.
На ссд вообще все сложно, контроллер живёт своей жизнью и в общем то часто плевать хотел на ОС, но соглашается с явными штатными командами. Он может как грохуть данные помеченные как "удаленные", так и посчитать что ячейки устали, и заменить их резервной областью оставив данные на месте. Благодаря чему данные фактически неуничтожимы. Благо в современных ссд все больше аппаратного шифрования, что с высокой долей вероятности все равно не позволит получить доступ к данным, на ячейках от которых контроллер отказался
Это никак не противоречит с моим утверждением выше о возможности восстановления данных не только со старых MFM-дисков, но с обычных современных в том числе вне зависимости от их объёма и технологии хранения.
Так я ведь и не пытался противоречить. Только указал, что с ssd может выйти так что данные никогда не будут удалены, несмотря на любые команды (правда и доступ к ним получить может не получиться). А если там нет аппаратного шифрования - то всегда можно попробовать и прямой доступ к нанд. Или наоборот, "умный" контроллер может прогнать trim в любой момент лишив надежды на восстановление
После обычного форматирования как раз восстановить не проблема.
Зависит от того, как выполняется форматирование. Оно может как просто перезаписывать служебные структуры тома "чистыми" (причём как полностью, так и "по минимуму"), так и перезаписывать (типа для проверки) часть или даже все секторы тома. В первом случае да, как правило, процент восстановления достаточно высок, и для большинства современных ФС даже может составить 100%. Во втором - те файлы, в которые попали "плевки" тестовой записи - невосстановимы.
Речь не про низкоуровневое форматирования или перезапись всех секторов.
Вообще-то в статье речь о прямой записи на диск безотносительно к имеющимся дисковым структурам. Всё, что попадёт под эту запись - невосстановимо. Всё, восстановление чего зависит от структур, хранившихся в перезаписанных секторах. восстановимо только эвристически (реконструкция на основании неповреждённых данных).
Низкоуровневое форматирование на современных накопителях обычному пользователю, как правило, недоступно.
Мы оба прекрасно понимаем о каком простом форматировании идёт речь. Зачем это размазывание манной каши по стенам?
В статье достаточно понятно было сказано какое форматирование и даже что именно надо сделать что бы восстановить было нереально.
И низкоуровневое форматирование вполне доступно пользователю.
На SMR дисках тоже fstrim/blkdiscard работает. Ну, на некоторых по крайней мере.
Зависит от того КАК были потеряны данные. В конце концов можно и с помощью АСМ читать блин жесткого диска. Только вот это совсем феерический способ себя задрочить без грантий на хоть какой то результат, особенно с учётом того, что позиционирование головки в современном жестком диске - очень неплохое. Но если просто грохнули фс/разметку, шансы вернуть данные - вполне есть, может конечно и не все... А вот после перезаписи - малореально
софт элементарно гуглился по слову unformat. на винде работало. правда бесплатным ПО не всегда удавалось все полностью корректно восстановить, но обычно все было и не обязательно. быстрый формат зачищает только таблицы, сами данные остаются. FAT вообще можно было руками руками восстановить. и вообще восстановление больше зависит от файловой системы, а не от интерфейса накопителя.
быстрый формат зачищает только таблицы, сами данные остаются.
Ну-ну... Вы поэкспериментируйте.
Создайте том. Заполните его все секторы данных рандомом. Потом выполните быстрое форматирование. А потом поищите и посчитайте в области данных секторы, заполненные нулями. Так вот - любой файл, на тело которого приходится такой сектор - невосстановимый труп.
cd -
А для перехода в домашний каталог можно использовать cd без аргументов.
Переход в предыдущий рабочий каталог
"cd -" по факту как бы шаг назад, при этом если в предыдущем каталоге использовать эту команду, вернетесь обратно в текущий с которого начали.
Эффективней мне кажется использовать "cd .." - что позволяет переходить каждый раз на шаг назад вплоть до рута.
Про вывод даты/время в 11 примере. Если повторно запустить команду, но немного изменив date, например на date -u, то на экране получится чередование форматов дат раз в секунду. Полезность сомнительная, но забавно. :)
по двум строкам
$ -- dd if=/dev/urandom of=/dev/disk --
и
$ -- "a command" > /dev/sda --
есть претензия. принято символом $ обозначать команды выполненные НЕ от привелигированного пользователя, тогда как символ # для привелегированного, в таком случае приведённые команды НЕ опасны.
а вот
$ -- rm -rf / --
это уже из истории так как в современных дистрибутивах уже свежая версия rm которая имеет защиту от долдурака, и чтобы удалить рекурсивно всё от корня требуется ещё один флаг, емнип что-то вроде --no-preserve-root.
остальные претензии уже высказали до меня выше.
Для тех кто пришёл сюда в поисках интересных команд думаю стоит оставить вот эту ссылку. Там такого много.
Генерация случайного пароля заданной длины
openssl rand -hex 4
(4 байта — 8 hex-символов)
/dev/urandom достаточно ресурсоемкая штука, так что выполнение
dd if=/dev/urandom of=/dev/diskБудет очень медленным. Есть разные модули для ядра (frandom, например), которые позволяют делать это без ощутимой нагрузки на процессор.
Есть специальные утилиты, которые зачищают диск на полной скорости носителя. Как вариант, можно взять random generator из openssl.
Стоит так же учитывать, что на современных носителях есть более эффективные и быстрые способы очистки.
А еще, размер блока у dd по умолчанию 512 байт. Это еще одна причина, почему подобная команда будет излишне грузить cpu.
dd if=/dev/urandom of=/dev/disk bs=4MЭто поможет только с последним, копирование всё равно скорее всего упрётся в генератор случайных чисел. Особенно, если накопитель быстрый
Упрётся конечно, но не то чтобы совсем уж:
$ dd if=/dev/urandom of=/dev/null bs=1M count=10k status=progress
10640949248 bytes (11 GB, 9,9 GiB) copied, 20 s, 532 MB/s
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 20,1818 s, 532 MB/s
У меня не такая красочная картинка на домашнем сервачке:
$ dd if=/dev/urandom of=/dev/null bs=1M count=1k status=progress
1054867456 bytes (1.1 GB, 1006 MiB) copied, 34 s, 31.0 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 34.6132 s, 31.0 MB/s
Но даже 530 не предел для современных накопителей.
openssl enc -e -aes-128-ctr </dev/zero >/dev/sd**у меня даёт около 3-4 гигабайт в секунду (проц с поддержкой aes-ni). Требуется также ввести 2 раза пароль (но можно задать его в явном виде в аргументе). Для повторяемой каждый раз последовательности необходимо добавить -nosalt.
А зачем затирать диск /dev/urandom?
Чем /dev/zero не устраивает? Точно быстрее будет.
Для поиска и удаления/хардлинкования дубликатов файлов рекомендую rdfind. Она даже лучше, чем fdupes.
А так статья ниочём.
18 отборных однострочных команд Linux