http://lj.rossia.org/users/pr0mix/ здесь, сейчас, этот момент - LJ.Rossia.org здесь, сейчас, этот момент Tue, 22 Oct 2013 17:10:00 GMT LiveJournal / LJ.Rossia.org http://lj.rossia.org/userpic/189009/49769 http://lj.rossia.org/users/pr0mix/ 100 100 http://lj.rossia.org/users/pr0mix/7925.html Tue, 22 Oct 2013 17:10:00 GMT http://lj.rossia.org/users/pr0mix/7925.html <b>DIZAHEX</b> - небольшой дизассемблерный движок, предназначенный для анализа x86/x86-64 (+ 16-разрядного) кода. Может использоваться как самостоятельный двигл, так и совместно с какими-либо другими движками: пермутатор, эмулятор, виртуальная машина итд. Варианты применения прежде всего в вирусах/червях/троянах, навесных защитах (пакеры, крипторы, протекторы) =). А также в других программах.<br /><br />DIZAHEX написан на Си, поэтому у него нет привязки к какому-либо процессору. И его можно использовать как в 32-х битных, так и в 64-х битных приложениях. Ещё одна особенность движка - у него нет неверных инструкций. То есть считается, что весь код, который анализируется - состоит из правильных команд (ёба,а так программы и пишутся). При желании можно написать внешний анализатор под требуемые задачи. <br /><br />Все подробности в мануале к движку. <br /><br />Скачать:<br /><a href="https://www.dropbox.com/s/o8bqtk2q0xxuu9u/dhv10.zip" target="_blank">DIZAHEX Disassembler Engine v1.0</a><br /><br /><div style="text-align:left"><font size="-2"><a href="http://lj.rossia.org/users/pr0mix/7925.html"><img src="http://lj.rossia.org/numreplies/pr0mix/7925" border=0 width=26 height=17 alt="number of comments" style="border:0px;" /> <strong>Comments</strong></a></font></div> http://lj.rossia.org/users/pr0mix/7925.html disassembler dizahex engine http://lj.rossia.org/users/pr0mix/7619.html Tue, 22 Oct 2013 16:41:52 GMT http://lj.rossia.org/users/pr0mix/7619.html <b>xTG v2.1.1 - eXecutable Logical Trash Generator (Logical Trash Technique)</b> - генератор мусорных инструкций (генерация логичного правивильного мусора; движки <b>xTG, RANG32, FAKA</b>). В данной версии появилась возможность на вход подать некоторый блок "полезного" кода, а на выходе получить блок, хорошо разбавленный добротным умным мусором. Полезно для разбавления статичных декрипторов, антиэмулей и другого кода.<br /><br /><b>iRPE v1.0 - It's Real Polymorph Engine</b> - полиморфный двигатель, созданный на базе xTG v2.1.1 (мультидекрипторность; инструкции, их расположение и вызовы, регистры и т.п. - всё это меняется).<br /><br />Все подробности в мануале к движкам. <br /><br />Скачать:<br /><a href="https://www.dropbox.com/s/omtzzdcmsfxrefo/xtgv211.zip" target="_blank">xTG v2.1.1</a><br /><a href="https://www.dropbox.com/s/n8i0n1ac1d7xrvx/irpev10.zip" target="_blank">iRPE v1.0</a><br /><br /><div style="text-align:left"><font size="-2"><a href="http://lj.rossia.org/users/pr0mix/7619.html"><img src="http://lj.rossia.org/numreplies/pr0mix/7619" border=0 width=26 height=17 alt="number of comments" style="border:0px;" /> <strong>Comments</strong></a></font></div> http://lj.rossia.org/users/pr0mix/7619.html engine generator irpe logical polymorph trash xtg http://lj.rossia.org/users/pr0mix/7287.html Sat, 19 Oct 2013 18:29:49 GMT http://lj.rossia.org/users/pr0mix/7287.html Привет!<br /><br /> Темы об <b>ав-чекерах</b> поднимались неоднократно: концепты, сырые и готовые реализации, размышления, а также всякая хуйня. Поэтому тут я сваливаю в одну кучу всё то, что касается рабочей схемы чекера. Только кое-что новое добавив, а кое-что лишнее выкинув.<br /><br /><lj-cut><br /><br /><p>----------------------------------------<wbr />----------------------------------------<wbr />----------------------------------------<wbr />--------</p><br /><br /><pre> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx x x x Ещё раз Об АВ-чекере x x x xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Привет! Темы об ав-чекерах поднимались неоднократно: концепты, сырые и готовые реализации, размышления, а также всякая хуйня. Поэтому тут я сваливаю в одну кучу всё то, что касается рабочей схемы чекера. Только кое-что новое добавив, а кое-что лишнее выкинув. Итак, ав-чекер - это онлайн-сервис, проверяющий файлы/данные на вирусы/трояны/черви/etc (заранее подготовленными) различными антивирусными (АВ) сканерами. Для начала нам потребуется мощный выделенный сервак, многопроцессорный (чем больше ядер, частоты, кеша - тем лучше), с кучей оперативной памяти и поддерживающий аппаратную виртуализацию (для гипервизора). А также широкие сетевые каналы и безлимитный трафик в придачу (конкретные ТТХ намеренно не указываются, так что тут рулят только желание + возможность). Можно обойтись "обычным" компьютером с установленной виртуальной машиной (ВМ), но тогда скорость работы ав-чекера будет соответствующей. Ибо первое узкое место в производительности - это мощность оборудования и его настройка. Что касается языков программирования, то писать можно на чём угодно и как угодно. Например, Си (для движка системы) и php + html (для веб-морды). Далее, онлайн-сканер можно наделить следующими (популярными) фичами aka проверками: [+] файлов - статика (проверка локальными ав-сканерами, чек трафа на лету, реалтайм проверка при копировании/скачивании данных - здесь задействованы сигнатурный анализатор + эвристик + кодоэмулятор); [+] связок (они же exploit pack / webpage / etc); [+] урлов/доменов; [+] файлов - динамика (проверка файлов на работоспособность, поведенческий анализ итд). Разберёмся с каждым из этих пунктов по порядку. ------------------------- Проверка файлов - статика ------------------------- Завуалировано говоря, чекер -&gt; это веб-админка + движок системы, которые "общаются" между собой посредством базы данных (БД) и размещены на некоем охуенном железе. Технология реализации: [+] на выделенном сервере создаём нужное количество ВМ (с гостевыми ОСями); [+] одну из ВМ делаем сервером - на нём будут крутиться веб-морда и БД (файлы будут закачиваться через админку и храниться в базе для последующей проверки антивирусом); [+] на каждую ВМ ставится один АВ и наша программа "обработчик", который: [1] загребает из БД файл, который нужно проверить на конкретном АВ. При этом опрос базы осуществляется постоянно через заданный интервал времени. Однако, здесь детектится очередное слабое звено - при большой нагрузке база начнёт неебически загибаться. Выход из ситуации - файлы держать в веб-директории, а в базе хранить только ссылки на их скачивание; [2] запускает АВ (консольный с нужными настройками) на сканирование файла. Но и тут затаился пиздец - низкая скорость проверки. А всё из-за того, что сканеры (некоторых) АВэх очень долго подгружаются (инициализация движка, загрузка модулей/вирусных баз и прочие махинации (и это, не считая времени самого чека)). Поэтому, как вариант, можно заюзать гуй-версию, которая грузит свои потроха в память только 1 раз. Плюс ко всему, сократим общее время сканирования, скачивая файлы не по одному, а пачкой и чекать, вызывая сканер также 1 раз. Дополнительно можно использовать проверку трафа на лету, а также реалтайм сканирование, настроив его выполнение при скачивании и/или копировании данных. Но, по стандарту, всё надо тщательно и рьяно проверять, ибо такие вещи у большинства Авэх по прежнему работают убого, особенно при повышенной нагрузке; [3] получает от АВ результат. Который можно поймать, например, перенаправив вывод консольного сканера в пайп/файл. Из "личного" лога ав-движка. Если манипулируем гуишкой, то через её форму путём отправки сообщений и тыканием по кнопкам. Другие варианты - из журналов событий, расшифровки скрытых файлов (хуёвый метод), БД (например, есть любители SQLite) etc; [4] кладёт результат в БД. Тут всё просто - парсим полученный отчёт, если файл чистый - отправляем "ОК", если грязный - посылаем название детекта; [5] проводит обновления АВ и его вирусной базы (с некоторым заданным интервалом). Ещё нужно позаботиться о том, чтобы проверяемые файлы не сливались к аверам (поднимаем локальную сеть): первым делом вырубаем интернет на всех ВМ, где валяются АВ. Затем, одну, заранее выделенную ВМ делаем роутером - всё это дело настраиваем. Далее, в другую ВМ будем скачивать антивирусные обновки и сохранять их в расшаренных папках. Финальный штрих - вырубаем в каждом АВ все службы анонимной отправки данных и прописываем в качестве зеркала обновлений нужные пути в шаре. Для тех, кто не поддерживает данный параметр - всё делаем самостоятельно: скачивание вирусных баз с помощью wget/curl и их раскидывание по нужным директориям. В особо тяжких ситуациях ставим проксик для контроля исходящего трафа. Основная писанина - это подпункты [2], [3] и [5] - так как для каждого АВ будет свой алгоритм. Поэтому эти поинты можно вынести в отдельный модуль (handler_n), который на входе будет иметь унифицированный интерфейс (task manager), а реализация, соответственно, будет заточена под каждый тип АВ. Схематично работу чекера можно представить так: ******************************&lt;-*********************************** * * * SERVER * * * * * * * * ************ * * * * * * 5. profit * * * 4. result * * *&lt;---------------------------* web-site *&lt;----------------------------------+ * * * * * * | * * * 1. file * * * | * * user *------------------------&gt;* * | * * * * ************ | * ************* * | | * * | 2. file\task | * * +----------------&gt;******** ********** * * * * 3. file\task * * * * * DB *---------------&gt;* engine * * * * * * * * * ******** ********** * * * * * * * ******************************-&gt;*********************************** ******************************&lt;-*********************************** * * * ENGINE * * * * * * * * ************* ******** * * * * &lt;-report * * * * +------&gt;* handler_1 *&lt;------------&gt;* AV_1 * * * | * * file-&gt; * * * * *********** | ************* ******** * * * * | * 3.2 result * * * | * &lt;--------------------------------* * | ************* ******** * * * task * &lt;-report * * &lt;-report * * * 3.1 file/task * * manager *&lt;-----------&gt;* handler_2 *&lt;------------&gt;* AV_2 * * --------------------------------&gt;* * file-&gt; * * file-&gt; * * * * * * | ************* ******** * * * * | * * * * | * * *********** | ************* ******** * * | * * &lt;-report * * * * +------&gt;* handler_n *&lt;------------&gt;* AV_n * * * * * file-&gt; * * * * ************* ******** * * * * * * * ******************************-&gt;*********************************** И вообще будет заебись, если замутить ещё: [+] (реалтайм) вывод результатов; [+] обработку архивов (распаковка файлов с последующим помещением каждого в веб-папку) / файлов (определение типа); [+] увеличение производительности (перед проверкой файла поиск его хэша в базе - найден / не найден - принимаем нужное решение); [+] скачивание и проверка больших по размеру файлов; [+] общее снижение нагрузки на сервер/админку/бд/движок; [+] (при наличии нескольких серверов) распараллеливание работы handler'ов; [+] под дополнительные сервисы, как проверка доменов итд - соответственно, поднять ещё ВМ с нужным обработчиком под конкретную задачу; [+] etc Ж). --------------- Проверка связок --------------- Вкратце, связка - она же связка/набор эксплоитов, выдающихся ротатором (+ имеется админка со статистикой и много чего другого). Ротатор - скрипт, который определяет различные характеристики машины (ОС, браузер и его версию, итд) и выдаёт подходящий сплоит. Связка юзается для тестирования софта на пробиваемость, заражения уязвимых машин с последующим распространением своего софта etc. Для движка ав-чекера проверка связок == проверке файлов, различия будут видны только админке. Принцип работы следующий: [+] на вход подаётся полный веб-адрес, по которому скачивается (одно и то же) содержимое страницы несколькими юзер-агентами (чем больше их, тем лучше - повторю, это нужно для того, чтобы связка выдала разные экспы); [+] полученные данные сохраняются в обычные файлы (например, с расширением *.html); [+] чек файлов авером. Ещё можно позаботиться о том, с какими протоколами будет работать проверка связок, и что делать, если в связке включена блокировка по IP после каждого захода (хотя, это затруднение уже не чекера). Вот такие дела. ---------------- Проверка доменов ---------------- DNSBL (DNS BlockList/BlackList - ранее RBL - RealTime Blackhole List) - по сути, это чёрный список IP/доменов, рассылающих спам, и хранящийся с использованием системы архитектуры DNS. Ещё существует множество различных DNSBL-серверов, предоставляющих свои услуги (списки) для борьбы с негодной информацией. А отсюда следует, что всё уже построено - нам остаётся только прикрутить нужные сервисы в свой чекер и автоматизировать проверки (ага, всего то, блядь, прикрутить =)). На самом деле задача довольно лёгкая, и, на мой взгляд, её проще реализовать на скриптах в пределах одной ВМ. Общий каркас системы будет почти такой же, как и на чекере файлов (с диспетчером задач, обработчиками etc), но со своими нюансами, а именно (следуя нумерации ранее перечисленных подпунктов): [1] вместо файла проверяется ip/domen (ну это и так понятно, хуле); [2] чек айпи/доменов осуществляют выбранные в админке DNSBL-сервисы. Причём имеем 3 основных типа чеков: [a] проверка по веб-базам путём парсинга скачанной страницы результатов. Например, для google это делается так: [+] составляем полный веб-адрес ("http://www.google.com/safebrowsing/diagnostic?site=eof-project.net"); [+] скачиваем содержимое по данному урлу; [+] на полученной страничке ищем определённый текст (нашли "NO" - домен чист); [b] скачивание (в простейшем случае, текстовой) базы грязных ипов/доменов с дальнейшим поиском нужного IP (spyeyetracker blocklist etc); [c] резолвинг IP -&gt; запись IP в нотации DNS PTR -&gt; добавление в хвост имени DNSBL-сервера -&gt; получение (отсутствие) ответа. Здесь же добавлю, что есть 2 типа DNSBL: LHSBL (Left Hand Side BlackList) и RHSBL (Right Hand Side BlackList). Основное различие в том, что в LHSBL проверяются IP, а в RHSBL - домены. Пример для LHSBL: допустим, имеется адрес eof-project.net. Получаем его айпишник - пусть это будет 12.34.56.78. Далее, записываем его в обратном порядке: 78.56.34.12. И добавляем имя какого-либо хоста списка: 78.56.34.12.cbl.abuseat.org. В Си проверку можно сделать, например, с помощью функи gethostbyname(char *name)). Если придёт ответ (для данного хоста - это IP 127.0.0.2), то проверяемый адрес залочен (находится в списке). Полученный IP может оказаться любым, важен лишь факт его наличия/отсутствия в ответе на запрос. Аналогичный пример и для RHSBL, только вместо IP подставляем домен (eof-project.имя_хоста); [x] другие типы чеков, реализуемые в соответствии с поставленной задачей (например, для Internet Explorer можно создать дополнительную ВМ, в которой эмулировать заход юзера на сайт итд). -------------------------- Проверка файлов - динамика -------------------------- К данной категории относятся: [1] проверка файлов на работоспособность (основная мулька - проверка на большом количестве различных ОСей. Результат - "воркает!" или "ошибка пляшет"); [2] "утилитный" поведенческий анализатор (мониторинг изменений файловой системы (ФС) и реестра, сетевая активность, логирование вызовов winapi-фунок, анализ трафика и нажатий клавиш, установка драйвера и другие фичи. Результат - подробный отчёт всех действий программы, на основании которого юзер сам выносит вердикт: файл чистый или грязный); [3] "аверский" поведенческий анализатор (иначе говоря - чек файлов проактивками АВэх. Результат авера (не юзера) - "OK"/"название детекта"); [x] etc etc. Как и в остальных случаях, есть несколько вариантов создания такой проверки (вышеперечисленные пункты, само собой, можно объединять в один большой или миксовать, как по кайфу =)): [+] ранее приведённая схема работы (чек файлов-статика) - сюда вписывается тоже отлично. И если будем строить, скажем, "аверский" поведенческий анализатор - то, ясное дело, вместо ав-сканеров будут работать проактивки - принцип их обработки схожий. Особое внимание заслуживает диспетчер задач (ДЗ) - его втыкаем на отдельную ВМ. Функции диспетчера - принимать/обрабатывать task'и, выдавать файлы обработчикам, получать от них результат и отсылать его в БД, откат снапшотов после каждой проверки файла проактивками, обновление ОСей/аверов (и другого софта) с созданием новых снапшотов итд. Кроме того, ДЗ в целом мониторит работу движка сервиса. И если что-то пошло не так, то принимает соответствующие меры (например, если какой-то процесс заглючил (что часто бывает), или проверяется хитрый софт, который bsod'ит ось etc). [+] всё остальное: [1] другой каркас: вариант без ДЗ, поочерёдная проверка, принцип "матрёшки" (внутри ВМ запущены другие ВМ) итд; [2] альтернатива ВМ: физическая машина (например, используется полный бэкап системы в посекторном режиме с возможностью отката), песочницы (со специальными анализаторами) и другое. ------------------------- 0x ------------------------- Вот такая получается картинка. В принципе, всё относительно просто. Разве что много рутины, очевидной и не очень, которая появится в процессе разработки. Но это всё фигня. Главное - найти мощный сервак :p. Так что, кому надо - делайте, и всё получится, ёба. Смотри также: [1] Крис Касперски "VirusTotal своим руками, лапами и хвостом", http://www.insidepro.com/kk/314/314r.shtml [2] Википедия "DNSBL", http://ru.wikipedia.org/wiki/DNSBL [3] Википедия "Сравнение виртуальных машин", http://ru.wikipedia.org/wiki/Сравнение_виртуальных_машин [+] 2013 m1x http://lj.rossia.org/users/pr0mix/ вирмэйкинг для себя...искусство вечно </pre><br /><br /><br /><br /><div style="text-align:left"><font size="-2"><a href="http://lj.rossia.org/users/pr0mix/7287.html"><img src="http://lj.rossia.org/numreplies/pr0mix/7287" border=0 width=26 height=17 alt="number of comments" style="border:0px;" /> <strong>Comments</strong></a></font></div> http://lj.rossia.org/users/pr0mix/7287.html av av-check check http://lj.rossia.org/users/pr0mix/6972.html Sat, 19 Oct 2013 18:15:09 GMT http://lj.rossia.org/users/pr0mix/6972.html Здарова!<br /> <br /> Здесь попиздим о <b>DLL Hijacking</b> (с примерами данной атаки) в контексте антивирусов. Этот текст следует рассматривать только как заметку. Ну и по умолчанию, если эта инфа покажется вам простой, то пусть это будет докой для новичков =) <br /><br /><lj-cut><br /><br /><p>----------------------------------------<wbr />----------------------------------------<wbr />----------------------------------------<wbr />---------</p><br /><br /><pre> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx x x x Несколько слов о DLL Hijacking x x x xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Здарова! Здесь попиздим о DLL Hijacking (с примерами данной атаки) в контексте антивирусов. Этот текст следует рассматривать только как заметку. Ну и по умолчанию, если эта инфа покажется вам простой, то пусть это будет докой для новичков =) DLL Hijacking - она же подмена DLL. Многие проги при вызове функции LoadLibrary(char *) передают в качестве параметра не полный путь к файлу, а только его имя. Что даёт возможность подменить загружаемую библиотеку на любую другую. Это связано с тем, что поиск данной dll начинается в директории, содержащей вызывающий EXE-файл. При этом, подменённая длл'ка выполняется с теми же привилегиями, что и запущенный процесс. К ав, как и к другому софту, также можно (и нужно) применять данную технику нападения. Ясное дело, что в результате успешной атаки наш код работает в доверенном приложении, имеет те же привилегии, а значит может делать всё, что хочет. Значит, разобьём ав'ы в плане самозащиты на 2 группы: [1] нихуя себя не защищающие (директории/файлы/процессы/окна/реестр/атрибуты/etc - частичная защита (например, протекция файлов или только реестра итп) не считается); [2] те, кто старается это делать. К первой группе, например, относится Comodo (AV/IS v5.10). (Увы) приложения, не входящие в список доверенных, так просто не смогут нанести урон различным данным в папке авера. Однако, имеется возможность копировать туда свои файлы. Далее, при беглом анализе некоторых компонентов комода, была обнаружена целая куча вызовов LoadLibrary для файлов, отсутствующих в заданной директории (и во всей оси в целом). Нам остаётся только закинуть свою библиотеку с конкретным именем в нужную папку и наслаждаться результатом (возможно, понадобится перезагрузка). Например, имеется такая дира: "C:\Program Files\COMODO\COMODO Internet Security\themes\" (путь по умолчанию) - там comodo хранит цветовые схемы, которые представляют собой ресурсные PE-файлы: "black.theme" (etc (HIEW)): +--------------------------------------------------------------------------------------------------+ | Number | Name | VirtSize | RVA | PhysSize | Offset | Flags | |--------------------------------------------------------------------------------------------------| | 1 | .rsrc | 0006AB68h | 00001000h | 0006AC00h | 00000200h | 40000040h | +--------------------------------------------------------------------------------------------------+ Алгоритм их подключения такой: /*------------------------------------------------------------------------------------------------*\ "cavscan.exe": 0046AA33 |. E8 4D040900 CALL cavscan.004FAE85 ; \-&gt; FindFirstFileW 0046AA38 |. 8945 D8 MOV DWORD PTR SS:[EBP-28],EAX 0046AA3B |. C645 FC 01 MOV BYTE PTR SS:[EBP-4],1 0046AA3F |. 8D4D CC LEA ECX,DWORD PTR SS:[EBP-34] 0046AA42 |. E8 E988F9FF CALL cavscan.00403330 0046AA47 |&gt; 837D D8 00 /CMP DWORD PTR SS:[EBP-28],0 ; cycle: loadind of themes 0046AA4B |. 74 6B |JE SHORT cavscan.0046AAB8 0046AA4D |. 8D4D DC |LEA ECX,DWORD PTR SS:[EBP-24] 0046AA50 |. E8 EA010900 |CALL cavscan.004FAC3F ; -&gt; FindNextFileW 0046AA55 |. 8945 D8 |MOV DWORD PTR SS:[EBP-28],EAX 0046AA58 |. 8D4D DC |LEA ECX,DWORD PTR SS:[EBP-24] 0046AA5B |. E8 4E030900 |CALL cavscan.004FADAE 0046AA60 |. 85C0 |TEST EAX,EAX 0046AA62 |. 75 52 |JNZ SHORT cavscan.0046AAB6 0046AA64 |. 8D4D DC |LEA ECX,DWORD PTR SS:[EBP-24] 0046AA67 |. E8 D4ECFEFF |CALL cavscan.00459740 0046AA6C |. 85C0 |TEST EAX,EAX 0046AA6E |. 75 46 |JNZ SHORT cavscan.0046AAB6 0046AA70 |. 8D55 C8 |LEA EDX,DWORD PTR SS:[EBP-38] 0046AA73 |. 52 |PUSH EDX 0046AA74 |. 8D4D DC |LEA ECX,DWORD PTR SS:[EBP-24] 0046AA77 |. E8 08060900 |CALL cavscan.004FB084 ; -&gt; gluing strings 0046AA7C |. 8945 B4 |MOV DWORD PTR SS:[EBP-4C],EAX 0046AA7F |. 8B45 B4 |MOV EAX,DWORD PTR SS:[EBP-4C] 0046AA82 |. 8945 B0 |MOV DWORD PTR SS:[EBP-50],EAX 0046AA85 |. C645 FC 03 |MOV BYTE PTR SS:[EBP-4],3 0046AA89 |. 8B4D B0 |MOV ECX,DWORD PTR SS:[EBP-50] 0046AA8C |. E8 EFA8FCFF |CALL cavscan.00435380 0046AA91 |. 50 |PUSH EAX ; /Arg2 0046AA92 |. 8B4D 08 |MOV ECX,DWORD PTR SS:[EBP+8] ; | 0046AA95 |. 51 |PUSH ECX ; |Arg1 0046AA96 |. 8B4D C0 |MOV ECX,DWORD PTR SS:[EBP-40] ; | 0046AA99 |. E8 42020000 |CALL cavscan.0046ACE0 ; \-&gt; ... LoadLibraryW 0046AA9E |. 0FB6D0 |MOVZX EDX,AL 0046AAA1 |. 0FB645 D7 |MOVZX EAX,BYTE PTR SS:[EBP-29] 0046AAA5 |. 0BC2 |OR EAX,EDX 0046AAA7 |. 8845 D7 |MOV BYTE PTR SS:[EBP-29],AL 0046AAAA |. C645 FC 01 |MOV BYTE PTR SS:[EBP-4],1 0046AAAE |. 8D4D C8 |LEA ECX,DWORD PTR SS:[EBP-38] 0046AAB1 |. E8 7A88F9FF |CALL cavscan.00403330 0046AAB6 |&gt;^ EB 8F \JMP SHORT cavscan.0046AA47 0046AAB8 |&gt; 8A4D D7 MOV CL,BYTE PTR SS:[EBP-29] .... 005A7328 &gt; \53 PUSH EBX ; /FileName 005A7329 . FF15 FCE46800 CALL DWORD PTR DS:[&lt;&KERNEL32.LoadLibrar&gt;; \LoadLibraryW 005A732F . 8946 28 MOV DWORD PTR DS:[ESI+28],EAX \*------------------------------------------------------------------------------------------------*/ [1] поиск папки "themes"; [2] поиск всех файлов в данной папке по маске "*.theme" (FindFirstFile/FindNextFile); [3] загрузка очередного найденного файла с помощью функи LoadLibrary; В течение работы антивируса цветовые схемы могут быть загружены/выгружены несколько раз: [+] при загрузке оси (темы загружает "C:\Program Files\COMODO\COMODO Internet Security\cfp.exe"); [+] при очередном скане папок (через "cavscan.exe"); [+] при открытии окна: COMODO -&gt; Разное -&gt; настройки -&gt; внешний вид (темы грузит "cfp.exe"); [+] etc; Таким образом, переименовываем свою dll, допустим, в "xuita.theme" и закидываем в папку с темами. Комод сосёт. Ко второй же группе ав можно отнести KIS/NOD32/DrWeb/etc. Рассмотрим NOD32 (AV/SS v5.2). Его директории защищены от записи, перемещения файлов и т.д. Но и у него был обнаружен код динамической загрузки "ppeset.dll" (читай доки "plugin for cisco nac") в сервисе "ekrn.exe": /*------------------------------------------------------------------------------------------------*\ "ekrn.exe": 0040205F |. 68 ECFA4A00 PUSH ekrn.004AFAEC ; /FileName="ppeset.dll" 00402064 |. FF15 80124A00 CALL DWORD PTR DS:[&lt;&KERNEL32.LoadLibrar&gt;; \LoadLibraryW 0040206A |. 8BF8 MOV EDI,EAX 0040206C |. 85FF TEST EDI,EDI 0040206E |. 74 19 JE SHORT ekrn.00402089 00402070 |. 68 04FB4A00 PUSH ekrn.004AFB04 ; /ProcName="DllRegisterServer" 00402075 |. 57 PUSH EDI ; |hModule 00402076 |. FF15 88124A00 CALL DWORD PTR DS:[&lt;&KERNEL32.GetProcAdd&gt;; \GetProcAddress 0040207C |. 85C0 TEST EAX,EAX 0040207E |. 74 02 JE SHORT ekrn.00402082 00402080 |. FFD0 CALL EAX 00402082 |&gt; 57 PUSH EDI ; /hLibModule 00402083 |. FF15 78124A00 CALL DWORD PTR DS:[&lt;&KERNEL32.FreeLibrar&gt;; \FreeLibrary 00402089 |&gt; 8B0D 646B4C00 MOV ECX,DWORD PTR DS:[4C6B64] \*------------------------------------------------------------------------------------------------*/ При дефолтовых настройках установки (и вообше) авера данной библиотеки не было найдено во всей ОС. Тогда поиметь нод32 мы можем так: [1] задаём имя своей dll "ppeset.dll" и кидаем её в папку %TEMP%; [2] в системной переменной окружения "Path" добавляем директорию %TEMP%; [x] или же забросить либу в системную папку и не париться с реестром; При следующей перезагрузке системы наша библиотека подхватится, вызовет функу DllRegisterServer() и выгрузится из адресного пространства (АП) процесcа "ekrn.exe". Есть ещё такая фишка: если какой-либо процесс АВ'a создал, например, диалоговое окно открытия файлов ("Open"/"Save"/etc), то мы можем через это окно перемещать свои файлы даже в защищаемые антивирусом директории ("Action Via Window" attack - пусть будет так, а хуле). Это связано с тем, что подобные окна создаются с помощью фунок GetOpenFileName / GetSaveFileName, которые принадлежат библиотеке "Comdlg32.dll". А она выполняется как раз таки в АП процесса ав, который считается доверенным и может иметь права админа и выше. Алгоритм для реализации данной атаки может быть такой: [1] запуск нашего процесса; [2] мониторинг окон на наличие диалогового окна открытия файлов; [3] при появлении такого окна мы узнаём, какому процессу оно принадлежит, и получаем его текущую папку; [4] если текущая директория - та, что нам нужна (защищённая папка авера) - тогда ещё проверим, имеется ли в ней (наш) файл (с определённым именем). Нашли? - Оке, прыгаем на пункт [6]. Иначе [5]. Если же текущая дира - другая, тогда [2]; [5] копируем/перемещаем файл в буфер обмена (БО), активизируем найденное окно, и отправляем ему комбинацию клавиш "Ctrl + V"; [6] завершение работы нашей проги; Это всё здорово, однако многие из представленных танцев наверняка не будут работать на Windows Vista/7 из-за ёбаного UAC'а. Как известно, при включённом uac'e большинство приложений запускается с правами обычного пользователя (даже если он находится под учётной записью админа). И изменить различные системные параметры нихера не выйдет (копирование/вставка/etc файла в системную директорию, изменение системных переменных окружения, инжекты в процессы и/или передача оконных сообщений им (защита UIPI) с более высоким Integrity Level etc etc - всё это под запретом). Очевидное решение - повышение прав, сводящееся к обходу данного контроля. Итак, обход можно поделить условно на 2 вида: активный (диалоговое окно uac не появляется) и пассивный (появляется). К активному отнесём: [+] эксплоиты; [+] (возможные) инжекты в процессы; [+] некоторые другие специфические фишки (например, известная манипуляция c интерфейсом "IFileOperation"); Пассивный: [+] имя нашего приложения должно содержать любую из следующих строк: "install", "setup", "update", "patch" (сработает эвристик загрузчика приложений, и наша прога при запуске попросит повышение привилегий); [+] клепаем в приложении специальный манифест (etc + доки по манифесту для повышения прав); [+] заёб юзера: проверка своих привилегий, и если они низкие - запускаем себя с повышенными правами (ShellExecute(Ex) с командой "runas") до тех пор, пока юзер не охуеет от диалоговых окон (и, наконец-то, блядь, разрешит выполнение с нужными нам привилегиями); [+] после старта наша прога скачивает какой-нибудь подписанный инсталлятор/апдейт/etc (обычно такой апдейт заранее анализируется для атаки dll hijack), кладёт рядом с ним заранее подготовленную, нашенкованную всякими прелестями dll с определённым именем и запускает скачанный файл. (Обычно) если юзер подтверждает запуск такого апдейта, он будет выполняться с повышенными правами, а вместе с ним и наша dll; [+] после старта наша прога мониторит появление новых процессов. Если таковой найден, то выходим на его файл, анализируем и стараемся провести dll hijack (как вариант, перед новым процессом мониторинг "Consent.exe"). Другой путь - переименовываем свой файл в имя нового процесса и запускаем его с повышением привилегий; [+] использование буфера обмена в надежде на то, что файл попадёт в нужное место; [+] и т.д.; Понятно, что в общем случае эффективнее будет активная атака - пробили дыру и действуем на полный ход. Но у пассива тоже хорошие шансы - мы никогда не научим юзеров читать =) В общем, возможно всё, действуй! х1ъ: существуют готовые утилиты для поиска уязвимых приложений в системе (например, "DllHijackAuditKit"). Плюс к этому можно наваять ещё пару дополнительных тулз для более точного, качественного анализа конкретных файлов/процессов/etc (поиск по строкам, коду etc); х1ъ: сорцы примеров находятся в папке "src" (перед запуском прог читай комменты в исходниках); х1ъ: все тесты проводились на Win XP/Vista/7 x86 с дефолтовыми настройками всех ав; m1x / EOF pr0mix@mail.ru / vxrulez@gmail.com вирмэйкинг для себя...искусство вечно 2012 </pre><br /><br /><p>----------------------------------------<wbr />----------------------------------------<wbr />----------------------------------------<wbr />---------</p><br /><br />Исходники: <a href="https://www.dropbox.com/s/344lrbc8e0qn2rm/src.zip" target="_blank">https://www.dropbox.com/s/344lrbc8e0qn2r<wbr />m/src.zip</a><br /><br /><br /><br /><div style="text-align:left"><font size="-2"><a href="http://lj.rossia.org/users/pr0mix/6972.html"><img src="http://lj.rossia.org/numreplies/pr0mix/6972" border=0 width=26 height=17 alt="number of comments" style="border:0px;" /> <strong>Comments</strong></a></font></div> http://lj.rossia.org/users/pr0mix/6972.html av dll hijack http://lj.rossia.org/users/pr0mix/6657.html Tue, 15 Oct 2013 20:38:48 GMT http://lj.rossia.org/users/pr0mix/6657.html Здравствуйте!<br /><br />Общими усилиями, стараниями армия отличных людей выпустила электронный журнал <b>Inception</b>! <br /><br />Доступны варианты Ru & En. <br />В журнале немало статей, а также исходники и креативы на различные темы. <br />Все подробности внутри. Это стоит хотя бы посмотреть :p. Будем рады вашим отзывам! И приятного чтения! <br /><br /> Благодарности:<br /><b> Izg0y, _sheva740, d3m, Alien Assault, pest, Ar3s, amdf, FanOfGun, rgb, MZh, XRipper, KostaPC, ProudPank, Versus71, valentin_p</b> <br /> и другим людям!<br /><br />На связи :p<br /><br />Скачать:<br /><a href="https://www.dropbox.com/s/hm6b2pkj5ib8r38/inception_ru.zip" target="_blank">Inception RU-version</a><br /><a href="https://www.dropbox.com/s/9f1wrvpvzblcf25/inception_en.zip" target="_blank">Inception EN-version</a><br /><br /><div style="text-align:left"><font size="-2"><a href="http://lj.rossia.org/users/pr0mix/6657.html"><img src="http://lj.rossia.org/numreplies/pr0mix/6657" border=0 width=26 height=17 alt="number of comments" style="border:0px;" /> <strong>Comments</strong></a></font></div> http://lj.rossia.org/users/pr0mix/6657.html e-zine inception vx zine http://lj.rossia.org/users/pr0mix/6634.html Tue, 01 Oct 2013 11:50:20 GMT http://lj.rossia.org/users/pr0mix/6634.html Основной задачей мусорных инструкций является скрытие/защита полезного кода (от аверов, зорких глаз реверсера и других любопытных). Однако, "неправильный" трэш может стать причиной обнаружения вирусного кода, сводя на нет все наши старания. <br><br /> <br />Этот текст о том, как улучшить качество генерируемого мусора... <br><br /><br /><lj-cut><br /><br /><p>----------------------------------------<wbr />----------------------------------------<wbr />----------------------------------------<wbr />---------</p><br /><br /><pre> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx x x x Умный мусор: построение логики x x x xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [x] Введение Основной задачей мусорных инструкций является скрытие/защита полезного кода (от аверов, зорких глаз реверсера и других любопытных). Однако, "неправильный" трэш может стать причиной обнаружения вирусного кода, сводя на нет все наши старания. Этот текст о том, как улучшить качество генерируемого мусора. [x] Кто противник Допустим, что происходит проверка файла, заражённого нашим вирусом. Антивирус может действовать так: -------------------------------------------------------------------------------------------------------------- - запустит поверхностный анализ файла: его структуры и каких-то участков кода (сбор информации для начала работы эмулятора, кодо-анализатора, эвристика, может чего-то ещё); -------------------------------------------------------------------------------------------------------------- - далее, запускается эмуль, в процессе работы которого могут быть вызваны: анализатор кода (сбор данных для (дальнейшей работы) эмулятора и эвристика), а также сигнатурный анализ (поиск известных сигнатур в уже проэмулированном коде); -------------------------------------------------------------------------------------------------------------- - после отработки эмуля в дело вступает эвристический анализ собранных данных (сигнатур для нашего виря ещё не сделали=)), где происходит подсчёт баллов "опасности". Если полученный результат больше заданного предела - получите клеймо heur-virus'a. -------------------------------------------------------------------------------------------------------------- От эмуля нам поможет рабочая антиэмуль, от сигнатур - генератор мусора, который (как оказывается xD) использует наш вирь. Но если созданный трэш-код окажется слабым, то нас накроет эвристика. [x] План наступления Итак, для построения более качественного трэш-кода, вначале я предлагаю выбрать, под генерируемый код какого компилятора мы будем "косить": ms, borland etc. После того, как выбран компилер (например, ms), можно ещё определить, под какой режим генерации/оптимизации мы будем подстраиваться ("min size"/"max speed"). Это всё, конечно же, не обязательно, но желательно. Так как под разными режимами код генерируется по-другому. Например, для ms-компилера, команда занесения единицы в регистр в режиме "max speed" (в основном) будет такая: ---------------------------------------------------------------------------------------------------------------- mov eax, 1 ;0xB8 0x01 0x00 0x00 0x00 ---------------------------------------------------------------------------------------------------------------- А для "min size" ---------------------------------------------------------------------------------------------------------------- xor eax, eax ;0x33 0xC0 inc eax ;0x40 ---------------------------------------------------------------------------------------------------------------- Трэшген может генерировать оба эти варианта, но более правдоподобно смотрится, если держаться одной тактики (неизвестно, какие извращения будут в новых версиях эвристиков). Далее, помимо разных фичезов, которые вы встроите в трэшген, он также должен уметь генерировать "реалистичный" код (похожий на обычный код стандартных программ, написанных на ЯВУ), а именно: -------------------------------------------------------------------------------------------------------------- + "правильные" инструкции (опкоды и операнды - например, команда "mov eax, ecx" может быть закодирована с помощью двух разных опкодов: 0x8B 0xC1 и 0x89 0xC8 -&gt; ms-компилер юзает первый вариант; некоторые команды с использованием регистра EAX, имеющие "оптимизированные" варианты опкодов; etc); -------------------------------------------------------------------------------------------------------------- + "правильные" конструкции (например, test/cmp без последующей инструкции jmp/jxx - очевидное палево); -------------------------------------------------------------------------------------------------------------- + множество различных команд (использующих регистры, адреса памяти и т.п.), функции (с прологами/ резервированием стэка/эпилогами etc и команды с использованием локальных переменных, входящих параметров), winapi и другие; -------------------------------------------------------------------------------------------------------------- + "правильная" статистика частоты встречаемости опкодов (собираем стату в обычных прогах и используем её; для более точного результата можно собирать стату только в файлах, собранных выбранным ранее компилером); -------------------------------------------------------------------------------------------------------------- + нормальная энтропия (в битах ~ [5.5; 6.8]; кстати, энтропия будет примерно в заданном диапазоне, если генерить "правильный" код + использовать стату встречи опкодов (сюда можно добавить и логику команд)); -------------------------------------------------------------------------------------------------------------- + только живой код (который может выполниться); -------------------------------------------------------------------------------------------------------------- + etc; -------------------------------------------------------------------------------------------------------------- Но даже такой трэш-код, построенный с учётом данных пунктов, может легко ловиться эвристикой. [x] Полезный мусор Основная засада в том, что мусорный код - это только мусор, набор бесполезных инструкций. В этом и кроются причины гнева эвристиков. А раз так, значит трэш должен стать полезным. Для этого надо реализовать ещё 2 задачи: ------------------------------------------------------------------------------------------------------------- 1. полезный код должен использовать результат работы трэш-кода (или наоборот, трэш-код должен как-либо повлиять на работу полезного кода) aka "псевдо-цель"; ------------------------------------------------------------------------------------------------------------- 2. "LOGICAL TRASH" technique; ------------------------------------------------------------------------------------------------------------- Первый пункт в общем случае реализуется довольно просто: генерируем мусор, запускаем его на выполнение, и после отработки трэша полученный результат используем в полезном коде. Например, сгенерировали такой код: ---------------------------------------------------------------------------------------------------------------- mov eax, 100 mov ecx, eax sub ecx, 95 ---------------------------------------------------------------------------------------------------------------- После его выполнения ECX = 5. И данное значение можно добавить к ключу для расшифровки вирусного кода (применений куча). Однако, сгенерированный трэш-код может быть и таким: ---------------------------------------------------------------------------------------------------------------- mov eax, 100 ;1 mov ecx, eax ;2 mov ecx, eax ;3 mov ecx, eax ;4 sub ecx, 95 ;5 ---------------------------------------------------------------------------------------------------------------- После его выполения ECX также равно 5. Но команды 2 и 3 выдают себя с потрохами, за что будут наказаны эвристикой. Решение состоит в построении "логичного" мусора. [x] "LOGICAL TRASH" technique Идея заключается в том, чтобы мусорный код сделать логичным, подобно логике кода обычных программ. Нормальный код вначале инициализирует параметры (регистры, локальные переменные etc); затем выполняет команды, использующие и/или как-либо влияющие на эти параметры. Причём команды являются одним целым - выполняют общую задачу, и среди них нет лишних - мусорных. Нет повторных инициализаций, использования и обращения к (значениям) неинициализированным параметрам. Все инструкции связаны друг с другом, каждая влияет на дальнейший ход выполнения кода. Примерно такую логику я реализовал в новой версии своего движка xTG (v2.0.0), который работает по следующей схеме: ________ | | | начало | |________| | | | | +--------------------------------------------+ | | | | | | | ________________________ | ________________________ | | | | | | | | | | модуль генерации | | | модуль логики | | | | команд | | | | | | | | | | | | | | | | | | | | | ---------------------- | | | ---------------------- | | +--&gt;| генерация |&lt;-----+ +---&gt;| парсер команд | | +------&gt;| правильно | | | | | | | построенной | адрес команды | | ---------------------- | | | | команды |-----------------+ | эмулятор команд | | | | | | | | | | ---------------------- | | ---------------------- | 0 | | | корректировка адреса |&lt;----------------+ | анализатор команд/ |---+ | 1 | для генерации новой | | 1 | корректор логики | +-------| команды | 0 +----| команд | | |------+ | | | ---------------------- | | | ---------------------- | |________________________| | |________________________| | | | ________ | | | | | конец |&lt;-----------------------------+ |________| Распишем подробно: ---------------------------------------------------------------------------------------------------------- I. вначале, конечно же, вызываем модуль генерации команд; ---------------------------------------------------------------------------------------------------------- II. генерируем "правильную" команду: правильные опкоды и остальные байты. Да, кстати, если разработанный двигатель логики (ДЛ) будет применяться к сторонним трэшгенам (или другим движкам), то ДЛ также должен проверять, правильно ли построена команда (aka проверка на уровне байтов); ---------------------------------------------------------------------------------------------------------- III. вызываем модуль логики, передавая в него адрес только что созданной команды; ---------------------------------------------------------------------------------------------------------- IV. за дело принимается парсер команд. Парсер может быть функцей, являющейся частью модуля логики, а может быть и отдельным самодостаточным движком (дизасм). Первый случай хорошо подходит, если модуль логики является частью генератора мусора. Тогда в функции парсера будут разобраны только те команды, которые может генерировать двигл. Второй случай хорошо подходит, если модуль логики является самостоятельным движком. И при этом мы не знаем, какие команды могут генерироваться. Парсер выясняет, какая перед ним команда, и получает её параметры (операнды: регистры, адреса etc) - в соответствии с этим сохраняет в некоторую структуру данные параметры и выставляет определённые флаги. Заполненная структура будет использоваться анализатором команд (об этом ниже). Также, например, если встретилась команда mov ecx, dword ptr [403008h] и т.п., тогда парсер заменит адрес 403008h на другой, соответствующий ему адрес в выделенной памяти для корректной эмуляции команды; ---------------------------------------------------------------------------------------------------------- V. затем эмулируем (скорректированную) команду. Эмуль, по аналогии с парсером, может быть как встроенной функцией в модуле логики, так и полноценным движком-пирожком; Эмуль получает адрес команды, подготавливает специальную среду, копирует туда команду и эмулирует. Причём эмуляция может быть как минимум 3-х видов: прямой запуск в специальной среде, полная имитация выполнения команды и сочетание этих двух методов (для большинства команд хватает 1-ого метода). Результат эмуляции (текущие значения параметров команды и др.) сохраняем в переменных: виртуальных регистрах и др. Кстати, эмуль - козырная технология для вирей, с помощью которой можно творить очень интересные темы (для UEP'a, виртуальных машин, "logical trash" tech, морфинга и прочих вкусностей); ---------------------------------------------------------------------------------------------------------- VI. и после вызываем анализатор команд/корректор логики. Анализатор, по аналогии с парсером и эмулем, может быть как встроенной функцией в модуле логике, так и полноценным двиглом; Анализатор, на основе данных от парсера (заполненная структура) и эмуля, решает, подходит ли команда по логике или нет. Анализ команды проходит в 2 этапа: 1. Проверка параметров команды. Сначала анализатор должен понять, какие есть параметры, и как их проверять. Для этого он использует флаги, переданные парсером. Набор флагов может быть такой: -------------------------------------------------------------------------------------------------------- LGC_INSTR_INIT equ 00000000000000000000000000000001b ;команда инициализации параметров; LGC_INSTR_CHG equ 00000000000000000000000000000010b ;команда изменения параметров; LGC_P1_DST equ 00000000000000000000000000000100b ;первый парам - приёмник LGC_P1_SRC equ 00000000000000000000000000001000b ;первый парам - источник LGC_P2_DST equ 00000000000000000000000000010000b ;второй парам - приёмник LGC_P2_SRC equ 00000000000000000000000000100000b ;второй парам - источник LGC_P1_REG equ 00000000000000000000000001000000b ;первый парам - регистр LGC_P1_ADDR equ 00000000000000000000000010000000b ;первый парам - адрес LGC_P1_NUM equ 00000000000000000000000100000000b ;первый парам - число LGC_P2_REG equ 00000000000000000000001000000000b ;второй парам - регистр LGC_P2_ADDR equ 00000000000000000000010000000000b ;второй парам - адрес LGC_P2_NUM equ 00000000000000000000100000000000b ;второй парам - число -------------------------------------------------------------------------------------------------------- Этими флагами можно описать почти все инструкции (некоторые флаги можно убрать). Если инструкция содержит больше 2 параметров, тогда остальные хранятся в отдельном поле. Далее, по флагам определяется, что и как чекать: проверки на возможность инициализации параметров, на изменение их значений, на использование их в других командах и многое другое. Результат каждой проверки заносится в маски. Их 2: regs_init & regs_used. Грубо говоря, это 2 dword'a, где каждый бит соответствует определённому параметру (например, какому-то регистру). Причём, биты в regs_init показывают, можно ли инициализировать параметр или нет (защита от повторной инициализации). А по битам в regs_used узнаём, можно ли вообще использовать параметр в командах или нет. 2. Проверка состояний параметров команды Итак, если первый этап пройден, то это означает, что параметры годные. Продолжим. Состояние - это некоторое сохранённое значение, которое принимал параметр. Состояния всех параметров хранятся в таблице состояний, которая представляет собой буфер определённого размера. Значит, анализатор берёт текущее значение параметра, которое мы получили с помощью эмуляции (и сохранили, например, в виртуальном регистре), и сверяет его со всеми накопленными состояниями данного параметра. Если совпадение найдено, тогда команду считаем мусорной, проверка не пройдена. В этом случае из таблицы состояний берём последнее сохранённое состояние данного параметра и делаем его текущим (сохраняем это состояние в виртуальном регистре); а также восстановим маски на предыдущие значения. Если совпадение не найдено - значит это новое состояние параметра, команда прошла проверку. Добавляем это значение в таблицу состояний; ---------------------------------------------------------------------------------------------------------- VII. переходим снова в модуль генерации команд. Смотрим, какое значение вернул нам модуль логики: если 0, тогда команда не подходит по логике - по её же адресу сгенерируем новую команду (перезапишем). Прыгаем на пункт II. если 1, тогда команда подходит по логике. Прыгаем на пункт VIII. ---------------------------------------------------------------------------------------------------------- VIII. увеличиваем адрес (для генерации новой команды) на размер проверенной команды. И выясним: если мы сгенерировали нужное количество байтов, тогда прыгаем на пункт IX. Если не все, тогда на пункт II. ---------------------------------------------------------------------------------------------------------- IX. выходим; ---------------------------------------------------------------------------------------------------------- [x] Примеры генерации простого мусора --------------------------------------- ------------------------------------ | такой код не пройдёт проверку логики, | | такой код пройдёт проверку логики, | | а значит не сгенерируется | | а значит сгенерируется | --------------------------------------- ------------------------------------ ---------------------------------------------------------------------------------------------------------------- ;1.1 ;2.1 mov edi, 1000 mov edi, 1000 mov esi, edi mov esi, edi mov edi, esi mov edi, 2000 ---------------------------------------------------------------------------------------------------------------- ;1.2 ;2.2 mov eax, 1000 mov eax, 1000 mov ecx, 2000 mov ecx, 2000 xchg eax, ecx xchg eax, ecx xchg eax, ecx inc ecx xchg eax, ecx ---------------------------------------------------------------------------------------------------------------- ;1.3 ;2.3 xor edi, edi xor edi, edi xor ebx, ebx xor ebx, ebx add edi, ebx inc ebx add edi, ebx ---------------------------------------------------------------------------------------------------------------- ;1.4 ;2.4 mov edx, 1000 mov edx, 1000 mov eax, edx mov eax, edx dec edx mov edx, 2000 mov edx, 2000 ---------------------------------------------------------------------------------------------------------------- ;1.5 ;2.5 mov eax, 1000 mov eax, 1000 mov ecx, 1001 mov ecx, 1001 sub ecx, eax sub ecx, eax sub eax, ecx sub eax, ecx inc eax dec eax ---------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------ В примере 1.1 первые 2 команды нормальные, а третья - мусорная. Регистр EDI инициализировать можно, но он примет такое же значение, какое имеет сейчас - ненужная инициализация. Пример 2.1 (и все остальные в дальнейшем) показывает правильный вариант инициализации. ------------------------------------------------------------------------------------------------------------------------ В примере 1.2 первые 3 команды правильные, а 4-ая - мусорная. Регистры EAX & ECX снова примут значения, которые уже имели (проверка состояний параметров). ------------------------------------------------------------------------------------------------------------------------ В примере 1.3 первые 2 команды правильные, а 3-я - мусорная. EDI += 0 (проверка состояний); ------------------------------------------------------------------------------------------------------------------------ в примере 1.4 первые 3 команды правильные, а 4-я - мусорная. Регистр EDX нельзя инициализировать, если он прежде не повлиял на значение другого параметра (проверка параметров); ------------------------------------------------------------------------------------------------------------------------ в примере 1.5 первые 4 команды правильные, а 5-ая - мусорная. После выполнения первых 4-x команд состояния регистра EAX будут такие: 1000, 999. А после выполнения 5-ой команды EAX = 1000. Такое состояние уже было (проверка состояний параметров). ------------------------------------------------------------------------------------------------------------------------ [x] Позитив =) Реализацию техники "логичного мусора", наглядные примеры генерации трэш-кода, а также более полное понимание задумки - всё это ты найдешь в сорцах xTG v2.0.0. Следует сказать, что в xTG наиболее лучшее качество логики получается при генерации линейного трэш-кода без winapi-функций. В остальных случаях логика будет нечёткой, но будет: на ветвлениях и с винапишками. Это связано с модулем логики - чем он мощнее, тем качественней выхлоп. Если же не устраивает логика каких-либо инструкций, достаточно просто установить другие флаги. Также, возможен вариант применения логики для уже сгенерированного кода. Однако искомый код может быть на 100% отличный от исходного. Используя данную технику, наш мусор становится полезным и логичным, что позволяет довольно эффективно обходить эвристику. И только комплексное применение техник воплотят наши желания в реальность. Ура! [x] Используемая инфа 1. beauty on the fire "Эмуляция программного кода", 2004, http://uinc.ru/articles/47/ 2. beauty on the fire "Анализаторы кода в антивирусах", 2004, http://uinc.ru/articles/45/ 3. Sl0n "Полиморфизм. Новые техники", 2004, http://vx.netlux.org/lib/vsl05.html [+] август, 2011 m1x pr0mix@mail.ru EOF вирмэйкинг для себя...искусство вечно </pre><br /><br /><br /><br /><div style="text-align:left"><font size="-2"><a href="http://lj.rossia.org/users/pr0mix/6634.html"><img src="http://lj.rossia.org/numreplies/pr0mix/6634" border=0 width=26 height=17 alt="number of comments" style="border:0px;" /> <strong>Comments</strong></a></font></div> http://lj.rossia.org/users/pr0mix/6634.html logical smart technique trash useful xtg http://lj.rossia.org/users/pr0mix/6311.html Tue, 01 Oct 2013 11:26:52 GMT http://lj.rossia.org/users/pr0mix/6311.html <p><strong>0000. Начало</strong><br /><p>Можно долго умничать как о возможности создания недетектируемого вируса, так и о детекте абсолютно всех файлов, но известно точно: существуют эффективные (и не очень) методы обнаружения малвари, и не менее эффективные (а то и больше) техники антидетекта. Вот об этом мы и поговорим. <br /><lj-cut><br /><p>Я предлагаю следующую классификацию антивирусного детектирования:<br /><br /><ol><br /> <li>статическое;</li><br /> <li>динамическое;</li><br /> <li>бесконтактное =)</li><br /></ol><br /><br /><p>В данном тексте речь пойдет о 1-ом пункте. Кстати, одни и те же методы детекта (<a href="http://fcenter.ru/online/softarticles/utilities/12214" target="_blank">эти</a> и другие) могут применяться как для 1-ого, так и для 2-ого пунктов, но в (несколько) иной форме.<br /><br /><p>Под <b>статическим детектированием</b> будем понимать методы, применяемые для обнаружения малвари и производимые без реального выполнения кода малвари (методы, используемые во время проверки файлов на дисках (локальных etc), трафика («на лету») и другие).<br /><p>Более подробно рассмотрим, как аверы могут палить файлы путем <b>анализа их структуры и данных, и возможные варианты обхода этих детектов. </b><br /><p>Вся <b>идея</b> заключается в том, чтобы файлы были <b>«правильными»</b> с точки зрения антивирусников. То есть созданные/заражённые нашим кодом файлы должны быть максимально похожими по своим структуре/коду/действиям на обычные приложения (например, на <i>calc.exe из Windows</i>). В результате: знания/опыт/что-то еще + красивый <b>«чистый»</b> файл внутренне и внешне. Для достижения поставленной цели нам достаточно взять и изучить каждую частичку хотя бы одного любого файла – все другие исследуются/делаются аналогично (за пазухой держим <a href="http://wasm.ru/article.php?article=green2red02" target="_blank">формат PE-файлов</a>).<br /><br /><p>Итак, будем ориентироваться на <a href="https://www.dropbox.com/s/96qq408wegijpmy/test1.exe" target="_blank">test1.exe</a>, собранный мной на Visual C++ 6. Это обычное Win32-приложение, его внутренности содержат всё самое необходимое (без всяких bound/delay import etc). И далее рассмотрим только те поля/структуры/etc файла, которые могут вызвать какие-либо затруднения/сомнения при их заполнении. Остальные поля обычно имеют те же значения, что и соответствующие поля в <b>test1.exe</b>.<br /><p>Все файлы/сорцы, приложенные к данному тексту, тестировались на x86: Win XP (SP2/SP3), 7, Vista; и на x64: Win 7. <br /><br /><p><br /><strong>0001. Структура</strong><br /><p>Начнем с просмотра общего вида PE-файла. Вот, собственно, он самый:<br /><p><em>Таблица 0001.0000 – общий вид PE-файла</em><br /><ul><br /> <li>IMAGE_DOS_HEADER (0x5A4D==“MZ”)</li><br /> <li>DOS Stub + Rich Signature</li><br /> <li>Signature (0x4550 == “PE\0\0”)</li><br /> <li>IMAGE_FILE_HEADER</li><br /> <li>IMAGE_OPTIONAL_HEADER (with IMAGE_DATA_DIRECTORY)</li><br /> <li>IMAGE_SECTION_HEADER (.text)</li><br /> <li>IMAGE_SECTION_HEADER (.rdata)</li><br /> <li>IMAGE_SECTION_HEADER (.data)</li><br /> <li>IMAGE_SECTION_HEADER (.rsrc)</li><br /> <li>…</li><br /> <li>Section .text</li><br /> <li>Section .rdata</li><br /> <li>Section .data</li><br /> <li>Section .rsrc</li><br /> <li>…</li><br /> <li>…other info…</li><br /></ul><br /><br /><p>Вперёд за подробностями =)<br /><br /><p><br /><strong>0010. IMAGE_DOS_HEADER</strong> <br /><p>Располагается в начале файла.<br /><p><strong>DWORD e_lfanew;</strong> - Смещение структуры IMAGE_NT_HEADERS в байтах от начала файла. <br /><p>Для этого поля используем наиболее часто встречаемые значения в диапазоне [0xC0..0xF8]. Должно быть кратно 8.<br /><br /><p><br /><strong>0011. Rich Signature</strong><br /><br /><p>Допустим, у нас есть троян, который палится антивирусом (назовем его <b>pizdec</b>). В ходе различных экспериментов выясняем, что детект привязан к нескольким местам в файле: какая-то херня в коде, импорте и…что-то не в поряде с рич-сигнатурой (р-с). Причем если убрать детект по последнему признаку, файл становится чистым. После очередных опытов с р-с понимаем, что pizdec ее чекает каким-то хитрым образом, и фишка с заменой одних байтиков другими (рэндомными) не прокатит. Постоянно копировать р-с других файлов тоже не вариант. Но, как говорится, на каждую хитрую жопу найдётся хуй с винтом, и поэтому сгенерим р-с так, как она выглядит в файле после сборки в VC++. Для этого нам поможет <a href="http://ntcore.com/files/richsign.htm" target="_blank">это</a>, а также читаем <a href="http://www.wasm.ru/forum/viewtopic.php?id=7056" target="_blank">тут</a> и <a href="http://www.wasm.ru/forum/viewtopic.php?id=8572" target="_blank">тут</a> (алгоритмы по работе с р-с из данной ссылки не изменяли и не проверяли некоторые значения, поэтому данный код мной был переписан и модернизирован).<br /><p>Р-с содержит информацию о версиях компилятора/линкера и, возможно, о каких-то флагах/опциях компиляции/линковки. И не хранит идентификаторы железа и т.п., поэтому если прога будет собрана на разных машинах с одинаковым софтом (одинаковые версии, сервис-паки, длл и т.д.), то р-с этих файлов совпадут.<br /><p>Графически р-с выглядит так: <br /><br /><div align="center"><img src="https://www.dropbox.com/s/syk2j1huha75lo9/rsg1.JPG?dl=1" alt="Rich Signature"></div><br /><br /><p>Расшифрованная р-с:<br /><br /><div align="center"><img src="https://www.dropbox.com/s/2anrrrem3r58hw2/rsg2.JPG?dl=1" alt="Decrypted Rich Signature"></div><br /><br /><p>Вначале идут байты (смещение 0x80) 0x12 0x6A 0xA4 0x7F. Это строка <b>"DanS"</b>, поксоренная на некоторое число (назовем его xmask). <br /><p>Далее подряд следуют 3 xmask (0x56 0x0B 0xCA 0x2C). Маска представляет собой 32-битное число, вычисленное некоторым алгоритмом.<br /><p>Затем идут данные (назовем их xdata), поксоренные на xmask (в диапазоне смещений [0x90..0xC7]). Для каждой р-с может быть свой набор данных и их количество.<br /><p>После данных располагаются строка <b>"Rich"</b>, xmask и нули (в данном примере их 8, но может быть как больше, так и меньше. Кол-во нулей кратно восьми). <br /><p>В некоторых случаях отсутствие р-с может улучшить положение по отношению к детектам…возможно, до следующего апдейта ав. Но зачем нам это, если есть рабочие алгосы по генерации «правильной» р-с =). Тем более что мелкомягкие всегда ее создают. <br /><p>Алгоритмы проверки р-с на целостность, подмены ее данных, а также ее генерации с нуля находятся тут: <a href="https://www.dropbox.com/s/botipxxf1mts5lo/frs_asm.rar" target="_blank">frs_asm.rar</a> и <a href="https://www.dropbox.com/s/5con9udknknpov3/frs_C.rar" target="_blank">frs_C.rar</a>.<br /><br /><p><br /><strong>0100. IMAGE_FILE_HEADER</strong><br /><p>Содержит самую общую информацию о файле и находится сразу после сигнатуры 0x4550 ("PE\0\0").<br /><p><strong>WORD NumberOfSections;</strong> - Количество секций в файле. <br /><p>Если строится exe-шка, то лучше создать 4 секции (.text, .rdata, .data, .rsrc). Остальные добавлять только при необходимости (например, .tls, .reloc). Для dll-ки важно включить и релоки (.reloc). <br /><p>Если же мы заражаем файл, то также, действуем аккуратно. Например, жертва (обычный файл, без оверлея, никак себя не проверяет и т.п.) имеет 3 секции (.text, .rdata, .data). Можно создать +1 секцию ресурсов, засунуть в нее какую-нить иконку (не забываем тогда и про группу иконок), создать еще ресурс, в котором сохраним тело своего зверя. Ну а дальше, продумать и сделать передачу управления на наш весёлый код и скорректировать поля в файле. Таким образом, мы заинфектили файл и при этом создали вполне нормальную секцию.<br /><p>Кстати, был случай, когда чистый файл палился каким-то забавным ав, а после инфекта данного файла детект исчезал. VX спасёт мир )<br /><br /><p><strong>DWORD TimeDateStamp;</strong> - Время, когда был собран PE-файл. В этом поле хранится количество секунд, прошедших с 1 января 1970 года до времени создания файла.<br /><p>Можно использовать функцию gmtime из стандартной библиотеки С (time.h), переводящую время из секунд в удобочитаемый вид: <br /><p><blockquote><pre> DWORD TimeDateStamp = 0x4C9FABF5; struct tm *xtm = gmtime((const long*)&amp;TimeDateStamp); printf("day = %d\nmonth = %d\nyear = %d\n", xtm-&gt;tm_mday, xtm-&gt;tm_mon, (xtm-&gt;tm_year + 1900));</pre></blockquote> <br /><p>В принципе, здесь можно сгенерировать любое число, например, в диапазоне [0x40000000..0x4C000000] (2004-2010 гг.). <br /><br /><p>WORD Characteristics; - Атрибуты файла. <br /><p>В основном характеристики строятся из этих флагов (побитовое «ИЛИ»):<br /><p><blockquote><pre> //Relocation info stripped from file. #define IMAGE_FILE_RELOCS_STRIPPED 0x0001 //File is executable(i.e. no unresolved externel references). #define IMAGE_FILE_EXECUTABLE_IMAGE 0x0002 //Line nunbers stripped from file. #define IMAGE_FILE_LINE_NUMS_STRIPPED 0x0004 //Local symbols stripped from file. #define IMAGE_FILE_LOCAL_SYMS_STRIPPED 0x0008 //32 bit word machine. #define IMAGE_FILE_32BIT_MACHINE 0x0100 //File is a DLL. #define IMAGE_FILE_DLL 0x2000</pre></blockquote> <br /><p>Для exe можно смело использовать значение 0x10F (для dll – 0x210E).<br /><br /><p><br /><strong>0101. IMAGE_OPTIONAL_HEADER</strong> <br /><p>Эта структура является обязательной и содержит важные дополнения к общей информации в IMAGE_FILE_HEADER. <br /><br /><p><strong>BYTE MajorLinkerVersion/MinorLinkerVersion;</strong> - Содержат версию линковщика, создавшего данный файл. Числа должны быть в десятичном виде, например, 2.56, 6.0 и т.д.<br />Значение этого поля может быть любым, но, чтобы не провоцировать pizdec, предлагаю использовать значение 6.0. <br /><br /><p><strong>DWORD SizeOfCode/SizeOfInitializedData/SizeOfU<wbr />ninitializedData;</strong> - Суммарный размер всех секций кода/с инициализированными данными/с неинициализированными данными. Значения этих полей вычисляются следующим образом:<br /><p><blockquote><pre> //формула выравнивания (см. ниже) #define ALIGN_UP ((x + (y - 1)) &amp; (~(y - 1))) //(code_sec.Characteristics &amp; IMAGE_SCN_CNT_CODE) == 1 SizeOfCode += ALIGN_UP(code_sec.Misc.VirtualSize, FileAlignment) //(init_sec.Characteristics &amp; IMAGE_SCN_CNT_INITIALIZED_DATA) == 1 SizeOfInitializedData += ALIGN_UP(init_sec.Misc.VirtualSize, FileAlignment) //(uninit_sec.Characteristics &amp; // IMAGE_SCN_CNT_UNINITIALIZED_ DATA) == 1 SizeOfUninitializedData += ALIGN_UP(uninit_sec.Misc.VirtualSize, FileAlignment)</pre></blockquote> <br /><p>Создаем мы файл с нуля или же инфектим чужой файл, значения данных полей (да и остальных тоже) всегда должны быть правильно подсчитанными, иначе однажды по одному такому признаку pizdec сообщит: “Ёба, да тут вирус пляшет!!!”, - и вся эстетика сравняется с дерьмом. <br /><br /><p><br /><strong>DWORD AddressOfEntryPoint;</strong> - RVA точки входа, отсчитываемый от начала ImageBase. <br />Во избежание приступов бешенства у pizdec лучше всего располагать точку входа (EP) в диапазоне:<br /><p><blockquote><pre> //EP != 0 (EP &gt;= code_sec.VirtualAddress &amp;&amp; EP &lt; (code_sec.VirtualAddress + code_sec.Misc.VirtualSize))</pre></blockquote><br /><p>Если code_sec.Misc.VirtualSize == 0, тогда берем code_sec.SizeOfRawData. <br /><br /><p><strong>DWORD BaseOfCode/BaseOfData;</strong> - RVA секции кода/данных.<br /><p><blockquote><pre> BaseOfCode = code_sec.VirtualAddress; //0x1000; //SectionAlignment; //!!!!! // = RVA, откуда начинаются секции данных BaseOfData = data_sec.VirtualAddress;</pre></blockquote> <br /><br /><p><strong>DWORD ImageBase;</strong> - Базовый адрес загрузки файла в памяти. <br />Компоновщик по дэфолту устанавливает базовый адрес 0x00400000. Вот это значение и прописываем при генерации exe-файлов (для длл берём 0x10000000). Если будет что-то отличное от данного значения, появляется большой шанс получить клеймо при следующем апдейте баз pizdec’а.<br /><br /><p><strong>DWORD SectionAlignment/FileAlignment;</strong> - Кратность выравнивания секций в памяти/на диске. Формула выравнивания:<br /><p><blockquote><pre> //для адресов секций (физических и виртуальных) #define ALIGN_DOWN(x, y) (x &amp; (~(y - 1))) //для размеров секций #define ALIGN_UP(x, y) ((x + (y - 1)) &amp; (~(y - 1)))</pre></blockquote><br /><p>, где x – выравниваемое значение, y– выравнивающий фактор.<br /><p>Обычно SectionAlignment = 0x1000, a FileAlignment = 0x200 или 0x1000.<br /><br /><p><strong>DWORD SizeOfImage;</strong> - Общий размер загруженного приложения в памяти, начиная от ImageBase до конца последней секции, и выровненный на величину SectionAlignment. Вычисляется по формуле: <br /><p><blockquote><pre> SizeOfImage = last_sec.VirtualAddress + ALIGN_UP(last_sec.Misc.VirtualSize, IMAGE_OPTIONAL_HEADER.SectionAlignment);</pre></blockquote><br /><br /><p><strong>DWORD SizeOfHeaders;</strong> - Суммарный размер всех заголовков, выровненный в файле на FileAlignment (в памяти на SectionAlignment). Часто равен 0x400. <br /><br /><p><strong>DWORD CheckSum;</strong> - Контрольная сумма образа файла. <br /><p>Для обычных исполняемых файлов контрольная сумма не проверяется, т.е. может быть любой. Если она нулевая, то она тоже может быть любой. Для всех системных длл должна быть корректная.<br /><p>Чтобы получить контрольную сумму данного исполняемого файла, надо вызвать функцию CheckSumMappedFile с соответствующими параметрами. Эта функция доступна из библиотеки Imagehlp.dll.<br /><p>Если мы создаем свой файл (обычный) или инфектим чужой, в котором CheckSum = 0, тогда значение этого поля оставляем равным нулю. В остальном всё по ситуации =)<br /><br /><p><strong>IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_E<wbr />NTRIES];</strong> - Массив структур типа IMAGE_DATA_DIRECTORY, количество задается полем NumberOfRvaAndSizes (обычно = 0x10).<br />По умолчанию VC++ (6) создает в «обычном» приложении 3 директории: импорта, ресурсов, IAT (по крайней мере, для Win32 Application). Поэтому именно эти 3 директории также должны быть в нашем создаваемом файле (+ tls, релоки при необходимости). <br /><br /><p><br /><strong>0110. IMAGE_SECTION_HEADER</strong><br /><p>Массив структур типа IMAGE_SECTION_HEADER, количество задается полем NumberOfSection.<br /><br /><strong>BYTE Name[8];</strong> - <br />8-байтовое ASCII-имя секции. Лучше юзать стандартные имена: .text, .rdata, .data, .rsrc, .tls, .reloc. <br />Данную информацию используем как при создании своих, так и при инфекте чужих файлов (если выбран метод добавления новой секции, имя секции выбираем с умом).<br /><br /><p><strong>DWORD VirtualSize;</strong> - <br />Виртуальный размер секции, при загрузке файла в память выравнивается вверх на SectionAlignment. Причем в файле VirtualSize &lt; SizeOfRawData для всех секций (названия которых уже не раз были написаны). Исключение для секции .data (тут наоборот). <br /><br /><p><strong>DWORD VirtualAddress/ PointerToRawData;</strong> - <br />Содержат RVA адрес начала секции в памяти и смещение секции относительно начала файла. Обычно first_sec.VirtualAddress = 0x1000, first_sec.PointerToRawData = 0x400 или 0x1000. Значения адресов секций выровнены вниз на SectionAlignment/FileAlignment.<br /><br /><p><strong>DWORD SizeOfRawData;</strong> - <br />Физический размер секции, выровненный вверх на FileAlignment.<br /><br /><p><strong>DWORD Characteristics;</strong> - <br />Атрибуты секции. <br />Часто атрибуты строятся из следующих флагов (побитовое «ИЛИ»): <br /><p><blockquote><pre> // Секция содержит код #define IMAGE_SCN_CNT_CODE 0x00000020 //Секция содержит инициализированные данные #define IMAGE_SCN_CNT_INITIALIZED_DATA 0x00000040 // Секция содержит неинициализированные данные. #define IMAGE_SCN_CNT_UNINITIALIZED_DATA 0x00000080 // Эта секция отбрасывается, когда программа уже загружена. #define IMAGE_SCN_MEM_DISCARDABLE 0x02000000 // Секция является исполняемой. #define IMAGE_SCN_MEM_EXECUTE 0x20000000 // Данные секции можно читать. #define IMAGE_SCN_MEM_READ 0x40000000 // В секцию можно записывать данные. #define IMAGE_SCN_MEM_WRITE 0x80000000</pre></blockquote><br /><br /><p>Для «обычных» файлов дело обстоит так: <br /><p><blockquote><pre> .text.Characteristics = 0x60000020; .rdata.Characteristics = 0x40000040; .data.Characteristics = 0xC0000040; .rsrc.Characteristics = 0x40000040;</pre></blockquote><br /><br /><p>В качестве примера я решил прочекать <b>test1.exe</b> на <i>virustotal.com</i> до и после изменения атрибутов секции кода, и вот что получилось:<br /><p><blockquote><pre> <a href="https://www.virustotal.com/ru/file/bc38f3411e14604b28820852db11c5e733a181b07fef692306d6fd38fc6d0adf/analysis/1286035250/" target="_blank">.text.Characteristics = 0x60000020;</a> <a href="https://www.virustotal.com/ru/file/28bd09672c2302093dc3bb2b846bca1c8537d5bc0efc28c37166244ea119fc1d/analysis/1286035373/" target="_blank">.text.Characteristics = 0xE0000020;</a></pre></blockquote><br /><br /><p>Так что хышники, готовые сцапать «аномалию», всегда найдутся =)<br /><br /><p><br /><strong>0111. Импорт</strong><br /><p>Импорт – это механизм, позволяющий использовать функции и/или переменные из модулей, отличных от данного.<br /><p>Для того, чтобы файл корректно работал во многих версиях Windows и при этом не вызывал подозрение у разных ав, наличие импорта в файле обязательно.<br /><p>Таблица импорта начинается с массива структур типа IMAGE_IMPORT_DESCRIPTOR.<br /><p>Для «обычных» файлов по дефолту некоторые поля импорта заполняются такими значениями, чтобы системный загрузчик при запуске файла использовал стандартный механизм импорта. Поэтому предлагаю использовать нижеприведенные значения.<br /><br /><p><strong>DWORD OriginalFirstThunk;</strong> - <br />RVA массива двойных слов. Каждый элемент этого массива является объединением IMAGE_THUNK_DATA32 и соответствует одной функции, импортируемой PE-файлом. <br /><br /><p><strong>DWORD TimeDateStamp;</strong> - <br />Временная отметка, когда был создан данный файл. Так как юзаем стандартный механизм импорта, то пишем сюда 0.<br /><br /><p><strong>DWORD ForwarderChain;</strong> - <br />Данное поле связано с форвардингом функций. Пишем 0.<br /><br /><p><strong>DWORD Name;</strong> - <br />ASCII-имя импортируемой dll.<br /><br /><p><strong>DWORD FirstThunk;</strong> - <br />RVA массива двойных слов IMAGE_THUNK_DATA32. <br />FirstThunk является таблицей адресов импорта (Import Address Table (IAT)).<br /><br /><p><strong>IMAGE_THUNK_DATA32</strong> - <br />Структура представляет собой dword, который соответствует одной импортируемой функции. <br /><br /><p><strong>DWORD AddressOfData;</strong> - <br />Если функция импортируется по имени, то данное поле содержит RVA на структуру IMAGE_IMPORT_BY_NAME, в которой находится имя нужной функции. Если происходит импорт по номеру (ординалу), старший бит двойного слова устанавливается в 1.<br /><br /><p><strong>IMAGE_IMPORT_BY_NAME</strong> - <br />Содержит информацию о функции импорта.<br /><br /><p>WORD Hint; - <br />Этот word создан для использования системным загрузчиком, чтобы лоадер мог быстро найти функцию в таблице экспорта. И содержит индекс функции в массиве экспортируемых функций, равный ординалу. Естественно, одна и та же функция имеет разные ординалы в разных версиях винды, так что универсального hint’a под все системы нет. <br /><p>Предлагаю вычислять хинт так:<br /><ol type="1"><br /> <li>получаем случайное число и сохраняем его в переменной cor_hint;</li><br /> <li>находим нужную функцию в таблице экспорта dll и сохраняем ее ординал в переменной hint;</li><br /> <li>прибавляем к hint значение cor_hint;</li><br /></ol><br /><br /><p><blockquote><pre> //это значение будет вычислено один раз и прибавляться к каждому новому хинту; WORD cor_hint = rand()%0x100; //для очередного хинта находим свой ординал и прибавляем cor_hint; WORD hint = *AddrOfNameOrd + cor_hint;</pre></blockquote> <br /><br /><p>Таким образом, хинт у нас будет рэндомный, но вычисленный на основе соответствующего ординала.<br /><br /><p><strong>BYTE Name[?];</strong> - <br />ASCII-имя импортируемой функции.<br /><br /><p>Теперь поговорим о порядке построения импорта и прочих деталях. <br /><p>Значит, внимательно рассмотрев нашу ехешку (и подобные файлы), видим следующее:<br /><ol type="1"><br /> <li>весь импорт находится в секции .rdata (импорт лежит по адресу, кратному 4);</li> <br /> <li>в самом начале секции .rdata находится IAT (после которого могут лежать различные данные…а могут и не лежать);</li><br /> <li>далее следует таблица импорта;</li><br /> <li>затем идут массивы dword’ов IMAGE_THUNK_DATA32. RVA этих массивов сохранены в полях OriginalFirstThunk (lookup-таблица);</li> <br /> <li>после располагаются массивы структур IMAGE_IMPORT_BY_NAME и имена dll, причем порядок таков: сначала идет массив структур IMAGE_IMPORT_BY_NAME, а после имя длл – она импортирует функции, имена которых находятся в данном массиве. Затем снова идет массив структур и имя длл и т.д. И количество таких пар, естественно, равно количеству импортируемых данным файлом библиотек.</li><br /></ol><br /><p>Библиотеки добавляются в импорт в порядке подключения их в проекте. Поэтому (пока что) никаких правил по порядку нет, и в импорте первой может идти как KERNEL32.dll, так и абсолютно другая длл (некоторые линкеры (Borland) вообще могут захуярить одну и ту же длл несколько раз – но там свои карусели). <br /><p>WinApiшки можно размещать также в любом порядке (сортировка нужна только для экспорта). <br /><p>Что касается парных апи – тут тоже нет однозначного ответа. Из всех тестов, проведенных мной, не было выявлено ни одного случая детекта по данному признаку (по крайней мере, он был не ключевым). Хотя, возможно, для каких-то функций и при определенных обстоятельствах палят. Например, в test1.exe есть LoadLibraryA, но нет FreeLibrary; имеется WriteFile, но отсутствует CreateFile (хотя нахрен эта апишка нужна, так как с помощью WriteFile можно писать не только в файл, но и в консоль =)). <br /><p>Теперь о строках. <br /><p>Имена длл часто такие: KERNEL32.dll, USER32.dll, GDI32.dll etc (имя пишем большими, а “dll” маленькими бук0вками). <br /><p>Также замечу, что имена dll и функций (возможно и другие строки в .rdata), походу выравниваются на четное количество байтов:<br /><br /><div align="center"><img src="https://www.dropbox.com/s/nnqphh6rdkwlw6n/img1.JPG?dl=1" alt="Import"></div><br /><br /><p>На рисунке изображены примеры двух строк – имен функций с разных библиотек, выровненных нулями.<br /><p>При создании фэйкового импорта можно юзать (только) часто встречаемые длл и функи. Тут большой плюс - отсутствие «аномальных» строк, и даже если файл палится в импорте, то, скорее всего это не главный признак, поэтому импорт долгое время может оставаться «одним и тем же» (при необходимости фильтруем его). Конечно, есть и другой путь – использовать «редкие» dll/functions. Минус на рыло – детект именно по ним. Но это и плюс: возможность быстрой чистки (для этого достаточно заменить палевную функцию на «чистую»). <br /><p>У аверов существует «чёрный список» api/dll, которые, по их мнению, используются в основном в малвари. А также, возможно, на подходе и «белый список», более суровый =). Чего нет в нём – то пиздец. Следует такую нездоровую ситуацию учитывать.<br /><p>Для сбора статистики апи/библиотек специально была написана тулза <a href="https://www.dropbox.com/s/lndmpiryplwvnc8/stait_C.rar" target="_blank">stait_C.rar</a>, которая может помочь нам в этом забавном деле.<br /><br /><p><br /><strong>1000. Ресурсы</strong><br /><p>Как показывает практика, ресурсы благотворно влияют на pizdec. Поэтому разберемся, что это такое, и что лучше добавлять в наш файл.<br /><p>Таблица ресурсов соответствует секции ресурсов (.rsrc). Для нас важно знать, что ресурсы – это двоичное отсортированное дерево, и в венде используются только 3 первых уровня (Type, Name, Language). Запомни! Так как эта инфа в дальнейшем облегчит кодинг с ресурсами.<br /><p>Обычно хватает RT_ICON, RT_GROUP_ICON и еще какой-нить хрени (строки, диалоги, картинки etc). Причем в такой хрени можно хранить важные пошифрованные данные (код). Но все, как говорится, по ситуации. RT_RCDATA – с этим товарищем следует быть аккуратней, в нем хранить только хуиту, не больше (pizdec по-особому чекает содержимое данного ресурса). <br /><p>Очень хорошо, что существуют winapi, практически делающие все сами по созданию/добавлению/etc ресурсов в нужный файл. Нам остается только создать и сохранить пустую секцию/директорию ресурсов (может еще чуть скорректировать ресурсы и другие поля в PE-файле). Остальную работу выполнят BeginUpdateResource, UpdateResource, EndUpdateResource, EnumResourceNames, EnumResourceTypes и т.д. (кстати, с помощью этих фунок можно и инфектить файлы вместо использования CreateFile/CreateFileMapping/MapViewOfFi<wbr />le/UnmapViewOfFile). <br /><br /><p><br /><strong>1001. Секции</strong><br /><p>Секция - непрерывная область памяти с одинаковыми атрибутами. В этом разделе коротко рассмотрены только самые важные из них (tls &amp; relocs может в другой раз).<br /><p><strong>.text</strong> - В эту секцию помещаем весь программный код (о нём поговорим отдельно). <br /><p><strong>.rdata</strong> - Здесь храним импорт, ну а после него дополняем секцию нулями для выравнивания (ALIGN_UP(SizeOfRawData, FileAlignment)).<br /><p><strong>.data</strong> - В данной секции размещаем различные данные: рэндомные строки, числа и т.п.<br /><p><strong>.rsrc</strong> - Тут лежат (только) ресурсы проги (смотри раздел «Ресурсы»).<br /><p>Значит, секции в файле и в памяти должны идти именно в том порядке, в котором они здесь перечислены. Иначе «аномалия». Еще важно следить за размерами секций и их соотношением. <br /><p>Хотя собранная статистика по файлам и показала, что каких-либо правил здесь нет (встречались файлы с абсолютно противоположными пропорциями секций (в зависимости от размера файла)), можно сделать так:<br /><ol type="1"><br /> <li>если файл создаётся с нуля, то берём за эталон размеры секций и их процентные соотношения из других «чистых» файлов нужных размеров (например, если мы собираемся генерить файлы размером = 80kb, то сначала находим какой-нибудь файл, размер которого также = 80kb, и собранный на VC++ (6). И затем используем размеры его секций и их пропорции при составлении своих).</li> <br /> <li>если же мы заражаем файл, то стараемся придерживаться пропорций его секций. То есть, например, если у файла было 15% / 12% / 70% кода/данных/ресурсов до инфекта, то после инфекта желательно сохранить такое соотношение (но не обязательно, если убрать другие флаги детекта);</li> <br /> <li>что касается хранения шифрованного кода для пунктов 1 и 2, то пихаем его полностью в одну из секций (или оверлей), либо, как вариант, разбиваем код на куски и раскидываем их по секциям с сохранением пропорций (для этого нужно знать размер нашего кода и соотношение размеров секций файла). Энтропия полученного файла (его секций) должна быть нормальной (об этом ниже);</li><br /> <li>всё тщательно тестим;</li><br /> <li>часто встречаются файлы, у которых (.text_sec.SizeOfRawData &gt; .rdata_sec.SizeOfRawData) &amp;&amp; (.text_sec.SizeOfRawData &gt; .data_sec.SizeOfRawData).</li> <br /></ol><br /><br /><p><br /><strong>1010. Энтропия</strong><br /><p>В некоторых ситуациях полезно программно узнать, запакован файл или нет. И на основе полученного результата продолжать какие-либо вычисления. К ав это имеет прямое отношение. <br /><p>Допустим, проверяется на зверьё некий файл. Эвристик ав определит, запакован/зашифрован ли файл. Если результирующий процент/коэффициент меньше заданного предела, то анализ закончен. Иначе определит, чем пожато/пошифровано. Если известно чем – вывод имени пакера/криптора. Если нет, напишет, что это какой-нить XCryptVirus. Вот и эвристика на простые вирусы. И такого рода проверки могут быть для чего угодно…не успели толком обрадоваться свеженаписанному зверьку, а на нём уже клеймо. Чтобы такую хуергу зарубить на корню, нам по-любому надо быть как минимум на шаг впереди. <br /><p>Для начала скажу, что существует несколько вариантов программной детекции упакованного файла. Вот некоторые из них:<br /><ol><br /> <li>первая инструкция в точке входа pushad;</li><br /> <li>нестандартные имена секций;</li><br /> <li>атрибуты секции кода на запись (возможно какой-либо другой секции, изначально не предназначенной для записи);</li><br /> <li>наличие оверлея;</li><br /> <li>высокая энтропия (файла/отдельных его частей);</li><br /> <li>среднее арифметическое;</li><br /> <li>сигнатуры;</li><br /> <li>статистический анализ байтов/команд;</li> <br /> <li>другие.</li><br /></ol><br /><p>Естественно, что каждый из этих пунктов 100% не скажет, действительно ли упакован файл. А только грамотное сочетание их для определенных типов файлов может дать наиболее точный результат.<br /><p>При правильной структуре файла, большинство пунктов сразу отсеется. <br /><p>Здесь остановимся на энтропии.<br /><p>Итак, кратко, информационная энтропия - мера хаотичности информации. Впервые понятия «энтропия» и «информация» связал К.Шеннон в 1948 году. Шеннон использовал бит как единицу измерения информации. Мерой количества информации Шеннон предложил считать функцию, названную им энтропией:<br /><p><blockquote><pre> H(i) = -P(i) * log2(P(i)); H = H(1) + H(2) + H(i)…</pre></blockquote><br /><p>H - энтропия Шеннона, P(i) - вероятность появления i-ого символа.<br /><br /><p>Подробнее об энтропии <a href="http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D1%8D%D0%BD%D1%82%D1%80%D0%BE%D0%BF%D0%B8%D1%8F" target="_blank">здесь</a> и <a href="http://wasm.ru/article.php?article=packers2#4" target="_blank">здесь</a>.<br /><br /><p>Единица измерения информации и энтропии зависит от основания логарифма. Мы же будем измерять в битах на 1 байт с точностью до десятых.<br /><p>Опытным путём установлено, что «нормальное» значение энтропии для PE-файлов (exe) лежит в диапазоне [5.5;6.8]. Если получается больше, скорее всего файл упакован.<br /><p>Еще, можно заметить, что в разных прогах, имеющих функцию подсчета энтропии, значение самой энтропии для одного и того же файла могут быть разные. Почему?<br /><p>На самом деле проги используют одну и ту же Шенноновскую формулу, но, как было уже написано, могут использоваться различные единицы измерения, результат можно выводить в процентах или коэффициентом. При подсчете можно откидывать выравнивающие нули, самый частый и самый редкий байты (для усреднения значения), привязать к размеру файла, считать энтропию всего файла и/или отдельных его частей (заголовков, секций etc). Если считать по секциям, то можно брать ее минимальный размер (из физического и виртуального размеров) и т.д. <br /><p>Для того, чтобы нас не поймали по энтропии, очевидно, мы должны ее улучшить. Тут тоже предлагаю несколько способов, как это сделать:<br /><ol><br /> <li>Перестановочные шифры. От перестановки мест слагаемых сумма не меняется =). Однако, если данные перед этим уже были сжаты, данный шифр теряет свой смысл.</li><br /> <li>Коды Хаффмана.</li> <br /> <li>Разбавление кода «однородным мусором». Например, по некоторому алгоритму вставляем в разные места кода цепочки 0x00, 0xFF или другие байты (можно выбрать любой, либо «неслучайно»: например, вставлять тот, который имеет самую большую вероятность появления в данном коде/файле или провести анализ всех файлов нужного типа в ОС, найти «самый популярный» байт и юзать его) до тех пор, пока энтропия не «нормализуется». Этот же алгос (или другой) должен уметь и очищать от мусора наш код.</li><br /> <li>Base64. Вкратце, это схема кодирования произвольного набора байт в последовательность печатных ASCII символов. В общем случае длина получаемого кода увеличивается примерно на 30%. Основное правило кодирования простое – мы умышленно сокращаем диапазон символов (байтов), которые (по)имеем на выходе. А чем меньше символов мы используем, тем меньше неопределенность их появления, а значит меньше энтропия. Как-то так =) . Для кодирования используется 64 символа (2 в 6-ой степени). В общем, читаем <a href="http://ru.wikipedia.org/wiki/Base64" target="_blank">тут</a>. Таким образом, можно шифровать некий код и пихать его в ресурсы на «своё» место =) (RT_STRING). Base64 – это своего рода подстановочный шифр. Ничто не мешает юзать шифр (где размер символа = 6 бит, тогда энтропия не превысит 6.0 по определению) и со своим собственным алфавитом. Кстати, как вариант: берём 3 байта, у каждого из них забираем по 2 бита. И записываем после этих 3 байт новый байт, состоящий из отрезанных бит, и т.д. Получается, что у каждого байта будут «рабочими» только 6 бит. Количество различных байт сократится с 256 до 64 вариантов. И энтропия, соответственно, снизится (&lt;= 6.0) (+ накидать несколько различных байт – следить за статистикой байтов).</li> <br /><li>Разбавить код так, чтобы на выходе получить «правильный» код с низкой энтропией и «правильными частотами». <br /> <a href="http://lj.rossia.org/users/herm1t/51176.html?nc=1" target="_blank">Вот</a> и <a href="http://wasm.ru/forum/viewtopic.php?id=28016" target="_blank">вот</a>.</li><br /></ol><br /><br /><p>В качестве примера написана прога <a href="https://www.dropbox.com/s/mb7odftlb35l3ir/xentr_C.rar" target="_blank">xentr_C.rar</a>, вычисляющая энтропию файлов (+ пара фичезов).<br /><br /><p><br /><strong>1011. Репутация файла</strong><br /><p>В последнее время у многих ав стало модным продвигать так называемые облачные технологии. И всё в принципе хорошо, только благодаря этим чудо-технологиям кто-то стал обезбашенным параноиком, кто-то потерял кучу бабосов, к кому-то пришел suspicious.insight. Но есть и большие плюсы…аверы знают =).<br /><p>Ну вот, вступление уже есть… Далее мы рассмотрим конкретного антивирусника – symantec и его братию. <br /><p>Как пишут сами симантюковцы, ими была создана «революционная» технология (кодовое название Quorum), обеспечивающая заshitу данных на основе оценки репутации. Чуть больше об этом <a href="http://www.symantec.com/ru/ru/about/news/release/article.jsp?prid=20090911_01" target="_blank">тут</a>. Покопавшись в различной инфе и поэкспериментировав с nis 2011, дополню описание данной технологии:<br /><br /><ol type="1"><br /><br /><li>norton insight – технология, обеспечивающая защиту без снижения производительности за счет исключения из проверки доверенных файлов. Это позволяет сократить время сканирования.</li><br /> <li>После запуска данной технологии, вначале идет соединение с сервером Shasta-rrs.symantec.com. Это, так называемая, их облачная платформа (<a href="http://techpulse360.com/2010/06/03/symantec-to-open-consumer-cloud-platform-shasta-video/" target="_blank">она самая</a>).</li><br /><li>По защищенному соединению (протокол TLS), передаются/принимаются/проверяются различные данные. Значит, по данным: передается/принимается ~300 байт. И если верить инфе с сайта разраба – никакая личная инфа, а также сам проверяемый файл не отсылаются на их сервера (файл не сканируется). Передается только статистическая инфа о файле: sha256 хэш от файла, (возможно) его имя, размер, версия (ресурсы), цифровая подпись (может определенные ее данные).</li> <br /> <li>Полученный хэш с помощью специальных алгоритмов сверяется с базой данных (хранится на серверах симантека), содержащей инфу об известных доверенных файлах. Полученный результат (репутация/степень доверия) + хэш файла вероятно сохраняются в зашифрованном виде в БД на компе юзера.</li><br /> <li>Если файл был изменён, полученное ранее доверие будет недействительным, и файл будет проверяться снова.</li> <br /> <li>а) следует отметить, что, возможно, в БД симантюка хранится и инфа о запущенных процессах/модулях/драйверах, различные следы файлов, данные о самой ОС и юзаемой файловой системе; б) наличие цифровой подписи у файла еще не означает, что файлу можно доверять. В исключении разве что мелкомягкие =).</li><br /></ol><br /><p>Кстати, был найден довольно простой способ обхода знакомого многим suspicious.insight’a (<a href="http://www.symantec.com/security_response/writeup.jsp?docid=2010-021223-0550-99" target="_blank">о нём</a>) (однако, против нортона не прокатит - ищем другое), который заключается в следующем:<br /><ol type="1"><br /> <li>берем любой файл с подписью, например, от ms;</li><br /> <li>выдираем из него цифровую подпись (все данные из директории IMAGE_DIRECTORY_ENTRY_SECURITY) и сохраняем ее на диске;</li><br /> <li>файлу, который хотим защитить от суспикус-инсайта, цепляем сохраненную цифровую подпись (а) сохраняем подпись как оверлей в самом конце файла; б) прописываем адрес и размер подписи в полях VirtualAddress &amp; Size директории IMAGE_DIRECTORY_ENTRY_SECURITY; в) пересчитываем поле IMAGE_OPTIONAL_HEADER.CheckSum).</li><br /></ol><br /><p>Полученный скорректированный файл, разумеется, не пройдет проверку цифровой подписи, но для нашей задачи полностью подходит: <br /><p><blockquote><pre> //сначала перечекаем test1.exe – он без фэйковой цифровой подписи //после перепроверки видно, что спустя некоторое время его уже палят =) //но сейчас о другом: нажимаем на кнопку «Show all» и видим, что //висит Suspicious.Insight <a href="http://www.virustotal.com/file-scan/report.html?id=bc38f3411e14604b28820852db11c5e733a181b07fef692306d6fd38fc6d0adf-1297133220" target="_blank">before_ds</a> //test1.exe //затем к test1.exe была добавлена подпись от excel.exe (XP SP3) //и проверим полученный файл //как видно, исчезли даже и другие детекты <a href="http://www.virustotal.com/file-scan/report.html?id=fe406a684f8d06f7681fe5a948ab02afa20d11e4f6713e1f2bac2a244aeb819f-1297133236&quot;" target="_blank">after_ds</a> //si_sux.exe</pre></blockquote><br /><br /><p>Сорцы прилагаются: <a href="https://www.dropbox.com/s/zl6plyeut9xalna/fakeds_C.rar" target="_blank">fakeds_C.rar</a>.<br /><br /><p><br /><strong>1100. Доброключение</strong><br /><p>Следует помнить: то, что помогло в чистке одного файла, может быть непригодно в чистке другого, так как для разных файлов возможны разные детекты. Поэтому, как говорится, нормально делай – нормально будет =). И знай, что сила в простоте. Тут всё. <br /><p><br /><br /><strong>Ссылки на доки</strong><br /><br /><ol type="1"><br /> <li><a href="http://www.fcenter.ru/online.shtml?articles/software/utilities/12214" target="_blank">Antivirus Engines</a></li><br /> <li><a href="http://wasm.ru/article.php?article=green2red02" target="_blank">PE format</a></li><br /> <li><a href="http://ntcore.com/files/richsign.htm" target="_blank">Microsoft's Rich Signature (undocumented)</a></li> <br /> <li><a href="http://www.wasm.ru/forum/viewtopic.php?id=7056" target="_blank">About Rich Signature</a></li><br /> <li><a href="http://www.wasm.ru/forum/viewtopic.php?id=8572" target="_blank">Fake Rich Signature</a></li><br /> <li><a href="http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D1%8D%D0%BD%D1%82%D1%80%D0%BE%D0%BF%D0%B8%D1%8F" target="_blank">Information entropy</a> (<a href="">eng</a>)</li><br /> <li><a href="http://ru.wikipedia.org/wiki/Base64" target="_blank">Base64</a> (<a href="http://en.wikipedia.org/wiki/Base64" target="_blank">eng</a>)</li><br /> <li><a href="http://wasm.ru/article.php?article=packers2#4" target="_blank">Calculation entropy</a> (<a href="http://wasm.ru/comment.php?artcode=packers2" target="_blank">+ comments</a>)</li><br /> <li><a href="http://lj.rossia.org/users/herm1t/51176.html?nc=1" target="_blank">About entropy</a></li><br /> <li><a href="http://wasm.ru/forum/viewtopic.php?id=28016" target="_blank">Crypting simple instructions</a></li><br /> <li><a href="http://www.symantec.com/ru/ru/about/news/release/article.jsp?prid=20090911_01" target="_blank">Symantec about technology Quorum</a></li><br /> <li><a href="http://techpulse360.com/2010/06/03/symantec-to-open-consumer-cloud-platform-shasta-video/" target="_blank">Symantec Cloud Platform Shasta</a></li><br /> <li><a href="http://www.symantec.com/security_response/writeup.jsp?docid=2010-021223-0550-99" target="_blank">Symantec Suspicious.Insight</a></li><br /></ol><br /><p><br /><strong>Исходники</strong><br /><ol type="1"><br /> <li><a href="https://www.dropbox.com/s/96qq408wegijpmy/test1.exe" target="_blank">test1.exe</a> &amp; <a href="https://www.dropbox.com/s/17jmid0d6b8bw9o/si_sux.exe" target="_blank">si_sux.exe</a></li><br /> <li><a href="https://www.dropbox.com/s/botipxxf1mts5lo/frs_asm.rar" target="_blank">frs_asm.rar</a> &amp; <a href="https://www.dropbox.com/s/5con9udknknpov3/frs_C.rar" target="_blank">frs_C.rar</a></li><br /> <li><a href="https://www.dropbox.com/s/lndmpiryplwvnc8/stait_C.rar" target="_blank">stait_C.rar</a></li><br /> <li><a href="https://www.dropbox.com/s/mb7odftlb35l3ir/xentr_C.rar" target="_blank">xentr_C.rar</a></li><br /> <li><a href="https://www.dropbox.com/s/zl6plyeut9xalna/fakeds_C.rar" target="_blank">fakeds_C.rar</a></li><br /></ol><br /><br /><p><br /><strong>Спасибо</strong><br /><p><b>izee</b>, который помогал в подготовке данного текста и в других тонких моментах. А также приветы <b>izee, Dark Prophet, fAMINE</b> и всем другим вирмэйкерам.<br /><br /><br /><div style="text-align:left"><font size="-2"><a href="http://lj.rossia.org/users/pr0mix/6311.html"><img src="http://lj.rossia.org/numreplies/pr0mix/6311" border=0 width=26 height=17 alt="number of comments" style="border:0px;" /> <strong>Comments</strong></a></font></div> http://lj.rossia.org/users/pr0mix/6311.html antivirus av aver bypass detection files static ав авер антивирус детект обход http://lj.rossia.org/users/pr0mix/5960.html Fri, 09 Aug 2013 21:05:00 GMT http://lj.rossia.org/users/pr0mix/5960.html Приятного времени суток!<br /><br />До выхода журнала уже совсем немного времени. Остаётся шанс принять участие всем решительным и творческим людям в поддержании традиций. Мы можем объединить усилия, расширить свои знания и сделать журнал вместе и лучше!<br /><br />--<br />крайний срок подачи материала: <b>10 октября</b><br />выпуск же состоится <b>15 октября</b><br /><br />ps: мы до сих пор наивно полагаем, что существуют ещё люди, стремящиеся показать свои знания и внести достойный вклад.<br /><br /><div style="text-align:left"><font size="-2"><a href="http://lj.rossia.org/users/pr0mix/5960.html"><img src="http://lj.rossia.org/numreplies/pr0mix/5960" border=0 width=26 height=17 alt="number of comments" style="border:0px;" /> <strong>Comments</strong></a></font></div> http://lj.rossia.org/users/pr0mix/5960.html e-zine vx zine http://lj.rossia.org/users/pr0mix/5864.html Thu, 04 Jul 2013 21:24:30 GMT http://lj.rossia.org/users/pr0mix/5864.html Здарова!<br /><br />Приглашаем всех желающих принять участие в создании <b>e-zine</b>. Без комерца, цензуры и прочей хуйни. Есть отличная возможность сделать эту тему вместе!<br /><br /><b>тематика</b>: vx и около-vx (кодинг, реверс, сети, криптография, обзоры, арт (...) )<br /><b>стиль написания</b> материала - любой;<br /><b>стафф</b> не должен быть ранее нигде опубликован<br /><br /><b>дедлайн</b>: 3 месяца<br /><br />ps: стафф уже есть и всё серьёзно =))<br /><br />Контакт один: <b>ezine31337@gmail.com</b><br /><br /><div style="text-align:left"><font size="-2"><a href="http://lj.rossia.org/users/pr0mix/5864.html"><img src="http://lj.rossia.org/numreplies/pr0mix/5864" border=0 width=26 height=17 alt="number of comments" style="border:0px;" /> <strong>Comments</strong></a></font></div> http://lj.rossia.org/users/pr0mix/5864.html e-zine vx zine http://lj.rossia.org/users/pr0mix/5288.html Fri, 08 Feb 2013 16:27:28 GMT http://lj.rossia.org/users/pr0mix/5288.html Re:)<br /><br />Изучая сорцы разных дизасмов, пришел к выводу, что как такового алгоритма дизассемблирования нет (хм, где-то я это уже видел). Возможно, по этой причине хотящие написать свой дизасм и спрашивают "с чего начать?", "как это сделать?" и т.д. И вот, как-то ночью увидев топик с подобным вопросом, я и решил написать кое-что по этому поводу.<br /><br />Это своего рода справочная портянка для создания (простого) <b>дизасма</b>.<br /><br />Предполагается, что тот, кто собирается прочитать сей текст, знает формат команд <b>IA-32</b> (так как здесь он описан коротко). Если это не так, то сначала желательно просмотри ссылки в конце данного текста.<br /><br />Итак, поехали.<br /><br /><lj-cut><br />Для начала определение:<br /><br /><b><i>Машинные Команды</i></b> - это сформированные по определенным правилам последовательности байтов. Так вот, правила эти называют форматом команд, и формат этот в свою очередь состоит из нескольких полей, <b>ОБЯЗАТЕЛЬНЫМ</b> из которых является <b><i>код операции (опкод)</i></b>. Остальные поля могут отсутствовать (тогда команда содержит только 1 байт - опкод). Формат команд IA-32:<br /><br /><b><i>ПРЕФИКС ОПКОД МОДРМ СИБ СМЕЩЕНИЕ НЕПОСРЕДСТВЕННЫЙ ОПЕРАНД</i></b><br /><br />А вот, собственно, вариант дизассемблирования:<br /><ol><br /><li>Определение префиксов команды</li><br /><li>Опкод (разбор)</li><br /><li>Парсинг ModR/M</li><br /><li>Парсинг SIB</li><br /><li>Смещение и непосредственный операнд</li><br /></ol><br />Теперь по порядку.<br /><br /><b>1. ОПРЕДЕЛЕНИЕ ПРЕФИКСОВ КОМАНДЫ.</b><br /><br />Префиксы - необязательные <b>однобайтные</b> элементы машинной команды, и в своем дизасме их также следует определять как <b>однобайтные</b> конструкции. В памяти - предшевствуют команде. Порядок следования префиксов может быть любым, а также может играть или не играть вообще никакой роли.<br /><br />Префиксы делятся на 4 группы:<br /><ul type="circle"><br /><li>блокировки шины (LOCK - 0F0h) & повторения(REP или REPE/REPZ - 0F3h, REPNE/REPNZ - 0F2h)</li><br /><li>замены сегмента (CS - 2Eh, SS - 36h, DS - 3Eh, ES - 26h, FS - 64h, GS - 65h)</li><br /><li>размера оперенда (66h)</li><br /><li>размера адреса (67h)</li><br /></ul><br />Максимальная длина команды равна <b>15</b> байтам. Все 15 байт префиксами быть не могут (почему? - вспоминаем про опкод:) - по ходу возникнет #UD (недействительный код операции). LOCK можно использовать только один раз и только с определенными командами. REP/E/NE - могут использоваться с командами обработки срок, могут быть частью команд из расширенного набора или вообще "быть не при делах". Разрешено многократное использование данных префиксов, однако это будет равносильно однократному + использоваться будет последний встреченный. 2 группа префиксов - по идее также используется последний встреченный. Здесь же: 2Eh и 3Eh (появились в Pentium 4 & Xeon) - еще и определяют (только с инструкциями Jcc):<br /><ul type="circle"><br /><li>2Eh - переход выполняется;</li><br /><li>3Eh - переход не выполяется.</li><br /></ul><br />Префиксы 66h/67h изменяют разрядность операнда/адреса: 16 или 32 бита, а также могут быть частью команд из расширенного набора. При создании дизасма - быть внимательным к этим префиксам(блин, и к другим тоже). В общем, здесь все. Остальное - внимательное изучение доков от Intel.<br /><br /><b>2. ОПКОД (РАЗБОР).</b><br /><br />Код оперции (опкод) - <b>обязательный</b> элемент, описывающий операцию, выполняемую командой. Может занимать 1,2,3 байта, а также и часть битов для некоторых машинных команд в байте ModR/M (о нем чуть ниже).<br /><br />Опкод не имеет однозначной структуры. В зависимости от определенных команд может иметь от 1 до 3 элементов, уточняющих детали операции:<br /><ul type="circle"><br /><li>d - направление передачи данных</li><br /><li>s - расширение <b>непосредственного операнда</b></li><br /><li>w - размер данных</li><br /><li>reg - регистр</li><br /></ul><br /><br />Бывают ситуации, что после разбора опкода надо вернуться к пункту 1 (посмотреть на выделенные префиксы - для некоторых команд из расширенного набора - но и это решается).<br /><br />Теперь, собственно, о декодировании команд. Так вот, лучше всего декодировать по <b>характеристикам</b> опкода. Как это делается? Тут есть несколько вариков: можно искать опкод<br /><ol><br /><li>кучей <b>if{} else{}</b>, и если нашли - установить соответствующие флаги (характеристики) - это имеющиеся в данном опкоде поля, набор параметров и другие.</li><br /><li><b>switch</b> (аналог <b>if/else</b>) - тогда их будет 2: 1-ый - для однобайтных опкодов, а 2-ой - для 0x0F, и также, при нахождении данного опкода выставлять соответствующие флаги. Но, по-моему, лучше вариант <b>#3</b>, а именно: </li><br /><li>соcтавить таблицы, содержащие <b>Характеристики уже всех</b> опкодов. Некоторые спрашивают, как же создаются эти самые таблицы и как узнать, какие из характеристик соответствуют какому опкоду? Так вот, таблицы (массивы) строятся так, чтобы опкод команды был <b>ИНДЕКСОМ</b> (индексом в массиве) элемента, описывающего данный опкод. Дизасм выбирает характеристики опкода из таблицы, после чего декодирует опкод уже по набору этих характеристик. Насчет характеристик: все находится в мануалах <i>Intel (IA-32 Intel Architecture Software Developer's Manual Volume 2B Instruction Set Reference N-Z</i> - где-то в конце книги <i>Appendix A Opcode Map</i>). Короче, приведу несколько примеров:<br /><br /><i>Opcode&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Instruction&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Des<wbr />cription<br />88 /r&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MOV r/m8,r8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Move r8 to r/m8<br />C6 /0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MOV r/m8,imm8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Move imm8 to r/m8<br /><br />88 /r&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MOV r/m8,r8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Move r8 to r/m8<br />C6 /0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MOV r/m8,imm8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Move imm8 to r/m8</i></li><br /></ol><br />Вспоминаем, что означают условные знаки "/r", "rb","/0", "r8", "imm32", etc.<br /><br />Обозначим, например, наличие ModR/M в команде как B_MODRM equ 01h, а наличие непосредственного однобайтного значения(imm8) как B_DATA8.<br /><br />Так, для опкода 0x88 выставлено "/r" - это означает, что ModR/M задаёт оба операнда (регистр и r/m) - значит выставляем флаг B_MODRM. Улавливаешь мыслю? Еще пример: опкод 0xC6. Напомню: "/0" говорит о том, что поле Reg в ModR/M всегда равно 0. Видно, что здесь также присутствует ModR/M. Но, еще здесь есть "imm8" - значит опкод 0xC6 будет содержать следующие характеристики: B_MODRM+B_DATA8. И так далее.<br /><br /><b>3. РАЗБОР ModR/M.</b><br /><br />Байт ModR/M несет информацию об операндах и режиме адресации и состоит из следующих полей:<br /><ul type="circle"><br /><li>mod</li><br /><li>Reg/Opcode (обычно называют Reg)</li><br /><li>R/M</li><br /></ul><br />Поле mod - определяет режим адресации и количество байтов поля СМЕЩЕНИЯ в команде. Поля Reg и R/M обычно служат для указания операндов. Следует уточнить, что в Reg для некоторых команд может кодироваться расширение опкода.<br /><br /><b>mod address</b><br /><br /><b>00b</b> [reg] - если reg==5, то сразу за modrm идет 32-битное смещение - если reg==4, то сразу за modrm идет байт SIB<br /><br /><b>01b</b> [reg+8-битное смещение] - если reg==4, то сразу за modrm следует байт SIB<br /><br /><b>10b</b> [reg+32-битное смещение] - если reg==4, то сразу за modrm следует байт SIB<br /><br /><b>11b</b> reg<br /><br />С префиксом 0x67 32-битное смещение превратится в 16-битное. Также при наличии 0x67, если mod=0, rm=6 (110b), то за modrm идет 16-битное смещение.<br /><br /><b>4. РАЗБОР SIB (Scale-Index-Base).</b><br /><br />Этот байт используется для расширения возможности адресации операндов. Его присутствие можно определить из байта ModR/M (смотри выше, как). SIB состоит из 3-х полей:<br /><ul type="circle"><br /><li>scale</li><br /><li>Index</li><br /><li>Base</li><br /></ul><br />С помощью байта SIB можно задавать выражения вида [reg1+reg2*scale+СМЕЩЕНИЕ]. Структура SIB:<br /><br />Биты 6-7: scale<br /><ul type="circle"><br /><li>00b - 1</li><br /><li>01b - 2</li><br /><li>10b - 4</li><br /><li>11b - 8</li><br /></ul><br />Биты 3-5: reg2 - если reg2 == 4, то reg2 не используется<br /><br />Биты 0-2: reg1 - если reg1==5 и если mod в ModR/M равен 00, то за сразу SIB идет 32-битное смещение, иначе ebp<br /><br />Важно: в 16-разрядном режиме (0x67) байта SIB <b>нет</b>!<br /><br /><b>5. СМЕЩЕНИЕ и НЕПОСРЕДСТВЕННЫЙ ОПЕРАНД.</b><br /><br />Эти поля - 8, 16 или 32-разрядные числа. Разрядность определяется по характеристикам опкода + префиксам (0x67/0x66).<br /><br />Также, хотелось бы черкануть пару слов о дизасмах в вирусах. Такую силу должен иметь каждый нормальный вирь:) Пока еще большинство прог (но не все!) юзают стандартные & fpu команды. Поэтому задумайся - так ли тебе нужны хери типа mmx, sse1/2/3? Дизассемблер должен быть быстр и предельно компактен - короче оптимизация во все щели. Но, как это часто случается, страдает либо морда, либо жопа. Компактен - не означает, что после написания движка к нему хер прикрутишь новые команды. Это важно. И естесственно, код должен быть базонезависимым.<br /><br />В общем, вот такие помидоры. В данном тексте я написал только некоторую часть тех вещей, с которыми может столкнуться писатель дизасма. Так как существуют еще и такие проблемы, как разделение кода и данных, реакция на инвалидность команд, и. т.д.<br /><br />Добавлю, что для написания своего дизасма в первую очередь нужно решить - для чего он тебе нужен? Ну а потом уже штудировать маны от Intel + сорцы других движков. Удачи!<br /><br />P.S. Начать изучение сорсов можешь с моего простенького <a href="https://www.dropbox.com/s/z6zputqg54zn4zj/LiTo.zip" target="_blank">дизассемблера</a>.<br /><br />Используемые ссылки:<br /><ul type="circle"><br /><li><a href="http://www.wasm.ru/series.php?sid=16" target="_blank">заклинание кода</a></li><br /><li><a href="http://vx.netlux.org/lib/vzo02.html" target="_blank">Дизассемблеры в вирусах</a></li><br /><li><a href="http://vx.netlux.org/lib/vzo33.html" target="_blank">О дисассемблировании и битовых масках</a></li><br /><li><a href="http://www.intel.com/products/processor/manuals/" target="_blank">Volume 2A: Instruction Set Reference, A-M; Volume 2B: Instruction Set Reference, N-Z</a></li><br /><li>книга Юрова по ассемблеру</li><br /></ul><br />//pr0mix@mail.ru<br /><br /><br /><div style="text-align:left"><font size="-2"><a href="http://lj.rossia.org/users/pr0mix/5288.html"><img src="http://lj.rossia.org/numreplies/pr0mix/5288" border=0 width=26 height=17 alt="number of comments" style="border:0px;" /> <strong>Comments</strong></a></font></div> http://lj.rossia.org/users/pr0mix/5288.html disassembler дизасм дизассемблер http://lj.rossia.org/users/pr0mix/1810.html Fri, 13 Jan 2012 13:03:10 GMT http://lj.rossia.org/users/pr0mix/1810.html 01:<lj-cut><br /><b>articles</b><br /><a href="https://www.dropbox.com/s/j0ng8u1a80fj18j/dizasm.zip" target="_blank">Несколько слов о дизасмах</a> [<a href="http://lj.rossia.org/users/pr0mix/5288.html" target="_blank">rus</a>]<br /><a href="https://www.dropbox.com/s/tkrmi9d55kgfku2/sdf.zip" target="_blank">Статическое детектирование файлов</a> [<a href="http://lj.rossia.org/users/pr0mix/6311.html" target="_blank">rus</a> / eng]<br /><a href="https://www.dropbox.com/s/s2lpjd6a1ctzj69/ltt.zip" target="_blank">Умный мусор: построение логики</a> [<a href="http://lj.rossia.org/users/pr0mix/6634.html" target="_blank">rus</a> / <a href="http://vxheaven.org/lib/vpo01.html" target="_blank">eng</a>]<br /><a href="https://www.dropbox.com/s/bmaq64rsvozmism/dllhijack.zip" target="_blank">DLL Hijacking в антивирусах</a> [<a href="http://lj.rossia.org/users/pr0mix/6972.html" target="_blank">rus</a> / <a href="http://vxheaven.org/lib/vpr02.html" target="_blank">eng</a>]<br /><a href="https://www.dropbox.com/s/b11hzxa5j7ymg9f/avcheck.zip" target="_blank">Ещё раз об АВ-чекере</a> [<a href="http://lj.rossia.org/users/pr0mix/7287.html" target="_blank">rus</a> / <a href="http://vxheaven.org/lib/vpr03.html" target="_blank">eng</a>]<br /><br /><b>viruses</b><br /><a href="https://www.dropbox.com/s/ams8ewk0i7kjd78/atix.zip" target="_blank">win32.atix</a> <small>- полиморфный, резидентный на процесс, uep вирус, содержащий анти-отладочные/эвристические/эмуляционн<wbr />ые/etc приёмы, инфектящий файлы методом расширения предпоследней/последней секции (rebuild .rsrc), etc</small><br /><a href="https://www.dropbox.com/s/bcgdom53fusp7pr/spectr0.zip" target="_blank">win32.spectr0</a> <small>- простой метаморфный зверь, из основных фич: рандомная перестановка блоков кода, регистров, замена некоторых команд и т.д. Использует движки SPECTR (swap reg motor) и LiTo (disassembler engine)</small><br /><a href="https://www.dropbox.com/s/lwxdot42k9e51kt/XtaiL.zip" target="_blank">win32.XtaiL</a> <small>- зверёк, инфектит файлы методом размазывания своего тела по концам секций</small><br /><a href="https://www.dropbox.com/s/vglxu2z9cjrkr6x/0x02.zip" target="_blank">win32.0x02</a> <small>- простой PE32-вирус. Написан как пример на С</small><br /><br /><b>engines</b><br /><a href="https://www.dropbox.com/s/6xo2ybeorqy4ym6/dhv101.zip" target="_blank">DIZAHEX Disassembler Engine x86/x86-64 v1.0.1</a> <small> - small disassembler engine v1.0.1</small><br /><a href="https://www.dropbox.com/s/o8bqtk2q0xxuu9u/dhv10.zip" target="_blank">DIZAHEX Disassembler Engine x86/x86-64 v1.0</a> <small> - small disassembler engine v1.0</small><br /><a href="https://www.dropbox.com/s/n8i0n1ac1d7xrvx/irpev10.zip" target="_blank">iRPE v1.0</a> <small>- It's Real Polymorph Engine (on base xTG v2.1.1 engine)</small><br /><a href="https://www.dropbox.com/s/omtzzdcmsfxrefo/xtgv211.zip" target="_blank">xTG v2.1.1</a> <small>- eXecutable Logical Trash Generator (engines: xTG, RANG32, FAKA + Logical Trash Technique)</small><br /><a href="https://www.dropbox.com/s/l0nllfrgev7mkvn/xTG2.zip" target="_blank">xTG2</a> <small>- eXperimental/eXtended/eXecutable Trash Generator. xTG v2.0.0 (+ RANG32 v1.0.2, + FAKA v2.0.0, Logical Trash Technique)</small><br /><a href="https://www.dropbox.com/s/ingeuxtk3f79dx1/xTG1.zip" target="_blank">xTG1</a> <small>- генератор исполнимого мусора (+ RANG32, + FAKe Api Generator (FAKA)). v1.0.1</small><br /><a href="https://www.dropbox.com/s/hfouimomsf9aauh/FLEA.zip" target="_blank">FLEA</a> <small>- UEP-мотор. Генерация рандомного числа пятен, а также их случайное расположение и вызовы; техника неизлечимости и др.</small><br /><a href="https://www.dropbox.com/s/mxrv1u8cfizstw0/FinE.zip" target="_blank">FinE</a> <small>- полиморфный двигатель. v1.0.1</small><br /><a href="https://www.dropbox.com/s/k8q8tvljkdjg4zu/spectr.zip" target="_blank">SPECTR</a> <small>- простой метаморфный движок. Рэндомная перестановка регистров, замена коротких переходов на длинные, замена некоторых команд и т.д.</small><br /><a href="https://www.dropbox.com/s/mz4839g8lxdtdec/rang32.zip" target="_blank">RANG32</a> <small>- генератор случайных чисел. v1.0.1</small><br /><a href="https://www.dropbox.com/s/z6zputqg54zn4zj/LiTo.zip" target="_blank">LiTo</a> <small>- дизассемблер (C и asm)</small><br /><br /><b>etc</b><br /><a href="https://www.dropbox.com/s/m4qjbzvnpvtyjuf/fakeds.zip" target="_blank">fakeds</a> <small>- прога для работы с ЭЦП (проверка, удаление, выдирание, добавление фэйковой digital signature)</small><br /><a href="https://www.dropbox.com/s/84b0f4qot53dp8y/xentr.zip" target="_blank">xentr</a> <small>- вычисление энтропии файлов (+ пара фичезов)</small><br /><a href="https://www.dropbox.com/s/7kd9ng8l3tov4z1/stait.zip" target="_blank">stait</a> <small>- статистический анализ(атор) таблицы импорта</small><br /><a href="https://www.dropbox.com/s/elhr6xxd2isdb7v/frs.zip" target="_blank">frs</a> <small>- aлгоритмы проверки rich-signature на целостность, подмены ее данных, а также её генерации с нуля (asm/C)</small><br /><a href="https://www.dropbox.com/s/d9b63mi6knvar5n/PE-infectors.zip" target="_blank">PE-infectors</a> <small>- простые PE-инфекторы (C и asm)</small><br /><br /><b>zines</b><br /><a href="https://www.dropbox.com/s/7cvov3zc8ot24m4/eof_3.rar" target="_blank">EOF#3</a>, <a href="https://www.dropbox.com/s/5itl010oqv4f6tz/valhalla2.zip" target="_blank">Valhalla#2</a>, <a href="https://www.dropbox.com/s/hm6b2pkj5ib8r38/inception_ru.zip" target="_blank">Inception-rus</a>, <a href="https://www.dropbox.com/s/9f1wrvpvzblcf25/inception_en.zip" target="_blank">Inception-eng</a><br /><br /><b>interviews</b><br />SPTH <a href="https://www.dropbox.com/s/9a1tny8hmnoiyre/intrv1.txt" target="_blank">"Interview with pr0mix"</a> for <a href="https://www.dropbox.com/s/5itl010oqv4f6tz/valhalla2.zip" target="_blank">Valhalla #2 e-zine</a> <br /><br /><b>links</b><br /><a href="http://vxheaven.org" target="_blank">VX Heaven</a><br /><a href="http://wasm.ru" target="_blank">WASM</a><br /><a href="http://z0mbie.host.sk" target="_blank">Z0MBiE's HomePage</a><br /><a href="http://lj.rossia.org/users/herm1t" target="_blank">herm1t LIVE!ng room</a><br /><a href="http://spth.virii.lu" target="_blank">SPTH's Artworks</a><br /><br /><br /><b>Новости</b>:<br />29.10.2013 <a href="https://www.dropbox.com/s/6xo2ybeorqy4ym6/dhv101.zip" target="_blank">DIZAHEX Disassembler Engine v1.0.1</a><br />22.10.2013 New Engines: <a href="https://www.dropbox.com/s/omtzzdcmsfxrefo/xtgv211.zip" target="_blank">xTG v2.1.1</a>, <a href="https://www.dropbox.com/s/n8i0n1ac1d7xrvx/irpev10.zip" target="_blank">iRPE v1.0</a>, <a href="https://www.dropbox.com/s/o8bqtk2q0xxuu9u/dhv10.zip" target="_blank">DIZAHEX v1.0</a><br />15.10.2013 Inception E-Zine [<a href="https://www.dropbox.com/s/hm6b2pkj5ib8r38/inception_ru.zip" target="_blank">rus</a> / <a href="https://www.dropbox.com/s/9f1wrvpvzblcf25/inception_en.zip" target="_blank">eng</a>] выпуск!<br />01.07.2013 Пилим <a href="http://lj.rossia.org/users/pr0mix/5864.html" target="_blank">журнал</a>, вливайся!<br />01.04.2013: :p<br /><br /><div style="text-align:left"><font size="-2"><a href="http://lj.rossia.org/users/pr0mix/1810.html"><img src="http://lj.rossia.org/numreplies/pr0mix/1810" border=0 width=26 height=17 alt="number of comments" style="border:0px;" /> <strong>Comments</strong></a></font></div> http://lj.rossia.org/users/pr0mix/1810.html m1x pr0m1x pr0mix vx http://lj.rossia.org/users/pr0mix/538.html Wed, 10 Aug 2011 18:00:29 GMT http://lj.rossia.org/users/pr0mix/538.html Постоянно идут рассуждения/говноспоры о жизни/смерти какой-либо технологии/… Вставлю тут и своё мнение, а именно: технологии приходит капец, когда её перестаёт юзать какой-то чел. И умерла она только для него =). Для остальных же людей (в теме) она живее всех живых: развивается и применяется. <br /><br />Другое дело, когда технология становится неэффективной (может только для конкретной задачи?). Однако, в купе с какой-нить фичей технология может обрести «новое дыхание». Или же стать частью другой, ещё большей технологии. Вариантов много. <br /><br />Так что, кто захочет — сможет, кому впадлу — заплачет.<br /><br /><div style="text-align:left"><font size="-2"><a href="http://lj.rossia.org/users/pr0mix/538.html"><img src="http://lj.rossia.org/numreplies/pr0mix/538" border=0 width=26 height=17 alt="number of comments" style="border:0px;" /> <strong>Comments</strong></a></font></div> http://lj.rossia.org/users/pr0mix/538.html technology технология