<< Предыдущая

стр. 25
(из 39 стр.)

ОГЛАВЛЕНИЕ

Следующая >>

Поэтому часто противнику достаточно изменить логическое имя драйвера
монитора, чтобы программа оказалась не в состоянии его обнаружить.
Кроме программ-мониторов, принадлежащих к семейству активных инстру-
ментов, есть и семейство пассивных инструментов. Это программы, которые
позволяют отслеживать произошедшие изменения, не находясь все время
в памяти. Просто до первого запуска защищенной программы необходимо
сохранить текущее состояние реестра или определенных файлов, а после
запуска сравнить новое состояние с предыдущим. Те записи, которые были
изменены, сразу окажутся на подозрении у противника. Использование пас-
сивных инструментов не может быть обнаружено защитой, и единственный
способ противостоять им — внести очень большое количество фиктивных
изменений, чтобы затруднить противнику определение действительно важ-
ных записей. Но такой подход неминуемо приведет к снижению производи-
тельности.
168 Часть III. Как не надо защищать программы

14.3.3. Программы
с возможностью регистрации
Программы, в которых предусмотрена возможность регистрации, выглядят
привлекательно с точки зрения маркетинга. Действительно, пользователей
должно радовать, что сразу после оплаты стоимости лицензии они получат
регистрационный код и могут моментально превратить ограниченную вер-
сию в полноценную. Не потребуется ни выкачивание другого инсталляци-
онного пакета, ни повторная инсталляция.
Однако интуитивно понятно, что подобная схема может быть уязвлена мно-
жеством способов.
Очень часто регистрация подразумевает ввод имени пользователя и одного
или нескольких регистрационных кодов. Если регистрация не имеет маши-
нозависимой составляющей, т. е. на любом компьютере определенному
имени пользователя соответствуют всегда одни и те же регистрационные
коды, то, зарегистрировав программу один раз, ее можно будет использовать
на любом количестве компьютеров. Неудивительно, что для очень многих
программ в Интернете можно без труда найти регистрационные коды.
Проверка правильности введенного регистрационного кода тоже может вы-
полняться по-разному. Нередко встречаются реализации, когда программа
вычисляет для введенного имени пользователя правильный регистрацион-
ный код, который просто сравнивается с тем кодом, который ввел пользова-
тель. В подобной ситуации для нелегальной регистрации программы на лю-
бое имя достаточно ввести это имя и произвольный код, найти точку, где
правильный регистрационный код уже вычислен, и прочитать его из памя-
ти. При следующей попытке регистрации достаточно ввести то же самое
имя и прочитанный из памяти код, чтобы программа решила, что она кор-
ректно зарегистрирована.
И, конечно же, если регистрационные данные просто проверяются на кор-
ректность, ничто не мешает противнику исправить тело процедуры провер-
ки таким образом, что любые введенные регистрационные коды будут счи-
таться правильными. Лучше сделать так, чтобы регистрационная
информация использовалась в жизненно важных функциях программы.
Это особенно полезно в свете того, что программа после регистрации долж-
на превратиться в полноценную версию без использования каких-либо до-
полнительных модулей. Следовательно, ограниченная версия должна в какой-
либо форме содержать весь код, доступный в полной версии. Одно из воз-
можных решений — зашифровать фрагменты программы, относящиеся
к полной версии, а ключ шифрования каким-то образом связать с регистра-
ционным кодом. При этом без знания правильной регистрационной ин-
Глава 14. Приемы, облегчающие работу противника 169

формации не удастся расшифровать защищенные фрагменты, даже если от-
ключить все проверки правильности регистрационного кода.


14.4. Распределенные проверки
Когда программа получила от пользователя регистрационную информацию,
не обязательно сразу же определять ее правильность и информировать об
этом пользователя. Если все проверки сосредоточены в одном месте, про-
тивнику гораздо легче определить, откуда начинать анализ.
Предпочтительнее выглядит следующий подход. При вводе регистрационной
информации выполняется первичная проверка, предназначенная скорее для
исключения ошибок набора с клавиатуры, чем для защиты. Если введенная
информация кажется правильной, она сохраняется на диске (в файле или
реестре) и пользователю выдается сообщение с благодарностью за регистра-
цию и предложением перезапустить программу, т. к. только после переза-
пуска будут активированы все функции, недоступные в бесплатной оценоч-
ной версии.
После перезапуска программа читает с диска регистрационную информацию
и тиражирует ее в памяти в нескольких экземплярах. Это делается для того,
чтобы противнику сложнее было найти место, где программа интерпретиру-
ет регистрационные данные.
В разных местах программы необходимо вставить разные функции, которые
будут проверять разные кусочки регистрационной информации или целост-
ность программы. Лучше иметь несколько функций, проверяющих одно и
то же, чем одну функцию, проверяющую сразу все. Противнику придется
разбираться со всеми функциями проверки, и чем их больше, тем ему будет
сложнее.
Если в результате одной из проверок выяснилось, что регистрационные
данные неверны, не стоит сразу сообщать об этом пользователю. Лучше ус-
тановить специальный флаг, указывающий на то, что программа не была
корректно зарегистрирована. А в другой функции, относящейся к совер-
шенно иному фрагменту программы, анализировать один или несколько
флагов и предпринимать соответствующие действия.
Действия могут быть самые разнообразные. Так, например, один из DOS-
овских симуляторов Formula-1 при запуске проверял наличие документации:
у пользователя просили ввести слово, написанное на определенной страни-
це. Исправлением одного байта можно было заставить программу запускать-
ся при вводе любого слова, но тогда автомобиль становился неуправляемым
через несколько минут после начала гонки.
170 Часть III. Как не надо защищать программы

