Статья в основном посвящена методам защиты баз данных от незаконного копирования, то есть попросту - от воровства. Общий подход, изложенный в статье, применим к базам данных различного формата, а не только к базам Access. Но изложение ведется именно для баз Access, что может несколько затруднить понимание для читателей, не знакомых с ним.
Помимо защиты в статье рассматривается еще ряд вопросов, близких к этой теме.
Вступление.
Если вы противник формата mde, или вы не знаете, где его применять, и, тем более, зачем его защищать, то у вас еще нет проблем с продажей вашей программы. И для вас статья носит чисто теоретический характер.
А вот если проблемы есть, то надеюсь, что некоторый накопленный опыт продаж программ на Access, может помочь вам в их разрешении.
Для упрощения изложения рассмотрим модельную ситуацию.
Вы разработали для своей организации программу на Access, которая успешно эксплуатируется. В программе клиентская часть отделена от данных и установлена на каждом компьютере. Системы защиты от любопытных юзеров установлены. Все это значит, что вы явно не начинающий программист. (Поэтому в статье даны только идеи, а их программная реализация оставлена за вами.)
Однажды шеф вызывает вас и сообщает, что его приятель-конкурент заинтересовался вашей программой и готов ее купить на пять компьютеров, при имеющихся у него восьми. Правда, приятель хочет, чтобы сначала его сотрудники познакомились с демонстрационной версией и предоставили ему свои замечания.
Далее шеф, охваченный мечтами о новом источнике доходов, говорит, что знает еще два десятка фирм, куда можно предложить программу. А если выставить ее на продажу по Интернету, то...
У него кружится голова от величины предполагаемых доходов, которыми он, с присущей ему щедростью, готов поделиться с вами. И голова начинает кружиться у вас...
Но не спешите разделить радость шефа. Может он не знает, что: "Разработка готового продукта стоит примерно в три раза дороже программы для собственных нужд (см. "Мифический человеко-месяц" Фредерика Брукса)". http://www.ashmanov.com/pap/obspro.phtml
И что для вас это означает работу, примерно вдвое большую, чем начальная разработка программы. Работу, которая включает в себя многое, не только доработку программы. Но и ее тоже. В частности, в программе надо сделать:
- специальный режим демоверсии;
- защиту от несанкционированного копирования.
В целом статья посвящена второму вопросу, но немного ниже будет сказано и о первом.
Принимаясь за придание программе товарного вида, вы вливаетесь в обширные ряды шароварщиков, у которых так много общих проблем, что для их обсуждения они создали свои клубы. Например, http://www.softshape.com/swrus/
Отмечу, что в числе шароварщиков акцессистов еще очень мало.
Режим демоверсии.
Для создания режима демоверсии обычно применяется один из двух методов:
- ограничение времени работы программы (стандарт - месяц);
- ограничение функций программы. Для Access чаще всего применяется ограничение количества записей в некоторых таблицах.
В обоих случаях следует где-то хранить данные, задающие режим демо. И написать программу перевода вашей базы из состояния демо в рабочее.
Если вы предоставите потенциальному покупателю демоверсию в формате mdb, то, вполне возможно, этим все и закончится. Или ваша первая продажа окажется последней. Причина изложена в статье "Защита баз mdb". База легко вскрывается опытным акцессистом, ваш режим демо снимается и база переводится в рабочее состояние. Так же не исключено, что, по заказу приятеля-конкурента, другой программист, слегка поменяв внешнее оформление вашей программы, может приступить к ее распространению. Такие случаи были. Например, с программой TurWin. (http://www.arimsoft.ru/soft/turwin.shtml)
Так что, забудьте о продажах в формате mdb. Без формата mde в Shareware базах вам не обойтись. Но так ли он надежен, этот формат mde? Нельзя ли его перевести в формат mdb? Этот вопрос настолько часто повторяется на форумах по Access, что это уже есть предложения - повесить на входе в форум ответ: "Нельзя!". Но многие интересуются подробностями - "А почему, собственно, нельзя?".
О переводе формата mde в формат mdb.
Microsoft разработал формат mde именно как средство защиты объектов базы данных. Идея - дать формат базы, лишенный исходных кодов и быстрее исполняемый. Вроде формата exe по сравнению с программой в исходных кодах, написанной на С++.
Но пароль владельца базы mde получить также легко, как и для формата mdb. То есть таблицы, макро, запросы можете считать полностью доступными кому угодно. Защита форм и отчетов построена на значении одного(!) байта в файле (А-1997, А-2000). Если его обнулить, то и они полностью доступны для редактирования.
Не могу не отметить, что подход Microsoft к защите файлов Access близок к уровню полной безответственности. И это при наличии других систем, отвечающим требованиям защищенности уровня С-2 (Пентагон)!
Остаются скрытыми только исходные тексты модулей. В файле mde их действительно нет. Они заменены на так называемые Р-коды. Можно ли их перевести в исходные коды? Я думаю, что можно. Это чисто техническая, хотя и трудоемкая задача. Осложненная непрерывным изменением форматов Р-кодов не только для разных версий Access, но в разных сборках одной версии. Для примера, измените свойство базы Build и посмотрите на реакцию Access. Для А-1997 я менял его с 5903 на 03. Access сообщил о перестроении Р-кодов. Думаю, что по этим причинам, а также по причине чисто хакерского характера работы, она до сих пор не сделана. Так что Р-коды остаются последним не взятым бастионом в задаче перевода mde в mdb.
Остается надеяться на его стойкость и на то, что Microsoft когда-нибудь поменяет свое отношение к защите баз Access.
Итак, формат mde защитит вашу базу от наглого воровства и не даст перевести ее в рабочий режим из состоянии демоверсии. Второе - только в том случае, если вы хорошо спрятали данные, задающие режим демо. О том, как их хорошо спрятать - ниже.
Но он никак не защитит от установки вашей программы именно на пять, а не на восемь компьютеров. Что еще хуже, он так же не защитит от передачи вашей программы в другие фирмы. Например, ваш первый покупатель возьмет и подарит (или продаст по дешевке) вашу программу еще одной фирме. А та - дальше.
Тут надо принимать меры защиты. А защита есть только одна - привязка программы к компьютеру.
Как привязать программу к компьютеру.
Первое, что приходит в голову - это пометить как-нибудь компьютер и проверять при старте эту отметку. Однако все методы пометки либо преодолеваются известными способами, либо создают много осложнений. Перечислим их с краткими характеристиками.
1.Внести запись о программе и ее состоянии в реестр.
Это стандартный подход. Однако есть программы, отслеживающие все обращения к реестру и позволяющие найти и скопировать разрешающую запись. Далее ваша программа распространяется вместе файлом записи в реестр. Этим приемом часто пользуются, например, при несанкционированном лицензировании элементов ocx.
2.Создать в запрятанных местах файл(ы), выполняющие ту же роль, что и запись в реестр.
И на этот случай есть программы, отслеживающие все обращения к файлам, и позволяющие найти нужные и скопировать. Этот метод ничем не лучше записи в реестр.
3.Внести запись в нестандартное место (флеш-память, запасные треки на диске, пустые кластеры на диске, пометив из как испорченные, дописать свою информацию к стандартным программам и т.д).
Это путь вирусописателей. Идти вместе с ними не следует. К тому же вы неизбежно падете жертвой антивирусных программ.
4. Добавить к компьютеру уникальное устройство.
Не стоит перечислять эти устройства. Главный их недостаток - их надо доставлять покупателю. А если у вас продажи по Интернет? Нужна ли вам головная боль от проблем доставки этих устройств, а также от выхода их из строя? Как универсальное решение этот подход явно не применим. Хотя он широко рекламируется фирмами, производящими эти устройства.
Другое направление - не помечать компьютер, а найти и запомнить его уникальные характеристики. Это направление изложено в статье Сергея Литовского "Система регистрации копий программы". http://nsa.chat.ru/Secur_RegProg.html. По-моему, оно значительно лучше.
Список доступных характеристик компьютера, данный в этой статье, можно еще увеличить. Однако и приведенный там список слишком велик. Дело в том, что любое изменение контрольных характеристик приводит к тому, что ваша программа прекращает работу. Дальше покупатель обращается к вам, и вы должны принимать меры для разбора сложившийся ситуации, решая вопрос: "Воруют или нет?", и выходить из нее.
Например, первоначально моя программа запоминала название компьютера, название диска С и его SerialNumber. Однако название компьютера и даже диска пользователи меняют с легкостью необыкновенной. Не думая о последствиях, о которых их, естественно, предупреждали. В конце концов я остановился только на SerialNumber диска С.
Но и с ним не все просто. Это вовсе не заводской номер диска, а номер, присваиваемый ему программой форматирования. При новом форматировании он изменится. Изменится он также при применении некоторых программ сжатия информации на диске. Далее, иногда он меняется при переустановке Windows. Причем не всегда. Пока не удалось понять, при какой именно переустановке он меняется. У меня в системах NT4, Win98, Win2000, WinMe он оставался одним и тем же. Но пользователи сообщают об изменении номера при замене Win98 на Win98. Хотелось бы найти действительно неизменную характеристику. Например, настоящий заводской номер физического диска. Говорят, что он есть. Но найти метод его чтения не удалось. Буду благодарен за любую информацию в этом направлении.
Остановимся на SerialNumber диска С. Будем запоминать и проверять его. Тем более, что избежать ситуации изменения характеристик компьютера невозможно в принципе. Например, фирма купила новый компьютер и желает переставить на него вашу программу. Для программы это и есть принципиальное изменение всех характеристик компьютера. Это должно быть обязательно допустимо. Так что надо подумать о логической схеме работы с SerialNumber.
Замечание. Литовский в свой статье рекомендует использовать SerialNumber диска, на котором установлена программа. Это снижает гибкость системы, так как запрещает свободный перенос программы с диска на диск даже в пределах одного компьютера.
Основная схема работы системы регистрации копий.
Основная схема придумана давно:
- демоверсия сообщает покупателю код компьютера;
- покупатель посылает его продавцу вместе со своими данными;
- продавец генерирует ключ перевода программы в рабочее состояние и посылает его покупателю;
- покупатель вводит ключ и программа переходит в рабочее состояние.
Но это основная схема. Различных вариантов ее реализации можно сделать очень много.
Ниже будет сделано еще несколько замечаний по предложениям С. Литовского. Поэтому, если вы еще не прочитали его статью, то сделайте это сейчас.
Сначала мелочь. Сосем не обязательно при выдаче кода компьютера шифровать его SerialNumber. Никакой уникальной информации он не несет. Поэтому код компьютера может быть просто ему равен.
Еще о SerialNumber:
- в некоторых случаях SerialNumber имеет отрицательный знак. Выдавайте его абсолютную величину. Путаницы меньше, а надежность та же.
- для чтения SerialNumber лучше использовать функцию из kernel32.dll GetVolumeInformation (у Литовского именно так - правильно), а не FileSystemObject. FSO работает не всегда (NT4).
Теперь основное замечание. Из текста "Пример процедуры для стартовой формы" следует, что каждая клиентская часть по Литовскому имеет свой регистрационный номер. И каждая привязана к своему компьютеру. Назовем это статической привязкой. В этом случае вам придется запрашивать код и высылать ключ для каждого компьютера в отдельности. При этой привязке перенос клиентской части с компьютера на компьютер без вас тоже обойтись не может.
Но главная трудность не в этом. Издалека вам не разобраться, то ли ваш покупатель заменяет парк компьютеров, запросив пять новых ключей взамен старых, то ли он его просто наращивает, слегка обманывая вас, то ли вообще передает вашу программу другой фирме, обманывая вас уже по крупному. Старые ключи-то у него остаются всегда...
Ниже излагается другая схема, которую можно назвать схемой динамической привязки программы к компьютерам. Суть состоит в следующем. Вместо запроса кодов всех компьютеров следует получить код одного (любого) компьютера из сети. Затем сгенерировать ключ перевода программы в рабочее состояние, включив в него следующую информацию:
- присланный вам SerialNumber;
- количество купленных лицензий (на скольких компьютерах программа будет работать);
- полное название организации, возможно с местом ее нахождения.
Ключ перевода должен быть обязательно зашифрован.
Программа обработки ключа должна:
- дешифровать ключ;
- сравнить SerialNumber с реальным;
- при совпадении записать в защищенную область (о ней ниже) базы с данными всю принятую информацию, дополнив SerialNumber именем компьютера. Имя компьютера имеет вспомогательное значение и используется для проведения деинсталляции.
Название организации - покупателя можно выводить в форме - заставке и в форме "О программе".
Далее, при старте любая клиентская часть должна прочитать SerialNumber своего компьютера и найти его в защищенной области. Если он есть, то программа молча работает дальше. Иначе она сравнивает количество записанных SerialNumber и количество лицензий. Если количество лицензий не исчерпано, то, после вопроса о правильности данной инсталляции, записывает новый SerialNumber и имя компьютера в защищенную область.
Таким образом, система учета даст возможность установить программу на любых пяти компьютерах сети и не позволит установить на шестой. Все клиентские части идентичны, что в свою очередь делает их Upgrade легко осуществимым.
Теперь нужно решить проблему переноса программы с компьютера на компьютер. Как указанно выше, она эквивалентна изменению SerialNumber какого-либо компьютера. Для этого дополним нашу программу системой деинсталляции. В программу включим форму, показывающую список имен компьютеров, на которых инсталлирована ваша программа. Список формируется, естественно, из данных, взятых из защищенной области. В форме сделаем кнопку "Деинсталлировать указанный компьютер". При ее нажатии из защищенной области удаляем указанный компьютер и его SerialNumber. Теперь, когда лицензия освободилась, покупатель может скопировать вашу программу на другой компьютер и запустить ее там. Программа проведет инсталляцию, чем и будет завершен процесс переноса. Таким образом, все перемещения покупатель может сделать сам, не обращаясь к вам. В том числе может сам бороться с последствиями изменения SerialNumber какого-либо компьютера. Он его деинсталлирует и установит заново. Забот у вас при применении динамической привязки станет несколько меньше.
Два замечания:
- удаление последней лицензии должно переводить программу снова в состояние демоверсии;
- если куплена лицензия только на один компьютер, то статическая и динамическая привязки совпадают. Но для Access работа на одном компьютере - не типичный случай. Да и разрешение на перенос (новый ключ) вы даете только на один компьютер, рискуя не очень многим.
При динамической привязке незаметно оказалась решена еще одна, ранее не указанная проблема: регистрация докупки лицензий. Если покупатель введет ключ с увеличенным количеством лицензий, то программа заменит содержимое защищенной области и будет заново инсталлировать компьютеры. Хотя здесь возможно иное решение: использование ключа другого формата, отрабатывая который, программа просто увеличит количество лицензий, допуская новые инсталляции.
Теперь вы готовы вести динамический учет компьютеров в сети. И программу, кажется, можно ставить покупателю.
Однако, что будет, если он решит подарить ее дружественной фирме? Для этого он деинсталлирует все компьютеры, кроме одного, и в этом виде передаст базу другой фирме. Далее инсталлирует свои компьютеры снова и будет работать как прежде. А дружественная фирма проведет инсталляцию своих компьютеров. То есть эта схема не защищена от незаконного копирования с разрешения законного владельца. Проблему надо решать. Отметим, что и в случае статической привязки она существует, только переносится на ваше усмотрение при обращении владельца за новыми ключами взамен старых. А ваше решение, как это не печально, в случае удаленности от фирмы-покупателя может быть только одно: дать ей новые ключи. То есть, в статической схеме от этой ситуации по существу защиты нет.
Защита от незаконного копирования с разрешения законного владельца.
Хочу отметить, что такая задача обычно шароварщиками не ставится и не решается. Принципиальное решение этой задачи заключается в том, чтобы считать и запомнить уникальную характеристику сети в целом. К сожалению, я не знаю такой устойчивой характеристики и буду рад о любой информации о ней. Реально применяю схему, которая тоже дает защиту, но с небольшой дырой.
Схема заключается в следующем:
- описание компьютера (номер, имя) пополняется еще одним полем - датой инсталляции;
- при вводе ключа системы дата для этого компьютера устанавливается нулевой, что означает "вечное" использование;
- если инсталляция происходит при запуске других программ-клиентов, то дата записывается равной текущей дате;
- при старте любой клиентской программы, как было указано выше, проводится поиск в защищенной области своего SerialNumber. При его нахождении дополнительно проверяется дата инсталляции. Если она равна нулю, то она обнуляется и у всех остальных компьютеров. То есть они становятся тоже "вечными". А если она не нулевая и прошло более 20 дней, то выводится предупреждение о незаконном копировании и рекомендация немедленно обратиться к продавцу. Через 31 день программа сообщает: "Незаконное копирование!" и прекращает работу.
Логика схемы: если все в порядке, то программа обязательно запускается со стартового (начального) компьютера, что приводит к "вечной" установке всех компьютеров и делает их равнозначными.
Если ваш покупатель передал программу в другую организацию, деинсталлировав все компьютеры, кроме одного, то в другой организации запуска с этого единственного "вечного" компьютера никогда не будет. А все другие компьютеры, инсталлированные в другой организации получат ненулевую дату. Далее сработает защита от незаконного копирования по дате инсталляции.
Дыру в схеме найдите сами.
Защита от хакера.
Вся система защиты построена на использовании SerialNumber. А ведь можно определить и перехватить обращение к чтению этого номера, и подсунуть программе известный правильный номер, имея лицензию хотя бы на один компьютер. Далее программу можно свободно распространять вместе с примочкой, подсовывающей правильный номер. Для программы это будет выглядеть как работа на одном компьютере при реальной работе многих. Не обманывайтесь мыслью, что увеличив число считываемых характеристик, вы защититесь от подмены. Можно перехватить и подменить чтение любых характеристик.
Но есть защита и от подмены. При запуске ваша программа получает номер процесса, который изменить нельзя, не нарушив работу Windows. Давайте запомним и его при старте программы, дополнив текущие характеристики компьютера. И будем его проверять, скажем, через каждые две минуты. Если он изменится, то для программы это будет означать, что на одном компьютере ваша программа запущена дважды. Осталось запретить такой запуск, предупредив об этом покупателя. Тем самым вы защититесь и от хакера.
Хранение учетной информации (защищенная область).
Хранить ее надо, как было сказано выше, в общей базе с данными. Можно использовать естественное место хранения - таблицу, а можно хранить в своих специально созданных Properties. Причем можно создать такие Properties, которые будут недоступны для программ печати свойств, построенных на их переборе. Например, Properties системной таблицы MSysQueries. Забавное свойство Access: распечатать нельзя, а напрямую читать и писать можно. Можно пойти еще дальше, используя Properties поля Expression системной таблицы MSysQueries. Так я вначале и сделал. Но оказалось, что это не здорово. Базы Access имеют свойство портиться. А один из методов восстановления - импорт данных. Но при импорте эти Properties не переписываются. Приходится установочную информацию либо вводить заново, либо переписывать спецпрограммой. То и другое осложняет жизнь. Лучшим выходом оказалось хранение информации просто в таблице, но в зашифрованном виде. Именно в шифрации и в контрольных суммах, учитывающих каждый байт хранимой информации, состоит защита установочной информации.
Особое внимание следует уделить алгоритму шифрации. Типичные ошибки демонстрирует статья Новикова и комментарий к ней Крамарева. http://nsa.chat.ru/Secur_Crypt.html. Если шифрация вскрыта, то все ваши усилия пойдут прахом. Рекомендую обратиться к алгоритму RSA : http://www.leadersoft.ru/subscribe/sub/sub32.htm. Хотя сам использую другой алгоритм. Но он пусть останется в тени.
В. Крамарев дал ссылку на хороший обзор методов шифрования:
http://www.ssl.stu.neva.ru/psw/crypto.html
Заключение.
Защита баз mde от незаконного копирования - необходимая, но не самая трудоемкая часть превращения вашей программы в товарный продукт. Вот еще некоторые другие: восстановление упавших баз ваших клиентов, решение проблем работы на мониторах с разным разрешением, Upgrade не только клиентской части, но и самой структуры данных и обеспечение работы со старыми структурами, автоматизация Upgrade в больших сетях, система настройки внешнего вида форм под вкусы разных пользователей, и, наконец, самая нелюбимая программистами часть - подробный контекстный хелп программы, учитывающий невысокую квалификацию ваших будущих пользователей.
Так что: "Не спешите разделить радость шефа" ...