26.02.2013

»деи продвинутого шифровани€ исполн€емых файлов .NET в реальном времени

image

ƒинамический шифратор (runtime-cryptor) шифрует двоичные исполн€емые файлы с сохранением их функциональности. ѕри запуске сначала расшифровываетс€ тело файла, а затем исполн€етс€ код. “акой подход позвол€ет запускать вредоносные программы в защищенных средах и затрудн€ет детектирование по сигнатуре и блокирование подозрительных файлов антивирусными средствами.

јвтор:  ристиан јмманн (Christian Ammann)

1 ¬ведение

ƒинамический шифратор (runtime-cryptor) шифрует двоичные исполн€емые файлы с сохранением их функциональности. ѕри запуске сначала расшифровываетс€ тело файла, а затем исполн€етс€ код. “акой подход позвол€ет запускать вредоносные программы в защищенных средах и затрудн€ет детектирование по сигнатуре и блокирование подозрительных файлов антивирусными средствами. «ашифрованна€ копи€ содержит неизвестную сигнатуру и не может быть исследована при помощи эвристического анализа, тем самым остава€сь незаметной дл€ антивируса.

¬ последнем документе [1] изложены теоретические аспекты шифровани€ в реальном времени (runtime encryption) PE-заголовка [2] и продемонстрирована базова€ реализаци€ PE-шифратора √иперион (Hyperion). √иперион генерирует случайный ключ и использует этот ключ дл€ шифровани€ входного файла с использованием алгоритма AES-128 [3]. ѕри запуске файла происходит его расшифровка путем подбора (bruteforcing) нужного ключа. AES-ключ не содержитс€ внутри шифрованного файла, что затрудн€ет детектирование зашифрованной области антивирусными средствами. ќднако основна€ задача еще не решена: √иперион шифрует лишь стандартные PE-файлы (regular portable executables) и не поддерживает байт-код, который используетс€ Microsoft в приложени€х, написанных на C# [5], J# [6] и Visual Basic [7].

¬ этом документе рассказываютс€ аспекты шифровани€ в реальном времени дл€ платформы .NET и представл€етс€ пилотна€ верси€ дл€ шифратора √иперион. —труктура документа: ¬ разделе 2 описываютс€ основы формата исполн€емых файлов платформы .NET и интеграци€ таких файлов в стандартные PE-файлы. ¬ разделе 3 рассматриваетс€ возможность реализации шифровани€ в реальном времени дл€ NET-приложений. ¬ разделе 3.1 в √иперион добавл€етс€ поддержка шифровани€ в реальном времени и исследуютс€ вопросы реверс-инжиниринга (reverse engineering)DLL-библиотек. ƒаже когда √иперион загрузил дешифрованный файл в пам€ть, среда выполнени€ .NET считывает заголовочную информацию из соответствующего образа диска, но поскольку образ зашифрован, среда выполнени€ аварийно завершает свою работу. ¬ разделе 3.2 мы решим эту проблему, путем частичного шифровани€ NET-файлов и представим пилотную реализацию. Ќекоторые продвинутые техники шифровани€ NET-приложений в реальном времени описываютс€ в разделе 4.

2 ‘ормат исполн€емых приложений платформы .NET

ƒанный раздел описывает формат NET-приложений и механизм их загрузки/запуска в оперативной пам€ти. .NET framework – это платформа, созданна€ компанией Microsoft, позвол€юща€ разрабатывать и запускать программные приложени€. ¬ отличие от других €зыков, например C, компил€тор .NET не создает собственного машинного кода (native code), а преобразует исходник в байт-код, который называетс€ Common Intermediate Language (CIL). ¬добавок к этому среда Common Language Runtime (CLR) €вл€етс€ частью платформы .NET framework и функционирует в качестве среды исполнени€. ѕри запуске CIL-файл передаетс€ в среду CLR, котора€ трансформирует его байт-код в собственные машинные инструкции и запускает соответствующее приложение. “акже существует возможность преобразовани€ NET-исходника в собственный машинный код при помощи Native Image Generator (NGEN).

ѕлатформа .NET была разработана компанией Microsoft дл€ операционной системы Windows. —оответственно, код NET-приложений встроен в стандартные PE-файлы, которые имеют следующий формат:

Ќаименование

—одержание

MZ-заглушка

MSDOS-заголовок, MSDOS-заглушка, указатель на Image FileHeader

