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

Хакеры (или крэкеры) вскрывают защиты программ, распространяют так называемые «кряки», серийные номера и т.д. На вооружении хакеров стоят мощные инструменты – мощные отладчики, интерактивные дизассемблеры, интеллектуальные шестнадцатеричные редакторы. Практически любая программа становится совершенно беззащитной перед этими продуктами. Если читатель имеет навыки программирования на языке ассемблере (или хотя бы теоретически слышал про этот язык), то он меня поймет. Здесь я не буду подробно расписывать особенности и предназначение ассемблера, про асм можно прочитать в рубрике «Ассемблер» на этом сайте, да и в ассемблере я не профи, поэтому по мере набирания опыта буду выкладывать новые мои наработки по теме. Любая программа будучи дизассемблированной, становится полностью открытой.

К сожалению, многие программисты практически не задумываются над защитой своего программного продукта и надеются на «авось». Стоит ли при таком раскладе удивляться, что кряки к популярным программам появляются буквально через считанные часы после их официального выхода в свет, а порой и раньше! Крэкерские команды сотрудничают с людьми софтверных компаний, здесь крутятся также большие деньги. А ведь если бы программист приложил немного усилий для защиты программы – и больше 90% новичков, захотевших взломать программу, плюнули на это дело. Почему 90%? Ну, в данной статье приводятся наиболее эффективные из тех методов защиты, которые несложно воплотить в жизнь, в основном все сводится к изменению исходников программы на языке высокого уровня. Ассемблерные вставки доступны только профессионалам, а значит только крупные производители ПО (программного обеспечения) могут себе позволить использовать работу таких специалистов.

Перед тем как написать свою программу, начать распространять ее, хороший программер подумает о вероятности взлома и устойчивости программы к нему. Тут надо немного порассуждать. Каждая программа имеет определенную ценность, и чем она ценнее, тем больше вероятность что кто-то попытается ее модифицировать. Программист стоит с одной стороны баррикады, хакер-с другой. Поскольку программистам принадлежит инициатива, они задают темп игры. Появляется защита, проходит какое-то время- и хакеры находят средство ее взломать, пишутся руководства по этому поводу, и защита постепенно теряет свою эффективность. Если разработчик много работал над устойчивостью программы к взлому, тогда время в течении которого не будет существовать взломанных копий, увеличивается. Тут мы натыкаемся на палку о двух концах: с одной стороны, защита должна быть как можно эффективнее и проще в ее воплощении, с другой- она все равно будет вскрыта за конечное время. Поэтому перед тем как начать защищать дистрибутив, не мешало бы подумать о ценности программы, обстановке положения ее на рынке и т.д. Тут нельзя дать универсального совета, но приведу пример: одна программа стоит 100$, другая, аналогичная ей, бесплатна. Тогда естественно, обычный пользователь будет использовать бесплатную программу вместо того чтобы платить $. Но с другой стороны, не каждый будет знать о существовании конкурента, и тогда придется покупать лицензию. Довольно часто начинающие программеры допускают одну ошибку – переоценивают реальную стоимость программы. Я прекрасно понимаю это чувство гордости, которое возникает когда твое детище работает и выдает превосходные результаты в своей сфере деятельности. Но многие часы проведенные за монитором при написании этой программы заставляют разработчика подумать что эта программа бесценна, а на самом деле цена ей – грош. Поэтому не нужно делать глупостей, реализуя первые же версии своих программ платными, придумывать изощренные защиты. Скорее всего, программа «сыра» и содержит в себе кучу ошибок (багов), запустится не на каждом компьютере и вообще оставит не самое приятное впечатление о себе. В таком случае не надо доверять себе в оценке стоимости программы, а предоставить это право посторонним людям. Предложите поработать с программой друзьям, знакомым – они дадут вам кучу советов и критики, многие найденные баги можно закрыть тут же, другие потребуют длительных мучительных копаний в программном коде. Можно выставить программу на своем сайте для тестирования – и вполне возможно, вскоре после некоторых доработок ее вполне можно предлагать за деньги. А какой смысл ставить защиту если цена проги невысока? Правильно, никакого.

Одна из основных заповедей людей занимающихся проблемой безопасности информации – все что создано, можно взломать. Если мне не изменяет память, эту фразу сказал один профессиональный хакер. Это так, но не совсем. Если в защите программы используются надежные криптоалгоритмы, то при грамотной их реализации (если возможность подбора ХЭШ’а сведена к минимуму) время раскрытия такого шифрования будет примерно равным времени, прошедшем с происхождения нашей вселенной до сего дня. То есть абсолютная. Но тут все упирается в баги. Да, вместо попытки подобрать криптоалгоритм чаще применяются поиски уязвимостей. В особо трудных случаях даже хакер-профи не может справиться с защитой, но это еще не значит что она не будет взломана. В крайнем случае хакер может купить одну лицензионную версию, затем на основании анализа различий в их работе добьется своего. Не потому ли многие крупные компании-разработчики ПО вообще перестали защищать свои продукты, предпочитая вместо защиты бросать все свои силы на усовершенствование непосредственно самой проги – «зачем защищать, если все равно взломают?». В грамотных профессиональных защитах взлом настолько затруднен, что время взлома будет сравнимо с временем написания защищаемой программы. И тут есть один интересный момент: когда время взлома примерно сравнимо с временем разработки проги, то хакер теоретически может самостоятельно (он же и программист неплохой) написать аналогичную прогу. Другое дело, если вы увидели что защита «непробиваема» и стали продавать ее или устанавливать на другие программные продукты. Тогда даже если исследуемая защищенная прога и не представляет особого интереса, узнав её хитрости, можно справляться с множеством других программ, защищенных по данной технологии.

