Лечу удивительную програму "GameMaker Studio"
Поборол практически все, кроме одного.
После запуска проги можно нормально работать... но по прошествии неопределнного времени (может быть и 5 минут может быть и час) все изображения типа "спрайт" в программе модифицируются путем наложения на оригиналы изображения черепа. Происходит это непотребство исключительно в памяти - но если нажать сохранение проэкта то сохранятся изображения с черепками.
Происходит такое только в случае если основной исполняемый файл модифицирован, то есть прога проверяет саму себя.

Собственно интересуют идеи - что можно попробовать отловить чтобы найти функции творящие такую гадость.

Прога написана на делфи (но не декомпилируется доступными декомпиляторами), не сжата, никакой навесной защиты, только своя вот такая.

| Сообщение посчитали полезным:

Была одна у меня такая, пофиксил CRC и все встало на свои места
В Вашем случае не знаю, поможет или нет. Думаю там все похитрожопее будет.

| Сообщение посчитали полезным:

figgler
если файл проверяет себя на модификацию, то, возможно, используется API функция ReadFile с последующим подсчетом CRC (или другой хэш-суммы), либо проверка конкретных байтов в файле...
также может независимо от этого проверяться образ файла в памяти, разными способами.

попробуйте для начала так: снимите трассу в Олли для исходного exe и для твоего модифицированного, сравните.

а также попробуйте IDR как декомпилятор Дельфи - DeDe уже безусловно староват, а IDR поновее.

З.Ы. кстати да, Vovan666 прав: не забывайте про GetTickCount и иже с ним

| Сообщение посчитали полезным:

figgler

больше своих наработjк, или распиши поподробнее, т.к. твоих дейстий ~0 (запустил, нашел ограничения)

-----
[nice coder and reverser]

| Сообщение посчитали полезным:

figgler
Вроде на всякие таймеры надо ловить, причем там несколько проверок на вшивость.

| Сообщение посчитали полезным:

figgler
Да метод классический - модифицируем прогу, потом на модифицированные байты ставим аппаратный брейкпоинт на чтение и смотрим, откуда программа эти байты читает. Это если не помогло отлавливание ReadFile.

Если отловили ReadFile, дайте ей отработать и тогда в памяти появится некий буфер. В этом буфере находите модифицированные байты, на них - опять аппаратник и ищете, откуда обращения к байтам.

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

Или CreateFileMapping/MapViewOfFile, да.

UPD: Какую версию ломаешь?
Если IDR показывает формы, можно сразу увидеть, есть ли там VCLные таймеры. И если да, то смотреть уже на них. Вообще, событие, происходящее через сколько-то времени, это почти всегда таймер. Или вцл-ный, или виндовый.

| Сообщение посчитали полезным:

Спасибо за идеи.

IDR - не берет эту прогу (только формы показывает)

Фикс СРС не помогает.

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

В общем, сейчас вроде отловил место где определяется полный путь к исполняемому файлу и передается дальше для анализа, нашел вроде и функцию в которой решение принимается - сейчас тестирую.
Проблема только в том, что ефект проявляется не сразу и надо долго ждать...

Спасибо за советы.

| Сообщение посчитали полезным:

figgler - с ней сейчас гимору не оберешся
Там не проверяется crc файла вроде, но определенных кусков кода это точно, там еще проверяется размер в .NET лаунчере.
Защита в основном реализована на таймерах, так что найди и отруби основной таймер, по которому идут все заподлянки. Регу так просто там уже не пропатчишь, наткнешся на дополнительные проверки, которые проверяют кей или его часть. Также если рега неправильно пропатчена - не получишь выбор форматов компиляции, а если и найдешь его и пропатчишь напрямую, то не видать рабочего файло, т.к. еще сервис какой-то подключают при компиляции, и он тоже что-то чекает. Короче, кидай лучше этот гимор - за бесплатно нехрен возится. И да, как только авторам попадет патч, они сразу оперативно отреагируют и добавят еще десяток проверок. Имхо, лучше всего скардить ключ, выкачать офлайн модуль активации и пропатчить онлайн чек.

-----
Array[Login..Logout] of Life

| Сообщение посчитали полезным:

Я ж говорю, все работает... с лицензией все просто, НЕТ ланчер - работает на себя, такая же проверка в самом основном ехе есть (убита), все форматы доступны, ограничения сняты, компиляция пашет нормально...
Вот только если там действительно таймер - то я его пробовал искать, но потом решил пойти другим путем...
Искал по функциям SetTimer - может не правильно, где бы почитать как таймеры ловить.


Кстати - офлайн модуля активации там нет.

Собсно есть простой способ - написать ланчер думаю с ним все будет ок работать. Просто интересно найти где эти чертовы черепа вылазят...

>UPD: Какую версию ломаешь?
>Если IDR показывает формы, можно сразу увидеть, есть ли там VCLные таймеры. И если да, то смотреть >уже на них. Вообще, событие, происходящее через сколько-то времени, это почти всегда таймер. Или >вцл-ный, или виндовый.

