• Уменьшение отступа

    Обратная связь

    (info@ru-sfera.pw)

ВАЖНО Учимся обходить детект антивирусов - Часть 1.


X-Shar

:)
Администрация
Регистрация
03.06.2012
Сообщения
6 068
Репутация
8 175
7829a65ed2d41323614d15455d769ead.jpg


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

Автор: Ege Balci

1. Вводное слово

В этой статье будут рассмотрены эффективные методы обхода статического, динамического и эвристического анализа, используемого в новейших антивирусных продуктах. Некоторые техники уже известны широкой публике, но есть и дополнительные трюки, которые являются ключевыми при генерации недетектируемого вредоноса. Объем файла не менее важен при использовании данных методов, и я постарался оптимизировать размер настолько, насколько возможно. В этом документе также будет затронута тема внутреннего устройства антивирусов и операционной системы Windows. Читателю желательно быть знакомым с C/C++ и ассемблером хотя бы на среднем уровне и понимать структуру PE-файла.

2. Введение

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

3. Терминология

Детектирование на базе сигнатур:

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

Статический программный анализ:

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

Динамический программный анализ:

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

Песочница:

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

Эвристический анализ:

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

Энтропия:

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

4. Распространенные техники

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

4.1 Обфускация

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

4.2 Упаковщики

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

4.3 Крипторы

Крипторы предназначены для шифровки бинарного файла с целью затруднения анализа или реверс-инжиниринга. У шифровщика есть две части: сборщик и стаб. Сборщик шифрует указанный бинарный файл и помещает внутрь стаб, являющийся самой важной частью криптора. При запуске бинарного файла сначала стаб расшифровывает первоначальную версию в память, а затем запускает расшифрованный файл при помощи метода «RunPE» (в большинстве случаев).

clip_image002.png

Рисунок 1: Схема шифрования инфицированного файла

clip_image004.png

Рисунок 2: Схема расшифровки бинарного файла

5. Проблема крипторов и упаковщиков

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

5.1 PE инъекция

Для того чтобы понять схему запуска PE-образа в памяти, необходимо упомянуть о том, как ОС Windows загружает PE-файлы. Обычно при компиляции PE-файла в адрес главного модуля устанавливается значение 0x00400000. Затем обрабатываются указатели полных адресов и рассчитываются инструкций длинных переходов на базе адреса главного модуля. По окончании компиляции в PE-файле создается секция таблицы релокации, которая содержит адреса инструкций, зависящих от базового адреса образа, например, указатели полных адресов и инструкций длинного перехода.

Во время выполнения PE-образа операционная система проверяет доступность предпочтительного адресного пространства. Если данное пространство не доступно, перед стартом системный загрузчик процессов должен подстроить абсолютные адреса в памяти. При помощи секции релокации загрузчик исправляет все инструкции, зависящие от адреса, и запускает приостановленный процесс. Весь этот механизм называется «Рандомизация размещения адресного пространства» (Address Space Layout Randomization; ASLR).

Для того чтобы выполнить PE-образ в памяти, криптору нужно распарсить PE-заголовки и переместить абсолютные адреса. Зачастую там имеется поддельный системный загрузчик, что сразу вызывает подозрение. Когда мы анализируем крипторы, написанные на С или языках высокого уровня, практически в каждом случае наблюдаются API функции «NtUnmapViewOfSection» и «ZwUnmapViewOfSection», которые попросту отключают представление секции от виртуального адресного пространства процесса. Эти функции играют очень важную роль при использовании метода RunPE, который встречается практически у 90% крипторов.

clip_image006.png

Рисунок 3: Пример использования функции NtUnmapViewOfSection

Естественно, антивирусные продукты не могут помечать каждую программу как вредоносную, которая использует эти API-функции. Однако сам факт наличия данных функций значит многое. Существует небольшой процент крипторов (в основном написанных на ассемблере), которые не используют эти функции и выполняют релокацию вручную. Какое-то время эти крипторы работают эффективно, но рано или поздно наступят последствия из-за попытки подделать системный загрузчик. Другой серьезный минус – при шифровании PE-файла серьезно увеличивается энтропия. Если антивирусный сканер детектирует нетипичный уровень энтропии, вполне возможно PE-файл будет помечен как подозрительный.

clip_image008.png

Рисунок 4: Результат измерения нетипичной энтропии у PE-файла

6. Идеальный метод

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

clip_image010.png

Рисунок 5: Общая блок-схема вредоноса