ћагическое PE-значение

—игнатура

Image File Header

–азмер опционального заголовка, количество секций

Image Optional Header

јдрес точки входа, база образа, размер образа

Data Directories

”казатели на таблицы импорта и экспорта

“аблица секций

—писок заголовков секций

—екции

—екции .code, .data и т. д.

 ак и стандартные PE-файлы, NET-приложени€ содержат MZ-заглушку, Image File Header, Image Optional Header, Dada Directory и соответствующие секции. ƒетальное описание этих терминов выходит за рамки данной статьи. — более подробным объ€снением этих пон€тий вы можете ознакомитьс€ в документах [1] и [2]. ѕри открытии NET-приложени€ в PE-редакторе (например, вLord PE) [8], можно увидеть следующую структуру:

  • —екци€ .text, содержащую таблицу импорта (import table), таблицу импортируемых адресов (import address table) и CIL-код.
  • —екци€ .rsrc, содержащую иконку файла (file icon).
  • —екцию .reloc, содержащую таблицу релокаций (relocation table). ¬ этой таблице хранитс€ только одна запись, инструкци€ точки входа (entry point instruction).

ѕри запуске NET-приложение загружаетс€ в пам€ть как обычный исполн€емый файл.  огда процесс загрузки окончен, адреса секций преобразуютс€ к виртуальным адресам, и PE-загрузчик определ€ет, содержит ли файл собственный машинный код или CIL-код. ≈сли файл содержит собственный машинный код, тогда загрузчик переходит к точке входа и далее приложение исполн€етс€ процессором. ¬ случае с CIL-кодом управление передаетс€ среде CLR. “аким образом, массив указателей (data directory) каждого PE-файла содержит запись заголовка среды исполнени€ CLR (CLR Runtime Header), при помощи которого можно отличить стандартный исполн€емый файл от NET-приложени€. ≈сли файл содержит байт-код CIL, тогда в секции CLRRuntime Header присутствует указатель на CIL-заголовок. ¬ случае стандартного исполн€емого файла этот указатель равен 0.

¬ спецификации PE-формата секци€ CLR Runtime Header описываетс€ так: недокументированный формат метаданных, который может использоватьс€ CLR-интерфейсами дл€ обработки метаданных.   счастью, это утверждение потер€ло смысл, после того, как Microsoft обнародовал спецификации дл€ CIL и CLR [9]. ¬добавок к этому, компани€ Microsoft представила Shared SourceCommon Language Infrastructure (SSCLI), платформу .NET с открытым исходным кодом [10], котора€ написана на C++ и используетс€ разработчика дл€ изучени€ внутреннего устройства .NETframework. Ћицензи€ разрешает применение SSCLI только в учебных цел€х и запрещает ее коммерческое использование.

ќдин из наиболее интересных классов SSCLI Ц класс PEReader, который можно найти в соответствующей поддиректории: samples/utilities/getcliversion/pereader.cs. Ётот класс разбирает PE-заголовок входного файла, включа€ CIL-заголовок.  роме того, синтаксис и семантика формата .NET также прекрасно описана в статье ƒэниэла ѕистелли (Daniel Pistelli) [11]. —огласно этим ресурсам, NET-код, который содержитс€ в PE-файле в соответствующей записи data directory, имеет следующий формат:

  1. CIL-заголовок.
  2. CIL-код и ресурсы.
  3. «аголовок метаданных (MetaData header).
  4. ѕотоки (Streams).
  5. “аблицы метаданных (MetaData tables).

ќписание формата не €вл€етс€ полностью правильным, поскольку CIL-код не расположен между CIL-заголовком и заголовком метаданных. Ќа самом деле, это описание Ц результат практических исследований и анализа исполн€емых файлов .NET.  роме того, это лишь краткое введение в NET-компоненты. «а более подробной информацией обращайтесь к соответствующей литературе.

CIL-заголовок содержит базовое описание NET-файла. ¬ двух запис€х представлены предыдуща€/последующа€ версии среды выполнени€ (runtime environment version), которые необходимы дл€ запуска CIL-кода. “акже CIL-заголовок содержит указатели на секцию с NET-ресурсами и заголовок метаданных.

