LINUX.ORG.RU

[брутфорс пароля на архив] концептуальный вопрос


0

1

Архив уже вскрыли, но стало интересно написать свой скрипт для брута. Берем алфавит, устраиваем цикл нужного уровня вложенности (по числу символов), начинаем перебор. Как сделать перебор максимально эффективным?

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

Пробовал:

1. Делать паузу после выполнения самого внутреннего скрипта 2. Делать wait pidof для того, чтобы дождаться окончания работы инстансов, вознкиших в цикле 3. Брать файл архива из /dev/shm

Результат - двусимвольный пароль с алфавитом из 62 символов (a-z, A-Z, 0-9) подбирается за 34 секунды (если пароль - самый последний по порядку вариант из перебираемых сочетаний), и эти секунды практически не зависят от процессора (гонял на amd athlon II x4 640 и на довольно крутом оптероне).

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

Когда инстансы видно в htop, ясно, что прцоессор они не едят, и это логично - нагрузка должна быть на io, но как-то не получается придумать, как улучшить ситуацию

pianolender ★★★
() автор топика

брутфорс
скрипт

You are doing it wrong.

Как сделать перебор максимально эффективным?

Для начала, переписать на нормальный ЯП.

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

Предполагал, что это правильный путь. А почему? Оптимизировать-то нужно вполне конкретный аспект - множественное переллельное обращение к данным. Если существует принципиально другая концепция (например, запихать все в кеш и брать оттуда), то в шелле это наверняка нельзя сделать, тогда все понятно.

Или что имеется в виду?

pianolender ★★★
() автор топика

Подряд перебирать, конечно, медленно, надо треды создавать.

Все равно подряд получится.

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

1. Найти готову или сделать самому библиотеку для декодирования твоего формата данных. На Си.
2. Написать брутфорсер. На том же Си.
3. Слинковать их.
4. ???
5. Успех!

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

Почему это будет принципиально отличаться по скорости от обращения к консольной утилите? Потому что за куском библиотеки не надо лезть на диск?

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

Твоему брутфорсеру надо уметь быстро отвечать на вопрос: «является ли данный пароль верным». ОЧЕНЬ БЫСТРО.

Ты предлагаешь дергать новый процесс для этого? Ну удачи...

geekless ★★
()

Подряд перебирать, конечно, медленно, надо треды создавать.

Поэтому ты пошел на лор и создал тред.

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

Хорошо, это оптимизация расковыривания архива. А в память/кеш его нужно вручную загрузить? Или это не такое узкое место?

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

Можешь попробовать заюзать POSIX asynchronous I/O.
man 7 aio

Только я не понимаю, зачем это тебе. Тебе же не 100500 архивов читать, а по одному и тому же ходить. Загрузи его 1 раз в память и вперед.

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

Загрузи его 1 раз в память и вперед.

вот весь и вопрос в том, сделает ли это система за меня при первом обращении и дальше будет обращаться в память, или надо явно это делать.

pianolender ★★★
() автор топика

Написал когда-то брутфорсер rar-архивов. Фактически патчик к unrar. Умел (умеет) подбирать по словарю и полным перебором.
Представляю, что было бы, если б я на каждый проверяемый пароль консольный unrar дёргал. :3

anonymous
()

надо треды создавать
Делать wait pidof для того, чтобы дождаться окончания работы инстансов, вознкиших в цикле

Бьёшь проверяемый диапазон на N частей. Каждый тред проверяет свою часть. Никаких wait, никакой коммуникации между потоками, сплошные радости. Как только какой-то из тредов возвращает ответ — остальные убиваешь.

Ну и, как уже сказали, не надо создавать по процессу для проверки каждого пароля.

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

Как только какой-то из тредов возвращает ответ — остальные убиваешь.

ну это понятно, но выигрыша не даст.

ок, дальше возиться с библиотекой надо.

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

В смысле, статический бинарник или нет? А какая разница? Не понимать.

anonymous
()

На процессоре? Гиблое дело. Пиши сразу на OpenCL.

Chaser_Andrey ★★★★★
()

113паролей/с.

доооо. в твоем тредике уже насоветовали годных советов

P.S. на ноутбуке подбор key по arc4 - 1.5 Mkeys/sec использовался icc, cilk+

parrot
()

для перебора паролей уже есть Advanced RAR Password Recovery от Элкомсофта, кажется так

идея со скриптом - бред

как поднять эффективность самого перебора.

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

надо треды создавать. Вопрос в том, как не создать их слишком много, но получить от них максимум эффективности.

не больше, чем процессоров в системе

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

> нагрузка должна быть на io
Вот это в корне не верно. Архив должен лежать в памяти, все должно происходить там же. Никаких io.

trex6 ★★★★★
()

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

namezys ★★★★
()

как уже выше заметили - для скорости архив должен быть УЖЕ в памяти. Добавлю что не весь архив, а только небольшой начальный блок, расшифровав который можно быстро сделать вывод пароль подошёл/нет (найдена нужная сигнатура/нет). Обычные консольные утилиты этого делать просто неумеют.

Вот и получается, что по крайней часть брутфорса волей-неволей делается на ЯВУ. А вообще брутфорс - интересная в реализации вещь, по крайней мере в плане синхронизации и распараллеливания на ядра,нити, процессы, ноды.

Генератор паролей :1->N: Дешифратор :N->M: Валидатор;

плюс обратные связи и над этим этим диспетчер (который уже может быть шелл-скриптом)

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

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

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

Таблицы же не для этого нужны, речь про то, как эффективно сделать брутфорс. Вроде рассказали, что смогли)

pianolender ★★★
() автор топика

марш изучать сырцы john the ripper

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

Таблицы же не для этого нужны, речь про то, как эффективно сделать брутфорс. Вроде рассказали, что смогли)

Что-то я не понял. Я для чего же тогда нужны радужные таблицы? У тебя что за архив? Насколько я знаю, радужные таблицы как раз для подбора паролей на архивы (вроде rar). Их можно использовать везде, где можно посчитать hash.

delete83 ★★
()

Можно, кстати, попытаться ускорить процесс, выбирая слова из словаря методом научного тыка Монте-Карло: случайным образом выбирать очередной пароль и удалять его из БД, как использованный.

Вот только все равно более-менее приличный пароль (символов на 15..40) будет подбираться крайне долго.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от delete83

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

Задача - брутфорс.

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

Да, действительно. Сейчас подумал еще немного и понял, что вы решаете задачу абстрактно, не вдаваясь в детали реализации конкретного формата архивации данных. В такой ситуации есть только один подход - прямым перебором с проверкой результата прямо из выхлопа архиватора. Если же речь идет о конкретном формате архивации, то тут можно попробовать придумать и более оптимальные техники.

delete83 ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.