Проблема со взломом программы

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

479D7F 0AC8 GetSystemTimeAsFileTime

Но вызов надо смотреть выше адреса 45F387.

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

А вообще - что за трабла, если файлег не удалять то он его сам пересчитает ... нет?

 

кода нет ессесно.
Если файл не удалять, то он записывает в него какой-то шифр при каждом запуске проги.
Какой смысл смотреть GetSystemTimeAsFileTime к файлу он не имеет отношение.

 

Важено следущее наблюдение.
1)Копирую файл
C:\Documents and Settings\All Users\Application Data\SYSTEMAX Software Development\SAI\NotRemoveMe.ssd
скажем сюда с:\NotRemoveMe.ssd
2)Удаляю файл
C:\Documents and Settings\All Users\Application Data\SYSTEMAX Software Development\SAI\NotRemoveMe.ssd
3) Копирую файл
из с:\NotRemoveMe.ssd в
C:\Documents and Settings\All Users\Application Data\SYSTEMAX Software Development\SAI\

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

 

Атрибуты/права абсолютно идентичны?

 

Ну так она скорее всего при каждом запуске уменьшает число допустимых запусков и записывет это в шифрованном виде назад. При этом скорее всего контролирует время также поэтому GetSystemTimeAsFileTime может быть важен.

немного странно что размер файла довольно большой. Это могут быть критичные данные без которых он не будет работать или открытая криптография или ... просто так чудно сделано.

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

 

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

 

Сейчас речь пока не о снятии триала, а избавиться от описанной проблемы, так как
она мешает снимать триал.

 

Тогда в логе скорее всего было бы DeviceIoControl/etc, не читает же он их через ReadFile.

 

Замечено следующее:
Если я копирую файл, но оригинал не удаляю, а затем скопированным файлом записываю поверх оригинала, то программа нормально запускается!!!!!

 

Может, в младшие биты даты/времени пихает? Те, которые даже тысячными долями секунды не являются и потому вообще никак не видны в файл-менеджерах. Или вообще создаются потоки NTFS и проверяется их содержимое, а ветвление после получения атрибутов файла - ну, так совпало

 

ну только если он по тысячным и считает. Так как при копировании минуты и секунды
меняются. Т.е. считает только по тысячным. Вопрос в том как получить тысячные
GetFileTime? мысль интересная проверим.
Эта функция возвращает такие структуры, в них можно тысячные спрятать.
typedef struct _FILETIME {
DWORD dwLowDateTime;
DWORD dwHighDateTime;
} FILETIME, *PFILETIME;

 

Нашел очень интересную пару

sai.exe 0045EE09 0AC8 CreateFileA(014E29E8: "C:\Documents and Settings\All Users\Application Data\SYSTEMAX Software Development\SAI\NotRemoveMe.s...", C0000000, 00000000, 00000000, 00000003, 00000080, 00000000) returns: 00000370

sai.exe 0045EE3D 0AC8 GetFileInformationByHandle(00000370, 0012EC6C) returns: 00000001

GetFileInformationByHandle возвращает интересную структуру:
в ней интересно следующие поля:
FILETIME ftCreationTime;
FILETIME ftLastAccessTime;
FILETIME ftLastWriteTime;

Возможно собака порылась в этих трех структурах.


typedef struct _BY_HANDLE_FILE_INFORMATION {
DWORD dwFileAttributes;
FILETIME ftCreationTime;
FILETIME ftLastAccessTime;
FILETIME ftLastWriteTime;
DWORD dwVolumeSerialNumber;
DWORD nFileSizeHigh;
DWORD nFileSizeLow;
DWORD nNumberOfLinks;
DWORD nFileIndexHigh;
DWORD nFileIndexLow;
} BY_HANDLE_FILE_INFORMATION, *PBY_HANDLE_FILE_INFORMATION;

 

предыдущая идея не оправдала себя. Обнулил
FILETIME ftCreationTime;
FILETIME ftLastAccessTime;
FILETIME ftLastWriteTime;
после выхода из GetFileInformationByHandle, при смене скопированного файла, но
программа на это время не обращает внимание.

Зато оправдала себя другая идея в логе АПи
было 2 такие функции перед тем как логи хорошие и плохие разошлись
плохой:

