Снова Rar 3.x. Признаки не верной расшифровки.

Вопрос адресован людям которые разбирались или разбираются во внутреннем формате rar.
Делаю переборщик паролей для решения задачи наиболее быстрого перебора словаря паролей(порядка 20000 слов).
Если в архиве зашифрованы имена файлов, то признак давольно прост, львиная доля неверных паролей отсекается по признаку что третий байт расшифрованных данных может принимать значения с 0х72 по 0х7c ну а дальше если условие выполнено считается crc небольшого блока.
Для архива с нешифрованными именами, пока для меня такой признак не известен. Дело в там что сам рар сначала распаковывает весь файл а потом считает его crc, но ведущие программы по перебору паролей используют другой признак(хотя если файл зашифрован без сжатия то и они распаковывают все и считают crc).
Как я подозреваю что таблица длин может иметь только опредленную конфиграцию (в сажитее данных я слабоват) и при неверной расшифровке по ее заполнению можно сделать вывод о не верном пароле, но это предположение.
Если мои подозрения верны то на какую особенность этой таблицы нужнообратить внимание? И конечно если есть другой способ отсечь неверный пароль то буду очень признаетлен...

 

табличная проверка первых n-символов на корректность?
Под корректностью я подразумеваю байты которым соответствуют символы которые могут быть в имени файла. Наприер первый 10h символов точно не могут быть в имени файла.

 

Дело в том что в раре если не шифруются имя файла, то оно известно сразу, зашифровано лишь содержимое.
Или я не правильно понял о каком имени идет речь.
Можно допустим расшифровывать 16 байт (обработка идет блоками), затем распаковывать первые 5-...( байт с распаковкой еще не разобрался), и посокльку известно имя(и расширение тобишь тип файла) то остается сверить сигнатуру на принадлежность этому типу файлов, но этот метод мне не очень нравится так как он не бладает обсалютной надежностью, что если расширение мне не известно или данный тип файлов не имеет сигнатуры? А тот же ARPR перибирает пароль на 400 метровый архив с файлом без расширения с тойже скоростью что и сним, значит есть другой признак.

 

Про какие таблицы длин идет речь, сжатие в RAR используется самое разнообразное, от байт-кода распаковщика (например для сжатия BMP32 с нулевой компонентой прозрачности) до PPMd Димы Шкарина. В Вашей постановке вопроса лучше честно распаковывать файл и считать его CRC. Нужно ведь понимать, что любое неправильное предположение для "наиболее быстрого перебора" приведет к тому, что проверки будут неправильными - и энергия, потраченная на проверку 20000 слов (1000 секунд?), только усугубит ситуацию с парниковым эффектом Да, и что такое 20000 слов, это пшик. Тут разница в скорости не сильно критична.

 

Доброй ночи!
Вся проблемма в том что нужно перебирать не для одно файла, а этих файлов много, срредняя длина 90 мб, так что если полностью распаковывать то около 5 сек на слово, больше суток на файл, не пойдет, в 1000 сек на AMD 64 3600 и надо уложиться (средняя длина слова 11 символов). На счет таблиц я говорю слабо пока в теме, это первое что я увидел в исходниках ну и в инфе что накопал. Я просто пытаюсь определиться с направлением, где надо копать.

ЗЫ пока отвечал провел эксперимент (почемуто раньше не дошло). Создал архив со 100 мб файлом без сжатия и нажал кнопку тест и ввел не верный пароль, WinRar затратил около 5 сек, однако если файл упакован то доли секунд, значит ответ должен быть в исходниках UnRar... будем искать, однако если кто скажет сразу куда смотреть буду очень рад

 

Однако погорячился, тестирование архива winраром странный процесс... то проходит за доли секунды то смеренно распаковывает весь файл...

 

Всем привет!

Входе исследований было установлено, что некоторые перборщики, отсекают не верный пароль, распаковав первый болк и проверив сигнатуру на соответствие расширению, однако если им подсунуть файл с искаженной сигнатурой они оказываются не удел, а вот ARPR обрабатывает нормально.
Было установлено что при тестировании программой Winrar запароленного архива при не верном пароле прогресс бары отображающие процесс тестирования бегут не синхронно а именно прогресс бар отображающий ход текущего файла обгоняет общий, а если пароль верный бегут синхронно. Одноко в исходниках unrar.dll я не нашел как получить данные на второй прогресс бар. Дело в том что есть функция UnRarCallBack(msg: Cardinal; UserData, P1, P2: integer): integer в нее передается из библиотеке инфа о ходе работы, допустим если msg равно 1 то P1 это указатель на память куда распакован блок, а Р2 это длиннна распакованного блока, так что из этой информации можно соорудить лиш первый прогресс бар, а вот как в unrar заметит эту не синхронность?

 

ARPR - отстой, т.к. не понимает многотомные архивы

 