Одна из самых сильных методик противодействия исследованию – написание собственного виртуального процессора. Тогда программа будет как бы выполняться на другом, придуманном процессоре, с которым хакерские инструменты окажутся бессильными и будут показывать абракадабру. Вымышленная архитектура, новые регистры – все зависит от изощренности фантазии. Но вряд ли вы, тот человек который сейчас читает мою статью, сможете грамотно реализовать эту защиту – для этого нужно посвятить всю свою жизнь изучению архитектуры персонального компьютера, просиживать за компом по 10-15 часов в сутки, делая небольшие вынужденные перерывы поспать, поесть и справить нужду. Такие люди есть – они, настоящие профи и гуру в своей области. Мало знать в совершенстве всю документацию от Microsoft и Intel по описанию функционирования операционной системы и процессора (а это уже многие тысячи страниц, покрытых кодами на которые без слез не взглянешь). Нужен также много практиковаться, читать море информации для знаний многих «штучек». Далеко не всегда все описывается в разного рода руководствах, по различным причинам многие вещи скрываются или вымышленно искажаются. Знание таких недокументированных особенностей архитектуры позволяет разрабатывать действительно профессиональные системы.

Заслуживает внимания и информация о хакерских инструментах. Некоторые из этих программ действительно бесценны, но опять таки все они имеют кучу недокументированных вещей, багов. Если такая программа коммерческая, то теоретически, у разработчика есть повод постоянно ее дорабатывать, чутко реагируя на высказывания тысяч пользователей. Но лень человеческая берет свое – далеко не все удосуживаются это делать. К тому же коммерческих программ в этой экзотической нише не так много, а значит, все держится исключительно на энтузиазме разработчиков (ка). Ну решил чел написать для облегчения собственной жизни прогу, ну и заодно не пожадничал и выставил ее на всеобщее обозрение. Народу прога понравилась, он начал ее активно юзать. А так как ничто не совершенно, то вскоре в нашей проге находится куча ошибок. Или просто у пользователей есть много предложений по ее улучшению – неважно, но в такой ситуации они могут только просить. Просить, чтобы ее «отец» засел на неделю-другую за комп и добавил-таки новую функцию, смысл есть. Но вот сделает он это далеко не всегда, а то и вовсе бросит полюбившийся миру продукт. И таких примеров- множество. Поэтому есть несколько рискованный шанс воспользоваться уязвимостями таких программ для препятствования исследованию ломаемой программы с помощью них. Опять-таки возможно уже в следующей версии инструмента уязвимость будет закрыта, и мощь вашей защиты несколько упадет. Но в конце концов, время гарантированного действия защиты небольшое, и уж точно меньше, чем выход новой версии подобного хакерского инструмента.

Современные хакеры уже далеко не те, что были например, в 80-е годы. Я ни в коей мере не сомневаюсь в профессионализме этих людей, но дело в том, что их сейчас очень много. Раньше не был популярен Интернет, не существовало никакой литературы, приходилось все постигать на собственном опыте. Отсюда люди, в совершенстве знающие архитектуру компьютера. Сейчас же ситуация иная. Чтобы ломать программы, уже не обязательно обладать такими знаниями, которыми, скажем, обладал хакер ушедшего века. Существует много программ облегчающих их деятельность, много литературы по принципу «делай как я». Такие люди могут противодействовать распространенным защитам и словно превращаются в маленьких слепых котят перед защитой иного рода. Из-за этого даже небольшие противоотладочные трюки сильно повысят общую защищенность проги, большинство таких «псевдохакеров» отступят. Молитесь только чтобы за защиту не взялся настоящий профессионал – он только посмеется над ней, а потом на досуге взломает. Но, повторюсь, таких людей очень мало и не факт что он возьмется за вашу прогу.

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

Дизассемблирование – код программы преобразуется в ассемблерный листинг. Читается такой листинг в зависимости от знаний достаточно трудно, а объем кода может быть в сотни и тысячи страниц. Но и не нужно «перелопатить» весь этот код (на это могут уйти годы), достаточно находить места где происходит работа защиты с тем чтобы модифицировать код, обезвредив защиту, или получить данные для работы с прочим хакерским арсеналом. Дизассемблирование относится к статическим методам, и отсюда многие достоинства и недостатки метода.