Функция «AV Detect.», показанная на схеме выше, будет детектировать, анализируется ли вредонос динамически внутри песочницы или нет. Если функция обнаруживает признаки антивирусного сканера, то либо вновь вызывается функция main, либо вредонос аварийно завершается. Если же признаки сканирования отсутствуют, будет вызвана функция «Decrypt Shellcode» для расшифровки шелл-кода.

На рисунке ниже показан обратный TCP-шелл-код под meterpreter в «сыром» формате.

clip_image012.png

Рисунок 6: Шелл-код в сыром формате

Для сохранения энтропии и размера на приемлемом уровне я будут обрабатывать шелл-код шифровщиком на базе алгоритма XOR с использованием мультибайтового ключа. Алгоритм XOR не является стандартом в индустрии, как например RC4 или blowfish, но в нашем случае сильное шифрование не требуется. Антивирусные продукты не будут заниматься дешифровкой. Нам достаточно защиты от статического анализа строк. Кроме того, XOR-шифрование намного быстрее и не использует библиотек, что влияет на итоговый размер вредоноса.

Тот же самый код под meterpreter, зашифрованный алгоритмом XOR с ключом.

clip_image014.png

Рисунок 7: Зашифрованный шелл-код

Поскольку мы пишем новый кусок вредоноса, хеш-сигнатура не будет известна антивирусным продуктам, и нам не нужно беспокоиться об обнаружении при помощи детектирования, построенного на базе сигнатур. Мы шифруем шелл-код и обфусцируем функции анти-детектирования/отладки и алгоритм дешифровки, что вполне достаточно для обхода статического/эвристического анализа. Нам осталось найти способ обхода динамического анализа, что является наиболее важной частью функции «AV detect». Перед написанием этой части необходимо разобраться, как работают эвристические алгоритмы антивирусных продуктов.

7. Эвристические движки

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

Вот некоторые известные правила, используемые при оценке угроз:

Присутствие цикла дешифровки.

  • Чтение текущего имени компьютера.
  • Чтение криптографического машинного GUID.
  • Соединение со случайными доменами.
  • Чтение даты установки Windows.
  • Удаление исполняемых файлов.
  • Присутствие потенциального IP-адреса в памяти бинарного файла.
  • Модификация настроек прокси-сервера.
  • Установка хуков/патчей к запущенному процессу.
  • Инжектирование в explorer.
  • Инжектирование в удаленный процесс.
  • Запрос информации о процессе.
  • Установка процесса в режим ошибки для сокрытия сообщения об ошибки.
  • Нетипичная энтропия.
  • Возможная проверка на присутствие антивирусного движка.
  • Присутствие функционала для расширения привилегий.
  • Модификация настроек политик приложений.
  • Чтение версии BIOS системы/видеокарты.
  • Конец PE-заголовка находится внутри нестандартной секции.
  • Создание защищенных областей памяти.
  • Создание множества процессов.
  • Попытка приостановить работу на долгое время.
  • Нестандартные секции.
  • Чтение Windows Product Id.
  • Присутствие функционала для запуска/взаимодействия с драйверами устройств.
  • Присутствие функционала для блокировки пользовательского ввода.
При написании функции по детектированию антивирусных продуктов и дешифровки шелл-кода, следует принимать во внимание эти правила.

8. Дешифровка шелл-кода

Обфускация механизма дешифровки чрезвычайно важна, поскольку большинство эвристических движков в состоянии обнаружить циклы дешифрования внутри PE-файлов. После значительного увеличения случаев, когда программа требовала выкуп, некоторые эвристические движки были почти полностью заточены под детектирование процедур дешифрования. После обнаружения процедуры дешифрования некоторые сканеры дожидались, пока в регистре ECX не окажется значение 0, что в большинстве случаев означает окончание цикла. По достижению окончания цикла дешифрования производится повторный анализ содержимого файла, которое будет представлять собой функцию дешифровки шелл-кода.

clip_image016.png

Рисунок 8: Функция дешифровки шелл-кода

На рисунке выше показан цикл for, внутри которого выполняются логические операции XOR между байтом шелл-кода и байтом ключа. Ассемблерные блоки наверху и внизу, по сути, не выполняют никаких операций. Эти блоки «накрывают» XOR-операцию случайным набором байтов и переходов. Поскольку мы не пользуемся продвинутые механизмы дешифровки, подобной обфускации будет достаточно для функции «Decrypt Shellcode».

9. Детектирование динамического анализа

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

9.1 Детектирование отладчика

