| Сейчас на форуме: (+7 невидимых) |
 |
eXeL@B —› Протекторы —› Исследование защиты Themida |
| << . 1 . 2 . 3 . >> |
| Посл.ответ | Сообщение |
|
|
Создано: 13 августа 2009 09:51 · Поправил: blueboar2 · Личное сообщение · #1 Решил тут поразбираться со страшным зверем которого зовут Themida. Причем не так, как большинство - как бы получше сграбить дамп, чтоб проверки протектора обмануть, а именно по хакерски - дизассемблировать и понять структуру протектора. Я понимаю, что в каждом случае штамм Themida отличается друг от друга (из-за ее возможностей, и разных настроек при запуске). Но не будете же вы спорить, что один раз ее дизассемблировав второй и последующие разы пойдут проще? Как подопытный кролик пошел The Bat 4.0.24 (авторские права автора The Bat я не нарушаю, так как взламывать его прогу я не собираюсь, а сам использую Outlook). Естественно, пока я Themida не взломал, но несколько шагов уже сделал. Результаты моих изысканий оформил тут: Собственно просьба к умным и знающим людям - где поправить, где наставить на путь истинный, а где и поругать. Я думаю, в конце концов мы таки разберемся в данном протекторе.  |
|
|
Создано: 17 августа 2009 15:47 · Личное сообщение · #2 blueboar2 пишет: абсолютно идентичные виртуальные машины с одинаковыми же командами Набор команд конкретной виртуальной машины зависит не от опций защиты, а от архитектуры виртуальной машины и от того подмножества кода которое виртуализировалось (машина не избыточна, т.е. хэндлеры команд, которые не использовались при виртуализации в машину не включаются. Вместо этого либо может быть дублирование хэндлера для одной и той-же команды или ссылки в таблице для разных опкодов на один хэндлер). Обфускация зависит от 4-х параметров: - набор регистров используемых при обфускации; - допустимость команд доступа к памяти при обфускации или только на регистрах и стеке; - вложенность обфускации (степень обфускации) для каждого обфусцируемого участка своя (не зависит от случайного числа, а от metamorphic level) - подмножество шаблонов обфускации (вот в рамках подмножества уже на случайном числе); опкод в данном случае лишь индекс в таблице хэндлеров. Таблица каждый раз строится и постоянной связи между хешированным значением опкода и хэндлером нет. ----- 127.0.0.1, sweet 127.0.0.1 |
|
|
Создано: 17 августа 2009 16:52 · Поправил: blueboar2 · Личное сообщение · #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" Или вы имеете в виду, что для каждой конкретной программы опкоды создаются на основании конкретных (не случайных) данных о ней - опкодах, контрольной суммы, защищаемых участков? То есть для одной и той же программы опкоды будут одинаковы (если не считать ключа), а для другой - другие И еще вопрос - как вообще виртуализируются переходы? Каждая команда для получения опкода сначала взаимодействует с "ключом", а потом ключ изменяется. Следовательно при выполнении одного кода два раза (например, цикл), второй раз ключ ведь будет другой, а значит будет переход по другому опкоду? |
|
|
Создано: 17 августа 2009 17:32 · Личное сообщение · #4 blueboar2 пишет: на PDFку, где написано информация февраля 2007 года - на тот момент когда была еще Фима 1.8.7.0, а исследовался Virtualizer с еще более старым ядром. Все меняется - на дворе Фима 2.1.0.0. Опкодов одинаковых не будет!!!! Исследуй... В помощь код в чистом виде всех CISC хэндлеров, таблица по которой формируется виртуальная машина и код основного цикла (не настроенный - константы 11111111) из Фимы 2.0.3.0.  866a_17.08.2009_CRACKLAB.rU.tgz - VM_CISC_Th2030.txt
----- 127.0.0.1, sweet 127.0.0.1 |
|
|
Создано: 18 августа 2009 13:53 · Личное сообщение · #5 Файл обновил. Теперь расшифровано три опкода, и небольшой кусок программы. Вопрос OKOBу - я всегда считал, что Themida эмулирует 8 регистров - флаги и 7 обычных, кроме ESP. А ESP не эмулирует. Я прав? Если я прав и ESP не эмулируется, то почему Themida переносит его из "реальных" в "виртуальные" регистры, как и все остальные? А если я не прав, и ESP так же эмулируется, как и остальные регистры, почему тогда в списке Themida всего 8 эмулируемых регистров (EFlags имеет номер 07)? Или они в случайном порядке - и регистр EDX скажем будет номер 08? |
|
|
Создано: 18 августа 2009 16:19 · Личное сообщение · #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:
----- 127.0.0.1, sweet 127.0.0.1 |
|
|
Создано: 20 августа 2009 12:29 · Личное сообщение · #7 Еще вопрос - периодически в процессе разбора обфусцированного кода, регистры загружаются константами, с ними происходят некоторые действия (но в результате опять же получается константа), и происходит (или не происходит) какой-нибудь переход, скажем MOV CH, 5E / AND CH, D8 / JGE CB82 А что будет, если перейти, если не надо. Или не перейти если надо. Там в любом случае тонны обфусцированного кода - если перейти куда надо - все работает. А если наоборот - протектор выведет какую-нибудь ошибку? Или просто повиснет? |
|
|
Создано: 20 августа 2009 15:39 · Поправил: OKOB · Личное сообщение · #8 blueboar2 пишет: Еще вопрос Вопрос риторический и скорее не основному форуму и разбору Фимы соответствует, а подфоруму вопросы новичков. Тем не менее ответ. Если команда условного принадлежит обфускации, то все будет нормально (скорее всего), если это реальная команда перехода, то в зависимости от ветвления в логике исходной программы. То можно так перейти, что действительно не надо было. Действия протектора самые разные как и другой любой программы в зависимости от контекста, от нарушения логики работы программы и подвисания до голубого экрана. Что касается возможных сообщений, то в прицепе у Фимы есть своя система обработки исключений (будет ли уже инициализирована на момент ошибки). ----- 127.0.0.1, sweet 127.0.0.1 |
|
|
Создано: 21 августа 2009 10:47 · Личное сообщение · #9 Деобфусцировал следующую команду. Вкратце (не считая ключа) - помещает прочитанный из потока байт по адресу [Начало_области_регистров + 28]. Что там есть? Видел, что эта область как-то участвует в обработке флагов, конкретно - битов 200000 и 800000 регистра EFLAGS. |
|
|
Создано: 21 августа 2009 12:19 · Личное сообщение · #10 blueboar2, Почитай еще раз тему с самого начала и о чем тебе писал OKOB и последуй его совету, если ты будешь при каждом затруднении спрашивать что и как, а не разбираться сам, то ты будешь долго возиться... |
|
|
Создано: 21 августа 2009 13:11 · Личное сообщение · #11 Я поступаю так: спрашиваю на форуме и начинаю разбираться сам одновременно. Если на форуме отвечают быстрее чем я разбираюсь, я принимаю ответ к сведению. Если я догадываюсь раньше, чем мне отвечают на форуме - я догадываюсь сам. Поэтому если я что-то спрашиваю - это еще не значит что я этого не узнаю сам. Даже наоборот - все, что мне ответил OKOB я впоследствии узнал и сам. Просто иногда спросить на форуме быстрее. Но если вы считаете, что форум только для того, чтобы крякнуть темиду и написать "ураа, я крякнул! Какой я крутой" - ладно, не буду больше вопросов задавать. |
|
|
Создано: 21 августа 2009 14:55 · Поправил: kioresk · Личное сообщение · #12 blueboar2 пишет: Но если вы считаете, что форум только для того, чтобы крякнуть темиду и написать "ураа, я крякнул! Какой я крутой" - ладно, не буду больше вопросов задавать. Делаешь странные выводы из советов, хотя можно просто прислушаться к тому что тебе советуют. Никто не говорит, что надо молчать в трубочку. Но тебе уже несколько раз сказали, что разумнее было бы как минимум ознакомиться с трудами людей, которые занимались этой задачей раньше — тогда бы большая часть вопросов просто бы отпала. Да и смысла исследовать защищенный файл, не анализируя код самого протектора (благо его постоянно релизят) тоже не много. Постскриптум Воспринимать исключительно как конструктивную критику. |
|
|
Создано: 21 декабря 2009 08:13 · Поправил: blueboar2 · Личное сообщение · #13 А вот и опять я  . После продолжительного затишься снова вернулся. Файл обновил. Там уже 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] |
|
|
Создано: 21 декабря 2009 18:19 · Поправил: Модератор · Личное сообщение · #14 В принципе ничего хитрого в этом нет, обычная стековая виртуальная машина, в вмпроте используется такая же. Т.е. такая логика уже заложена на уровне перевода кода в ВМ. В принципе, как и в большинстве проектов, колесо они не изобрели, а содрали достаточно известную ВМ, ибо ВМ должна обладать покрытием множества эмулируемых команд. |
|
|
Создано: 22 декабря 2009 11:44 · Личное сообщение · #15 А попродробнее? Что это за ВМ, как называется? Если она так известна и в куче протов используется? |
|
|
Создано: 22 декабря 2009 16:50 · Личное сообщение · #16  БлуБор , ты ее уже разбираешь , прочитай что такое стековая виртуальная машина по поиску ,это модель вычисления , и сравни с хэндлерами что ты разбираешь , реализация стэковой машины не случайна , так как она в разы ускоряет работу кода , в сравнении по тестам регистровая виртуальная машина работает очень медленно. Правда на сегодня уже полно альтернативных вариантов ускорения , проты будут прогрессировать 6db4_22.12.2009_CRACKLAB.rU.tgz - VMProtect VM.rar
----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube |
|
|
Создано: 22 декабря 2009 19:00 · Личное сообщение · #17 Тьфу ты. Вы про "стековую виртуальную машину" в принципе. Так это я знаю. Разбирал и не раз. Я думал есть какая то "особенная" стековая виртуальная машина - со своим набором команд - и именно ее все используют. А так то - да, именно стековые ВМ чаще всего используются. Более того - регистровых я еще и не видел
|
|
|
Создано: 22 декабря 2009 22:54 · Личное сообщение · #18 Ну фактически стековая и имеет определённые характеристики, в частности, положить оба аргумента в стек, произвести действие, потом снять результат. З.Ы. Регистровая в старфорсе, хотя там не совсем ВМ в прямом смысле этого слова. Но не будем уходить в оффтоп. |
|
|
Создано: 23 декабря 2009 09:01 · Личное сообщение · #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 В темиде до сих пор однопоточная ВМ? |
|
|
Создано: 23 декабря 2009 14:27 · Личное сообщение · #20 Не знаю как насчет поточности, но пока (50 инструкций от начала) многопоточностью и не пахнет . Возможно дальше.BTW: Уже разобрано 14 команд |
|
|
Создано: 23 декабря 2009 14:30 · Личное сообщение · #21 blueboar2 пишет: регистровых я еще и не видел АПИ Guardant 5.0 и ранние 5.1 - регистровая ВМ позднее они перешли на стековую ВМ |
|
|
Создано: 23 декабря 2009 16:31 · Личное сообщение · #22 blueboar2 Посмотри на цитату, которую. я привел из листинга OKOB-а. Пока ВМ занята обработкой кода потока, то все остальные потоки будут "курить" в этом цикле пока ВМ не освободится. Вот мне и интересно - неужели в темиде до сих пор такая убогая архитектура? |
|
|
Создано: 23 декабря 2009 16:42 · Личное сообщение · #23 blueboar2 Что значит многопоточностью не пахнет ? Если вы уже разобрали варианты многопоточности , то я бы послушал. Иногда пишут полная поддержка потоков , это значит вм должна иметь полный потоковый контоль (создание , приостановка, возврат , прекращение , синхронизация между потоками) , к тому же подходы к реализации многопоточности весьма обширны .... dermatolog почему такой вывод ?! Не знаю поэтому спрашиваю ... вот например Code:
в еди переадется поинтер на контекст , а параметр бузи может быть в разных случаях , все не смотрел но обычно популярный подход это контекстно поточная виртуальная машина ... ----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube |
|
|
Создано: 23 декабря 2009 17:02 · Личное сообщение · #24 mak пишет: почему такой вывод ?! Не знаю поэтому спрашиваю ... Скачай разобранный исполнитель из этого поста. Вот это кусок из него: Code:
Не трудно догадаться что здесь происходит ожидание когда ВМ освободиться. Освободжается она вот здесь: Code:
Если тебе все еще непонятнет смысл поля Busy в контексте ВМ, то объясню на пальцах - если 2 разных потока будут вызывать один и тотже исполнитель ВМ, то второй поток зайдя в исполнителе затрет контекст первого потока и в результате первый поток наибнецца. Поэтому чтобы такого не произошло аффтары темиды придумали вот такой вот финт ушами - второй поток будет ожидать завершение выполнения пикода первого потока и ТОЛЬКО после этого начнет выполняться сам. Вот такой вот подход к проектированию ВМ полностью убивает смысл многопоточности в приложении (при условии что разные потоки дергают один и тотжде исполнитель ВМ). ПОэтому я и спросил - в более новых версиях темиды все также работает через жопу или уже нет? )
|
|
|
Создано: 23 декабря 2009 17:23 · Поправил: mak · Личное сообщение · #25 это все я видел , и контекстами в виде накладок ясно, не нуби же , я о том что у каждого потока может быть свой интерпретатор , это и есть контекстно поточная вм , а этот параметр может быть просто приостановкой .... прочитай еще раз мой пост выше. Если то что ты говоришь есть реализация свитчед вм , то тогда в случае приостановки потока , контекст должен сохранятся для последующего запуска , а начинаться новый ....но этого кода при быстром взгляде я не вижу , поэтому если кто увидел реализацию потокового енджина в листинге ткните плз пальцем. А если передается каждому потоку свой указатель на контекст в еди , тот тут уже без вопросов. Вот что я имею ввиду ...Поправлено - Да я так и понял что мы о разных вещах , так надо было и сказать что бузи это тоже самое что критические секции. Критической секцией как вариант может быть та же приостановка в ожидании , о чем я и сказал выше. Тогда уже вопрос сводится банально к оптимальной реализации. Есть какие то более оптимальные решения доступа ? В нынешнем софте полно программ в которых не учтены такие моменты , это разве большой минус архитектуры ?! ----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube |
|
|
Создано: 23 декабря 2009 17:37 · Личное сообщение · #26 mak Ты путаешь 2 совершенно разные вещи - многопоточность на уровне ОСи и многопоточность на уровне клиентского приложения. Планированием потоков (остановкой, запусками и т.п.) занимается ОСь и когда поток уже создан - ему больше не нужно думать над тем, а как же я бля все-таки живу. Тоже самое относится и к ВМ - ёй совершенно пофигу на то как живут потоки, которые её дергают. У ВМ темиды в силу своей непродуманной архитектуры (судя по 2.0.3) есть только одна проблема - это не дать разным потокам записать свой контекст в одну и туже "глобальную переменную" (читай контекст). Решал когда-нибудь задачу доступа из разных потоков к одной и тойже переменной? В общем задача решается с использованием критических секций (т.е. пока текущий поток не выйдет из этой секции в неё больше никто не зайдет). Дак вот тут тоже самое, только в роли критической секции выступает поле Busy в контексте ВМ. |
|
|
Создано: 23 декабря 2009 18:05 · Личное сообщение · #27 Так у разных потоков могут быть разные контексты? И у каждого потока EDI указывает именно на свой? |
|
|
Создано: 23 декабря 2009 18:43 · Личное сообщение · #28 Ясный красный, у разных потоков разный контекст. А вм действительно однопоточная, ибо на критических секциях самодельных построена. |
|
|
Создано: 23 декабря 2009 19:05 · Личное сообщение · #29 Какбэ капитан очевидность подсказывает, что самодельные критические секции есть лажа, и нормальный многопоток на них не построишь, ибо второй поток может отставать от первого всего на одну-две инструкции, и в этом случае занятость\свобода контекста совершенно неочевидна, сталобыть стековая реализация гораздо более адекватный подход к многопоточности
----- "Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels |
|
|
Создано: 23 декабря 2009 19:06 · Личное сообщение · #30 mak пишет: Тогда уже вопрос сводится банально к оптимальной реализации. Есть какие то более оптимальные решения доступа ? В нынешнем софте полно программ в которых не учтены такие моменты , это разве большой минус архитектуры ?! Какие нах "оптимальные решения доступа"? Надо полностью менять концепцию ВМ - хранилище под контекст должно быть потоконезависимым. А что у нас независимое между потоками? Пральна - это стек. Кто мешает хранить контекст ВМ на стеке? Никто. Сразу же отпадает гемор с "критическими секциями" и автоматически имеем многопоточную ВМ. Интересует реализация - кури исходники исполнителя ВМ от вмпротекта, которые ты сам сюда и выкладывал )
|
|
|
Создано: 23 декабря 2009 20:25 · Поправил: mak · Личное сообщение · #31 Короче все понятно ...ужс какойто , все это тоже уже давно известно , простые истины ... получается что только по параметру бузи сделали вывод что вм однопоточная ... а то что параметр еди то есть указатель на контекст может быть сменен никто даже не подумал ...
----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube |
| << . 1 . 2 . 3 . >> |
|
eXeL@B —› Протекторы —› Исследование защиты Themida |
Для печати