Здравствуйте, 0xDEADBEEF, Вы писали:

DEA>Здравствуйте, Vedern, Вы писали:

V>>а в программном коде что-то можно сделать?
DEA>В современной программе — возможностей очень много. Попробуте проанализируйте 250к машинного кода... (ВАШЕГО КОДА — библиотечный код легко отсеивается) Или, если оно дизассемблировано, то порядка 4 мегов ассемблера. Попа порвется.
Распространённое заблуждение. Нет никакого смысла исследовать всю программу, как правило достаточно несколько функций. Кстати, компилятор значит довольно много: после BCB или Delphi восстановить исходный HLL код нампного проще, чем после MSVC или ICC (особенно, при использовании оптимизации вроде WPO).

DEA>Так что, "защит от дизассемблера" для этого совсем не надо. Обьем кода вас защищает. В любом случае, крякер следует за потоком данных — т.е. от момента ввода серийного номера до момента его анализа. Лучше заморочиться на затруднении пути крякера к коду анализа серийника. Простейший для этого способ — хранить данные на хипе.
И вот как это выглядит на практике: вводится серийник, поиском находится его адрес в памяти. Потом ставится breakpoint на чтение этого адреса и програма отпускается. Вуа-ля, мы в функции проверки .

DEA>Причем, перед распределением памяти под "ключевую" информацию, нужно внести в это дело энтропию... То есть, сделать случайное количество пустых распределений и, лучше всего — случайного размера. Короче, чем случайнее, тем лучше. А еще лучше, если те функции из которых вы извлекаете энтропию задействованы но своему прямому назначению...
Хорошая мысль . Это облегчит исследователю поиск ключей в памяти по энтропии . На случай, если вышеописанный метод вдруг не сработает.

DEA>Второй способ — косвенность. Threads, QueueUserWorkItem, виртуальные вызовы, фабрики классов и тд — чем больше прыжков по коду и косвенных вызовоы — тем лучше. НО... Не забывать про энтропию! Чем СЛУЧАЙНЕЕ, тем ЛУЧШЕ!
И это ничем не поможет против аппаратной точки останова на чтение серийника из буфера .

DEA>Еше одна заповедь: не передавать серийник через глобальную переменную. Только через стек, параметры сообщений, что-угодно, но ТОЛЬКО не ГЛОБАЛЬНАЯ ПЕРЕМЕННАЯ! Именно в итоге таких промашек появляется заметка "The author is klever isdiot" в описании кряков...
А большая ли разница? Когда отладчик вроде soft ice ищет строку в памяти, он одинаково хорошо находит данные как в секциях PE файла, так и на стеке. Впрочем, этому совету лучше следовать .

DEA>...А еще лучше, побродите по сети, попытайтесь что-нить сами сломать
А полезнее почитать туториалы по взлому.

DEA> подумайте над результатами и придете к одному порстому выводу (известному вот уже 10 лет): сломают все. Вопрос тоьько в том, сколько автор потратил на защиту.
Совершенно верно. Есть только одно НО. Себестоимость снятия серийной защиты на порядок ниже оной для качественной "доморощенной". Поэтому, если программа не представляет собой огромную ценность, её могут и не сломать.