Я тут написал крякмис (пароль был заложен длиной 10 байт). Решил подобрать пароль к хешу и обнаружил, что есть некоторая особенность, возможно из-за нее или по другой причине пароль долго не подбирался (при моем способе подбора пароля). То есть было перебрано в несколько раз больше вариантов, чем 2**32 и хеш не совпадал. Кому интересно, посмотрите его и скажите была ли у вас похожая проблема при подборе пароля к хешу. Так же интересно бы узнать, сколько у кого времени потребовалось на подбор пароля и может кто то поделится своими крякмисами. Пароль я потом подобрал способом, использующим особенность хеша (плохой хеш). При этом гарантированно потребовалось менее 2**32 вариантов перебора. Ну об этом я расскажу позже. Хотелось бы услышать ваши комментарии. Да, условие взлома: COM файл патчить нельзя, так как это слишком просто.

_1405134978__Crck_pr.com

Хмм... Брутфорс?.. ;p
Такие крякмисы не очень...
Ты бы лучше алгоритм какой-нибудь
интересный залобал бы, что б можно было
кейгенчик написать...

P.S.
Тут не так давно я спрашивал про "умножение", т.е.
имеем:

mov eax,12345678h
imul eax,0ABCDEF77h

"Обратимо" ли это дело?..
Ну так мне ответили, что нельзя тут вернуть
начальное значение eax после такого умножения:
число станет большим, отсечётся старшая часть, в eax
будет только кусочек числа, etc...
Только брутфорс.. М-да...
Ан-нет.. Хе-хе.. оказавается можно... ;)
Вот такие пирожки... Ням-ням... d:)

To snatch: конечно умножение можно обратить, для этого , например расписываем в столбик в двоичной системе 0ABCDEF77H*X=RESULT, где RESULT известен и биты для X находятся довольно несложно. Для их нахождения можно написать простую программку. В результате для X будут найдены некоторые биты, а некоторые оставшиеся неопределенными можно поставить произвольными. Короче говоря, это задача для пятиклассников.
Теперь насчет моего крякмиса: если кто его решил напишите здесь пожалуйста как ломали, сколько времени ушло и.т.д. У меня какое то чувство, что хеш в моем крякмисе можно обратить, то есть не использовать тупой перебор, который к тому же например в моем случае принес мне неприятный сюрприз и мне пришлось поменять способ перебора. Я уже говорил об этом выше, но пока не буду рассказывать в чем причина, а то вам будет неинтересно. Я жду ваших мнений и очень удивлен тем, что никто его как я понимаю его не решил. Ладно, так уж и быть, кое чего напишу: если в найденном пароле два байта, расположенных через промежуток в три байта поксорить с одним и тем же значением, то хеш не поменяется, таким образом, найдя один пароль длины N, можно найти все другие той же длины. Ну это уже подсказка.
PS: ответьте кому интересно.

ответьте кому интересно

Ключевое слово "интересно" ;(

cs:0100 FA             cli
cs:0101 30C0           xor    al,al
cs:0103 2EA20801       mov    cs:[0108],al
cs:0107 EB02           jmp    010B
cs:0109 CD20           int    20
cs:010B 88C4           mov    ah,al

Хмм... AFAIK, только на четверках можно было подменять команду,
когда она уже загружена на конвеер. Теперь же этот код немедленно вылетает.
Или я туплю?

Он наверное просто сделает недействительной строку кеша т.е. будет тоооооормозить
А иначе как же совместимость ;) (Или это я туплю?)

Для пятиклассников?.. хе-хе.. ;)
А вот и нет.. Иди снова в школу
и учи матешу, т.к. никакого подбора битов
тут делать не надо.. d:P

To captain cobalt: Эту часть кода я использовал для того, чтобы при пошаговой отладке человек обламывался (у него при этом завершается программа cs:0109 cd 20 int 20h), тогда как при нормальном запуске программа продолжается с адреса cs:010bh. Под отладчиком turbo debugger этот прием срабатывает. К сожалению похоже, что с soft ice это не пройдет. Здесь идея в следующем: на момент выполнения инструкции mov [cs:010bh],al, инструкция безусловного перехода jmp 010bh уже в процессоре идет на декодирование и исполнение (скорее всего она уже декодирована) и ей уже без разницы что там записано в память она выполнится в своем первоначальном виде. В случае же работы под отладчиком в пошаговом режиме между инструкциями mov [cs:010bh],al и jmp 010bh будет исключение отладки и длинный код отладчика. Поэтому в этом случае будет выполнена модифицированная инструкция и безусловный переход будет на инструкцию int 20h - завершение программы. Надеюсь я понятно объяснил в чем дело. Если не понятно, то может я попробую поподробней объяснить. Кажется об этом приеме я прочитал в какой то статье Касперского. Вот только не знаю он ли автор этого способа или это кто то другой. Да, может кто нибудь покажет здесь свои крякмисы. И наконец вопрос: если кто решил мой крякмис, то напишите здесь пожалуйста о результатах и своих мыслях, а так же мне интересно что думает народ о том необходим ли здесь перебор или может хеш можно обратить грубо говоря карандашом на листике бумаги.

Нет!!!
В самих мануалах интела написано, что, начиная с Pentium1 при модификации
кода на конвеере, он очищается и заполняется заново. Поэтому при свободном
запуске этот крякмис вылетает (увы, с запрещенными прерываниями)

А ты пробовал его на Pentium запускать? У меня он нормально запускался и на Pentium-е. Мануалы интела конечно хорошо, но решающее слово за экспериментом, а он говорит об обратном.

Результат: этот четырехбайтовый хэш можно запросто обратить безо всякого
подбора... "Секрет" заключается в том, чтобы начать с последнего, четвертого
байта. Его можно однозначно вычислить по константам из программы...
Затем, зная четвертый байт и константы из программы, мы вычисляем
третий байт, и т.д... Я проделываю это, и получаю пароль

COBALTV)3f

Password OK !!!

:))))))

P.S. Да, у меня вылетает...

Поздравляю тебя captain cobalt!
Мне кстати понравилось как ты использовал свой ник в начале пароля. Насчет вылета программы я не знаю из-за чего она у тебя вылетала, может узнать запускается ли она у остальных, то есть набрать какую то статистику, может причина станет ясна. Может например у тебя AMD-шный процессор, а у них как известно есть некоторые отличия от Intel-овских. Может ты мне дашь какой нибудь свой крякмис (желательно не более 500 байт и под ДОС). Или еще кто у кого есть свои крякмисы пусть разместит их здесь.

Недавно запустил свой крякмис на Celerone 2.5 ГГц (писал и испытывал его еще в прошлом году, когда у меня был 486) и он действительно вылетел с завершением. Помню как он нормально запускался на Pentium 166. Поэтому была уверенность, что он будет нормально идти на всех Pentium-ах. Так что оказалось, это не так и captain cobalt прав. Да, не очень то совместимыми оказываются процессоры разных поколений. Не расскажет ли кто-нибудь о других несовместимостях, которые могут приводить к неработоспособности программ работавших нормально на более ранних моделях процессоров.

PS: Что интересно, так это то, что недокументированные инструкции, которые у меня шли на 486 выполняются и на Celerone, хотя этого вроде как и не следовало ожидать.