Возможно и отстой, но это пока лидер в своей отрасли, если у вас есть другие варианты озвучьте пожалуйста, я имею ввиду не только функции для взлома но интерфейс и языковая поддержка, короче для пользователя самое то. А на счет много томности я конечно не пробовал, но есть способ и ARPR ломануть многотомный архив, первый том много томного архива отличается от обычного всего лишь одним битом по-моему, его обнуляешь в ручную и должен ломать. Я знаю одну прогу называется crark про нее написано что она самая мощная по перебору и генерации паролей (целая библиотека какая-то там подмучена), но для моей задачи требуется перебрать по словарю, я три дня бился не смог ее заставить, и даже разработчик мне толком ничего не объяснил, а ARPR я даже в справку не залазил так что я думаю ты не совсем прав.

Но лучше по существу высказаться

 

вполне рабочая, один раз использовал, для перебора пароля по словарю для
многотомного архива

есть еще одна, но платная

 

Если не трудно расскажи как настроить хочу сравнить со своим творением, есть файл со списком паролей текстовый, как нужно настроить чтоб все работало.

 

написал bat'ник

Код (Text):

1. @echo off
2.  
3. @rem crark-hp -pmypass.def archive.part1.rar
4.  
5. crark -pmypass.def archive.part1.rar
6.  
7.  
8. echo.
9. pause
10. cls

файл mypass.def

Код (Text):

1. # определение словарей - только в том случае, если будут
2. # использоваться макросы $u или $w
3.  
4. $w = "C:\\Progra~1\\RARPasswordCracker\\passwords1.txt"    # надо экранировать '\'
5.  
6.  
7.  
8.  
9. ##
10.  
11. # Простейщая атака по словарю (раскомментируйте определение $w
12. # при опеределении словарей)
13. $w

файл паролей

Код (Text):

1. PASS
2. 12345678900987654321
3. renault52
4. soft-best.ws
5. boogeyman
6. DarkShinigami
7. ...............

 

Спасибо наконец то я протестировал эту прогу, да все верно что про нее говорят жучит она не кисло, делает мою(ну и все остальные и ARPR и rarpasswordcracker) на 40%, единственно что моя еще может в много поточном режиме работать, тогда crark проигрывает мне гдето 30%, но я слышал что он обещал много поточность подмутить.
Ну да ладно главный вопрос остался без ответа каков принцип определения не верной расшифровки?

Я конечно начал писать сигнатурный метод, но всетаки хотелось чтото более надежное.

 

Реализация шифрования в RAR v3.x - странная, особенно это касается небольших файлов, если начать перебор пароля в ARPR, то очень часто пароль находится, НО НЕ ТОТ! Причем WinRAR его спокойно принимает, но в результате расшифровки и распаковки выдает мусор (никаких ошибок не выдает). А причина проста: пароль верен/не верен на основании CRC32 - это "привет" из прошлого века. Я не удивлюсь, если кто-нибудь докажет, что ~262000 хэширований на самом деле вырождаются и этот огород сводится к чему-нибудь тривиальному.

Jhonny
А что Вы все-таки хотите сделать? Обогнать crark по скорости? Попробуйте в свойствах сжатия у WinRAR поставить Advanced -> Compression -> Text Compression -> Force: Memory: 128Mb, Prediction: 63 и сожмите какой-нибудь файл в пару десятков Mb и защитите паролем. Думаю, что любая программа по перебору крепко призадумается. И принципов определения неверной расшифровки скорее всего миллион и больше, над RAR'ом можно всю жизнь работать, заодно и в смежных областях "нобелевскую" премию получить И все из-за того, что шифрование реализовано не по рекомедованным стандартам. И поэтому изначально тяготеет к уязвимостям.

 

Живой примерчик можно, если не сложно (небольшой архив, подошедший пароль, настоящий пароль) ?

По идее сначала идёт расшифровка архива неправильным ключом, а потом попытка распаковать этот мусор после расшифровки. Распаковщик должен прийти в дикий восторг от попытки распаковки мусора, до проверки CRC распакованного файла дело просто не дойдёт, имхо.

 

Задача такая есть куча файлов (несколько десятков) размером в среднем 80-95 мб, необходимо перебрать к каждому словарь паролей состоящий из примерно из 20000 слов (средняя длинна пароля 11 символов), причем скорость перебора на один поток должна не уступать ведущим в этой области прогам таким как ARPR, RarPasswordCracker (ну crark пока серьезно опережает хотя я дезасемлировал его посмотрел что-то подобное делаю и я быть может он что-то придумал с памятью по лучше не знаю потом посмотрю ща не это важно).
Для файлов с шифрованными именами эта задача решена, для простых запароленных сейчас доделываю сигнатурный метод, дело в том что эти файлы не совсем произвольны они на 80% мультимедиа содержимое, на 20% приложения, ну и дальше образы документы и тд. Другими словами львиная доля файлов будет обработана нормально так как сигнатуры известны с большой долей вероятности. Однако я предвижу вопросы некоторых пользователей "А вот ваша программа не подобрала пароль к такому-то файлу а другая программа подобрала."

 

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

 

Jhonny

что-то подумалось, а файлы не спутниковой рыбалкой случайно получены?

 

может можно попробовать совместить сигнатурный поиск + оценка энтропии расшифрованных данных

 

Именно так

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