Привет,
Пытаюсь понять механизм защиты одной программулины японской.
Программа создает некий файл. Если его скопировать и удалить
старый и затем вместо удаленного вставить сохраненный программа
видит это дело и переустанавливается. Пробовал сохранять все даты
Создан, Открыт, Изменен ничего не получается. Смотрел не ставит
ли программа дров, тоже оказалось, что нет. Файл скопированный
абсолютно идентичный удаленному.
Можете подсказать в чем может быть дело? Прога небольшая рисовалка
японская. Взлом интереса ради. Если надо могу выложить на slil.ru
залил сюда:
slil.ru/29276386

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

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

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

для того, чтобы прога проверяла по каким секторам разбит ее файл, без драйвера не обойтись?

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

C:\Documents and Settings\All Users\Application Data\SYSTEMAX Software Development\SAI\NotRemoveMe.ssd
вот этот файл, с которым происходят чудеса.

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

почему же тогда сравнение проходит успешно копии и оригинала?

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

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

-----
Следуй за белым кроликом

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

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

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

Есть мысли?

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

Есть 1 мысль, но очень хорошая: протри глаза и узри кнопку Правка, не плоди ненависть.

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

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

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;

возможно все дело в долях секунды, которые файловые менеджеры не отражают.

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

Возможно, а что мешает сам файл поотлаживать и разобраться?

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

пытаюсь разобраться, опыта мало.

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

работа с файлом начинается 0045EE2E
если файл не валидный, то в loc_47BBB5 по
0047BBC0 jnz loc_47BD08
или по
0047BBD1 jnz loc_47BD08
получаем: 0047BD08 push offset aErrorUnmatchId
иначе всё в порядке

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

Все друзья!!! Сломал защиту, где можно статью опубликовать?

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

http://exelab.ru/art/?action=add

-----
Gutta cavat lapidem. Feci, quod potui. Faciant meliora potentes

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

Млин, обнаружилась небольшая проблема, прога не хочет открывать и сохранять рисунок.
Придется еще попотеть. И отдать на тестирование.

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

Ну ты если что пиши. ЗЫ так в чем там дело-то было?

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

Обязательно отпишусь.

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

В общем, такая теперь проблема, как прога защищает себя стало, через ряд экспериментов ясно:
1)читает из файла данные, затем изменяет их и записывает
в этот файл снова.
2)Снова читает из этого файла, записанные данные
3)Сравнивает с прочитанным и измененным ранее в 1) и если все нормально, но не лишает программу функционала.

Вопрос, какая тактика будет самой оптимальной по времени, для
взлома этой программы?

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

найти переход после сравнения и изменить

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

понятно, проблема в том, что:
1)Сначала происходит 6 раз чтения из файла по 4096 байт
2)Затем 4 раза записи в файла по 4096 байт
3)Затем 2 раза чтения из этого файла по 4096 байт.

Найти, где это сравнивается при таком наличии буферов, довольно проблематично.

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

Видел патчи в которых патчится по 1024 байта, любое "работающее решение" является нормальным

-----
Gutta cavat lapidem. Feci, quod potui. Faciant meliora potentes

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