Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
NIRS_Reverse_Engineering (1).doc
Скачиваний:
1
Добавлен:
01.07.2025
Размер:
2 Мб
Скачать
☆

Защита программ от анализа

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

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

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

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

За последние 20 — 30 лет в данной области было проведено множество исследований, в результате которых был разработан целый ряд средств и методов, позволяющих увеличить трудоемкость анализа защищаемой программы в десятки раз. В конце 1980-х и начале 1990-х гг. защита программ от анализа применялась очень широко. Доходило до того, что отсутствие в программе средств защиты от анализа рассматривалось как проявление непрофессионализма разработчиков. Однако в первой половине 1990-х гг.

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

• наличие в программе средств защиты от анализа заметно усложняет

отладку программы и тем самым снижает ее надежность.

Очевидно, что философский вопрос «Кто будет отлаживать защиту

от отладки?» не имеет удовлетворительного ответа;

• защита от анализа может давать ложные срабатывания при запуске

защищенной программы в необычной программноаппаратной

среде: на новой модели процессора, в новой версии

операционной системы, в эмуляторе и т.п. Многим памятна

история о том, как с появлением процессора Pentium I около половины программ, защищенных от анализа, стали обнаруживать

отладчик при любом запуске на этом процессоре;

• механизмы юридической защиты авторских прав за прошедшие годы

сильно усовершенствовались. Для большинства программ необходимость

в защите от анализа программными средствами отпала;

• операционная система реального режима MS-DOS стала вытесняться

операционными системами защищенного режима Windows,

OS/2 и UNIX, в которых защита от анализа реализуется заметно

сложнее.

Сейчас защита от анализа включается в программы довольно

редко, в основном в следующие виды программного обеспечения:

• программы, оснащенные защитой от несанкционированного

копирования, — обычно очень дорогие программы либо программы,

предназначенные для обработки строго конфиденциальной

информации;

• программные закладки, в том числе и компьютерные вирусы.

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

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

До 40 % пользователей программ, защищенных с помощью StarForce, испытывают те или иные проблемы, связанные с системой защиты от копирования [20]. Автору лично приходилось неоднократно сталкиваться с ситуациями, когда лицензионная компьютерная игра, оснащенная защитой StarForce, воспринимает себя как контрафактную копию и отказывается запускаться. Кроме того, некоторые источники

[25] отмечают наличие до августа 2006 г. программных уязвимостей StarForce, позволяющих непривилегированному пользователю несанкционированно получать административные полномочия в операционной системе. Интересно, что CNET начиная с 2006 г. Классифицирует StarForce как вредоносное программное обеспечение.

Существуют специальные программные средства StarFuck и StarForce Nightmare, отключающие защиту от копирования StarForce. Известныи методы обхода некоторых систем StarForce, не использующие специально разработанное программное обеспечение, а использующие лишь широко распространенные программные продукты Alcohol 120 % и Daemon Tools [23].

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

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

1. Встроенная защита. Средства защиты от анализа включаются

непосредственно в исходный текст программы в ходе ее разработки.

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

практически непробиваемую за приемлемое время. С другой стороны,

проектирование и кодирование встроенной защиты весьма трудоемко

и сильно затрудняет отладку и сопровождение программного продукта.

2. Пристыковочная защита. Средства защиты от анализа пристыковываются

к готовому программному модулю с использованием

«вирусных» алгоритмов уже после компиляции модуля. В этом случае

защита от анализа не оказывает никакого влияния на отладку и сопровождение

программного продукта. Разработка защитных функций

выполняется отдельной группой программистов, никак не связанной

с программистами, разрабатывающими основную функциональность

защищаемого продукта. Часто создание пристыковочной защиты от

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

на создании пристыковочных защит, например упомянутая

выше StarForce. Если к мощности защиты от анализа не предъявляются

повышенные требования, то для защиты программы может

быть применена типовая система, ранее разработанная для другого

программного продукта или вообще универсальная, способная пристыковаться

практически к любому программному модулю заданного

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

сделана очень мощной — как только аналитик сумеет «прорваться»

через барьер, создаваемый пристыковочной защитой, дальнейший

анализ программы не вызывает никаких проблем.

Далее мы рассмотрим типовые методы защиты программ от анализа. Сразу отметим, что ни один из этих методов, примененный по отдельности, не дает заметного эффекта. Для построения по-настоящему мощной защиты следует применить в одной программе не

менее 10 —15 различных методов защиты от анализа. Классифицировать методы защиты от анализа весьма сложно. Существующие классификации имеют множество недостатков и в настоящем пособии мы не будем пытаться строить стройную классификацию, а просто перечислим методы подряд, в более-менее произвольном порядке.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]