Я столкнулся с похожей проблемой, когда поиск _в хеш-таблице завершился сбоем из-за Unknown system error
.
Я полагал, что это произошло после импорта закрытого ключа через gpg (, а не через gpg2 )с использованиемgpg --allow-secret-key-import --import private.key
После установки уровня доверия после этого поста ошибка исчезла.
grep
имеет тенденцию к нехватке памяти, поскольку он считывается до конца -строки -, но в двоичных данных может не быть конца -строки -в течение длительного времени. Вы все еще можете использовать grep, выбирая фрагменты меньше -, чем -, размер памяти, примерно:
# dd bs=1M iflag=fullblock if=/dev/sdb skip=X count=Y | grep...
Промыть и повторить для всех кусков. Если вы не уверены, будут ли данные правильно выровнены, сделайте так, чтобы фрагменты перекрывались (next X=X+Y -1 ).
В качестве альтернативы, strings
вероятно, позволит избежать нехватки памяти (маловероятно появление очень длинных строк печатаемого ASCII ). Затем у вас есть список смещений для проверки. Это могут быть ложные совпадения, поскольку strings
исключает часть \xba\xbe
.
# strings -t d -n 4 /dev/sdb | grep 'LUKS$'
11534336 LUKS
23068672 LUKS
34603008 LUKS
# losetup --find --show --offset=23068672 /dev/sdb
/dev/loop9
# cryptsetup luksDump /dev/loop9
Такие инструменты, как testdisk
илиbinwalk
(с пользовательской магической подписью ), могут более эффективно находить заголовки LUKS. Но для быстрого взлома strings
обычно работает достаточно хорошо.