Другой пример нестандартной реакции. Программа ReGet Deluxe, предна-
значенная для управления выкачиванием файлов по протоколам HTTP и
FTP, иногда подменяла загруженные файлы, если обнаруживала, что код
программы был модифицирован. Так у пользователя взломанной версии
ReGet Deluxe были шансы в архиве обнаружить файл readme.txt, содержа-
щий текстовую строку "This file downloaded with cracked version of ReGet
Deluxe", или получить сообщение с тем же текстом при запуске закачанного
исполняемого файла.
Также существует красивая легенда, касающаяся программы 1С:Бухгалтерия.

1 С:Бухгалтерия и ключи HASP
Бухгалтерская программа от компании 1С исторически была защищена от ко-
пирования при помощи аппаратных ключей HASP. Для всех ключей HASP того
времени существовали эмуляторы, и 1С нормально работала при отсутствии
ключа, если на машине был установлен эмулятор, и очень многие это знали.
Но, видимо, о существовании эмуляторов были неплохо осведомлены и про-
граммисты 1С. Во всяком случае, однажды программа перестала работать под
эмулятором, в то время как при наличии настоящего ключа никаких проблем не
возникало.

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

Расчет был сделан очень точно, и, по слухам, компания 1С за 2 недели прода-
ла столько копий своей Бухгалтерии, сколько обычно продавалось за полгода.

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



14.5. Инсталляторы с защитой
Некоторые производители программного обеспечения позволяют всем же-
лающем скачать инсталлятор программы с официального интернет-сайта.
При этом инсталлятор может быть защищен таким образом, что для уста-
новки программы необходимо знать некоторую информацию, которую про-
изводитель сообщит только после получения оплаты.
Глава 14. Приемы, облегчающие работу противника 171_

Однако д&чеко не все разработчики знают, что некоторые способы защиты
инсталляторов совсем не так безопасны, как хотелось бы.

14.5.1. ZIP-архивы с паролем
Очень многие программы распространяются в ZIP-архивах. И очевидная
идея защиты дистрибутива — установка пароля на архив. Если выбранный
пароль содержит буквы, цифры и знаки препинания и имеет достаточно
большую длину, то для отыскания такого пароля перебором потребуется
очень много времени. Однако кроме подбора пароля методом грубой силы
(brute force) существуют и более эффективные варианты атаки.
Если архив был создан с помощью программы, основанной на исходных
текстах от InfoZIP Group (например WinZip), и содержит пять или более
файлов, существует алгоритм, отыскивающий ключ и расшифровывающий
архив примерно за час.
Если применялся архиватор, не основанный на InfoZIP, то противник мо-
жет попытаться воспользоваться атакой на основе открытого текста. Для
этого ему понадобится иметь в открытом виде один из файлов, зашифро-
ванных в архиве.
Но как можно получить незашифрованный файл? Оказывается, создатели
архива часто сами помещают в архив с дистрибутивом файл, который можно
найти в открытом виде. Например, файл README.TXT, описывающий
продукт, обычно доступен по ссылке с web-страницы, а также находится
в дистрибутиве.
Если инсталлятор программы, зашифрованный в архиве, создан при помо-
щи пакета InstallShield, то в архиве окажется с десяток файлов, некоторые из
которых идентичны для всех инсталляторов, созданных с помощью Install-
Shield той же версии. Следовательно, незашифрованный файл может быть
взят от другой программы или найден в Интернете с помощью службы
FTPsearch.

14.5.2. Norton Secret Stuff
Некоторые производители для распространения своих продуктов использо-
вали разработанную компанией Symantec бесплатную программу Norton
Secret Stuff (NSS), создающую из указанного набора файлов самораспаковы-
вающийся архив с паролем. Все данные шифруются с помощью криптогра-
фически стойкого алгоритма BlowFish, но в силу действовавших на момент
создания NSS ограничений на экспорт программного обеспечения, исполь-
зующего стойкую криптографию, применяется ключ шифрования, в кото-
ром неизвестными являются только 32 бита.
•\72 Часть III. Как не надо защищать программы


