Сегодня у меня приключилось знаменательное событие. Я наконец-то добил рутовый FreeBSD-MD5 хеш который у меня стоял на бруте с сентября месяца)))) Обрадованный таким подарком я собрал несколько своих заметок, написанных в разное время и посвященных особенностям брута FreeBSD MD5. JTR vs Passwordspro На моем компьютере “perform a benchmark” для JTR показал: 7700 crypt/сек, Passwordspro - 2215 crypt/сек –скорость JTR в 3,5 раза выше. Для своего pentium’a я использую john-mmx, который оптимизирован для этих процессоров и показывает лучший результат (на 8%), чем john-386. Время главный враг Средняя скорость перебора на среднестатистической машине составляет 7000-8000 crypt/сек, отсюда не сложно подсчитать, что количество возможных комбинаций для семизначного пароля состоящего из 7 цифр и букв нижнего регистра (ИМХО: самые распространенные пароли) составляет 80603140212, время которое уйдет для полного перебора в JTR - 120 дней. Правда, при самом плохом раскладе. Конечно, нам может сильно повезти пароль окажется 6-символьным, тогда понадобится максимум 80 часов или 7-символьным, но он окажется в самом начале перебираемого ряда. Количество имеет значение FreeBSD-MD5 хеши как правило соленные, т.е. даже если пароли одинаковы, их хеши в shadow будут иметь разный вид и генерировать хеш для каждой записи придется по новому. Perform a benchmark JTR показывает время генерации хеша для одной записи, для 2 двух его нужно разделить на 2, для ста на сто. В итоге, для 100 хешей вида FreeBSD MD5, скорость перебора составит всего 77 crypt/сек. А если таких хешей 500 или 1000, что не такая уж большая редкость – 7 – 15 crypt/сек. Вывод напрашивается сам: пихать в JTR или PP много хешей просто не имеет смысла. Уже не раз видел такой вопрос: «Я использую JTR в HIGH режиме, но загрузка процессора не превышает 50-60%. Как заставить его использовать процессор полностью?» Ответ на самом деле очень прост: огромное количество одноядерных процессоров поддерживают технологию Hyper Trending (HT), более того этот режим включен по умолчанию на основной массе материнских плат. Суть технологии ее в том, что один физический процессор представляется операционной системе как два логических процессора. С одной стороны это хорошо т.к. приложение выполняется в два потока, что может поднять производительность. НО… есть большое НО, ЕСЛИ приложение умеет работать с мультипроцессорной системой. Я провел небольшой тест с включенным и отключенным режимом HT, а также небольшим разгоном (20%) в обоих режимах (WINDOWS) на своем давно устаревшем Intel Pentium 3000 под 478 сокет Как видно на диаграмме, и PP и JTR не умеют работать с двухядерными процессорами и отключение Hyper Trending дало некоторый прирост. Другой вопрос - насколько это необходимо? Ради выигрыша менее чем в 10% мы практически теряем работоспособный компьютер. И JTR и PP радостно набрасываются на оставшийся в одиночестве процессор, захватывают 100% ресурсов и заниматься чем либо еще становится очень трудно. Для своей системы я использую разгон +режим HT, это дает неплохой результат и делает практически незаметным работающий в фоне переборщик, загрузка процессора не превышает 50-55%. MPI Пользователям купившим компьютер с двухядерным процессором или собирающихся его купить, стоит обратить внимание на MPI версию JTR. Еще в 2004 году Ryan Lim оптимизировал JTR1.6.36 для многопроцессорных систем. По результатам проведенных им тестов становится ясно, что скорость перебора возрастает линейно с каждым задействованным процессором, т.е. в 2 раза для двхухядерного процессора На настоящий момент доступна версия 1.7.2MPI для UNIX переработанная Джоном Андерсеном (Только под UNIX). Для PP многоядерных радостей пока не нет))))) ------------------------------------- http://cse.unl.edu/~rlim/jtr-mpi/ - здесь берем отчет Ryan Lim посвященный MPI, а также смотрим первую MPI версию JTR ------------------------------------- http://www.bindshell.net/tools/johntheripper/ - здесь последние версии JTR MPI ------------------------------------- Сессия Запускаем JTR ВСЕГДА c опцией –session:name1, где name1 – имя сохраненной сессии. Теперь в любой момент мы можем прервать брут и когда нужно, запустить с того же самого места опцией –restore:name1 Для прерывания работы JRT лучше не использовать комбинацию Ctrl+C, т.к. возможно некорректное сохранение сессии и .POT-файла, используем комбинацию Ctrl+Break Просмотреть статус сохраненной сессии можно опцией –status:name1