Трассировка – динамический метод. С помощью отладчика можно запустить на выполнение небольшой участок кода, посмотреть в прямом смысле результаты его работы, просмотреть содержание регистров памяти, а это значит что нужно найти нужный участок кода- и дело в шляпе. Ниже я приведу пример проверки программой серийного номера на Visual Basic:

If strRegNumber = «1234-5678-9GHK-LTYD» Then
MsgBox «Программа зарегистрирована»: Registr = True ’Если серийный номер соответствует введенному, то выходит соответствующее сообщение и переменная показывающая регистрацию (Registr) принимает значение True.
Else:
MsgBox «Серийный номер неверен. Пожалуйста, введите правильный ключ»: Registr=False ‘Иначе программа незарегистрирована.
End If

В принципе все верно, но если воспользоваться дизассемблером или отладчиком, то места сравнения введенного кода с правильным будут находиться совсем рядом с сообщениями о регистрации. Поэтому будет очень замечательно, если программеру удастся разбросать такие места по всему телу программы, не сосредотачивая код в таких узких местах. Возможно вы спросите: «Да от меня тут что зависит, откуда я знаю как расположит код компилятор!». Да, это отчасти так, но все же существуют методики противодействия такому взлому. Такой метод защиты называется Скремблинг. Опять пример, на этот раз на старом добром QBasic:

10 Goto 40
20 Registry = 1: Goto 60
30 Print «Неверный регистрационный номер!»: Goto 70
40 If Peremennaya = «12345» Then Goto 20
50 Registry= 0: Goto 30
60 Print «Программа зарегистрирована, спасибо за регистрацию!»
70 End

В этом примере мы видим, что классическое расположение «проверка-вывод результата» изменилось, все поменялось местами и может серьезно озадачить хакера. Конечно, код стал трудночитаемым но за все в этой жизни надо платить. Можно к тому же сделать для себя подробные комментарии в коде, дабы не забыть сущность хитросплетений.

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

Данные о регистрации нельзя хранить прямо в папке с программой, лучше использовать разные «укромные» места вроде различных подпапок директории «WINDOWS», давая имя файлу какой-нибудь безобидный «System», «System32», «SystemConfig»… Ну в общем вы поняли. Данные желательно шифровать, чтобы в файле не было такого: «Registry = True». Если защита использует системный реестр, то лучше создавать ветку какого-нибудь нейтрального названия. Ни в коем случае нельзя хранить данные о регистрации в одном месте, таких мест должно быть несколько, как в реестре, так и просто в файлах. Регистрационный ключ может собираться из его «кусочков», лежащих в разных файлов. Так вы запутаете хакера и есть вероятность что он не доведет начатое до конца.

Как уже говорилось выше, очень эффективно получается использовать криптоалгоритмы. При этом главное условие – используемый алгоритм должен быть хорошо зарекомендован в профессиональной литературе, а ключом к расшифровке может быть сам серийный номер. Эта защита очень эффективна – как можно взломать то, чего в программе нет? Шифруются несколько важных функций, без которых работы программы невозможна.

Использование хэш-функции (чаще CRC32) очень эффективно, при этом программа с помощью определенной работы регистров проверяет свою целостность, но для начинающего трудна и единственная возможность применить CRC32- воспользоваться специальным программным обеспечением от третьих фирм. Это протекторы и упаковщики (читайте статью «Обзор и тестирование упаковщиков исполняемых файлов). Здесь я не буду подробно останавливаться на них.

И напоследок, несколько интересных противоотладочных приемов:

- избегать хранения в коде программы открытых текстов. Это может достигаться специальным кодированием исходников в динамические массивы. Тогда код будет подобен этому: Chr (1)+ Chr (2) + Chr (3) + Chr (n) и тогда место регистрации будет труднее найти. Вместо того чтобы заниматься этим самостоятельно, можно положиться на средства сторонних производителей, но в таком случае вы не получите главного – знания принципов, а стало быть сильных и слабых сторон происходящего;
- не хранить регистрационные переменные в открытом виде и в одном месте – переменная может быть закриптована и суммироваться из нескольких составных переменных;
- Вставлять некоторый «мусорный» код в месте регистрации. Это могут быть различные числовые и строковые переменные, можно объявлять их с именами смахивающими на ключ «Reg, Serial…», различные сообщения связанные с регистрацией (кто говорил об оптимизации?);
- регистрирующую функцию можно поставить в цикл и повторять многократно, с тем чтобы сбить с толку взломщика;
- проверка правильности серийного номера лучше будет осуществляться не простым сравнением, а например, по его хэшу, длине, по определенным перестановкам и действиям над символами серийника и т.д.

Автор статьи Тремасов Михаил (С) 2007. Все права защищены. Распространение статьи разрешено только с письменного разрешения автора. Данная статья является ознакомительной и автор не несет ответственности за действия, вызванные неправильной трактовкой материала статьи.
Сайт автора: <a href=”http://www.easycoding.fatal.ru”www.easycoding.fatal.ru</a>