«аголовок метаданных содержит магическое число и, также как CIL-заголовок, хранит информацию о предыдущей/последующей версии среды выполнени€ (runtime version), которые, согласно [11], игнорируютс€ загрузчиком. ¬ажными элементами заголовка метаданных €вл€ютс€ заголовки потоков (stream headers).  аждый такой заголовок содержит им€, размер и смещение (offset). ѕо умолчанию в каждом NET-файле присутствую потоки Strings или Blob. ѕоток Strings содержит информацию о строках, а Blob Ц двоичные данные.

Ёлементы потоков Ц это ссылки на таблицы метаданных, которые €вл€ютс€ частью потока #~. “аким образом, формат NET-файлов, о котором рассказано выше, нуждаетс€ в корректировке: таблицы метаданных €вл€ютс€ частью секции потоков. ’очетс€ подчеркнуть, что семантика этого потока отличаетс€ от семантики остальных потоков и вынесена в дополнительный раздел. “аблицы метаданных содержат следующие элементы:

  • »мена классов, подклассов и т. п.
  • »мена переменных, типов и их начальные значени€.
  • »мена констант и их значени€.
  • »мена методов, параметры, тело метода, возвращаемые значени€ и т. п.

—ледующий пример демонстрирует взаимосв€зь CIL-кода, таблиц метаданных и потоков. ƒопустим, в NET-приложение объ€влена константа со значением 1.  роме того, там же присутствует класс B, в котором реализован метод c(). »дентификаторы a, B и c хран€тс€ в потоке Strings, а значение константы в потоке Blob. ¬ таблице метаданных хран€тс€ записи класса, константы и метода. ѕо сути, эти записи €вл€ютс€ ссылками на соответствующие элементы потока.   тому же, в таблице присутствует запись-ссылка на CIL-код, который запускаетс€ при вызове функции. ≈ще раз обращаем внимание на то, что это лишь краткое описание формата, и за более подробной информацией рекомендуем обратитьс€ к соответствующим источникам.

“еперь вам знакома структура NET-приложени€, котора€ встроена в структуру PE-файла. ќсталс€ еще один аспект, который не описан Ц запуск CIL-кода по его загрузке в оперативную пам€ть. ƒл€ этого загрузчик сначала провер€ет содержание ссылки на CIL-заголовок в data directory файла.  огда корректна€ ссылка найдена, в пам€ть загружаетс€ MsCorEE.dll, а затем вызываетс€ функци€ _CorValidateImage(). Ёта функци€ модифицирует PE-заголовок, перезаписыва€ точку входа. Ќова€ точка входа €вл€етс€ адресом функции _CorExeMain(), котора€ передает управление среде CLR.

3 Ўифрование NET-файлов в реальном времени

¬ предыдущем разделе описан формат NET-приложений и механизм их запуска. ¬ этом разделе будет рассмотрено два способа шифровани€ NET-файлов в реальном времени. ƒалее будет представлена базова€ реализаци€ шифратора √иперион и рассмотрена проблема механизма загрузки зашифрованного файла в пам€ть. «атем эта проблема будет решена и представлена пилотна€ верси€ шифратора, которую можно использовать дл€ реализации более изощренного алгоритма шифровани€ NET-файлов в реальном времени.

ƒл€ запуска процесса Windows-приложени€ используют функцию CreateProcess(). ќдин из параметров этой функции им€ запускаемого файла. — точки зрени€ шифратора такой механизм запуска имеет недостаток, поскольку файл должен быть расшифрован и сохранен на диске перед вызовом функции CreateProcess().   тому же, в √иперионе и ему подобных динамических шифраторах реализован собственный PE-загрузчик, который работает с оперативной пам€тью, а не образом диска.

CIL-код избавлен от подобных ограничений, поскольку может использовать возможности reflection в .NET framework. Reflection framework содержит перегруженную функцию Assembly.Load(), котора€ в качестве параметра может принимать как строку с именем NET-приложени€, так и массив байтов, содержащий образ NET-файла. “аким образом, в отличии стандартных Windows-приложений и функции CreateProcess(), CIL-код можно выполнить в другой NET-программе, напр€мую из пам€ти без переопределени€ PE-загрузчика.

ѕри помощи reflection API шифрование NET-приложений в реальном времени может быть реализовано следующим образом: динамический шифратор считывает входной файл, шифрует его, оставл€€ незашифрованную часть в виде исполн€емого файла загрузчика (dropper executable) (например, в качестве ресурса). ѕри запуске загрузчик расшифровывает основную программу в пам€ти и запускает ее при помощи функции Assembly.Load(). ƒанный механизм прост и пон€тен, но содержит следующие недостатки:

  • Assembly.Load() св€зана с CIL-кодом.
  • јнтивирус может легко обнаружить вызов функции Assembly.Load() и затем запустить эвристический анализ.

