От 386го к виртуальному

В силу исторических причин, на плюсы я пересел сравнительно недавно (4 года назад), до этого порядка 6 лет были отданы MASM и FASM. После болезненного перехода, оказалось что плюсы невероятно удобный язык. ООП даёт ряд преимуществ, например можно завернуть в него всю работу с памятью и не переживать что где-то будет протечка.

Зачастую на ассемблере не было нужных системных хидеров и пришлось передрать их с других языков. Встроенные макросы делали из MASM нечто си-подобное, но ничего удобнее чем Си (для работы с сырыми данными) не существует.

Скорость разработки стала на порядок выше: компилятор взял на себя большую часть работы, в SDK нас ждали хидеры, а мир opensource подарил проверенные десятилетиями алгоритмы. Из низкоуровневой работы остались WinApi и управление памятью.

Язык приучает нас к определённому стилю мышления. Если девизом ассемблера мог бы стать «Do it yourself», то на HLL стоит уметь правильно использовать чужой труд.

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

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

Но есть и более простое решение, о котором мы неоднократно писали — байткод интерпретаторов. Особых потерь в скорости исполнения не будет. Виртуальные машины (особенно с JIT) стали действительно быстрыми, критичные к быстродействию модули пишутся на Си. А морфить скрипты проще чем ассемблерную кашу.

Касательно удешевления виртуальных машин, нужно сказать про «облачный» тренд, когда перед запуском хеш файла проверяется в онлайне базе, а в случае подозрений файл льётся на виртуалки AV.

Они ориентированы на самые «средние» угрозы — standalone файл, который можно скачать и запустить без танцев с дроппером. До полностью «тонкого» клиента, выносящего сканер в сеть ещё далеко, например: Avast сначала запускает файл внутри «песочницы» (сейчас не про эмуляторы) и если он вёл себя хорошо, позволяет полноправно работать в системе.

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

Бытует мнение о низком качестве любого php кода, что абсолютная глупость, вызванная низким порогом вхождения. Правила написания качественного кода везде одинаковы: хорошее именование, TDD, проектирование до написания кода.

Хотя судя по утекающим исходникам, вредоносная отрасль остаётся островком аутизма в огромном море разработки ПО. Проблема в сообществах, культивирующих архаичную культуру. Многие решения (на стадии проектирования) заимствуются от предшественников, совершенно не подозревая что мир изменился.

Чтобы научить бинарный софт новым трюкам придётся убить немало часов, в то время как Python штатно имеет набор инструментов как швейцарский нож. Конкатенация строк, ручное управление памятью, обработка системных исключений, сборка модулей с нужной версией CRT – всё это добавляет исходникам длины, а разработке времени. Интерпретаторы стали шагом вперёд, позволив нам забыть про эти прелести, так же как в своё время Си помог забыть про регистры процессора.

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

2 thoughts on “От 386го к виртуальному

  1. Всё из-за тупых крабов, те кто подобный софт покупает жаждет видеть “НАПИСАНА НА АЗМЕ” и подобные страшные слова.

Добавить комментарий