Тестирование защиты
Очень важно провести некоторое тестирование после установки навесной защиты. Суть тестирования заключается, прежде всего, в проверке полной работоспособности программы. После этой стадии также необходимо в некоторой мере протестировать защиту на соответствие уровню. Иначе говоря, стоит немного времени пожить в шкуре злоумышленника и попытаться всеми доступными средствами снять протектор. Как минимум, защита хотя бы должна быть стойкой к различным автоматическим распаковщикам. К универсальным распаковщикам пакеров и некоторых протекторов класса low end можно отнести GenericUnpacker и Quick Unpack. Следовательно, стоит попытаться снять защиту с помощью данных утилит, но с действительно хорошими протекторами типа Armadillo, ASProtect, Obsidium и др. можно и не пытаться сделать это, так как все равно ничего хорошего не получится.
Многие протекторы используют защиту таблицы импорта в файле, так что можно использовать программу Import REConstructor для ее восстановления, а также трейсер для ее нахождения. Если после всех этих операций импорт оказался восстановленным до первоначального состояния, можно судить о том, насколько крута выбранная защита.
Неплохо также проверить криптор в режиме отладки, дабы убедиться в работоспособности его антиотладочных премудростей, а те, кто знаком с принципами взлома приложений, могут пойти дальше и попробовать распаковать программу вручную.
Контрольные вопросы
1. Для чего предназначены пакеры? Чем они отличаются от архиваторов?
2. Какие действия над исполняемыми файлами выполняет протектор?
3. Какие способы защиты может применять протектор?
4. Для чего предназначен и какие возможности есть у инструмента ASProtect?
5. Какие достоинства есть у ASProtect?
6. Для чего предназначен и какие возможности есть у инструмента Obsidium?
7. Для чего предназначен и какие возможности есть у инструмента Armadillo?
8. Какой принцип работы применяется в Armadillo? Какую технологию работы с памятью использует Armadillo, в чем ее суть?
9. Какой основной недостаток у инструмента Armadillo?
10. Для чего предназначен и какие возможности есть у инструмента ORiEN? В чем заключается особенность работы данного инструмента?
11. Какие действия производят в рамках тестирования защиты?
Лекция 22
ТЕМА: Автоматизация процесса сборки проекта.
Литература: 1. Осипов Д. Delphi XE2.
2. http://www.finalbuilder.com.
Определение: Автоматизация сборки –это этап написания скриптов или автоматизация широкого спектра задач применительно к программному обеспечению, используемому разработчиками в их повседневной деятельности, включая такие действия, как:
· компиляция исходного кода в бинарный код;
· сборка бинарного кода;
· выполнение тестов;
· разворачивание программы на производственной платформе;
· написание сопроводительной документации или описание изменений новой версии.
Например, раз в неделю может выполняться следующая последовательность действий:
· создание и сохранение резервных копий (backup);
· сборка проекта в Release конфигурации;
· обновление и компиляция языковых файлов;
· разнесение собранных файлов в нужные директории;
· защита проекта ASProtect‘ом;
· обновление скриптов инсталляции;
· сборка инсталляции;
· загрузка файлов в хранилище;
· рассылка уведомлений.
В последние годы решения по управлению сборкой сделали еще более удобным и управляемым процесс автоматизированной сборки. Для выполнения автоматизированной сборки и контроля этого процесса существуют как коммерческие, так и открытые решения. Некоторые решения нацелены на автоматизацию шагов до и после вызова сборочных скриптов, а другие выходят за рамки действий до и после обработки скриптов и полностью автоматизируют процесс компиляции и линковки, избавляя от ручного написания скриптов. Такие инструменты чрезвычайно полезны для непрерывной интеграции, когда требуются частые вызовы компиляции и обработка промежуточных сборок.
Продвинутая автоматизация сборки предоставляет возможность удаленному пользователю управлять обработкой распределенных сборок или распределенной обработкой сборки.
Термин «распределенные сборки» подразумевает, что вызовы компилятора и линковщика могут передаваться множеству компьютеров для ускорения скорости сборки.
Распределенная обработка означает, что каждый этап процесса может быть адресован разным машинам для выполнения ими данного шага. Например, этап после сборки может потребовать выполнения множества тестовых скриптов на множестве машин. Распределенная обработка позволяет послать команду на исполнение различных тестовых скриптов на разных машинах. Распределенная обработка не может взять скрипты от make или maven, разбить их и послать команды на компиляцию и линковку различным машинам. Распределенный процесс сборки должен обладать определенной логикой, чтобы правильно определить зависимости в исходном коде для того чтобы выполнить этапы компиляции и линковки на разных машинах. Решение автоматизации сборки должно быть способно управлять этими зависимостями, чтобы выполнять распределенные сборки. Некоторые инструменты сборки могут распознавать подобные взаимосвязи автоматически (Rational ClearMake distributed), а другие зависят от пользовательских указаний (Platform LSF lsmake). Автоматизация сборки, способная рассортировывать взаимосвязи зависимостей исходного кода, также может быть настроена на выполнение действий компиляции и линковки в режиме параллельного выполнения. Это означает, что компиляторы и линковщики могут быть вызваны в многопоточном режиме на машине, сконфигурированной с учетом наличия более одного процессорного ядра.
Не все инструменты автоматизации сборки могут выполнять распределенные сборки. Большинство из них лишь реализует поддержку распределенной обработки. Кроме того, большинство решений, поддерживающих распределенные сборки, могут лишь обрабатывать код на языках Си и C++. Решения автоматизации сборки, поддерживающие распределенную обработку, зачастую основаны на Make и не поддерживают Maven или Ant.
В качестве примера решения распределенной сборки можно привести Xoreax’s IncrediBuild для платформы Microsoft Visual Studio. Это может потребовать специфической настройки программного окружения, чтобы успешно функционировать на распределенной платформе (нужно указать расположение библиотек, переменные окружения и т. д.).
Преимущества автоматизации сборки:
· улучшение качества продукта;
· ускорение процесса компиляции и линковки;
· избавление от излишних действий;
· минимизация «плохих (некорректных) сборок»;
· избавление от привязки к конкретному человеку;
· ведение истории сборок и релизов для разбора выпусков;
· экономия времени и денег благодаря причинам, указанным выше.
Типыавтоматизации сборок:
· автоматизация по запросу (On-Demand automation): запуск пользователем скрипта в командной строке;
· запланированная автоматизация (Scheduled automation): непрерывная интеграция, происходящая в виде ночных сборок;
· условнаяавтоматизация (Triggered automation): непрерывная интеграция, выполняющая сборку при каждом подтверждении изменения кода (commit) в системе управления версиями.
Одна из особых форм автоматизации сборки – автоматическое создание make-файлов (makefiles). Эти файлы совместимы с такими инструментами как:
· GNU Automake;
· CMake;
· imake;
· qmake;
· nmake;
· wmake;
· Apache Ant;
· Apache Maven;
· OpenMake Meister.
Дата добавления: 2015-09-07; просмотров: 933;