ƒл€ устранени€ этих недостатков, используетс€ еще один подход при реализации динамического шифратора. —огласно разделу 2, NET-файлы загружаютс€ в пам€ть подобно обычным PE-файлам, а затем запускаетс€ функци€ _CorExeMain(). ¬ соответствии с этим, √иперион можно модифицировать так: когда файл находитс€ в пам€ти, записи data directory могут быть проверены. ¬ случае обнаружени€ CIL-заголовка вызываетс€ функци€ _CorValidateImage(). ¬ конце концов, загрузчик переходит к функции _CorExeMain() и выполн€етс€ CIL-код. ‘ункции _CorExeMain() и _CorValidateImage() нужно динамически подгрузить, использу€ функцию GetProcAddress() и другие методы обфускации. ¬се это позволит создать эффективную защиту от детектировани€ исполн€емого файла антивирусными средствами.

3.1 √иперион 1.0 и платформа .NET

¬ предыдущем разделе было рассмотрено и проанализировано два подхода к созданию динамического шифратора. Ќа основе сделанных выводов, мы выбрали второй алгоритм, который будет реализован в √иперионе. Ѕазова€ верси€ шифратора работает так: сначала расшифровываетс€ основна€ часть программы путем подбора шифр-ключа, после чего расшифрованный файл загружаетс€ в пам€ть согласно содержанию PE-заголовков и заголовков секций. ¬ конце происходит переход к точке входа, и управление передаетс€ распакованному файлу.

–ис. 1. —ообщение об ошибке после распаковки файла.

—ледующий участок кода показывает, как √иперион переходит к точке входа после расшифровки файла:

01. ;...
02. mov edx,[image_base]
03. mov eax,[edx+IMAGE_DOS_HEADER.e_lfanew]
04. add eax,edx
05. add eax,4
06. ;image file header now in eax
07. add eax,sizeof.IMAGE_FILE_HEADER
08. mov eax,[eax+IMAGE_OPTIONAL_HEADER32.AddressOfEntryPoint]
09. add eax,[image_base]
10. ;entry point of original exe is now in eax
11. jmp eax

–ассмотрим листинг подробнее. Ѕазовый образ (base image) расшифрованного файла хранитс€ в регистре edx. ƒалее вычисл€етс€ и сохран€етс€ в регистре eax адрес PE-заголовка. PE-заголовок используетс€ дл€ получени€ опционального заголовка, который содержит соответствующую точку входа. ѕосле перехода к точке входа происходит запуск исполн€емого файла. ƒл€ NET-файлов вышеприведенный листинг добавл€етс€ небольша€ модификаци€: в строке 1 по€вл€етс€ функци€, котора€ получает в качестве параметра адрес загрузки расшифрованного файла и разбирает PE-заголовки дл€ получени€ массива указателей (data directory). ≈сли data directory содержит указатель на CIL-заголовок, вызываетс€ функци€ _CorValidateImage(), котора€ измен€ет адрес точки входа, и √иперион переходит к функции _CorExeMain().

“ака€ модификаци€ кода позвол€ет использовать шифрование в реальном времени дл€ NET-файлов. –езультаты тестировани€ простой реализации этого механизма (файл blah.exe) представлены на рис. 1, где видно сообщение об ошибке при попытке считать версию среды выполнени€. »нформаци€ о предыдущей/последующей версии среды выполнени€ содержитс€ в CIL-заголовке (см. главу 2).

ѕервое, что приходит на ум Ц в √иперионе произошла ошибка, и файл некорректно загрузилс€/расшифровалс€ в пам€ти. ѕосле анализа образа расшифрованного файла был сделан вывод, что загрузка и расшифровка произошла успешно. “аким образом, текуща€ ситуаци€ такова:

  • ѕоскольку файл был расшифрован, значит, NET-приложение работает корректно, и правильна€ рабоча€ верси€ доступна в системе.
  • ѕосле расшифровки файла, среда исполнени€ не может прочитать CIL-заголовок, даже в случае корректной загрузки файла в пам€ть.

