Точка останова на функцию вывода сообщения, несколько возвратов по ret и вот мы и на месте. А вообще если на лету не понятно как работает, используй IDA и применяй сигнатуры, сразу станет все понятно.

Как я понял такойже подход и к контрольной сумме. Выскакивает сообщение об ошибке, начинаем обратную трассировку до места падения проги. Правильно ли я понимаю? neprovad скажи я правильно подпатчил код? А то я сомневаюсь. Можно ещё один вопрос? Начал читать про инлайн патчинг. Как я понял Патч происходит в памяти, скажем когда распаковщик отработал, передал управление на OEP, адрес ОЕР подменяется Jamp*ом на наш код. После того как он отработал, возврашаем управление проге. Вопрос: Сначала в отладчике надо узнать адреса которые надо патчить? И еще, гдето прочёл в одном из топиков что если Если проверок много то применяют инлайн патчинг? Но у меня возник вопрос: Что если в коде есть проверка контрольной суммы всего файла? Инлайн в пролёте? Или как вариант приидётся писать отдельную прогу и патчить когда подопытная прога полностью распаковалась ? Или всётаки можно вклиниться между упаковщиком и прогой?

- Можно было заменой одного байта обойтись
- Конечно, узнать адреса необходимо до начала инлайн патчинга
- Раз на раз не приходится, вопрос в трате времени (быстрее снять защиту совсем или нейтрализовать инлайном)
- Если есть проверка, она находится и нейтрализуется, либо ей (проверке) подсовывают оригинальные значения. Опять же смотря как она вызывается (одно дело по таймеру периодично, другое дело один раз при запуске программы). Каждый случай обычно требует своего подхода, вернее его всегда можно найти. Пожалуй так.

Что это за Thinstall Setup Capture как и чем можно его снять, распаковать. Перерыл все, вразумительного ответа не нашел.

Так проверь чем упаковано! Использование PeID, RDG Packer Detector никто не отменял.

PEiD v0.94 говорит UPolyX v0.5 [Overlay] *
xeinfo PE - Thinstall VS 3.0.x -> Jitit Software
RDG Packer Detector говорит Delphi
FlexHEX в начале файла есть вот что:


Boot loader for Thinstalled packages FileVersion 3.349
InternalName boot_loader_exe. LegalCopyright 2005-2007. Thinstall boot_loader_exe.exe ProductName Thinstall ProductVersion 3.349

Ну вот, самое время самостоятельно разобраться как оно все работает.
Бряк на CreateFileA попробуй и жди выгрузки.

Ок ща попробую! От функции надо в обратном направлении трасировать или дальше по коду ?

Поясняю свою мысль насчет CreateFileA. Почему я выбрал именно её?
Thinstall известен тем что виртуализирует, помещая в песочницу "sandbox" выполняемый процесс, при этом контролируя все его попытки работы с файловой системой.
Так вот, ставим бряк на CreateFileA, ждем срабатывания, смотрим на имя открываемого\создаваемого файла и делаем вывод - как относится данный файл к работе подопытного приложения. Если кажется что файл нужен нам, запоминаем путь, ставим бряк на CloseHandle и ждем срабатывания (по логике после CreateFileA вызовется WriteFile а затем CloseHandle). После этого можно ныжный нам файл скопировать и делать с ним что угодно.
Для удобства понимания работы рекомендую использовать WinApiOverride (см. в разделе инструменты)