удобный визуальный комбайн

ВИТАЛИЙ ИЖЕВСКИЙ

Спецвыпуск: Хакер, номер #065, стр. 065-062-5

Вот ты пишешь собственные компоненты. Долгие бессонные ночи, радость от порождения гениальных идей. Мучительно отлаживаешь… После всего этого некоторые люди начинают подумывать о том, как бы извлечь побольше выгоды и как защитить свое детище, а кое-кто — как обойти все защиты и получить побольше и побесплатнее :).

[принципы защиты] кода. Здесь есть несколько моментов, которых нужно коснуться. То, что использование стандартных функций API или компонентов ни в коем случае не ведет к эффективной защите, — не новость. Не секрет и то, что набор хакера довольно велик и при использовании все того же старого доброго SoftIce очень помогает настройка символьных имен для любых библиотек, которые просто на пальцах рассказывают, что к чему. Так что, какие бы желания ни возникали, как бы мы ни расписывали прелести RAD, придется обратиться за помощью к ассемблеру. Если ты используешь простой способ хранения регистрационного кода, не следует пользоваться проверкой типа:

if RegCode<>TrueCode then

Begin

ShowMessage('Неверный код, дальнейшая работа невозможна');

halt;

end;

Назвать код такого вида «защитой» даже язык не поворачивается. Для начала посоветуем хранить код в нескольких динамических переменных и использовать при этом хотя бы какое-никакое шифрование. Кроме того, не следует сразу заявлять злоумышленнику, что он ошибся. Скажи позже, скажем, через два дня, когда осядет пыл славы взломщика. Конечно же, для проверки кода глупо брать один-единственный алгоритм. Можно разбить код на части и проверять каждую часть отдельным алгоритмом. Плюс желательно проверять его не сразу же после запуска программы, а в тот момент, когда хитрый пользователь сделает большую часть своей работы.

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

[теперь об оптимизации] написанного кода. Всем известен тот факт, что компилятор Delphi — самый быстрый из существующих. Но не стоит забывать и о его недостатке — элементарной неоптимальности кода, ведущей к снижению производительности. Для того чтобы не давать компилятору повода пороть код, нужно просто писать программы правильно. Удобство визуальных компонентов — большой плюс для ускорения разработки приложений, но не следует забывать, что компоненты не всегда написаны так, чтобы оптимизировать выполняемый код.

Остановимся на нескольких моментах. Возьмем, к примеру, использование упрощенных математических выражений. Компилятор Delphi понимает все выражения буквально и последовательно, ничего не упрощая. Если говорить о сложных выражениях, где используются математические функции, компилятор не вычисляет их — они вычисляются в процессе работы программы, поэтому писать x:=sin(30*Pi)/cos(60*sqrt(2/3)) неразумно. Любое подобное выражение будет вычисляться только непосредственно после запуска программы.