ƒалее была запущена отладка зашифрованного файла с использованием Immunity [12] и точкой останова на функции _CorExeMain() (котора€ €вл€етс€ точкой входа среды CLR) и пошагово пройден файл. –езультаты отладки показаны на рис. 2 (выделено красным пр€моугольником).

–ис. 2. ѕроцесс отладки NET-приложени€.

CIL framework открывает файл при помощи CreateFileW(), обраща€сь к образу диска. “акое поведение странно, поскольку в нем нет необходимости, так как файл уже загружен в пам€ть PE-загрузчиком. ƒальнейшие исследовани€ вы€вили следующую картину:

  • ¬ызываютс€ функции CreateFileW, CreateFileMapping and MapViewOfFile() дл€ мапировани€ образа диска в пам€ть
  • ƒалее происходит разбор и обработка PE-заголовка файла образа диска

Ёта проблема возникла потому, что образ диска зашифрован. —реда CLR не может считать предыдущую/последующую версию среды выполнени€ в CLI-заголовке, и в √иперионе возникает ошибка при работе с исполн€емыми файлами .NET.

3.2 „астичное шифрование NET-файлов

»сследование в предыдущем разделе показало, что CIL framework обращаетс€ к файлу образа диска даже в том случае, когда файл уже загружен в пам€ть PE-загрузчиком. —ледовательно, при загрузке исполн€емых файлов NET, зашифрованных √иперионом, возникает ошибка, поскольку среда CLR не может считать CIL-заголовок. ¬ этом разделе будет представлена пилотна€ реализаци€ шифровани€ в режиме реального времени дл€ NET-приложений, где CLI-заголовок остаетс€ незашифрованным. Ќовый метод шифровани€ разделен на две части:

  • Ўифровщик: шифруетс€ только CIL-код; PE-заголовок, CIL-заголовок и метаданные остаютс€ нетронутыми.
  • «агрузчик: стартует зашифрованный файл при помощи функции CreateProcess(). √лавный поток находитс€ в состо€нии ожидани€. «агрузчик расшифровывает CIL-код и возвращаетс€ в главный поток.

—амо собой, при такой реализации приложение не защищено от статического анализа антивирусами, поскольку остаютс€ незашифрованные места. ¬ разделе 4 будет реализовано расширение дл€ √ипериона, которое будет шифровать все NET-файлы.

3.2.1 Ўифровщик

Ќа входе шифровщик получает входной файл и копирует его в пам€ть. ƒалее происходит разбор заголовков файла, чтобы определить местонахождение CIL-кода и зашифровать его.

 аждый PE-файл начинаетс€ с MZ-заголовка, содержащего указатель на заголовок COFF. –азмер заголовка COFF €вл€етс€ посто€нным, за ним следуют опциональные стандартные заголовки (optional standard headers) и windows-заголовки (optional windows headers), которые также фиксированного размера. ѕосле опциональных windows-заголовков находитс€ data directory, размер которого определ€етс€ переменной NumberOfRvaAndSizes, €вл€ющейс€ элементом опционального windows-заголовка. ѕоскольку размер data directory может быть равным нулю, рекомендуетс€ высчитывать размер опционального заголовка через переменную SizeOfOptionalHeader, а не обращатьс€ к переменной NumberOfRvaAndSizes. Data directory представл€ет из себ€ массив структурImageDataDirectory:

01. struct ImageDataDirectory f
02. uint32_t VirtualAddress;
03. uint32_t Size;
04. g;

 ажда€ запись содержит относительный виртуальный адрес (relative virtual address, rva) и относительный адрес. ≈сли rva равен нулю, то эта запись не используетс€ в PE-файле. —ледующий код провер€ет присутствие в файле CIL-кода:

01. ImageCor20Header* rva_cil_header = (ImageCor20Header*)
02. data_directory [CLR_RUNTIME_HEADER]).VirtualAddress;
03.
04. if(rva_cil_header==0)f
05. printf("no clr runtime header found");
06. return false;
07. g

CIL-заголовок представлен структурой ImageCor20Header, котора€ имеет такой формат:

