Русский / Russian English / Английский

Сейчас на форуме: (+2 невидимых)
 · Начало · Статистика · Регистрация · Поиск · ПРАВИЛА ФОРУМА · Язык · RSS ·

 eXeL@B —› Протекторы —› Исследование защиты Themida
<< . 1 . 2 . 3 . >>
Посл.ответ Сообщение

Ранг: 16.0 (новичок)
Статус: Участник

Создано: 13 августа 2009 09:51 · Поправил: blueboar2 New!
Цитата · Личное сообщение · #1

Решил тут поразбираться со страшным зверем которого зовут Themida. Причем не так, как большинство - как бы получше сграбить дамп, чтоб проверки протектора обмануть, а именно по хакерски - дизассемблировать и понять структуру протектора.

Я понимаю, что в каждом случае штамм Themida отличается друг от друга (из-за ее возможностей, и разных настроек при запуске). Но не будете же вы спорить, что один раз ее дизассемблировав второй и последующие разы пойдут проще?

Как подопытный кролик пошел The Bat 4.0.24 (авторские права автора The Bat я не нарушаю, так как взламывать его прогу я не собираюсь, а сам использую Outlook). Естественно, пока я Themida не взломал, но несколько шагов уже сделал. Результаты моих изысканий оформил тут:

http://bigblueboar.narod.ru/kill_themida.rar

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




Ранг: 529.7 (!)
Статус: Участник
Победитель турнира 2010

Создано: 17 августа 2009 15:47 New!
Цитата · Личное сообщение · #2

blueboar2 пишет:
абсолютно идентичные виртуальные машины с одинаковыми же командами


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

Обфускация зависит от 4-х параметров:
- набор регистров используемых при обфускации;
- допустимость команд доступа к памяти при обфускации или только на регистрах и стеке;
- вложенность обфускации (степень обфускации) для каждого обфусцируемого участка своя (не зависит от случайного числа, а от metamorphic level)
- подмножество шаблонов обфускации (вот в рамках подмножества уже на случайном числе);

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



Ранг: 16.0 (новичок)
Статус: Участник

Создано: 17 августа 2009 16:52 · Поправил: blueboar2 New!
Цитата · Личное сообщение · #3

Не согласен! В том же топике, который вы мне указали, в первом посте есть ссылка на PDFку, где написано "Unless the 'fake' Virtual Opcodes, you can say that the Virtual Opcodes would be IDENTICAL if you protect an application twice and compare the Virtual Opcodes. What make them different, is a global variable in the Code Virtualizer, that i have called KEY". То есть, по нашему "Если не считать мусора (кодов, которые не делают ничего), то опкоды (ссылки в таблицу) всегда одинаковы! Они становятся разными лишь из-за разного начального и последующих ключей, которые находятся в регистре BL"

Или вы имеете в виду, что для каждой конкретной программы опкоды создаются на основании конкретных (не случайных) данных о ней - опкодах, контрольной суммы, защищаемых участков? То есть для одной и той же программы опкоды будут одинаковы (если не считать ключа), а для другой - другие

И еще вопрос - как вообще виртуализируются переходы? Каждая команда для получения опкода сначала взаимодействует с "ключом", а потом ключ изменяется. Следовательно при выполнении одного кода два раза (например, цикл), второй раз ключ ведь будет другой, а значит будет переход по другому опкоду?




Ранг: 529.7 (!)
Статус: Участник
Победитель турнира 2010

Создано: 17 августа 2009 17:32 New!
Цитата · Личное сообщение · #4

blueboar2 пишет:
на PDFку, где написано

информация февраля 2007 года - на тот момент когда была еще Фима 1.8.7.0, а исследовался Virtualizer с еще более старым ядром. Все меняется - на дворе Фима 2.1.0.0.

Опкодов одинаковых не будет!!!!
Исследуй...

В помощь код в чистом виде всех CISC хэндлеров, таблица по которой формируется виртуальная машина и код основного цикла (не настроенный - константы 11111111) из Фимы 2.0.3.0.


{ Атач доступен только для участников форума } - VM_CISC_Th2030.txt



Ранг: 16.0 (новичок)
Статус: Участник

Создано: 18 августа 2009 13:53 New!
Цитата · Личное сообщение · #5

Файл обновил. Теперь расшифровано три опкода, и небольшой кусок программы.

Вопрос OKOBу - я всегда считал, что Themida эмулирует 8 регистров - флаги и 7 обычных, кроме ESP. А ESP не эмулирует. Я прав?