Наш первый механизм детектирования антивирусного продукта будет проверять присутствие отладчика внутри процесса. Для решения этой задачи существует API-функция, которая определяет, отлаживается ли процесс отладчиком уровня пользователя (user-mode debugger). Но мы не будем использовать данную функцию, поскольку большинство антивирусных продуктов мониторят выражения API-вызовов. Скорее всего, после детектирования вызов будет расценен как противодействующий реверс-инжинирингу. Вместо использования API-функции мы будем искать байт «BeingDebuged» в PEB-блоке.

clip_image018.png

Рисунок 9: Функция для детектирования отладчика

Участок кода на рисунке выше извлекает байт BeingDebuged из PEB-блока. Если отладчик присутствует, проверка повторяется заново, и так до тех пор, пока в стеке не будет переполнение. После переполнения сработает исключение, и процесс будет закрыт. Этот путь - самый простой для выхода из программы. Ручная проверка байта BeingDebuged позволит обойти приличное количество антивирусных продуктов, но в некоторых приложениях предусмотрен подобный случай, и мы должны сделать обфускацию кода, чтобы защититься от статического анализа строк.

clip_image020.png

Рисунок 10: Функция, разбавленная мусорными инструкциями

Добавление переходов (инструкций JZ) после каждой операции не повлияет на логику работы функции, но добавление мусорных байтов между переходами позволит обойти фильтры статического анализа строк.

9.2 Загрузка поддельной библиотеки

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

clip_image022.png

Рисунок 11: Загрузка поддельной библиотеки

9.3 Использование функции GetTickCout()

В этом методе мы будем опираться на тот факт, что время, которое отводится на сканирование, ограничено. В большинстве случаев антивирусные сканеры созданы для конечного пользователя. Соответственно, приложение должно быть как можно более дружелюбно и пригодно для ежедневного использования. Сей факт означает, что сканер не может тратить слишком много времени на сканирование файлов, а должен завершать весь процесс как можно быстрее. Вначале разработчики вредоносов использовали функцию «sleep()» с целью дождаться окончания сканирования, но сейчас этот трюк практически не работает, поскольку каждый антивирусный продукт пропускает данную функцию. Мы будем использовать другой метод, показанный на рисунке ниже, который использует API-функцию «GetThickCount()». Данная функция извлекает количество миллисекунд, прошедших с момента запуска системы (до 49.7 дней). Мы будем использовать эту функцию для получения времени, прошедшее с момента запуска операционной системы, затем остановимся на 1 секунду. После функции sleep мы проверим, был ли этот участок пропущен, при помощи сравнения двух значений, полученных при помощи GetTickCout().

clip_image024.png

Рисунок 12: Проверка на то, была ли пропущена функция sleep()

9.4 Проверка количества ядер

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

clip_image026.png

Рисунок 13: Проверка количества ядер процессора

9.5 Выделение большого объема памяти

Этот метод также эксплуатирует ограниченное время, используемое при сканировании. Мы выделяем около 100 Мб памяти и заполняем данное пространство пустыми байтами. Затем память освобождается.

clip_image028.png

Рисунок 14: Выделение, заполнение и освобождение большого объема памяти

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

9.6 Манипуляция флагом трассировки

Как следует из названия, этот флаг используется во время трассировки программ. Если флаг трассировки установлен, каждая инструкция будет инициировать исключение «SINGLE_STEP». Флагом трассировки можно манипулировать с целью противодействия трассировщиками при помощи кода, показанного на рисунке ниже:

clip_image030.png

Рисунок 15: Манипуляция флагом трассировки

9.7 Проверка мьютексов

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

clip_image032.png

Рисунок 16: Проверка мьютекса

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

10. Правильные методы выполнения шелл-кода

Начиная с Windows Vista, компания Microsoft внедрила технологию DEP (Data Execution Prevention; Предотвращение выполнения данных). Эта мера, направленная на укрепление безопасности, помогает предотвратить порчу компьютера путем периодического мониторинга. Мониторинг позволяет поддерживать корректно использование памяти. Если механизм DEP обнаруживает случай некорректного использования памяти вашего компьютера, программа закрывается, и пользователь оповещается. Соответственно, вы не можете просто поместить несколько байт в символьный массив и выполнить свое творчество. Вам нужно выделить область памяти с флагами на чтение, запись и выполнения при помощи API-функций.

Компания Microsoft предусмотрела несколько API-функций для резервирования страниц памяти. Большинство вредоносов для резервирования используют функцию «VirtualAlloc», что, как вы уже догадались, облегчает задачу по детектированию. Использование других функций для манипуляции памятью поможет выполнить тот же самый трюк более незаметно.