01. struct ImageCor20Header
02. f
03. uint32_t cb;
04. uint16_t MajorRuntimeVersion;
05. uint16_t MinorRuntimeVersion;
06. struct ImageDataDirectory MetaData;
07. uint32_t Flags;
08. uint32_t EntryPoint;
09. struct ImageDataDirectory Resources;
10. struct ImageDataDirectory StrongNameSignature;
11. struct ImageDataDirectory CodeManagerTable;
12. struct ImageDataDirectory VTableFixups;
13. struct ImageDataDirectory ExportAddressTableJumps;
14. struct ImageDataDirectory ManagedNativeHeader;
15. g;

ƒл€ реализации шифровщика важным элементом €вл€етс€ указатель на метаданные, представленный структурой ImageDataDirectory.  ак только получен CIL-заголовок, шифровщик считывает следующую информацию:

  • –азмер и относительный адрес CIL-заголовка.
  • –азмер и относительный адрес заголовка метаданных.

—огласно спецификации формата .NET, описанной в главе 2, CIL-код находитс€ между CIL-заголовком и заголовком метаданных. »сход€ из полученных данных, шифровщик высчитывает смещение (offset) CIL-кода и производит простое XOR-шифрование.

«десь упущен один аспект: входной файл смапирован в пам€ть по определенному адресу загрузки (image base). «аголовки PE-файлов содержат указатели, €вл€ющие относительными виртуальными адресами (rva). Rva должен быть трансформирован в соответствующий физический адрес (raw address), после чего будет доступна запись и чтение данных. ƒл€ преобразовани€ адреса используетс€ функци€:

01. unsigned char* rvaToOffset(unsigned char* base,

02. struct SectionHeader* sections,
03. uint16_t sections_size, uint32_t rva)
04. f
05. unsigned char* ret = 0;
06. for(int i=0;i<sections_size;i++)f
07. if(rva >= sections[i].VirtualAddress &&
08. rva < sections[i].VirtualAddress + sections[i].VirtualSize)f
09. ret = base + sections[i].PointerToRawData +
10. (rva - sections[i].VirtualAddress);
11. g
12. g
13. return ret;
14. g

ћетод rvaToOffset() на входе получает следующие параметры: адрес загрузки файла в пам€ть, указатель на секцию заголовков, число секций заголовков и относительный адрес, который необходимо преобразовать. ¬ начале работы происходит поиск секции, содержащей относительный виртуальный адрес. ƒалее к адресу загрузки файла добавл€етс€ смещение секцииPointerToRawData и разность между относительным виртуальным адресом и виртуальным адресом секции VirtualAddress, а затем возвращаетс€ итоговое значение преобразованного адреса.

3.2.2 «агрузчик

¬ предыдущем разделе был рассмотрен процесс шифровки CIL-кода NET-приложени€. «агрузчик запускает зашифрованный файл, использу€ метод CreateProcess(). ѕри этом главный поток приостанавливаетс€. ѕосле дешифровки CIL-кода загрузчик вновь возвращаетс€ в главный поток.

01. STARTUPINFOA startupinfo;
02. memset(&startupinfo, 0, sizeof(startupinfo));
03. startupinfo.cb = sizeof(STARTUPINFOA);
04. PROCESS_INFORMATION process_information;
05. memset(&process_information, 0, sizeof(process_information));
06. CreateProcessA(application_name_and_path, 0, 0, 0,
07. false, NORMAL_PRIORITY_CLASS | CREATE_SUSPENDED, 0, 0, &startupinfo,
08. &process_information);

ћетод CreateProcess() использует две структуры: STARTUPINFO и PROCESS INFORMATION. ¬ вышеприведенном листинге сначала обе структуры инициализированы нулевыми байтами, а затем CreateProcess() запускает приложение. »нформаци€ о созданном процессе хранитс€ в структуре process_information. CIL-код расшифровываетс€ при помощи следующего алгоритма:

  • ћетод VirtualProtectEx() делает участок пам€ти процесса доступной дл€ записи
  • ћетод ReadProcessMemory() копирует участок пам€ть процесса в буфер. “уда же попадает выше заполненна€ структура process_information
  • ƒешифруетс€ CIL-код
  • ќбновленный буфер копируетс€ обратно в пам€ть процесса с использованием метода WriteProcessMemory()
  • VirtualProtectEx() восстанавливает прежние атрибуты участка пам€ти процесса

ѕосле отработки алгоритма загрузчик возвращаетс€ в потом, использу€ конструкцию ResumeThread(process information.hThread);.

4 «аключение и направление дальнейшей работы

