[0x0000]Предисловие
[0x0001] Введение и инструментарий
IDE
Языки программирования
C
C++
Пару слов о других языках
Об ООП
Реверс-инжиниринг и ассембл
Дизассембле
IDA
radare2/Cutt
Ghidra
Дебаггеры
OllyDbg
x64dbg
WinDbg
Ассемблер
FASM
Вставки
Прочее
WinAPI & NTAPI
WinAPI
NTAPI
В чем различие?
Виртуальные машины
VirtualBox
[0x0010] Присуще малвари
Пару слов о составляющей системы
Перзистентность
Инжект
DLL-Injection
Reflective
DLL-Injection
PE-Injection
SetWindowsHookEx
WinAPI Callback Injection
Process Hollowing
No Injection No Allocation
Шеллкодинг
Антиотладка
IsDebuggerPresent
TLS Callbacks
NtGlobalFlags
ForceFlags & Flags
DR0 – DR7
NtSetInformationThread
Антивиртуализация / Антиэмуляция
Детект видеокарты/видеодрайвера
Детект процессов виртуалки
Ключи реестра
Обращаемся к I/O портам
О чем стоило упомянуть
[0x0100] Криптор
Понятие криптора
Логика и понятие стаба
Что делает криптор?
Полиморфизм, метаморфизм и пермутативность
[0x1000] Разное Криптография
[0xFFFF] Послесловие и материалы
[0x0001] Введение и инструментарий
IDE
Языки программирования
C
C++
Пару слов о других языках
Об ООП
Реверс-инжиниринг и ассембл
Дизассембле
IDA
radare2/Cutt
Ghidra
Дебаггеры
OllyDbg
x64dbg
WinDbg
Ассемблер
FASM
Вставки
Прочее
WinAPI & NTAPI
WinAPI
NTAPI
В чем различие?
Виртуальные машины
VirtualBox
[0x0010] Присуще малвари
Пару слов о составляющей системы
Перзистентность
Инжект
DLL-Injection
Reflective
DLL-Injection
PE-Injection
SetWindowsHookEx
WinAPI Callback Injection
Process Hollowing
No Injection No Allocation
Шеллкодинг
Антиотладка
IsDebuggerPresent
TLS Callbacks
NtGlobalFlags
ForceFlags & Flags
DR0 – DR7
NtSetInformationThread
Антивиртуализация / Антиэмуляция
Детект видеокарты/видеодрайвера
Детект процессов виртуалки
Ключи реестра
Обращаемся к I/O портам
О чем стоило упомянуть
[0x0100] Криптор
Понятие криптора
Логика и понятие стаба
Что делает криптор?
Полиморфизм, метаморфизм и пермутативность
[0x1000] Разное Криптография
[0xFFFF] Послесловие и материалы
Это своеобразный документ по миру андерграунда. В нем вы найдете некоторые полезные вещи, которые потом будете пытаться освоить сами, искать их в сети или на специализированных форумах. Это просто документ, который покажет вам, что необходимо в мире девиантной разработки, какие есть техники и прочее. С остальным вы вынужденны знакомиться сами. А я в свою очередь не хочу, чтоб вы ожидали многого от этого документа. Еще стоит сказать, что разработка малвари — то же самое программирование в обычном понимании. Мы задаем какой-либо алгоритм действий для выполнения наших потребностей. Есть и техники сугубо присуще малвари (и читам), о них тут будет рассказано.
Вы своевольны распространять этот материал. Только прошу, не ищите и не долбите меня по поводу того, что я что-то не упомянул. И так голова болит.
Ах, и помните, что в подобной деятельности — понятия морали не существует.
Посмотреть вложение 33803
Вы своевольны распространять этот материал. Только прошу, не ищите и не долбите меня по поводу того, что я что-то не упомянул. И так голова болит.
Ах, и помните, что в подобной деятельности — понятия морали не существует.
Посмотреть вложение 33803
IDE
Конечно же, нам понадобится среда разработки и компилятор, для выполнения и написания наших действий. Рассмотрим два интересных вариантов:
Visual Studio
Официальная среда разработки от Microsoft, поставляется уже с компилятором. Обычно, ее все и используют в «андерграунде», т.к тебе не нужно будет возиться с cmake и прочей билебердой. К сожалению, она достаточно тяжелая, так что у вас должно быть хотяб гигабайт 15-20 для ее установки (+ дополнительные пакеты для разработки). Да и в интерфейсе можно легко запутаться. Используется в основном для C, C++, C#. Кстати, персональный эдит - бесплатный
Clion
Среда разработки от JetBrains, хорошая и шустрая, позволяет выбирать компиляторы, но стоит денег (хотя, вы всегда можете ее спиратить). Не поставляет компилятор из «коробки», вам придется ставить его самому. Выбор из компиляторов сугубо личный, я вот MinGW люблю. Поддерживает Rust.
Языки программирования
Логично, что нам пригодится язык программирования. Поэтому, проведу краткий экскурс.
С
На мой взгляд — лучший выбор. Язык достаточно легок и прост, в свою очередь он также не наполнен различными фреймворками. Единственная тема, которая начнет вам доставлять — указатели, но тут нужна практика, чтоб понять их арифметику и работу.
Существует достаточно материала по сишечке, но сугубо мои рекомендации это: Керниган, Ритчи «C Programming Language» и одноименная книга от Стивена Прата. Разница в том, что в книгах описываются разные стандарты (авторы первой книги — создатели этого языка, кстати). Ну, и Прата все досконально объясняет, за что его тоже любят.
C++
Тоже хороший выбор, но стоит помнить, что плюсы это не С с классами, это множество различных библиотек и надстроек, ООП и прочее. Но он все также не плох! Только более трудный для изучения, так что если вы любите грызть гранит науки — вам его изучение понравится (нет).
По плюсам могу посоветовать книгу самого автора языка — Страуструпа. Ну и куда же без Прата? У него тоже есть книга по плюсам! Во как! Также есть различные курсы, от OTUS, к примеру, но я не знаю какие они по качеству. Так что вам придется самому искать сливы или покупать их.
Пару слов о других языках
Я привел выше два наиболее подходящих под тематику малвари. Писать малварь можно также на C# и Rust. По сути, эти языки также позволяют работать с системой, но уже не напрямую. Ну, и ожидайте соответствующий выхлоп от компиляторов в несколько мегабайт бинарник. Хотя, в том же Rust вы можете отключить STD, но я насколько понимаю, вам придется писать все с unsafe (а может и нет, не берусь говорить точно). На самом деле, выбор языка это дело ваше, я не вправе выбирать и настаивать за вас. Я просто привел два языка, наиболее подходящих для этого.
Об ООП
Иногда задаются вопросы об ООП на форумах. Выбор всегда за вами, но скажу сразу — я топлю за процедурность (тот же С). Я считаю, что ООП в разбираемой нами темой — не нужно. У нас напросто не будет таких моментов, где нам пригодятся понятия этой парадигмы (по крайней мере у меня таких моментов не было).
С другой стороны, если вам удобно работать с ООП — дерзайте. Ничего такого в этом нет.
Реверс-инжиниринг и ассемблер
Нет вы учить ассемблер не обязаны, он вам пригодиться буквально в паре случаев. К примеру — детект виртуальной машины. В большей мере вам придется реверсить, чтоб понимать, что происходит в вашей или (внезапно) чужой малвари.
Реверс-инжиниринг — это исследование ПО (и не только) на предмет недокументированных особенностей. Кратко — анализ. Из этого я хочу посоветовать вам Дениса Юричева «Реверс-Инжиниринг для начинающих», ее можно найти на libgen совершенно бесплатно. Ну, или поддержать автора — он крутой.
Дам совет — реверсить чужие, особенно сложные программы нет смысла. Для начала лучше реверсить свои и сравнивать дизассемблированные листинги с вашим кодом. Это будет хорошей практикой
Дизассемблеры
Для статического анализа нам понадобятся дизассемблеры. Я выделяю 3 из них, которыми сам пользуюсь.
IDA
Один из лучших дизассемблеров со своим декомпилятором. Единственная проблема — он платный, но вам тоже не помеха его спиратить при желании. Как и говорил, поставляется со своим закрытым декомпилятором. Достаточно удобный и понятный интерфейс, а также возможность разрабатывать и подключать плагины (пишутся на Python) сделают Иду вашим лучшим другом. Работает везде, даже с помощью Wine.
radare2/Cutter
Бесплатный и тоже хороший, его плюсом является открытый исходный код. Уступает по мощности Иде, но все же лучше, чем ничего. Кроссплатформенный. Если radare2 – это консольный вариант программы, то Cutter – фронтенд для radare2. Плюсом, в отличии от Иды будет являться поддержка различных декомпиляторов. Их конечно всего 3 (и то один у меня нормально не собирается), но кому не похуй? Ах, да, тоже поддерживает плагины, их не так много правда.
Ghidra
Нет, я не про торговую площадку наркотическими веществами. Я про вполне себе интересный дизассемблер. Он достаточно мощный и бесплатный, тоже может в поддержку плагинов. Но вот есть один маленький минус — он от NSA. Т.е мы уже не исключаем наличие анальных зондов от правительства США, так что все на страх и риск, ну и вашу совесть, наверное. Единственное, что мне в нем не нравится — неудобный интерфейс.
Дебаггеры
Неразлучная вещь любого реверсера для проведения динамического анализа. Выделю несколько буквально.
OllyDbg
Старая Олька, спросите любого крякера и он поделиться своими историями с ней! До сих пор хороша как для обучения, так и для реальной работы. Но уступает более современным дебаггерам.
Стоит отметить, что есть, ну как сказать, «надстройки» или очень похожие вещи на Olly, из таких мне пригляделся Immunity Debugger, но я им практически не пользовался, трудно будет выделить его как-то.
x64dbg
Современный и мощный дебаггер с возможностью подключения плагинов (Scylla включена). Есть возможность сохранять свои патчи для программ, что является несомненным плюсом. Так же есть два типа дебаггера — x32dbg и x64dbg (идут вместе), что позволяет дебажжить программы собранные на процессорах разных разрядностей. Посмотрите в его сторону обязательно!
WinDbg
Страшная вещь от Microsoft, но надо отдать должное — весьма мощная вещь. Позволяет дебажжить код на уровне исходного кода (а вам это пригодится, я уверяю), просматривать краш-дампы и еще кучу других вещей! Единственное, что я вам посоветую — найдите cheatsheet по командам.
Ассемблер
Как и говорил ранее — ассемблер вам пригодится только в весьма узких и спорных местах, где это необходимо. А, ну и шеллкодинг, там тоже пригодится. Вообще, есть несколько диалектов ассемблера: FASM, MASM, NASM и TASM. Чем они различаются — лучше гуглить вам самим, я не буду расписывать еще это на несколько страниц (да и есть шанс, что я упущу некоторые вещи). Я делал выбор в сторону FASM.
FASM
Наиболее удобный диалект ассемблера со своей IDE и документацией. Есть куча туториалов и видосов по нему. Но, чистые листинги вы будете писать от силы раза два, наверное. Весьма интереснее, практичнее и удобнее вещь следующая.
Вставки
Вставки позволяют вам работать с ассемблером в исходном коде, вот так к примеру:
Посмотреть вложение 33804
Правда, надо помнить, что каждый компилятор жрет вставки по разному (т.е могут быть разные объявления). Поэтому будьте аккуратны, если будете переходить с одного компилятора на другой.
Прочее
Вам могут пригодится различные hex-редакторы и сканеры. Из hex-редакторов могу посоветовать HxD и ImHex. Из сканеров либо PE scanner, либо DIE (Detect It Easy).
WinAPI & NTAPI
Было бы правильней разместить этот заголовок перед заголовком о реверс-инжиниринге и ассемблере, но да ладно. Тут мы поговорим о великих и ужасных.
WinAPI
Это основной API винды, знакомьтесь. Его все ненавидят и любят одновременно. Но это единственный нормальный метод взаимодействия с системой. По нему, как ни странно, не очень много интересного и годного материала, но он все же есть. Могу вам посоветовать Финогенова К.Г «Win32. Основы программирования», Джеффри Рихтера «Windows via C/C+ +» и Харта «Системное программирование в среде Windows». В некоторых есть задания для практики, но рекомендую просто практиковаться после каждой темы.
Вам придется работать с этим, вам некуда бежать.
NTAPI
Ну, его основная проблема — он до сих пор практически весь недокументированный. Но упоминания он достоин, так как рано или поздно вы с ним все равно столкнетесь. Есть несколько проектов, документирующие его функции, не все, конечно, но всё же.
В чем различие?
NTAPI существует с NT версий винды и как не парадоксально — даже сейчас винда живет и на нем тоже (к примеру NTOSKRNL.EXE). Поэтому, NTAPI расположен ближе к ядру, нежели WinAPI. Самыми близким к аппаратному уровню являются HAL и EFI функции, но это так, для справки. В принципе, что одно API, что другое меняются мало.
Виртуальные машины
Вы столкнетесь с ними по мере работы со своими проектами. Вам также придется и тестировать свои наработки на виртуальных машинах. Так как я с VMWare работал очень мало, расскажу о VirtualBox.
Virtual Box
Продукт от Oracle. Весьма себе хорошая вещь для новичка и не очень. Позволяет достаточно гибко настроить систему под себя и под ваши нужды. Позволяет создать динамический диск, а не только фиксированный, что очень удобно для машин с малым объемом памяти (у меня ноутбук с SSD на 500 гигабайт, вот так).
Конечно же, нам понадобится среда разработки и компилятор, для выполнения и написания наших действий. Рассмотрим два интересных вариантов:
Visual Studio
Официальная среда разработки от Microsoft, поставляется уже с компилятором. Обычно, ее все и используют в «андерграунде», т.к тебе не нужно будет возиться с cmake и прочей билебердой. К сожалению, она достаточно тяжелая, так что у вас должно быть хотяб гигабайт 15-20 для ее установки (+ дополнительные пакеты для разработки). Да и в интерфейсе можно легко запутаться. Используется в основном для C, C++, C#. Кстати, персональный эдит - бесплатный
Clion
Среда разработки от JetBrains, хорошая и шустрая, позволяет выбирать компиляторы, но стоит денег (хотя, вы всегда можете ее спиратить). Не поставляет компилятор из «коробки», вам придется ставить его самому. Выбор из компиляторов сугубо личный, я вот MinGW люблю. Поддерживает Rust.
Языки программирования
Логично, что нам пригодится язык программирования. Поэтому, проведу краткий экскурс.
С
На мой взгляд — лучший выбор. Язык достаточно легок и прост, в свою очередь он также не наполнен различными фреймворками. Единственная тема, которая начнет вам доставлять — указатели, но тут нужна практика, чтоб понять их арифметику и работу.
Существует достаточно материала по сишечке, но сугубо мои рекомендации это: Керниган, Ритчи «C Programming Language» и одноименная книга от Стивена Прата. Разница в том, что в книгах описываются разные стандарты (авторы первой книги — создатели этого языка, кстати). Ну, и Прата все досконально объясняет, за что его тоже любят.
C++
Тоже хороший выбор, но стоит помнить, что плюсы это не С с классами, это множество различных библиотек и надстроек, ООП и прочее. Но он все также не плох! Только более трудный для изучения, так что если вы любите грызть гранит науки — вам его изучение понравится (нет).
По плюсам могу посоветовать книгу самого автора языка — Страуструпа. Ну и куда же без Прата? У него тоже есть книга по плюсам! Во как! Также есть различные курсы, от OTUS, к примеру, но я не знаю какие они по качеству. Так что вам придется самому искать сливы или покупать их.
Пару слов о других языках
Я привел выше два наиболее подходящих под тематику малвари. Писать малварь можно также на C# и Rust. По сути, эти языки также позволяют работать с системой, но уже не напрямую. Ну, и ожидайте соответствующий выхлоп от компиляторов в несколько мегабайт бинарник. Хотя, в том же Rust вы можете отключить STD, но я насколько понимаю, вам придется писать все с unsafe (а может и нет, не берусь говорить точно). На самом деле, выбор языка это дело ваше, я не вправе выбирать и настаивать за вас. Я просто привел два языка, наиболее подходящих для этого.
Об ООП
Иногда задаются вопросы об ООП на форумах. Выбор всегда за вами, но скажу сразу — я топлю за процедурность (тот же С). Я считаю, что ООП в разбираемой нами темой — не нужно. У нас напросто не будет таких моментов, где нам пригодятся понятия этой парадигмы (по крайней мере у меня таких моментов не было).
С другой стороны, если вам удобно работать с ООП — дерзайте. Ничего такого в этом нет.
Реверс-инжиниринг и ассемблер
Нет вы учить ассемблер не обязаны, он вам пригодиться буквально в паре случаев. К примеру — детект виртуальной машины. В большей мере вам придется реверсить, чтоб понимать, что происходит в вашей или (внезапно) чужой малвари.
Реверс-инжиниринг — это исследование ПО (и не только) на предмет недокументированных особенностей. Кратко — анализ. Из этого я хочу посоветовать вам Дениса Юричева «Реверс-Инжиниринг для начинающих», ее можно найти на libgen совершенно бесплатно. Ну, или поддержать автора — он крутой.
Дам совет — реверсить чужие, особенно сложные программы нет смысла. Для начала лучше реверсить свои и сравнивать дизассемблированные листинги с вашим кодом. Это будет хорошей практикой
Дизассемблеры
Для статического анализа нам понадобятся дизассемблеры. Я выделяю 3 из них, которыми сам пользуюсь.
IDA
Один из лучших дизассемблеров со своим декомпилятором. Единственная проблема — он платный, но вам тоже не помеха его спиратить при желании. Как и говорил, поставляется со своим закрытым декомпилятором. Достаточно удобный и понятный интерфейс, а также возможность разрабатывать и подключать плагины (пишутся на Python) сделают Иду вашим лучшим другом. Работает везде, даже с помощью Wine.
radare2/Cutter
Бесплатный и тоже хороший, его плюсом является открытый исходный код. Уступает по мощности Иде, но все же лучше, чем ничего. Кроссплатформенный. Если radare2 – это консольный вариант программы, то Cutter – фронтенд для radare2. Плюсом, в отличии от Иды будет являться поддержка различных декомпиляторов. Их конечно всего 3 (и то один у меня нормально не собирается), но кому не похуй? Ах, да, тоже поддерживает плагины, их не так много правда.
Ghidra
Нет, я не про торговую площадку наркотическими веществами. Я про вполне себе интересный дизассемблер. Он достаточно мощный и бесплатный, тоже может в поддержку плагинов. Но вот есть один маленький минус — он от NSA. Т.е мы уже не исключаем наличие анальных зондов от правительства США, так что все на страх и риск, ну и вашу совесть, наверное. Единственное, что мне в нем не нравится — неудобный интерфейс.
Дебаггеры
Неразлучная вещь любого реверсера для проведения динамического анализа. Выделю несколько буквально.
OllyDbg
Старая Олька, спросите любого крякера и он поделиться своими историями с ней! До сих пор хороша как для обучения, так и для реальной работы. Но уступает более современным дебаггерам.
Стоит отметить, что есть, ну как сказать, «надстройки» или очень похожие вещи на Olly, из таких мне пригляделся Immunity Debugger, но я им практически не пользовался, трудно будет выделить его как-то.
x64dbg
Современный и мощный дебаггер с возможностью подключения плагинов (Scylla включена). Есть возможность сохранять свои патчи для программ, что является несомненным плюсом. Так же есть два типа дебаггера — x32dbg и x64dbg (идут вместе), что позволяет дебажжить программы собранные на процессорах разных разрядностей. Посмотрите в его сторону обязательно!
WinDbg
Страшная вещь от Microsoft, но надо отдать должное — весьма мощная вещь. Позволяет дебажжить код на уровне исходного кода (а вам это пригодится, я уверяю), просматривать краш-дампы и еще кучу других вещей! Единственное, что я вам посоветую — найдите cheatsheet по командам.
Ассемблер
Как и говорил ранее — ассемблер вам пригодится только в весьма узких и спорных местах, где это необходимо. А, ну и шеллкодинг, там тоже пригодится. Вообще, есть несколько диалектов ассемблера: FASM, MASM, NASM и TASM. Чем они различаются — лучше гуглить вам самим, я не буду расписывать еще это на несколько страниц (да и есть шанс, что я упущу некоторые вещи). Я делал выбор в сторону FASM.
FASM
Наиболее удобный диалект ассемблера со своей IDE и документацией. Есть куча туториалов и видосов по нему. Но, чистые листинги вы будете писать от силы раза два, наверное. Весьма интереснее, практичнее и удобнее вещь следующая.
Вставки
Вставки позволяют вам работать с ассемблером в исходном коде, вот так к примеру:
Посмотреть вложение 33804
Правда, надо помнить, что каждый компилятор жрет вставки по разному (т.е могут быть разные объявления). Поэтому будьте аккуратны, если будете переходить с одного компилятора на другой.
Прочее
Вам могут пригодится различные hex-редакторы и сканеры. Из hex-редакторов могу посоветовать HxD и ImHex. Из сканеров либо PE scanner, либо DIE (Detect It Easy).
WinAPI & NTAPI
Было бы правильней разместить этот заголовок перед заголовком о реверс-инжиниринге и ассемблере, но да ладно. Тут мы поговорим о великих и ужасных.
WinAPI
Это основной API винды, знакомьтесь. Его все ненавидят и любят одновременно. Но это единственный нормальный метод взаимодействия с системой. По нему, как ни странно, не очень много интересного и годного материала, но он все же есть. Могу вам посоветовать Финогенова К.Г «Win32. Основы программирования», Джеффри Рихтера «Windows via C/C+ +» и Харта «Системное программирование в среде Windows». В некоторых есть задания для практики, но рекомендую просто практиковаться после каждой темы.
Вам придется работать с этим, вам некуда бежать.
NTAPI
Ну, его основная проблема — он до сих пор практически весь недокументированный. Но упоминания он достоин, так как рано или поздно вы с ним все равно столкнетесь. Есть несколько проектов, документирующие его функции, не все, конечно, но всё же.
В чем различие?
NTAPI существует с NT версий винды и как не парадоксально — даже сейчас винда живет и на нем тоже (к примеру NTOSKRNL.EXE). Поэтому, NTAPI расположен ближе к ядру, нежели WinAPI. Самыми близким к аппаратному уровню являются HAL и EFI функции, но это так, для справки. В принципе, что одно API, что другое меняются мало.
Виртуальные машины
Вы столкнетесь с ними по мере работы со своими проектами. Вам также придется и тестировать свои наработки на виртуальных машинах. Так как я с VMWare работал очень мало, расскажу о VirtualBox.
Virtual Box
Продукт от Oracle. Весьма себе хорошая вещь для новичка и не очень. Позволяет достаточно гибко настроить систему под себя и под ваши нужды. Позволяет создать динамический диск, а не только фиксированный, что очень удобно для машин с малым объемом памяти (у меня ноутбук с SSD на 500 гигабайт, вот так).
Тут я расскажу о самих методиках и техниках, которые присутствуют в малвари. Правда вам придется смириться, что эта сцена весьма динамична, так как разрабатываются все новые методы защиты безопасниками и появляются новые методы обхода, эксплуатации малварьщиками и крипторами. Вы должны быть динамичны и упорны, чтоб заниматься подобным. Так что не исключено, что завтра какие-либо вещи описанные здесь поменяются и не будут работать.
Пару слов о составляющей системы
Так как мы работаем под винду, все же хочу сказать, что система не ограничивается RING3 – RING0. Винда — очень комплексное понятие и вам пригодиться ее глубокое понимание, чтоб создавать более технически продвинутые продукты. По устройству системы читайте Марка Руссиновича. И да, вы же понимаете шестнадцатеричную систему? Надеюсь, что да.
Перзистентность
Перзистентность в системе это синоним устойчивости. Но вообще, на языке нормальных людей это называют закреплением.
Существуют различные способы перзистентности. Самый простой — через ключ автозагрузки:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
Он достаточно прост в понимании и не требует повышения привилегий у пользователя, т.е нам не нужны будут права администратора в системе. Существуют еще некоторые способы закрепления в системах.
На пример, закрепление через телеметрию в винде:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\AppCompatFlags\ TelemetryController
Или вы можете абьюзить тот же CLR в винде, как пример. Только в этом случае вам надо понимать, как он хотяб работает.
Инжект
Достаточно обширный топик этот инжект. Поэтому тут будет немного больше информации, чем о перзистентности. Тут не будет некоторых техник, которые я считаю бессмысленными. В приложении [0xFFFF] будут приложены некоторые материалы, они в вашем распоряжении, так что дерзайте. В принципе, там будут исходники к некоторым вещам. Ох, да, готовьтесь к детектам, тут будут техники, которые уже заабьюжены всеми! А приватом делиться я не буду.
DLL-Injection
Из ряда простых техник, даже классических, хах! Не требует каких-то особых сил и магии. Как и в предыдущей технике инжект происходит в запущенный процесс. Только единственный минус — вам придется сбрасывать вашу DLL на диск «жертвы». Это не есть хорошо.
Reflective DLL-Injection Эта техника сродни обычного DLL-инжекта. Но ее преимущество в том, что оно выполняется из памяти, т.е вам не нужно будет дропать DLL на диск, это будет для нас несомненным плюсом. Ее достаточно долго описывать, поэтому приложу ссылку на гит оригинально разработчика техники.
PE-Injection
Идея заключается в инжекте обычного бинарника в уже существующий и выполняемый процесс. Таким образом ваш бинарник будет выполняться уже в существующем процессе пользователя. Правда, детектиться антивирусами, ну, как и всегда.
SetWindowsHookEx
Эту функцию можно использовать в качестве инжекта в процессы, к примеру с помощью вашей DLL. Вам нужно дропнуть на диск DLL (плоха!!1), хукнуть любой процесс и поставить SetWindowsHookEx на клавиатуру (чаще всего используется именно клавиатура).
WinAPI Callback Injection
Можно создавать инжекты с помощью коллбэков, для этого как и везде нужен заготовленный шеллкод (о шеллкодинге мы поговорим чуть позже). Подобные вещи я видел только с Enum функциями: EnumChildWindows, EnumWindows и т. п.
Process Hollowing
Идея этого инжекта заключается в запуске легитимного процесса в системе жертвы и перезапись кода процесса на наш, вредоносный код. Плюсом будет, что по сути пользователя не уведомляют, что создался какой-то непонятный, а вполне себе обычный процесс.
No Injection No Allocation
Эта техника интересна тем, что она не использует подозрительные функции для аллокации памяти. Она пытается сократить вызов подозрительных функций без использования ебучих ROP чейнов, с которыми надо возиться миллион лет (читайте о Возвратно Ориентированном Программировании). Как на нее реагируют антивирусы я не знаю, не видел еще. Надо будет обязательно протестировать как-нибудь (можете тут сказать, что я пишу сам не знаю о чем).
Шеллкодинг
Шеллкод — чистый ассемблер, только записанный в виде опкодов (номеров мнемоник команд процессора). Вы по любому видели вот эту вот вещь:
\x31\xdb\x64\x8b\x7b\x30\x8b\x7f
Это и есть шеллкод. Он выполняется в памяти, является «динамическим» и может работать без зависимостей от API операционной системы жертвы и рантайм либ.
Шеллкодинг предоставляет нам возможность преобразовать некоторые проблемные участки нашей малвари в проекте. К примеру, проверка лицензии (если мы маленькие, пишем стиллер и этот документ неожиданно попадет в руки детей (лолзеров)), шифрование или дешифрование чего-либо. Кстати, шеллкод достаточно удобно шифровать, имейте ввиду.
Есть два вида создания шеллкодов. Первый — просто написанная маленькая программа, которую вы потом будете вытаскивать из hex-редактора. Минус этого подхода, что с ним будут адекватно работать только небольшие шеллкоды, ибо вы заебетесь. Второй подход более адекватный и преимущественно используется для больших шеллкодов. Единственное, что вам придется создать, так это map-файл, ибо с большим шеллкодом будет сложнее высчитывать смещение между RVA (Relative Virtual Address) и VA (Virtual Address).
Антиотладка / антидеббаг
Шутки кончились, теперь мы защищаемся от реверсеров. Потому что они хотят разрыть нашу софтину! Антидеббаг применяется (логично) против динамического анализа. Тут я расскажу о некоторых интересных и не очень методах, КОТОРЫЕ Я САМ ИСПОЛЬЗУЮ (да, капсом для самых смышленых), так что потом не надо плеваться в меня и говорить, что я не упомянул о каком-нибудь SetHandleInformation – я о нем прекрасно знаю.
Скажу сразу, что обходить их я вас учить не буду.
IsDebuggerPresent
Базовая и основная функция используемая против дебаггера, ее можна занопить нахххххуууууууииииииии. Вообще, эта функция использует структуру PEB (Process Environment Block). В свою очередь PEB содержит некоторые поля о загружаемых модулях, состоянии процесса и т.п.
TLS Callbacks
Относительно интересная вещь, т.к работает до вызова OEP (Original Entry Point). Идея заключается в том, что мы вставляем в TLS Callbacks приемы и функции для антидебагга. К примеру, тот же IsDebuggerPresent или функции и некоторые вещи, о которых мы будем говорить далее. Погуглите о этой технике на досуге.
NtGlobalFlags
Это поле находится в PEB структуре. NtGlobalFlags выставляет несколько флагов на контроль кучи от переполнения буффера. А затем дебаггер использует эти флаги. Единственное, что вам надо знать: битовая маска флагов равна 0x70, смещение рассматривого поля в x86 – 0x68, а для x64 – 0xBC.
ForceFlags & Flags
Все в том же PEB есть поля ForceFlags и Flags. Эти поля содержатся в структуре _HEAP. Идея в том, что эти же поля тоже задействованы во время отладки. Так что все очень просто — мы должны детектить, когда поле ForceFlags не равно 0, а Flags – 0x00000002.
DR0 – DR7
Это деббаг-регистры. И они доступны только в Ring 0. Нас интересуют только DR0, DR1, DR2 и DR3, так как они содержат в себе информацию о брейкпоинтах. Поэтому нам надо проверять, когда они не равны 0 и пиздить деббагер. NtSetInformationThread Для этой функции у нас есть флаг HideFromDebugger (0x11). Думаю, понятно что оно делает. Если нет — мы таким образом можем «отсоединиться» от дебаггера и игнорировать его любовные порывы.
На основе этих вещей вы можете писать антиотладочные методы или вкрайняк нагуглить их самим!
Антивиртуализация / Антиэмуляция
Методы антивиртуализации (анти-вм) позволяют нам бинарнику понять, выполняется ли он в виртуальной машине. Вот тут существуют узкие места, где необходим ассемблер. Я подобных методов знаю всего несколько, но о них я все же расскажу. Будем работать на примере VMWare (с VirtualBox все также будет работать, только процессы и значения немного разные будут).
Детект видеокарты / видеодрайвера
Вмки имеют свойство менять данные о видеокарте. Особо нечего рассказывать, если честно. Просто приведу пример:
Посмотреть вложение 33806
Можете его доработать. Я там как раз ошибку допустил)
Детект процессов виртуалки
Далеко не секрет, что виртуалки создают свои процессы. Одни из таких могут быть процессы для обработки 3D графики. Мы можем детектить такой процесс как vm3dservice.exe или vmtoolsd.exe получая снапшот всех процессов (функция CreateToolhelp32Snapshot).
Ключи реестра
Вм создают несколько ключей реестра, которые можно проверять. К примеру:
HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\ Logical Unit Id 0
Содержит сведения о виртуальном HDD, в свою очередь нас интересует параметр Identifier.
Обращаемся к I/O портам
В топике по ассемблерным вставкам вы могли заметить код, который детектил бы версию VMWare. Идея в том, что виртуальные машины используют виртуальные I/O порты. Чтоб понять, обменивается ли виртуальная машина с хостом, мы можем попытаться поработать со специальным «мостом» VX. Передаваемый операнд обязан содержать VX, а это происходит только в случае, когда регистр EAX содержит magic number VMXh.
О чем стоило упомянуть
Как минимум про вес бинарника и CRT. Вот вы же не будете дропать огромный файл в 100 мегабайт в папку temp? CRT достаточно часто дает детекты, ну, при определенных условиях, да и он тоже влияет на вес бинарника. Поэтому его отключают. Вам делать на первых порах это не советую.
Я не расписал о перзистентности должным образом, все же не последней важности топик, но в основном все используют ключи реестра, по моей памяти.
А еще я не доволен, как я написал про инжекты, да. В любом случае, в предисловии я говорил, что ждать тут много не стоит.
Пару слов о составляющей системы
Так как мы работаем под винду, все же хочу сказать, что система не ограничивается RING3 – RING0. Винда — очень комплексное понятие и вам пригодиться ее глубокое понимание, чтоб создавать более технически продвинутые продукты. По устройству системы читайте Марка Руссиновича. И да, вы же понимаете шестнадцатеричную систему? Надеюсь, что да.
Перзистентность
Перзистентность в системе это синоним устойчивости. Но вообще, на языке нормальных людей это называют закреплением.
Существуют различные способы перзистентности. Самый простой — через ключ автозагрузки:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
Он достаточно прост в понимании и не требует повышения привилегий у пользователя, т.е нам не нужны будут права администратора в системе. Существуют еще некоторые способы закрепления в системах.
На пример, закрепление через телеметрию в винде:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\AppCompatFlags\ TelemetryController
Или вы можете абьюзить тот же CLR в винде, как пример. Только в этом случае вам надо понимать, как он хотяб работает.
Инжект
Достаточно обширный топик этот инжект. Поэтому тут будет немного больше информации, чем о перзистентности. Тут не будет некоторых техник, которые я считаю бессмысленными. В приложении [0xFFFF] будут приложены некоторые материалы, они в вашем распоряжении, так что дерзайте. В принципе, там будут исходники к некоторым вещам. Ох, да, готовьтесь к детектам, тут будут техники, которые уже заабьюжены всеми! А приватом делиться я не буду.
DLL-Injection
Из ряда простых техник, даже классических, хах! Не требует каких-то особых сил и магии. Как и в предыдущей технике инжект происходит в запущенный процесс. Только единственный минус — вам придется сбрасывать вашу DLL на диск «жертвы». Это не есть хорошо.
Reflective DLL-Injection Эта техника сродни обычного DLL-инжекта. Но ее преимущество в том, что оно выполняется из памяти, т.е вам не нужно будет дропать DLL на диск, это будет для нас несомненным плюсом. Ее достаточно долго описывать, поэтому приложу ссылку на гит оригинально разработчика техники.
PE-Injection
Идея заключается в инжекте обычного бинарника в уже существующий и выполняемый процесс. Таким образом ваш бинарник будет выполняться уже в существующем процессе пользователя. Правда, детектиться антивирусами, ну, как и всегда.
SetWindowsHookEx
Эту функцию можно использовать в качестве инжекта в процессы, к примеру с помощью вашей DLL. Вам нужно дропнуть на диск DLL (плоха!!1), хукнуть любой процесс и поставить SetWindowsHookEx на клавиатуру (чаще всего используется именно клавиатура).
WinAPI Callback Injection
Можно создавать инжекты с помощью коллбэков, для этого как и везде нужен заготовленный шеллкод (о шеллкодинге мы поговорим чуть позже). Подобные вещи я видел только с Enum функциями: EnumChildWindows, EnumWindows и т. п.
Process Hollowing
Идея этого инжекта заключается в запуске легитимного процесса в системе жертвы и перезапись кода процесса на наш, вредоносный код. Плюсом будет, что по сути пользователя не уведомляют, что создался какой-то непонятный, а вполне себе обычный процесс.
No Injection No Allocation
Эта техника интересна тем, что она не использует подозрительные функции для аллокации памяти. Она пытается сократить вызов подозрительных функций без использования ебучих ROP чейнов, с которыми надо возиться миллион лет (читайте о Возвратно Ориентированном Программировании). Как на нее реагируют антивирусы я не знаю, не видел еще. Надо будет обязательно протестировать как-нибудь (можете тут сказать, что я пишу сам не знаю о чем).
Шеллкодинг
Шеллкод — чистый ассемблер, только записанный в виде опкодов (номеров мнемоник команд процессора). Вы по любому видели вот эту вот вещь:
\x31\xdb\x64\x8b\x7b\x30\x8b\x7f
Это и есть шеллкод. Он выполняется в памяти, является «динамическим» и может работать без зависимостей от API операционной системы жертвы и рантайм либ.
Шеллкодинг предоставляет нам возможность преобразовать некоторые проблемные участки нашей малвари в проекте. К примеру, проверка лицензии (если мы маленькие, пишем стиллер и этот документ неожиданно попадет в руки детей (лолзеров)), шифрование или дешифрование чего-либо. Кстати, шеллкод достаточно удобно шифровать, имейте ввиду.
Есть два вида создания шеллкодов. Первый — просто написанная маленькая программа, которую вы потом будете вытаскивать из hex-редактора. Минус этого подхода, что с ним будут адекватно работать только небольшие шеллкоды, ибо вы заебетесь. Второй подход более адекватный и преимущественно используется для больших шеллкодов. Единственное, что вам придется создать, так это map-файл, ибо с большим шеллкодом будет сложнее высчитывать смещение между RVA (Relative Virtual Address) и VA (Virtual Address).
Антиотладка / антидеббаг
Шутки кончились, теперь мы защищаемся от реверсеров. Потому что они хотят разрыть нашу софтину! Антидеббаг применяется (логично) против динамического анализа. Тут я расскажу о некоторых интересных и не очень методах, КОТОРЫЕ Я САМ ИСПОЛЬЗУЮ (да, капсом для самых смышленых), так что потом не надо плеваться в меня и говорить, что я не упомянул о каком-нибудь SetHandleInformation – я о нем прекрасно знаю.
Скажу сразу, что обходить их я вас учить не буду.
IsDebuggerPresent
Базовая и основная функция используемая против дебаггера, ее можна занопить нахххххуууууууииииииии. Вообще, эта функция использует структуру PEB (Process Environment Block). В свою очередь PEB содержит некоторые поля о загружаемых модулях, состоянии процесса и т.п.
TLS Callbacks
Относительно интересная вещь, т.к работает до вызова OEP (Original Entry Point). Идея заключается в том, что мы вставляем в TLS Callbacks приемы и функции для антидебагга. К примеру, тот же IsDebuggerPresent или функции и некоторые вещи, о которых мы будем говорить далее. Погуглите о этой технике на досуге.
NtGlobalFlags
Это поле находится в PEB структуре. NtGlobalFlags выставляет несколько флагов на контроль кучи от переполнения буффера. А затем дебаггер использует эти флаги. Единственное, что вам надо знать: битовая маска флагов равна 0x70, смещение рассматривого поля в x86 – 0x68, а для x64 – 0xBC.
ForceFlags & Flags
Все в том же PEB есть поля ForceFlags и Flags. Эти поля содержатся в структуре _HEAP. Идея в том, что эти же поля тоже задействованы во время отладки. Так что все очень просто — мы должны детектить, когда поле ForceFlags не равно 0, а Flags – 0x00000002.
DR0 – DR7
Это деббаг-регистры. И они доступны только в Ring 0. Нас интересуют только DR0, DR1, DR2 и DR3, так как они содержат в себе информацию о брейкпоинтах. Поэтому нам надо проверять, когда они не равны 0 и пиздить деббагер. NtSetInformationThread Для этой функции у нас есть флаг HideFromDebugger (0x11). Думаю, понятно что оно делает. Если нет — мы таким образом можем «отсоединиться» от дебаггера и игнорировать его любовные порывы.
На основе этих вещей вы можете писать антиотладочные методы или вкрайняк нагуглить их самим!
Антивиртуализация / Антиэмуляция
Методы антивиртуализации (анти-вм) позволяют нам бинарнику понять, выполняется ли он в виртуальной машине. Вот тут существуют узкие места, где необходим ассемблер. Я подобных методов знаю всего несколько, но о них я все же расскажу. Будем работать на примере VMWare (с VirtualBox все также будет работать, только процессы и значения немного разные будут).
Детект видеокарты / видеодрайвера
Вмки имеют свойство менять данные о видеокарте. Особо нечего рассказывать, если честно. Просто приведу пример:
Посмотреть вложение 33806
Можете его доработать. Я там как раз ошибку допустил)
Детект процессов виртуалки
Далеко не секрет, что виртуалки создают свои процессы. Одни из таких могут быть процессы для обработки 3D графики. Мы можем детектить такой процесс как vm3dservice.exe или vmtoolsd.exe получая снапшот всех процессов (функция CreateToolhelp32Snapshot).
Ключи реестра
Вм создают несколько ключей реестра, которые можно проверять. К примеру:
HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\ Logical Unit Id 0
Содержит сведения о виртуальном HDD, в свою очередь нас интересует параметр Identifier.
Обращаемся к I/O портам
В топике по ассемблерным вставкам вы могли заметить код, который детектил бы версию VMWare. Идея в том, что виртуальные машины используют виртуальные I/O порты. Чтоб понять, обменивается ли виртуальная машина с хостом, мы можем попытаться поработать со специальным «мостом» VX. Передаваемый операнд обязан содержать VX, а это происходит только в случае, когда регистр EAX содержит magic number VMXh.
О чем стоило упомянуть
Как минимум про вес бинарника и CRT. Вот вы же не будете дропать огромный файл в 100 мегабайт в папку temp? CRT достаточно часто дает детекты, ну, при определенных условиях, да и он тоже влияет на вес бинарника. Поэтому его отключают. Вам делать на первых порах это не советую.
Я не расписал о перзистентности должным образом, все же не последней важности топик, но в основном все используют ключи реестра, по моей памяти.
А еще я не доволен, как я написал про инжекты, да. В любом случае, в предисловии я говорил, что ждать тут много не стоит.
Магическая вещь, которой владеют самые просвещенные. На самом деле сложного мало, но нужно нехилое понимание самой винды опять же. В этом топике я немножечко расскажу что из себя представляет криптор и как он выглядит. А также я расскажу о более продвинутых вещах, по типу движков. Я бы мог расписать о крипторах больше, но я не пишу подобные вещи. Также я не буду расписывать о работе антивируса, о сигнатурных детектах и эвристики. Это все на ваших руках. Также здесь не будет RunPE и Process Doppelganging.
Понятие криптора
Криптор — программа, способная скрыть вредоносный файл от антивирусных алгоритмов.
Логика и понятие стаба
Да-да, охуенное понятие сверху. Но да ладно.
Криптор занимается шифрованием целевого (оригинального) файла, помещением его в стаб, затем он подготавливает ключи расшифровки и функции, потом формирует стаб.
Стаб — это файл-контейнер, содержащий в себе криптованный файл, при запуске которого он извлекает криптованный файл в память и запускает его там же. Логика стаба заключается в поиске внутри себя проинициализированной сигнатуры буфера зашифрованного файла, расшифровке файла, аллокации и передачи исполнения коду оригинального файла.
Что делает криптор?
- Криптор генерирует или добавляет мусорный код в оригинальный файл, не влияющий на основной ход кода оригинального файла. Таков код может быть разным по реализации и может быть очень похож на код реальных приложений.
- Криптор может использовать различные методы антиэмуляции, чтоб обойти антивирусные эмуляторы. Таким образом антивирус не сможет расшифровать оригинальный файл или понять действия реального кода. - Крипторы могут быть максимально легитимными приложениями. Для этого создатели крипторов пиздят ресурсы с легитимных приложений и добавляют их в стабы, с целью запутывания антивирусной эвристики и эмуляции.
И так далее.
Полиморфизм, метаморфизм и пермутация
Упомяну еще про некоторые техники здесь. На них стоит обратить внимание.
Полиморфизм — уникальный стаб от билда к билду. Точнее, он должен постоянно меняться от билда к билду.
Метаморфизм — no-stub техника, когда нам сам по себе не нужен стаб, так как изменяется все тело нашего вредоносного бинарника. В таком случае в памяти оказывается каждый раз новый сэмпл, от чегоантивирусы охуевают сигнатурный анализ памяти оказывается бесполезным.
Пермутация — по сути это некий встроенный «генератор» в наш вредоносный бинарник. Таким образом малварь может криптовать саму себя по некоторым наборам наши правил для билда
Понятие криптора
Криптор — программа, способная скрыть вредоносный файл от антивирусных алгоритмов.
Логика и понятие стаба
Да-да, охуенное понятие сверху. Но да ладно.
Криптор занимается шифрованием целевого (оригинального) файла, помещением его в стаб, затем он подготавливает ключи расшифровки и функции, потом формирует стаб.
Стаб — это файл-контейнер, содержащий в себе криптованный файл, при запуске которого он извлекает криптованный файл в память и запускает его там же. Логика стаба заключается в поиске внутри себя проинициализированной сигнатуры буфера зашифрованного файла, расшифровке файла, аллокации и передачи исполнения коду оригинального файла.
Что делает криптор?
- Криптор генерирует или добавляет мусорный код в оригинальный файл, не влияющий на основной ход кода оригинального файла. Таков код может быть разным по реализации и может быть очень похож на код реальных приложений.
- Криптор может использовать различные методы антиэмуляции, чтоб обойти антивирусные эмуляторы. Таким образом антивирус не сможет расшифровать оригинальный файл или понять действия реального кода. - Крипторы могут быть максимально легитимными приложениями. Для этого создатели крипторов пиздят ресурсы с легитимных приложений и добавляют их в стабы, с целью запутывания антивирусной эвристики и эмуляции.
И так далее.
Полиморфизм, метаморфизм и пермутация
Упомяну еще про некоторые техники здесь. На них стоит обратить внимание.
Полиморфизм — уникальный стаб от билда к билду. Точнее, он должен постоянно меняться от билда к билду.
Метаморфизм — no-stub техника, когда нам сам по себе не нужен стаб, так как изменяется все тело нашего вредоносного бинарника. В таком случае в памяти оказывается каждый раз новый сэмпл, от чего
Пермутация — по сути это некий встроенный «генератор» в наш вредоносный бинарник. Таким образом малварь может криптовать саму себя по некоторым наборам наши правил для билда
Тут некоторые вещи, не вошедшие ни в одну из тем, но тоже важные.
Криптография
Криптография рано или поздно вам пригодится при шифровании шеллкода или просто строк, как минимум. Для этого пойдет банально какой-нибудь base64. Другое дело если вы ранзомы (шифровальщики) хотите писать, вам нужно разбираться в криптографии как никто другой. Чем отличаются потоковые алгоритмы от блочных, симметричные от ассиметричных, что лучше использовать для ранзома и т.п. Существует достаточно много реализаций хэш-функций, ECDSA и прочих криптоалгоритмов. Вы спокойно можете найти их без меня. Если вы хотите почитать о криптографии, я рекомендую Шнайера Брюса «Прикладная криптография: Протоколы, алгоритмы, исходные тексты на языке Си»
Криптография
Криптография рано или поздно вам пригодится при шифровании шеллкода или просто строк, как минимум. Для этого пойдет банально какой-нибудь base64. Другое дело если вы ранзомы (шифровальщики) хотите писать, вам нужно разбираться в криптографии как никто другой. Чем отличаются потоковые алгоритмы от блочных, симметричные от ассиметричных, что лучше использовать для ранзома и т.п. Существует достаточно много реализаций хэш-функций, ECDSA и прочих криптоалгоритмов. Вы спокойно можете найти их без меня. Если вы хотите почитать о криптографии, я рекомендую Шнайера Брюса «Прикладная криптография: Протоколы, алгоритмы, исходные тексты на языке Си»
Я надеюсь я вам хоть чем-нибудь да помог, определил что надо учить и наставил вас на путь «истинный». Надеюсь, вы смогли определиться, будете ли вы работать в этой стезе, экспериментировать и т.д и т.п.
Я просто еще раз хочу сказать, что этот документ не позиционировал себя как нечто особенное, что научит вас разрабатывать подобные проекты с нуля. Нет, только теория и практика!
Так же я вам не рассказал о понятии PE (Portable Executable) – это по сути бинарник и есть. Извиняюсь за все орфографические, пунктуационные и речевые ошибки, а также за разрушенные ожидания!
Посмотреть вложение 33807
Я просто еще раз хочу сказать, что этот документ не позиционировал себя как нечто особенное, что научит вас разрабатывать подобные проекты с нуля. Нет, только теория и практика!
Так же я вам не рассказал о понятии PE (Portable Executable) – это по сути бинарник и есть. Извиняюсь за все орфографические, пунктуационные и речевые ошибки, а также за разрушенные ожидания!
Посмотреть вложение 33807