Если я прав и ESP не эмулируется, то почему Themida переносит его из "реальных" в "виртуальные" регистры, как и все остальные?
А если я не прав, и ESP так же эмулируется, как и остальные регистры, почему тогда в списке Themida всего 8 эмулируемых регистров (EFlags имеет номер 07)? Или они в случайном порядке - и регистр EDX скажем будет номер 08?




Ранг: 529.7 (!)
Статус: Участник
Победитель турнира 2010

Создано: 18 августа 2009 16:19 New!
Цитата · Личное сообщение · #6

В контексте CISC VM регистра ESP нет.

00000000 SLcisc_VMContext struc ; (sizeof=0x44)
00000000 _ecx dd ?
00000004 _eax dd ?
00000008 _edx dd ?
0000000C _edi dd ?
00000010 _ebx dd ?
00000014 _esi dd ?
00000018 _ebp dd ?
0000001C _eflag dd ?

доступ к содержимому регистров в контексте осуществляется таким кодом

Code:
  1. mov     eax, [ebp+operand]
  2. sub     eax, 0F0000000h
  3. shr     eax, 3
  4. mov     eax, [edi+eax*4]




Ранг: 16.0 (новичок)
Статус: Участник

Создано: 20 августа 2009 12:29 New!
Цитата · Личное сообщение · #7

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

MOV CH, 5E / AND CH, D8 / JGE CB82

А что будет, если перейти, если не надо. Или не перейти если надо. Там в любом случае тонны обфусцированного кода - если перейти куда надо - все работает. А если наоборот - протектор выведет какую-нибудь ошибку? Или просто повиснет?




Ранг: 529.7 (!)
Статус: Участник
Победитель турнира 2010

Создано: 20 августа 2009 15:39 · Поправил: OKOB New!
Цитата · Личное сообщение · #8

blueboar2 пишет:
Еще вопрос

Вопрос риторический и скорее не основному форуму и разбору Фимы соответствует, а подфоруму вопросы новичков.

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

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



Ранг: 16.0 (новичок)
Статус: Участник

Создано: 21 августа 2009 10:47 New!
Цитата · Личное сообщение · #9

Деобфусцировал следующую команду. Вкратце (не считая ключа) - помещает прочитанный из потока байт по адресу [Начало_области_регистров + 28]. Что там есть? Видел, что эта область как-то участвует в обработке флагов, конкретно - битов 200000 и 800000 регистра EFLAGS.




Ранг: 154.2 (ветеран)
Статус: Участник
REVENGE Crew

Создано: 21 августа 2009 12:19 New!
Цитата · Личное сообщение · #10

blueboar2,

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



Ранг: 16.0 (новичок)
Статус: Участник

Создано: 21 августа 2009 13:11 New!
Цитата · Личное сообщение · #11

Я поступаю так: спрашиваю на форуме и начинаю разбираться сам одновременно. Если на форуме отвечают быстрее чем я разбираюсь, я принимаю ответ к сведению. Если я догадываюсь раньше, чем мне отвечают на форуме - я догадываюсь сам.

Поэтому если я что-то спрашиваю - это еще не значит что я этого не узнаю сам. Даже наоборот - все, что мне ответил OKOB я впоследствии узнал и сам. Просто иногда спросить на форуме быстрее. Но если вы считаете, что форум только для того, чтобы крякнуть темиду и написать "ураа, я крякнул! Какой я крутой" - ладно, не буду больше вопросов задавать.




Ранг: 154.2 (ветеран)
Статус: Участник
REVENGE Crew

Создано: 21 августа 2009 14:55 · Поправил: kioresk New!
Цитата · Личное сообщение · #12

blueboar2 пишет:
Но если вы считаете, что форум только для того, чтобы крякнуть темиду и написать "ураа, я крякнул! Какой я крутой" - ладно, не буду больше вопросов задавать.


Делаешь странные выводы из советов, хотя можно просто прислушаться к тому что тебе советуют.

Никто не говорит, что надо молчать в трубочку. Но тебе уже несколько раз сказали, что разумнее было бы как минимум ознакомиться с трудами людей, которые занимались этой задачей раньше — тогда бы большая часть вопросов просто бы отпала.

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

Постскриптум
Воспринимать исключительно как конструктивную критику.



Ранг: 16.0 (новичок)
Статус: Участник

Создано: 21 декабря 2009 08:13 · Поправил: blueboar2 New!
Цитата · Личное сообщение · #13

А вот и опять я . После продолжительного затишься снова вернулся. Файл http://bigblueboar.narod.ru/kill_themida.rar обновил. Там уже 9 опкодов (да, из 168, самому смешно) и пара-тройка десятков разобранных команд ВМ Themida

Очень понравилась эмуляция команды ADD ESP,4 . Преобразуется в 5!!! виртуальных опкодов. Причем - ладно бы - мусорных - для усложнения разброки, так нет - все нужно:

Команда 1: MOV REDX, ESP (REDX - нормальный регистр EDX, не виртуальный)
Команда 2: PUSH REDX
Команда 3: PUSH 4
Команда 4: ADD (сложить два числа на стеке - REDX (который ESP) и 4)
Команда 5: MOV ESP, [ESP]




Ранг: 2014.5 (!!!!)
Статус: Модератор
retired

Создано: 21 декабря 2009 18:19 · Поправил: Модератор New!
Цитата · Личное сообщение · #14

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



Ранг: 16.0 (новичок)
Статус: Участник

Создано: 22 декабря 2009 11:44 New!
Цитата · Личное сообщение · #15

А попродробнее? Что это за ВМ, как называется? Если она так известна и в куче протов используется?




Ранг: 673.3 (! !)
Статус: Участник
CyberMonk

Создано: 22 декабря 2009 16:50 New!
Цитата · Личное сообщение · #16

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



{ Атач доступен только для участников форума } - VMProtect VM.rar



Ранг: 16.0 (новичок)
Статус: Участник

Создано: 22 декабря 2009 19:00 New!
Цитата · Личное сообщение · #17

Тьфу ты. Вы про "стековую виртуальную машину" в принципе. Так это я знаю. Разбирал и не раз. Я думал есть какая то "особенная" стековая виртуальная машина - со своим набором команд - и именно ее все используют. А так то - да, именно стековые ВМ чаще всего используются. Более того - регистровых я еще и не видел




Ранг: 2014.5 (!!!!)
Статус: Модератор
retired

Создано: 22 декабря 2009 22:54 New!
Цитата · Личное сообщение · #18

Ну фактически стековая и имеет определённые характеристики, в частности, положить оба аргумента в стек, произвести действие, потом снять результат.
З.Ы. Регистровая в старфорсе, хотя там не совсем ВМ в прямом смысле этого слова. Но не будем уходить в оффтоп.




Ранг: 116.6 (ветеран)
Статус: Участник

Создано: 23 декабря 2009 09:01 New!
Цитата · Личное сообщение · #19

OKOB
___:0060B832 33 C0 xor eax, eax
___:0060B834 F0 0F B1 4F 30 lock cmpxchg [edi+SLcisc_VMContext.Busy], ecx
___:0060B839 75 F7 jnz short loc_60B832

В темиде до сих пор однопоточная ВМ?



Ранг: 16.0 (новичок)
Статус: Участник

Создано: 23 декабря 2009 14:27 New!
Цитата · Личное сообщение · #20

Не знаю как насчет поточности, но пока (50 инструкций от начала) многопоточностью и не пахнет . Возможно дальше.

BTW: Уже разобрано 14 команд



Ранг: 43.2 (посетитель)
Статус: Участник

Создано: 23 декабря 2009 14:30 New!
Цитата · Личное сообщение · #21

blueboar2 пишет:
регистровых я еще и не видел

АПИ Guardant 5.0 и ранние 5.1 - регистровая ВМ
позднее они перешли на стековую ВМ




Ранг: 116.6 (ветеран)
Статус: Участник

Создано: 23 декабря 2009 16:31 New!
Цитата · Личное сообщение · #22

blueboar2
Посмотри на цитату, которую. я привел из листинга OKOB-а. Пока ВМ занята обработкой кода потока, то все остальные потоки будут "курить" в этом цикле пока ВМ не освободится. Вот мне и интересно - неужели в темиде до сих пор такая убогая архитектура?




Ранг: 673.3 (! !)
Статус: Участник
CyberMonk

Создано: 23 декабря 2009 16:42 New!
Цитата · Личное сообщение · #23

blueboar2 Что значит многопоточностью не пахнет ? Если вы уже разобрали варианты многопоточности , то я бы послушал.

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

dermatolog почему такой вывод ?! Не знаю поэтому спрашиваю ...
вот например

Code:
  1. ___:0060B7F2                   ; ---------------------------------------------------------------------- -----
  2. ___:0060B7F2                   EBX - entry key
  3. ___:0060B7F2                   ESI - pcode pointer
  4. ___:0060B7F2                   EDI - contex pointer


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




Ранг: 116.6 (ветеран)
Статус: Участник

Создано: 23 декабря 2009 17:02 New!
Цитата · Личное сообщение · #24