В 1998 году Павел Семьянов разработал программу No More Secret Stuff
(NMSS), позволяющую подобрать 32-битовый ключ и расшифровать архив
не более чем за 4 недели на компьютере с процессором Intel Pentium
166 МГц. С тех пор производительность процессоров значительно выросла,
и подбор ключа может быть осуществлен на одном компьютере за считан-
ные дни. А если выполнять вычисления одновременно на нескольких ма-
шинах, то результат может быть достигнут буквально за насколько часов.
Ключ шифрования вычисляется из пароля при помощи хэш-функции MD5.
На настоящий момент не существует эффективного способа обращения
этой функции, но на подбор пароля, порождающего заданный 32-битовый
ключ, уходит примерно в 64 раза меньше времени, чем на поиск самого
ключа. Таким образом, несмотря на то, что поиск пароля не является необ-
ходимым для расшифрования архива NSS, если известен ключ шифрования,
при желании можно найти и пароль, затратив при этом на 2 % больше ре-
сурсов.

14.5.3. Package For The Web
Если инсталлятор состоит не из одного файла, часто применяется дополни-
тельная программа, позволяющая все файлы, составляющие инсталлятор,
упаковать в один исполняемый файл. Пользователь скачивает этот файл и
запускает его, что приводит к распаковке инсталлятора во временную ди-
ректорию и запуску процесса инсталляции. После того как инсталляция за-
вершится, автоматически будут удалены все временные файлы.
Популярной программой для упаковки инсталляционного пакета в один ис-
полняемый файл является Package For The Web (PFTW), бесплатно распро-
страняемая InstallShield Software Corporation и, похоже, входящая в состав
коммерческой программы InstallShield. PFTW позволяет установить пароль
на исполняемый файл, что не позволит распаковать, а значит, и запустить
инсталлятор, пока не будет введен правильный пароль.
Однако то, как проверяется пароль в PFTW, заслуживает серьезной крити-
ки. В ранних версиях пароль просто сравнивался со строкой, хранившейся
в зашифрованном виде. Следовательно, можно было или откорректировать
условие, в результате проверки которого принималось решение о правиль-
ности ввода пароля, или "подсмотреть" пароль в момент проверки.
Более новые версии PFTW поступают гораздо умнее. Пароль нигде не хра-
нится даже в зашифрованном виде, но запоминается его 14-битовый хэш,
который сравнивается со значением хэша от введенного пользователем па-
роля. В случае несовпадения пользователя сразу информируют о том, что
пароль неверен. Но так как длина хэша составляет всего 14 бит, примерно
один из 16 тысяч паролей будет проходить эту проверку. Это широко рас-
Глава 14. Приемы, облегчающие работу противника 173

пространенный подход, который позволяет защититься от случайных опеча-
ток, но не дает возможности правильно определить пароль, даже если удаст-
ся обратить хэш — каждому значению хэша будет соответствовать, например,
почти полмиллиона семисимвольных паролей, состоящих только из м&тень-
ких латинских букв, но только один из этих паролей будет правильным.
Если проверка хэша прошла успешно, из пароля вычисляется ключ, кото-
рый используется для расшифрования инсталлятора. Но именно тут разра-
ботчики PFTW допустили оплошность.
Дело в том, что длина ключа шифрования соответствует длине пароля, и
преобразование пароля в ключ является обратимым, т. е., зная ключ шиф-
рования, легко вычислить пароль. А алгоритм шифрования не устойчив
к атаке на основе открытого текста, т. е., зная несколько байт открытого
текста и соответствующего ему шифртекста, очень просто вычислить фраг-
мент ключа шифрования той же длины, что и известный открытый текст.
Таким образом, для определения пароля достаточно найти фрагмент откры-
того текста, который по длине не короче пароля.
Но, как оказалось, шифруемые данные представляют собой так называемый
САВ-файл, формат которого был разработан корпорацией Microsoft. CAB-
файл является разновидностью архивного файла, хранящего один или не-
сколько других файлов в упакованном виде, и всегда начинается со строко-
вой сигнатуры "MSCF" (Microsoft CAB File), за которой следуют 4 нулевых
байта и 64-битовое число, соответствующее размеру САВ-файла. Таким об-
разом, определить первые 16 байт открытого текста, а значит и пароля, дли-
на которого не превышает 16 байт, не составит труда. В САВ-файле присут-
ствуют и другие области, значение которых совсем не трудно предугадать.
Их можно использовать для вычисления более длинных паролей.
Часть IV

ОСНОВНЫЕ АСПЕКТЫ
ЗАЩИТЫ ДАННЫХ

Глава 15. Обеспечение секретности

Глава 16. Особенности реализации DRM

Глава 17. Стеганографическая защита данных

Глава 18. Причины ослабления средств защиты
176 Часть IV. Основные аспекты защиты данных


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

<< Предыдущая

стр. 25
(из 39 стр.)

ОГЛАВЛЕНИЕ

Следующая >>