Взлом и исправление багов в WinNavigator v1.96
 

Взлом и исправление багов в WinNavigator v1.96

Сегодня будем исследовать мой любимый файловый менеджер WinNavigator. Я лет 5 пользовался 1.95 версией, т.к.
1.96(последняя версия, доступна на wnsoft.com, жаль проэкт закрыт уже 4 года) имела один досадный баг,
времени на исследование которого никогда не хватало(по при4ине утери всех интсаллов это время теперь нашлось ;).
Все, кто еще с DOSa привык пользоваться горя4имы клавишами, как и я, плохо себя 4увствуют если какая-то из них не работает.
Так в 1.96 версии сабжа при нажатии хоткея "Ctrl + \" для перехода в корень текущего диска возникала ошибка вместо нужной операции:

Усугубляется проблема еще тем, 4то при попытке распаковки выполняемого файла программы
(как сказал PEID, он запротек4ен ASProtect 1.22 - 1.23 Beta 21 -> Alexey Solodovnikov) лицензия пропадает
даже при нали4ии валидной регистрации =(
Протестировать можно на этом клю4е(лу4ше вбивать клю4 непосредственно в редакторе реестра):
Приступим к распаковке навесного протектора. Загрузив подопытного в ольку, видим знакомые команды.

В "исклю4ениях" свойств отладки отклю4аем все 4екбоксы и (не забыв активировать плагин IsDebugPresent, либо вру4ную пропат4ив соответствующий флаг)
проходим 32 исклю4ения. Видим такой код:

Ставим бряк на 012005DD, жмем Ctrl + F9 и бряк на доступ к памяти секции кода екзешника. F9 и мы на OEP. Дампим, восстанавливаем импорт в Imprec
(воспользовавшись функциями DisAsm1 и плагом для аспра, 4тобы восстановить нерезолвящиеся функции).

Запустив распакованый файл на свое удивление полу4аем такое вот сообщение (даже при валидной регистрации):

Изменив выделенную команду на нопы, сообщении выдаваться не будет.
4тобы узнать логику срабатывания условного перехода делаем следующее.
Ставим бряк на соответсвующие строки и жмем F9. При отработке бряка смотрим в стек вызовов и самой верхней надфункцией в нем есть
00537ADB |. E8 D4040000 CALL fixed.00537FB4
Входим в нее и видим код:

Можно догадаться, 4то в пакованом (видимо это особенность мутации ли4ной версии спра с выполняемым файлом) файле функция .00537FE2
выдаст правильный результат, т.к ей аргументом передастся верный hModule, в нашем же слу4ае для подмены результатов проверки (в распакованной проге, понятное дело, они никогда не будут правильными)
достато4но занопить команду .00537FE9.

Нагов нет, вот только осталась надпись о незарегистрированности в окне "О программе". 4тобы ее по-быстрому снять, ищем строку
"NOT REGISTERED COPY" в перекрестных ссылках. Попадаем сюда:

Видим знакомый вызов. Поскольку GetProcAddress явно возвратит 0, а не нужный адрес искомой функции (которая потом будет вызываться call esi),
то во избежение переполнения удалим весь код непосредственно до .4FD37F

Теперь все зарегистрированно и красиво, можно приступать до главного вопроса - поиска бага и его устранения.

Самый быстрый способ - отклю4ить игнор в ольке на все эксепшены и просто нажать в запущеной проге Ктрл + \ ;)
Брякаемся на эксепшене

На 3 команды выше выполняется основная функция файлового менеджера по парсингу путей, которая выдаст в EDX
указатель на надпапку (EDX=0121A114, (ASCII ".."). Команда .53E92B постоянно возвращает нуль (DS:[012087CC]=00000000).
Таким образом, команда .53E931 будет ссылаться на несуществующий указатель. А поскольку команда пыталась записать в DL
байт по [EDX] (а EDX имел нулевое зна4ение), то можно предположить, 4то в DL надо просто записать нуль (либо ни4его не делать, т.к.
в нешем слу4ае он уже там). Тогда просто забиваем .53E931 нопами и радуемся полнофункциональности файлового менеджера и отсутствию
исследованого бага.

gl hhf!