Версию - последнюю 450. IDR пишет Cannot find table of initialization and finalization procedures
И да, там есть 2 таймера (по крайней мере на MainForm), но как найти адреса их процедур?

| Сообщение посчитали полезным:

figgler, ты уверен, что осталось тебе только "черепа"? Это всего лишь одно из видимых ограничений, ты же не знаешь про проверки с определенным интервалом времени, то стирающей комнату, то код, то еще какая нибудь лажа при вычислениях и открывании/закрывании форм? То что я ковырял, то и видел, давно уже, для кустомер юзеров там в кодесе был вариант офлайн активации, что там счас хз. Вот когда ты будешь прибивать события по таймеру (коих должно быть очень много), тогда с дополнительными граблями и столкнешся, если найдешь общий вызов - его нельзя патчить, т.к. там переплетаются нужные функции для программы и проверки, так что удачи

-----
Array[Login..Logout] of Life

| Сообщение посчитали полезным:

figgler
IDR пишет Cannot find table of initialization and finalization procedures
Исполняемый файл бросьте мне пож-ста на crypto2011@gmail.com. Если IDR показывает формы, то похоже, что файл написан на BC++, а не на Delphi.

| Сообщение посчитали полезным:

crypto файл скинул. (раньше они всегда на делфе писали)

Вот почикал еще один переход - всю ночь студия работала - черепов нет... с остальным будут разбираться уже пользователи (сообщать о возможных новых ловушках)...

kyndly Я вот рассуждал логически - можно конечно ломать механизм лицензирования и активации, поймать при этом кучу необычного, но ведь можно и другим путем пойти, тем более что товарищи разработчики сами дают нам такую возможность введя "Фрии лайсенз". В итоге получается, на мой взгляд, 2 проблемы - 1 - нужно чтобы программа думала что она полная и для всех платформ, 2 - учитывая что модифицируется файл, выплывают (как выяснилось) проблемы с проверкой его целостности. 1 проблема решилась просто и элементарно - в определенных местах изменил ссылки на строки из лицензии и программа теперь при старте всегда думает что она полная и для всех платформ - причем решение это принимает она сама (ни одного перехода не изменено) и механизм активации не затрагивается, а вот со 2 возникли в итоге проблемы, причем чисто технического характера, часть проверок успешно была отключена (использовались функции WinTrust) ну и надеюсь вторая часть теперь тоже отключена (была отловлена функция с CASE которая вызывалась весьма редко и только после получения полного пути к исполняемому файлу)...

| Сообщение посчитали полезным:

figgler
Как мне кажется, нужно пойти таким путём. Вначале проверяем, работает ли прога с лоадером (луанчером/загрузчиком), который бы патчил нужные байтики в памяти, не трогая бинарь на диске. Тут два варианта - либо работает, либо нет.

Если работает. Значит для проверки используется механизм чтения файла с диска, а раз так, то можно отслеживать любое открытие файла через CreateFileW (можно даже через NtCreateFile), и подсовывать проге полный путь до непатченного образа. И пусть таймеров там хоть миллион, лес им обеспечен.

Если не работает. Значит используются только/также проверки целостности в памяти. Здесь нужно попытаться локализовать проверяемые куски. Т.е. не вся память проверяется. Проверяются обычно критически важные для защиты участки. А значит есть ещё такие, которые не проверяются. Т.е. их можно патчить безболезненно. Тогда идея в следующем. Выделяете критически важную функцию и переносите её в выделенную область памяти, эту область выделяете через VirtualAlloc. Это называется морфинг. Далее в коде патчите все обращения так, чтоб они шли в новую область, а старый непатченный код попросту не вызывался бы. И получаете две копии одной функции. Первая непропатчена, но и не работает, а присутствует для прохождения всяких проверок на целостность, а вторая работает. На практике это связано с определёнными сложностями. Во-первых, нужен морфирующий движок, во-вторых, нужно как-то определить, какие области чекаются, а какие - нет. Т.к. софт написан то ли на BC++, то ли на делфи, то морфинг возможен. Если сложно определить границы критического кода, можно отморфить побольше с запасом, захватив в отморфленную область часть некритического, того, который не проверяется. Плюс никто не запрещает комбинировать этот способ со способом подмены полного пути к бинарнику. Есть ещё модификация этого способа, при котором на выделенную область ставиться доступ PAGE_GUARD, но мне кажется, что в человеке должно быть много энтузиазма для реализации этих техник. Плюсом является относительно высокая надёжность и быстрая адаптация к новым релизам. Т.е. вшла новая версия, вы нашли место, где патчить проверку, а потом для сокрытия патчинга заюзали свой движок, и жизнь прекрасна.

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

figgler
Написана на Дельфи 2010. Используйте базу для него (см. мыло)

| Сообщение посчитали полезным:

crypto спасибо, уже...

| Сообщение посчитали полезным: