Как это делается? Посидел и просто восстанавливал код, убирая полиморф (различные вариации на тему безусловного перехода, изменение значений регистров с последущей восстановкой, etc. Все стандартно, простой полиморф), но кода там много. Уже нашел пару повторяющихся фрагментов (это опкоды ВМ), но анализировать так весь код - этож какое терпение и внимательность нужна. Неужели не продвинулся анализ в сторону более автоматического? Какие нибудь программы, помогающие анализирующему? И что хорошего можно почитать на тему "Проектирование ВМ", "Написание ВМ"?
Общая схема такая: disassembler -> AI -> assembler Под AI может скрываться как банальный фильтр(ы) мусорных команд, так и ох.енный анализатор. Более-менее приличный полиморф не позволит дизассемблировать весь код целиком, в общем случае, анализатор должен применяться даже на стадии дизассемблирования, т.к. команды ветвлений/переходов/вызовов также могут быть поморфены. Ассемблер может быть и не для всех команд, но для rel-команд -- must have, т.к. большинство полиморфиков rel'ы перестраивают. Многие полиморфики любят разбивать поток, начиная от тупого перемешивания JMP'ами (например, guardant api), до схем посложнее, например split'ы в execryptor'е. Почитать на эту тему можно (скорее всего) во всяких вирмэйкерских журналах, но там на тему создания, а не декодирования. Вряд ли можно найти 'на почитать' что-нибудь стоящее, равно как и готовые проги для декодрования, которые б пригодились. Борьба с полиморфом -- это как и спасение утопающих, личное дело самих борцов.
Про выкрутасы полиморфных движков мне известно. Меня больше волнует ВМ (виртуальная машина). С чего начинать, неужели проходить весь код пока не получишь все команды машины? Как распознать тип машины, какие вообще есть типы машин (читал что стековые и регистровые). Слабо верится что разработчики каждый раз с нуля пишут свои ВМ, скорее всего на что-то опираются. Вот хотелось бы тоже этих знаний.
Ну, есть несколько к подходов к вм: 1) Эмулятор процессора. (для каждой команды существует процедура ее эмуляции). Снимается легко. 2) Микрокодовая вм. (каждая команда разбивается на последовательность микроопераций, сама вм имеет только несколько элементарных команд) Если нет обфускатора, то тоже относительно нетрудно снимается, но с обфускатором все гораздо хуже потому, что невозможно однозначно восстановить код. 3) Макрокодовая ВМ. (каждая команда ВМ выполняет одновременно много сложных действий и может быть представлена большим куском кода). Такие ВМ содержат очень много команд и разбираются весьма тяжело. 4) HLL ВМ. (код для ВМ генерируется не из машинного кода, а пишется вручную на каком-нибудь скриптовом языке программирования). Это получается что-то типа p-code в VB. Но в любом случае тебе придется разобрать исполнитель ВМ полностью и вникнуть в алгоритмы ее работы.
Может быть у этой вм есть название? А вобще ты попал , подумай стоит ли трать на это свое время? а времени ты потратиш многа Все зависит от задач которые ты перед собой ставиш, если тебе надо распаковать, защищаемый этой вм код, тогда можна реализовать это только с помощью отладчика, (при условии что нет серьезной анти отладки). Если же часть функций защищаемого кода перенесены на вм, тут дело обстоит по сложнее, но одно могу сказать что именно эти функции будут не полиморфными на 90%, так как реализовать это охрененно сложно, т.е. эти функции в п-коде но не мутируют, их тоже можна найти и расклеить в натив. Если же основная часть кода лежит на мутирующей вм, даже если ты найдеш проверяющие фукции, пофиксить их будет крайне сложно ввиду мутации. Декомпилить п-код как сказал BC дело гиблое т.к. 99% сам п-код тоже меняется. Скорее всего тебе нужно будет изучить порядок мутаций программы и порядок мутаций п-кода, и опираясь на это сделать декомпил, после этого будеш долго и муторно резать и собирать прогу по кускам, и после этого ты поймеш что проще такую прогу написать с нуля но а вобще удачи еще почитай Криса, по мойму назыается Техника и Философия хакерских атак, он там немного об этом расказывает. не хочу обидеть автора если неправильно сказал название книги, у меня крайне плохая память на название книг и на ФИО авторов этих книг
Ну а всеж таки, загляни на http://www.nf-team.org/drmad/zf/zf5/index.html. Вдруг найдешь пищу для мозгов по сабжу топика?
Меня просто интересует, как обычно выглядит структура. Например, берем простую ВМ - старый VM Protect. Там сам цикл машины такой: Код (Text): seg000:0026F000 VMProc: seg000:0026F000 pushf seg000:0026F001 pusha seg000:0026F002 push 0 seg000:0026F007 mov esi, [esp+28h] seg000:0026F00B mov edx, offset VM_mem seg000:0026F010 cld seg000:0026F011 call GetCurrentThreadId seg000:0026F017 mov ebx, eax seg000:0026F019 mov ecx, 100h seg000:0026F01E mov edi, edx seg000:0026F020 repne scasd seg000:0026F022 jz short loc_26F031 seg000:0026F024 mov eax, 100h seg000:0026F029 xchg eax, ecx seg000:0026F02A mov edi, edx seg000:0026F02C repne scasd seg000:0026F02E mov [edi-4], ebx seg000:0026F031 seg000:0026F031 loc_26F031: seg000:0026F031 mov ebp, edi seg000:0026F033 sub edi, edx seg000:0026F035 shl edi, 4 seg000:0026F038 lea edi, [edx+edi+3C0h] seg000:0026F03F mov ebx, esi seg000:0026F041 sub ebx, [esp] seg000:0026F044 seg000:0026F044 machine_loop: seg000:0026F044 lodsb seg000:0026F045 add al, bl seg000:0026F047 rol al, 7 seg000:0026F04A sub al, 72h seg000:0026F04C xor al, 27h seg000:0026F04E rol al, 1 seg000:0026F050 sub al, 55h seg000:0026F052 rol al, 2 seg000:0026F055 add al, 3Fh seg000:0026F057 rol al, 5 seg000:0026F05A add al, 5Eh seg000:0026F05C xor al, 4 seg000:0026F05E add al, 90h seg000:0026F060 xor al, 9Ah seg000:0026F062 add bl, al seg000:0026F064 movzx eax, al seg000:0026F067 jmp VM_table[eax*4] На вход процедуры поступает адрес блока, содержащего команды машины (процедура, переведеная в ВМ). Где VM_table содержит код для каждой команды ВМ. Причем это (я так понял) стековая ВМ: тоесть каждая команда берет данные из стека, преобразовывает их, и ложит обратно в стек. Вот и хотелось бы описания реализаций разных ВМ: теории хоть немного. drmad Я чего-то не нашел там ничего про ВМ. Может в старых номерах?
_BC_ У меня код вообще другой: там нельзя понять (во всяком случае я пока не вник), где какая инструкция эмулируется. Код (Text): push eax ; opcode 000 push edi lea edi, dword ptr [101D1030h] movzx eax, byte ptr [edi+1Ah] lea edi, dword ptr [ebx+eax*4] mov dword ptr [edi], edx pop edi pop eax Вот этот участок отвечает за запись по адресу, взятому из таблицы по индексу, взятому из другой таблицы значения в EDX. Он там повторяется довольно часто, я пока для себя его назвал опкод 0. Вообще атомы (тоесть участки, выполняющие логически завершенную последовательность действий) видно стразу: Код (Text): push edi lea edi, dword ptr [101D1030h] movzx edx, byte ptr [edi+17h] lea edi, dword ptr [ebx+edx*4] mov edx, dword ptr [edi] pop edi и еще: Код (Text): push ecx push edx push edi lea edi, dword ptr [101D1030h] movzx ecx, byte ptr [edi+1] lea edi, dword ptr [ebx+ecx*4] mov ecx, dword ptr [edi] pop edi mov dl, cl shr ecx, 8 xor dl, cl rol dl, 1 shr ecx, 8 xor dl, cl rol dl, 1 shr ecx, 8 xor dl, cl rol dl, 1 and edx, 0FFh add eax, edx pop edx pop ecx И так далее. Проблема в том, что пока только значения берутся из одной области и ложатся в другую + некоторые преобразования. У меня сейчас идея такая: ловить вызов CreateFile (получает дескриптор драйвера, рабочие участки которого, кстати, тоже подвергнуты ВМ), далее ловить WriteFile, ReadFile и смотреть какие преобразования происходят с данными получеными из драйвера, если известно что на входе. А сам драйвер пока считать черным ящиком. Это позволит стразу перейти к сути, а то подготовительный код я еще дого буду трассировать такими темпами.
В том примере кстати не используется таблица адресов обработчиков опкодов, скрипт сам формирует смещения для выборки команды, плюс никаких imm-операндов в пкоде, они собираются по битам также самим скриптом.
Ms Rem NeoGuard. А там похожий принцип, или что? Почему сразу ссылка к StarForce? И где можно скачать что либо, защищенное этой "Фемидой"?
Потому что симптомы и код ВМ напоминают Star Force 1 Basic Edition. http://www.soft32best.com/soft/development/delphi/themida.shtml Фемида защищена сама собой, если охото, то распаковывай. И чем ты этот NeoGuard отлаживаешь то? Неужели имея драйвер он не портит отладочные прерывания.
Ms Rem Хм, возможно разработчики NeoGuard решили так "учесть" предыдущий опыт и использовали наработки StarForce. А возможно это общий подход при проектировании ВМ такого типа, кто знает. Только учти, что здесь я показываю код, "избавленый" от мусора, оставленного полиморфом. Возможно они взяли ВМ от StarForce и просто пропустили ее через свой полиморф. Опять же, кто знает. Либо у меня "простая" версия, либо разработчики посчитали что с исследователя и ВМ будет достаточно выше крыши. Поэтому SoftIce идет на ура. Впрочем "порча отладочных прерываний" меня остановила бы ненадолго.
Да уж, это точно не старфорс, раз полиморф только мусор оставляет. Хотя в Basic Edition так и было, вот StarForce Pro сильнее в разы.. Ну, просто портить прерывания это сакс, так как их легко востановить. На нах обычно вешают что-либо жизненно важное для защиты, например в третьем старфорсе ring0 ВМ вызывается через int 3. А если при этом еще и проверяются дескрипторы в IDT и код отвечающий за обработку этих прерываний, то запустить отладчик становиться не так уж просто.
Ms Rem Ну там не мусор, а путаный код + обманные изменения. Все это направлено на исключение автоматического анализатора. Пример: Код (Text): .text:10006D5A pushf .text:10006D5B call loc_1001D0A8 .text:1001D0A8 loc_1001D0A8: .text:1001D0A8 lea esp, [esp+4] .text:1001D0AC popf .text:1001D0AD push ebp .text:1001D0AE mov ebp, esp .text:1001D0B0 push ebx .text:1001D0B1 push ecx .text:1001D0B2 pushf .text:1001D0B3 call loc_100622E9 .text:100622E9 loc_100622E9: .text:100622E9 lea esp, [esp+4] .text:100622ED popf .text:100622EE push edx .text:100622EF push esi .text:100622F0 pushf .text:100622F1 call loc_1007842F Обманки с регистрами: 1 Код (Text): .text:10078434 xchg ebx, edx .text:10078436 xchg edx, ebx 2 Код (Text): .text:100AB118 pushf .text:100AB119 or ebp, ebp .text:100AB11B and edx, edx .text:100AB11D popf 3 Код (Text): .text:1008107F push ebx .text:10081080 mov ebx, ecx .text:10081082 mov ecx, eax .text:10081084 push ebx .text:10081085 pop ecx .text:10081086 pop ebx 4 Код (Text): .text:10081091 pushf .text:10081092 xor eax, ecx .text:10081094 xor ecx, eax .text:10081096 xor eax, ecx .text:10081098 xchg eax, ecx .text:10081099 popf etc... "Замороченый" безусловный переход: Код (Text): .text:100815B6 push 27005DC9h .text:100815BB jmp short loc_100815C0 .text:100815BB ; ---------------------------------------------------------------------- ----- .text:100815BD db 0E8h, 0E9h, 0FFh .text:100815C0 ; ---------------------------------------------------------------------- ----- .text:100815C0 .text:100815C0 push esi .text:100815C1 push edi .text:100815C2 mov esi, 85A3B1Fh .text:100815C7 sub [esp+8], esi .text:100815CB jmp short loc_100815CE .text:100815CB .text:100815CD align 2 .text:100815CE .text:100815CE loc_100815CE: .text:100815CE mov edi, 0F161F155h .text:100815D3 add [esp+8], edi .text:100815D7 mov edi, [esp] .text:100815DA mov esi, [esp+4] .text:100815DE add esp, 8 .text:100815E4 jmp short loc_100815EA далее через пару JMP'ов следует RETN Вот вариаций на вышеперечисленное там тьма. Я это обозвал полиморф ибо подозреваю что от DLL к DLL даный код меняется.
Да, правильно ты назвал это полиморфом, потому что на метаморф это явно не тянет. Морф на уровне вирусных движков, простое шаблонное кодирование. А автоматический анализатор к такому морфу даже без эмуляции легко сделать.
techgl Я чего-то не нашел там ничего про ВМ. Может в старых номерах? Теперь понятно - об чем топик. Нет, этого там нет. Есть немножко про то, что _BC_ назвал AI. Извиняюсь. З.Ы. А какой-то теории или общей структуры, имхо, просто нет. И практически невозможен автоматический анализ ВМ-движка.
знакомый очень код..... они в своем крякми такой же обфускатор применяли. большая часть мусора чистится автоматом, наверное можно и полностью на автомате, но при небольшом объеме кода можно и руками.