Далее я покажу методы выполнения шелл-кода при помощи различных API-функций.

10.1 HeapCreate/HeapAlloc:

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

clip_image034.png

Рисунок 17: Копирование шелл-кода в созданную кучу

10.2 LoadLibrary/GetProcAddress

Комбинация WINAPI-функций LoadLibrary и GetProcAddress позволяет использовать другие API-функции. В этом случае не будет прямого вызова функций, связанных с манипуляцией памяти, а сам вредонос, вероятно, будет более незаметен.

clip_image036.png

Рисунок 18: Пример использования функций LoadLibrary и GetProcAddress

10.3 GetModuleHandle/GetProcAddress

Этот метод вовсе не использует функцию LoadLibrary, а получает обработчик уже загруженного модуля kernel32.dll при помощи функции GetModuleHandle. Данная техника для запуска шелл-кода, возможно, одна из самых незаметных.

clip_image038.png

Рисунок 19: Пример использования функций GetModuleHandle/GetProcAddress

11. Мультипоточность

PE-файлы, использующие несколько потоков, всегда сложнее анализировать, в том числе и для антивирусных продуктов. При помощи мультипоточного подхода мы можем запускать шелл-код и одновременно продолжать выполнение функции «AV Detect».

clip_image040.png

Рисунок 20: Пример выполнения шелл-кода в отдельном потоке

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

12. Заключение

В конце статьи хотелось вы поделиться некоторыми мыслями относительно компиляции вредоносов. При компиляции исходных текстов необходимо включить защиту стека и удалить символы с целью затруднения реверс-инжиниринга и уменьшение размера конечного исполняемого файла. Рекомендуется компилировать в Visual Studio из-за присутствия ассемблерных вставок.

Если воспользоваться одновременно всеми методами, продемонстрированными в этой статье, сгенерированный вредонос сможет обойти 35 наиболее продвинутых антивирусных продукта.

clip_image042.png

Рисунок 21: Результаты проверки вредоноса

Источник:

Часть два сейчас будет ! :)
 

pastorok

Пользователь
Форумчанин
Регистрация
04.02.2015
Сообщения
33
Репутация
19
я тоже недавно думал что шеллкоды и ассемблер - "Идеальный метод". Но забил на этот низкий уровень, взял Qt и написал свой трой с нуля.
Естесно он был FUD. Но кода на него сделали сигнатуру то я попытался добавить мусора в код. Потом залив на VT обнаружил что палево не прошло.
Ну я подумал, и решил вынести все строки из кода в "C struct" и шифранул. Залил на VT и снова FUD. Добавил мусора и снова FUD.
Вся фишка в том что эти ленивые дураки из лабораторий не знают что делать с exe файлом. Так как мой код не использует WinAPI и не хранит строк, то им ничего не остаётся как составить рандомную сигнатуру или хеш. Мой код не делает никаких инжектов, не выполняет динамических шеллкодов, ведёт себя как легальная прога, работает на чистом XP и 10, но и не мешает скомпилировать её под linux. Может для когото C++ слишком сложно, но для меня тема детекта закрыта.
 

virt

Просветленный
Просветленный
Регистрация
24.11.2016
Сообщения
706
Репутация
228
зял Qt и написал свой трой с нуля.
QT не подходит для написания малвари, ибо требует кучу библиотек, в итоге сам экзешник будет не хилый, даже без гуя...:)

Лучше тогда юзать студию ! :)
 

pastorok

Пользователь
Форумчанин
Регистрация
04.02.2015
Сообщения
33
Репутация
19
QT не подходит для написания малвари, ибо требует кучу библиотек, в итоге сам экзешник будет не хилый, даже без гуя...:)
только ради этого я готов юзать Qt , так как Dll лежат рядом, а у VT ошибка not found ****.dll - сам exe содержит только вызовы на них
я в общем кроссплатформенный кодер потому мне удобней и компилятор MinGW
вообще qt open source и множества плюшек там

как раз таки многофайловая прога и больше похожа на легальную, это нормально, тут C:\Windows\System32 тоже до*ера dll
 
Последнее редактирование:

virt

Просветленный
Просветленный
Регистрация
24.11.2016
Сообщения
706
Репутация
228
а у VT ошибка not found ****.dll - сам exe содержит только вызовы на них
А у пользователей также ! :)