Код (Text):

1. sai.exe      0045F360 0AC8 SetFilePointer(00000370, 00005000, 0012DBB4, 00000000) returns: 00005000
2. sai.exe      0045F387 0AC8 ReadFile(00000370, 0012DBB8, 00001000, 0012DBAC, 00000000) returns: 00000001
3. sai.exe      0045F815 0AC8 CreateFileA(00EA5978: "C:\Documents and Settings\All Users\Application Data\SYSTEMAX Software Development\SAI\NotRemoveMe.s...", C0000000, 00000000, 00000000, 00000003, 10000080, 00000000) returns: FFFFFFFF

хороший:

Код (Text):

1. sai.exe      0045F360 097C SetFilePointer(00000374, 00005000, 0012DBB4, 00000000) returns: 00005000
2. sai.exe      0045F387 097C ReadFile(00000374, 0012DBB8, 00001000, 0012DBAC, 00000000) returns: 00000001
3. sai.exe      00460584 097C GetSystemTime(0012EC50) returns: 0012EC50

Далее сделал трейс от последнего SetFilePointer до CreateFileA при плохом варианте
и трейс от последнего SetFilePointer до GetSystemTime и сравнил. Нашел интересное отличие по адресу

Код (Text):

1. 0047BBD1   /0F85 31010000   JNZ 0047BD08                             ; sai.0047BD08

при плохом варианте прыгаем, при хорошем нет.
Затем заставил прогу не прыгать при любом варианте, теперь проблема с переустановкой программы в случае если делаем:

Код (Text):

1. 1)Копирую файл
2. C:\Documents and Settings\All Users\Application Data\SYSTEMAX Software Development\SAI\NotRemoveMe.ssd
3. скажем сюда с:\NotRemoveMe.ssd
4. 2)Удаляю файл
5. C:\Documents and Settings\All Users\Application Data\SYSTEMAX Software Development\SAI\NotRemoveMe.ssd
6. 3) Копирую файл
7. из с:\NotRemoveMe.ssd в
8. C:\Documents and Settings\All Users\Application Data\SYSTEMAX Software Development\SAI\

, исчезла.
Теперь нужно разобраться в механизме, что же делает программа с этим файлом.
Что интересно размер файла NotRemoveMe.ssd равен 24576 байтам, если разделить на 4096(1000 hex) то равняется 6, делится без остатка.

 

то есть резюмируя все сказанное, можно с определенностью сказать, что
SetFilePointer и ReadFile ответственны за такое поведение программы.
Стоит заметить, что SetFilePointer установил укзатель файла на 5000 hex.
Насколько мне известно, система отведет файлу 4096 байт на диске(зависит от размера
кластера) даже если размер файла равна 1 байту. Можете создать текстовый файл
с одним символом и потом посмотреть в свойствах этого файла его размер на диске.
Тогда идея с японской защитой заключается в следующем, ведь никто мне не мешает
записать в последний байт файла, а именно в 4095 записать какое-нибудь значение,
но система все равно будет видеть только один байт. По-моему так устроена эта защита.
надо теперь обнаружить в коде.

 

Чтобы писать и читать за пределами файла (но в пределах кластера) ReadFile/WriteFile ИМХО вряд ли достаточно - нужен низкоуровневый доступ.

Судя по логу прога просто читает 6 блоков по 1000h байт, что-то с ними делает, возможно дешифрует, сравнивает. Скорее всего с текущей датой. Это скорее всего и есть найденный JNZ. Если все хорошо, она апдейтит содержимое этого файла.

 

neutronion,

Есть ещё один момент, связанный с BY_HANDLE_FILE_INFORMATION:

Если аккуратно перемещать (не копировать и удалять) файл в пределах тома (возможно, только NTFS), идентификатор остаётся прежним.

 

хотите сказать, что при перемещении файла меняется идентификаторы?
Это нетрудно проверить.

 

можно сказать, что защита дрогнула, если не прыгать здесь, то все пучком.
0047BBD1 /0F85 31010000 JNZ 0047BD08

то все пучком.

 

neutronion

При такой перезаписи сохраняется исходное время создания файла ftCreationTime, а если сначала удалить исх.файл, то оно устанавливается заново (= текущему времени)

 

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