mak пишет:
почему такой вывод ?! Не знаю поэтому спрашиваю ...

Скачай разобранный исполнитель из этого поста.
Вот это кусок из него:
Code:
  1. ___:0060B832 33 C0 xor eax, eax
  2. ___:0060B834 F0 0F B1 4F 30 lock cmpxchg [edi+SLcisc_VMContext.Busy], ecx
  3. ___:0060B839 75 F7 jnz short loc_60B832

Не трудно догадаться что здесь происходит ожидание когда ВМ освободиться. Освободжается она вот здесь:
Code:
  1. ___:0060AB40 C7 42 30 00 00 00+                mov     [edx+SLcisc_VMContext.Busy], 0
  2. ___:0060AB47 61                                popa
  3. ___:0060AB48 9D                                popf
  4. ___:0060AB49 C3                                retn

Если тебе все еще непонятнет смысл поля Busy в контексте ВМ, то объясню на пальцах - если 2 разных потока будут вызывать один и тотже исполнитель ВМ, то второй поток зайдя в исполнителе затрет контекст первого потока и в результате первый поток наибнецца. Поэтому чтобы такого не произошло аффтары темиды придумали вот такой вот финт ушами - второй поток будет ожидать завершение выполнения пикода первого потока и ТОЛЬКО после этого начнет выполняться сам. Вот такой вот подход к проектированию ВМ полностью убивает смысл многопоточности в приложении (при условии что разные потоки дергают один и тотжде исполнитель ВМ). ПОэтому я и спросил - в более новых версиях темиды все также работает через жопу или уже нет? )




Ранг: 673.3 (! !)
Статус: Участник
CyberMonk

Создано: 23 декабря 2009 17:23 · Поправил: mak New!
Цитата · Личное сообщение · #25

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

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




Ранг: 116.6 (ветеран)
Статус: Участник

Создано: 23 декабря 2009 17:37 New!
Цитата · Личное сообщение · #26

mak
Ты путаешь 2 совершенно разные вещи - многопоточность на уровне ОСи и многопоточность на уровне клиентского приложения. Планированием потоков (остановкой, запусками и т.п.) занимается ОСь и когда поток уже создан - ему больше не нужно думать над тем, а как же я бля все-таки живу. Тоже самое относится и к ВМ - ёй совершенно пофигу на то как живут потоки, которые её дергают. У ВМ темиды в силу своей непродуманной архитектуры (судя по 2.0.3) есть только одна проблема - это не дать разным потокам записать свой контекст в одну и туже "глобальную переменную" (читай контекст). Решал когда-нибудь задачу доступа из разных потоков к одной и тойже переменной? В общем задача решается с использованием критических секций (т.е. пока текущий поток не выйдет из этой секции в неё больше никто не зайдет). Дак вот тут тоже самое, только в роли критической секции выступает поле Busy в контексте ВМ.



Ранг: 16.0 (новичок)
Статус: Участник

Создано: 23 декабря 2009 18:05 New!
Цитата · Личное сообщение · #27

Так у разных потоков могут быть разные контексты? И у каждого потока EDI указывает именно на свой?




Ранг: 2014.5 (!!!!)
Статус: Модератор
retired

Создано: 23 декабря 2009 18:43 New!
Цитата · Личное сообщение · #28

Ясный красный, у разных потоков разный контекст. А вм действительно однопоточная, ибо на критических секциях самодельных построена.



Ранг: 500.5 (!)
Статус: Участник

Создано: 23 декабря 2009 19:05 New!
Цитата · Личное сообщение · #29

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




Ранг: 116.6 (ветеран)
Статус: Участник

Создано: 23 декабря 2009 19:06 New!
Цитата · Личное сообщение · #30

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

Какие нах "оптимальные решения доступа"? Надо полностью менять концепцию ВМ - хранилище под контекст должно быть потоконезависимым. А что у нас независимое между потоками? Пральна - это стек. Кто мешает хранить контекст ВМ на стеке? Никто. Сразу же отпадает гемор с "критическими секциями" и автоматически имеем многопоточную ВМ. Интересует реализация - кури исходники исполнителя ВМ от вмпротекта, которые ты сам сюда и выкладывал )




Ранг: 673.3 (! !)
Статус: Участник
CyberMonk

Создано: 23 декабря 2009 20:25 · Поправил: mak New!
Цитата · Личное сообщение · #31

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


<< . 1 . 2 . 3 . >>
 eXeL@B —› Протекторы —› Исследование защиты Themida

Видеокурс ВЗЛОМ