Т.к. этих длл-ок у них нет, либо нужно делать самораспаковывающийся архив, либо инсталлер, либо всё собирать в эксе, что гемор для малвари...:(

Да палится не будет, но какому лоху вы это подсуните, либо эксе в 10Мб, либо инсталлер в 5-10 Мб, подходит только для адвари, хотя в принципе лохов хватает ! :)
 

pastorok

Пользователь
Форумчанин
Регистрация
04.02.2015
Сообщения
33
Репутация
19
либо нужно делать самораспаковывающийся архив,
1 еxe с dll в обычном zip
вы наверно не понимаете, те dll библиотеки содержат "золотой код", это на подобии портабельного .NET или Java - очень удобно, программы пишутся легко и с удовольствием
одходит только для адвари, хотя в принципе лохов хватает ! :)
доступна вся файловая система, смело можно писать стиллер, и никакого WinAPI
 
Последнее редактирование:

virt

Просветленный
Просветленный
Регистрация
24.11.2016
Сообщения
706
Репутация
228
вы наверно не понимаете, те dll библиотеки содержат "золотой код", это на подобии портабельного .NET или Java - очень удобно, программы пишутся легко и с удовольствием
Я-то это понимаю, но этот самый "золотой код" нужно каждый раз с собой таскать, в виде длл в данном случае, что увеличивает вес вашей программы, это хорошо-что без гуя, например я пустую форму в своё время слинковал экзешник в 20-ть мегабайть и это только пустая форма без всего, дальше нужно продолжать ?

Малварь должна-быть маленькая, лёгкая и надёжная, а не этот "крокодил" на QT.

Не ну смотря что-вы делаете с малварью, в принципе "Хомякам" можно и 100Мб файл дать...Dmeh-Smeh-Smeh!!!sholoh it

Но если-же говорить о малваре, как искусстве, то то-что вы предложили делать на QT, это почти то-же что и на .NET писать в данном случае, т.е. не тру...:)

Я не говорю, что QT плох, но для примера, кейлоггер на ассемблере будет весить 2-3 килобайта, кейлоггер на QT мегабайт 5-10-ть, а-то и более...:)
 

pastorok

Пользователь
Форумчанин
Регистрация
04.02.2015
Сообщения
33
Репутация
19
это почти то-же что и на .NET писать в данном случае, т.е. не тру...:)
всё тру), код компилится в "mov eax" и подобное, что не скажешь о .NET. Представь лица а.в. работников когда они снова видят "mov eax" и непонятные "call" в dll
тебе ничто не машает сделать asm вставку или слинковать .obj. Но если хочешь писать тонны платформенного кода пиши)

если хочешь потерять всё, вибирай ассемблер, это дауншифтинг, сил не хватит
кейлоггер на ассемблере будет весить 2-3 килобайта, кейлоггер на QT мегабайт 5-10-ть, а-то и более...:)
я могу слинковать твою прогу с dll и она будет весить в сумме хоть 100 mb. WinAPI это и есть Dll
твой кейлог по сути занимает весь Windows\System32 то есть ты System32 фреймворк кодер
ну майкософт же не дураки чтобы писать всю систему на ассемблере
 
Последнее редактирование:

virt

Просветленный
Просветленный
Регистрация
24.11.2016
Сообщения
706
Репутация
228
то есть ты System32 фреймворк кодер
ну майкософт же не дураки чтобы писать всю систему на ассемблере
Если всё делать на API, то зачем тогда ассемблер ? На API можно на любом языке кодить так-то....:)

Лично я делаю ассемблерные вставки где это необходимо, основной язык это си, причём классический, честно давно не кодил на ООП, даже забыл что это такое...:)

По сабжу, зачем мне линковать ассемблерный код, если он будет работать на любой винде, начиная от хрюши и заканчивая 10-ой, чего не скажешь про QT, да он работать будет но с бубнами и ещё-раз повторюсь вес бинарника не в пользу QT, если говорить про малварь.

Что за троян в 20-ть мегабайт, это нонсенс, думаю кто в теме это подтвердят, когда я занимался кейлоггер в 20 килобайт, заметь килобайт, а не мегабайт, считалось не круто, а вы предлагаете делать малварь в несколько десятков метров !

Это первое, второе, вот механизмы предложенные здесь вполне работают и с API-функциями и без всякого геммароя с непонятным "мусором" и ненужной нагрузки в десятки мегабайт, как в случае с QT.

Если говорить про малварь, думаю ООП тут тоже лишне, достаточно юзать чистый си и вставки ассемблера, гуй тоже не нужен, либо в основном если какие-то настройки малвари делать, сам гуй можно на чём угодно писать, хоть на батниках...:)
 
Верх Низ