¬ этой статье описываетс€ формат NET-файлов. «атем реализуетс€ шифратор √иперион, в котором реализовано шифрование NET-файлов в реальном времени. “акой подход не годитс€, поскольку среда исполнени€ .NET аварийно завершает работу, поскольку обращаетс€ к образу диска и не может считать версию среды выполнени€. ƒалее алгоритм работы был модифицирован. —тал шифроватьс€ лишь CIL-код, а CIL-заголовок и метаданные остались нетронутыми.

’от€ така€ реализаци€ может использоватьс€ дл€ шифровани€ .NET файлов в реальном времени, у нее есть несколько недостатков:

  • »спользуетс€ простое XOR-шифрование, в то врем€ как √иперион может использовать алгоритм AES-128.
  • Ўифруетс€ только CIL-код, а заголовок и метаданные остаютс€ у€звимыми дл€ статического анализа антивирусными средствами.

¬ дальнейшем функционал шифровщика будет доработан, и √иперион сможет шифровать все NET-файлы по следующему алгоритму: сначала происходит перехват (hook) методов CreateFileW(),CreateFileMapping() and MapViewOfFile() в модуле kernel32.dll. ѕерехватчик провер€ет, пытаетс€ ли среда исполнени€ обратитьс€ к файлу образа диска. ≈сли такое происходит, тогда возвращаетс€ указатель образа ранее дешифрованного файла и среда CLR получает доступ к CIL-заголовку. Ёто решает проблему, описанную в разделе 3.1, что позвол€ет полностью зашифровать NET-файлы.

5 Ѕлагодарности

ћы хотим выразить благодарность  рису  аулингу (Chris Cowling), яну  висту (Ian Qvist) и “омасу ѕедерсену (Thomas Pedersen) за помощь при работе над данной статьей.  роме того, мы хотим сказать спасибо всей команде Nullsecurity за плодотворные беседы и (что более важно) за прекрасную вечеринку на Berlin-Sides 2012.

Ћицензи€

»деи продвинутого шифровани€ в реальном времени исполн€емых файлов .NET  ристиана јмманна распростран€ютс€ под лицензией Creative Commons Attribution 3.0 Unported License. ѕодробности см. здесь: http://creativecommons.org/licenses/by/3.0/ for details.

—сылки

[1] Christian Ammann. Hyperion: Implementation of a PE-Crypter. http://nullsecurity.net/papers/nullsec-pe-crypter.pdf.

[2] Microsoft Cooperation. Microsoft PE and COFF Specification. http://msdn.microsoft.com/en-us/windows/hardware/gg463119.aspx.

[3] Information Technology Laboratory (National Institute of Standards and Technology). Announcing

the Advanced Encryption Standard (AES) [electronic resource]. Computer Security Division, Information Technology Laboratory, National Institute of Standards and Technology, Gaithersburg, MD :, 2001.

[4] Microsoft Cooperation. The .NET Framework. http://www.microsoft.com/net.

[5] Microsoft Cooperation. C# Programming Guide. http://msdn.microsoft.com/en-us/library/67ef8sbd.aspx.

[6] Microsoft Cooperation. J-Sharp. http://msdn.microsoft.com/en-us/vstudio/bb188593.

[7] Microsoft Cooperation. Visual Basic. http://msdn.microsoft.com/en-us/vstudio/hh388568.aspx.

[8] y0da. Lord PE. http://www.woodmann.com/collaborative/tools/index.php/LordPE.

[9] Microsoft Cooperation. Standard ECMA-335 - Common Language Infrastructure (CLI).

http://www.ecma-international.org/publications/standards/Ecma-335.htm.

[10] Microsoft Cooperation. Shared Source Common Language Infrastructure. http://www.microsoft.com/en-us/download/details.aspx?id=4917.

[11] Daniel Pistelli. The .NET File Format. http://www.codeproject.com/Articles/12585/The-NET-File-Format.

[12] Immunity Inc. Immunity Debugger. https://www.immunityinc.com/products-immdbg.shtml.

или введите им€

CAPTCHA
MyVery$elf
28-02-2013 13:06:27
¬серавно пал€т. «апускают в виртуалке, но пал€т. ќт какого нить стиллера закриптованого приходит отчет из виртуальной машины, но тотже нод32 визжит когда распакует. “ут как вариант можно использовать можно использовать "лишние" данные безобидного содержани€ дл€ запуска в "песочнице".
0 |