среда, 1 сентября 2010 г.

Упаковщики, крипторы, протекторы

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



Прежде чем разрабатывать новый защитный софт нужно  учитывать очень много нюансов, вот два из них:
  • Защищенный софт вашим поделием могут детектировать антивирусы;
  • Обработанные файлы должны иметь возможность работать не привязываясь исключительно к одной версии системы;
Хотел бы остановиться прежде всего на детктировании антивирусами. Почему в одних случаях антивирус вдруг начинает ругаться, а в совершенно такой же ситуации без какой-то там "мелочи", вдруг говорит что это зловред?

Дело в том что, закриптованное\упакованное\запротекченное приложение для специалистов антивирусных компаний попадает в одну и туже категорию, которую условно называеют "packed objects" и логично, ведь антивирусный продукт не знает, что этот файл упакован, а не запротекчен, другими словами продукт не может знать цели обработки файла! Это может озвучить только человек, поиследовав файл. Именно по этой причине все обработанный файлы и не похожие на стандартные попадают в одну "свалку" называемую "packed objects".

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

После выявления факта "обработанности" и соотнесения его в группу пакованных объектов, можно выявить "нелегальные" действия, которые "честный" протектор либо не позволит себе, либо применит в случае крайней нужды. Какие действия можно считать "не легальными" ?
  • На точке входа "анти-дебаг" или "анти-дизасм" или какой-либо трюк, т.к. это потенциальный кандидат в "анти-эмуляционные" трюки;
  • На упакованные файлы несложно создать сигнатуру, в плоть до статической! Ведь автор настолько умен, что создал неломаемый для реверса прот и ему не зачем от кого-то прятаться! Да и в следующем билде прота, многое поменяется, смысл прятаться?
  • В стабе нет кода работающего со спецификой системы, к примеру с полями PEB, значения регистров на старте. Потому что это недокументированности, как вывод есть вероятность, что не будет работать на другой версии системы. А автор между прочим стремится к стабильной работе на множестве систем!
Советы при построении стаба:
  • Не применять сложный код мешающий наложить сигнатуру, аверам будет влом и они задетектят, а вы в очередной раз будет рвать волосы с криками "ааа, они там все ламеры, опять...". Лучше потратьте силы на разработку виртуализации кода, чем на "недетектируемость".
  • Откажитесь от использования каких-либо "громоздких" циклов на точке входа и применения всяческих недокументированностей!
  • Используйте GetProcAddress вместо того чтобы искать самому, сложность реверса заключается в отнюдь не в получении ответа "Да как же это он апи-шки то находит?", отнюдь! Эмуляция "GetProcAddress" это вчерашний день! Сегодня может служить, только "довеском", лучше улучшайте виртуализацию кода, детект виртуальных машин, ну и сохранение результатов того же GetProcAddress черт знает куда и др. вещи;

Комментариев нет: