Декомпилятор ВМ

Сейчас на форуме: (+9 невидимых)

<< . 1 . 2 . 3 . 4 . 5 . 6 . 7 . 8 . 9 . 10 ... 23 . 24 . >>

Посл.ответ	Сообщение
Vamit Ранг: 331.1 (мудрец), 561thx Активность: 0.19↘0.06 Статус: Участник	Создано: 03 марта 2010 12:33 · Личное сообщение · #1 Вашему вниманию предлагаются наработки по декомпиляции ВМ. Проект на сегодняшний день для меня завершен, но жаль если результат "ляжет на полку", может кому-нибудь и пригодится. Предлагаю сначала ознакомиться с обзором, и если будет интерес то могу выложить и сам плагин, или здесь или в личку заинтересованным лицам, каким образом, пока ещё не решил... Но если кто-либо ожидает увидеть "автоматическое чудо", то сразу скажу - его нет. Для того чтобы получить результат нужна ручная предварительная работа: - с исследуемой программы должна быть снята упаковка - точки входа в ВМ находятся вручную - возможно неоднократное "жамкание" клавиш в OllyDbg, а возможно и модификация кода, чтобы попасть в нужное место, в зависимости от защищенной функции - необходимо вручную прицепить к программе требуемый секцию - запись результатов в файл это тоже ручная работа, но уже более приятная Не всё гладко обстоит с определением реализаций ВМ, на сегодняшний день примерно каждая третья реализация автоматом не определяется, приходится под неё модернизировать плагин, т.к. не могу сразу предусмотреть все случаи "издевательств" ВМ с кодом примитивов. Лучше дела с восстановлением "исходного" кода защищенных функций - 70% нормально восстанавливается, хотя во многом это зависит от самой структуры функции. Таким образом, если будет заинтересованность и помощь в нахождении подобных ситуаций, то проект может быть доведен до релизной стадии. ЗЫ: Речь идет об Ореановских машинах. Нигде специально не упоминал. 9c41_03.03.2010_CRACKLAB.rU.tgz - VMSweeperLst.rar ----- Everything is relative...

Vamit Ранг: 331.1 (мудрец), 561thx Активность: 0.19↘0.06 Статус: Участник	Создано: 18 марта 2010 15:42 · Поправил: Vamit · Личное сообщение · #2 Заканчиваю написание деобфускатора апишных вызовов применительно к этому. на входе имеем, вернее при создании этого кода уже "удалены" вызовы call, jmp и jcc Code: Instr: 0 parsing - 0x01A39CD8: push 0FF3B31FBh Instr: 1 parsing - 0x01A39CDD: pushad Instr: 2 parsing - 0x01A39CDE: mov ss:[esp + 20h], eax Instr: 3 parsing - 0x01A39CE2: lea eax, ds:[eax + ebp8 + 0B4710A2Eh] Instr: 4 parsing - 0x01A39CE9: pushad Instr: 5 parsing - 0x01A39CEA: mov* eax, ds:[0x01A22BA2] Instr: 6 parsing - 0x01A39CEF: pushfd Instr: 7 parsing - 0x01A39CF0: pushfd Instr: 8 parsing - 0x01A39CF1: push 0D3CE15F6h Instr: 9 parsing - 0x01A39CF6: push 01A39CFBh Instr: 10 parsing - 0x01A2FA0C: lea esp, ss:[esp + 50h] Instr: 11 parsing - 0x01A2FA10: push 01A2FA15h Instr: 12 parsing - 0x01A1ED7B: push 0B03C1EBEh Instr: 13 parsing - 0x01A1ED80: push 01A1ED85h Instr: 14 parsing - 0x01A2F026: push 95703AEEh Instr: 15 parsing - 0x01A2F02B: pushad Instr: 16 parsing - 0x01A2F02C: pushfd Instr: 17 parsing - 0x01A2F02D: pop ss:[esp + 28h] Instr: 18 parsing - 0x01A2F031: stc Instr: 19 parsing - 0x01A2F032: stc Instr: 20 parsing - 0x01A2F033: add eax, 0AFBF00BFh Instr: 21 parsing - 0x01A2F038: mov ss:[esp], 0E2B0h Instr: 22 parsing - 0x01A2F03E: clc Instr: 23 parsing - 0x01A2F03F: rol eax, 6 Instr: 24 parsing - 0x01A2F042: mov ss:[esp + 4], si Instr: 25 parsing - 0x01A2F047: mov ss:[esp + 4], 0CFh Instr: 26 parsing - 0x01A2F04C: push 01A2F051h Instr: 27 parsing - 0x01A28D4F: dec eax Instr: 28 parsing - 0x01A28D50: test dx, bx Instr: 29 parsing - 0x01A28D53: not eax Instr: 30 parsing - 0x01A28D55: test 43B0153Ah, ebx Instr: 31 parsing - 0x01A28D5B: mov ss:[esp + 4], al Instr: 32 parsing - 0x01A28D5F: add eax, 5F508C6Bh Instr: 33 parsing - 0x01A28D64: pushfd Instr: 34 parsing - 0x01A28D65: ror eax, 4 Instr: 35 parsing - 0x01A28D68: push ss:[esp + 4] Instr: 36 parsing - 0x01A28D6C: test 7Fh, bl Instr: 37 parsing - 0x01A28D6F: push ss:[esp] Instr: 38 parsing - 0x01A28D72: bt di, 3 Instr: 39 parsing - 0x01A28D77: not eax Instr: 40 parsing - 0x01A28D79: stc Instr: 41 parsing - 0x01A28D7A: pushfd Instr: 42 parsing - 0x01A28D7B: sub eax, 88B8FB44h Instr: 43 parsing - 0x01A28D80: cld Instr: 44 parsing - 0x01A28D81: test ch, ch Instr: 45 parsing - 0x01A362BC: stc Instr: 46 parsing - 0x01A362BD: not eax Instr: 47 parsing - 0x01A362BF: pushfd Instr: 48 parsing - 0x01A2A8C3: push ss:[esp + 40h] Instr: 49 parsing - 0x01A2A8C7: popfd Instr: 50 parsing - 0x01A2A8C8: mov ss:[esp], 0A44006F0h Instr: 51 parsing - 0x01A2A8CF: mov ss:[esp], bp Instr: 52 parsing - 0x01A2A8D3: mov ss:[esp], sp Instr: 53 parsing - 0x01A2A8D7: mov ss:[esp + 4], ecx Instr: 54 parsing - 0x01A2A8DB: push ss:[esp + 44h] Instr: 55 parsing - 0x01A2A8DF: retn 48h Instr: 56 parsing - 0x01A2FA15: pushad Instr: 57 parsing - 0x01A2FA16: push ebx Instr: 58 parsing - 0x01A2FA17: pushad Instr: 59 parsing - 0x01A2FA18: mov edi, eax Instr: 60 parsing - 0x01A2FA1A: cwde Instr: 61 parsing - 0x01A2FA1B: mov eax, ss:[esp + 44h] Instr: 62 parsing - 0x01A2FA1F: mov ss:[esp + 10h], 99h Instr: 63 parsing - 0x01A2FA24: pushfd Instr: 64 parsing - 0x01A2FA25: push ss:[esp] Instr: 65 parsing - 0x01A2FA28: lea esp, ss:[esp + 50h] на выходе получил Code: 01A39CD8: edi = 0x7C802446 // kernel32.Sleep что делать дальше вроде бы понятно, но есть вопросы (задаю в скобках) - найти съеденную IAT (можно ли это автоматизировать? или отдать юзеру, пусть сам ищет и вводит границы в предлагаемую форму?) - найти в IAT секцию для kernel32 (каким образом, если она будет вообще пустой?) - записать на свододное место секции адрес функции Sleep, адрес записи перенести в команду mov edi, [addr] - записать восстановленную команду на своё родное место - запись изменений в файл (большой вопрос - на данном этапе ВМ с распаковки файла ещё не снята, импорт не восстановлен, стаб то же, следовательно записать в файл ничего не можем, как поступить в этом случае?) ----- Everything is relative...
DillerInc Ранг: 283.6 (наставник), 56thx Активность: 0.13↘0 Статус: Участник Author of GeTaOEP	Создано: 18 марта 2010 18:01 · Поправил: DillerInc · Личное сообщение · #3 Vamit пишет: следовательно записать в файл ничего не можем, как поступить в этом случае? ...выделяешь память размером с секцию кода, копируешь туда саму секцию и все изменения вносишь в эту память,высчитывая смещение: instr VA - code section VA == offset \| temp mem VA + offset == instr in temp mem VA Я считаю, что подобный подход необходим всегда, ибо протектор может запросто проверять определённые метки во время выполнения своих процедур расчёта импорта, краденных инструкций и т.п. ----- the Power of Reversing team
pavka Ранг: 1045.7 (!!!!), 31thx Активность: 0.57↘0 Статус: Участник	Создано: 18 марта 2010 20:11 · Личное сообщение · #4 Vamit пишет: найти съеденную IAT (можно ли это автоматизировать? или отдать юзеру, пусть сам ищет и вводит границы в предлагаемую форму?) Обычно сначала заполняется табличка, отловить GPA прота не сложно да и проще сначала заполнить табличку по загружаемым библам чем раскидывать кашу при трейсе , а затем правит вызовы в сответствии с табличкой.
Vamit Ранг: 331.1 (мудрец), 561thx Активность: 0.19↘0.06 Статус: Участник	Создано: 19 марта 2010 14:15 · Поправил: Vamit · Личное сообщение · #5 Подскажите, как в Ольке проверить на валидность начало какой-либо инструкции? Например, нашли jmp в нужную область, он может быть или реальным или липовым... (имеется ввиду не руками, конечно, а из SDK) ----- Everything is relative...
Vamit Ранг: 331.1 (мудрец), 561thx Активность: 0.19↘0.06 Статус: Участник	Создано: 21 марта 2010 11:25 · Личное сообщение · #6 Vamit пишет: как в Ольке проверить на валидность начало какой-либо инструкции? т.к. ответа нет, отвечу сам Code: ulong sz; uchar* pDec = Finddecode(ip, &sz); if(pDec && ((*pDec & DEC_TYPEMASK) == DEC_NEXTCODE)) // инструкция липовая else // инструкция годная вот только не знаю, насколько это решение полное... ----- Everything is relative...
Bronco Ранг: 312.0 (мудрец), 349thx Активность: 0.46↗0.65 Статус: Участник Advisor	Создано: 23 марта 2010 19:42 · Личное сообщение · #7 Vamit пишет: т.к. ответа нет, отвечу сам да это нормально, обычно так и бывает, ковыряешь то, на что у многиих много чего нет //в основном времени и...моска.. ----- Чтобы юзер в нэте не делал,его всё равно жалко..
Vamit Ранг: 331.1 (мудрец), 561thx Активность: 0.19↘0.06 Статус: Участник	Создано: 24 марта 2010 08:41 · Личное сообщение · #8 Обновил VMSweeper, добавлено: - анализ всех точек входа в ВМ с отображением статуса - восстановление съеденного импорта, в том числе и структуры IAT Эти две функции по идее могут работать с любыми типами ВМ, подопытный "кролик" здесь, но чем больше типов ВМ будет протестировано и сообщены результаты, то... тем лучше d8be_23.03.2010_CRACKLAB.rU.tgz - VMSweeper1_2beta.rar ----- Everything is relative...
daFix Ранг: 529.0 (!), 110thx Активность: 0.29↘0.04 Статус: Участник 5KRT	Создано: 24 марта 2010 13:14 · Личное сообщение · #9 Восстановление импорта тестировалось только на ВМпроте? Вроде похожий импорт был EXEcryptor Найду прогу с такой опцией, дам ссыль ----- Research For Food
kioresk Ранг: 154.2 (ветеран), 66thx Активность: 0.08↘0 Статус: Участник REVENGE Crew	Создано: 24 марта 2010 13:26 · Личное сообщение · #10 Vamit, лучше убери шаманство с добавлением к файлу секции .vm, ибо все протекторы с нормальной ВМ всегда проверяют контрольную сумму файла, а добавлять секцию, править CRC, потом восстанавливать код, потом снова править CRC не айс.
Vamit Ранг: 331.1 (мудрец), 561thx Активность: 0.19↘0.06 Статус: Участник	Создано: 24 марта 2010 16:02 · Поправил: Vamit · Личное сообщение · #11 daFix пишет: Восстановление импорта тестировалось только на ВМпроте? Да, на том что было в наличии... kioresk пишет: лучше убери шаманство с добавлением к файлу секции .vm, ибо все протекторы с нормальной ВМ всегда проверяют контрольную сумму файла лучше, чем что...? ладно, это лирика. во-первых секция цепляется уже к распакованному файлу, который запускается и работает, так что CRC здесь не причем, на дампе она не проверяется. во-вторых, она нужна для декомпиляции тела ВМ в промежуточный код, что можешь предложить взамен? Пока нужно где-то 64Кб, но возможно и больше в зависимости от длины кодированного участка функции, причем код в ней должен быть рабочим с вызовом из тела восстанавливаемой функции. После восстановления фунции(й) эта секция больше не нужна. ----- Everything is relative...
kioresk Ранг: 154.2 (ветеран), 66thx Активность: 0.08↘0 Статус: Участник REVENGE Crew	Создано: 24 марта 2010 16:47 · Личное сообщение · #12 во-первых секция цепляется уже к распакованному файлу, который запускается и работает, так что CRC здесь не причем, на дампе она не проверяется. Если файл не надо будет предварительно распаковывать, то это облегчит жизнь реверсера (минус одна операция). во-вторых, она нужна для декомпиляции тела ВМ в промежуточный код, что можешь предложить взамен? Пока нужно где-то 64Кб, но возможно и больше в зависимости от длины кодированного участка функции, причем код в ней должен быть рабочим с вызовом из тела восстанавливаемой функции. Могу предложить VirtualAllocEx.
progopis Ранг: 101.0 (ветеран), 344thx Активность: 1.15↘0 Статус: Участник	Создано: 24 марта 2010 17:03 · Личное сообщение · #13 kioresk +10, именно так декомпиляторы и делаются.
Vamit Ранг: 331.1 (мудрец), 561thx Активность: 0.19↘0.06 Статус: Участник	Создано: 24 марта 2010 17:07 · Поправил: Vamit · Личное сообщение · #14 kioresk пишет: то это облегчит жизнь реверсера (минус одна операция). Если реверсер не сможет распаковать файл, то это уже не реверсер - ему и дальше делать нечего... А вы хотите, чтобы декомпилятор ещё и файл полностью распаковал..., нет, таких задач я не ставил. kioresk пишет: Могу предложить VirtualAllocEx Проверено, не работает, для работы эту память должна видеть Олька, а не только плагин, а Олька к сожалению видит только то, что пристегнуто к файлу. ----- Everything is relative...
progopis Ранг: 101.0 (ветеран), 344thx Активность: 1.15↘0 Статус: Участник	Создано: 24 марта 2010 17:09 · Личное сообщение · #15 Vamit пишет: А вы хотите, чтобы декомпилятор ещё и файл полностью распаковал..., нет, таких задач я не ставил. Декомпилятор это средство для декомпиляции. Не надо требовать распакованности файла, равно как и требовать от него распаковку. Vamit пишет: Проверено, не работает, для работы эту память должна видеть Олька, а не только плагин, а Олька к сожалению видит только то, что пристегнуто к файлу. В контексте программы не пробовали сделать VirtualAllocEx?
Vamit Ранг: 331.1 (мудрец), 561thx Активность: 0.19↘0.06 Статус: Участник	Создано: 24 марта 2010 17:24 · Поправил: Vamit · Личное сообщение · #16 progopis пишет: В контексте программы не пробовали сделать VirtualAllocEx? Да всё пробовал, вся беда в том, что плагин может вносить изменения только после того как файл загружен в Ольку, но, после того как он уже загружен (EIP на точке входа), к нему ничего Олькой не добавить. Память должна видеться не программой, а именно Олькой, как контекст программы. Был ещё один вариант: сделать пустую dll загрузить в систему, а затем из Ольки выполнять на неё переход, не получилось, т.к. чтобы её увидела Олька она должна быть в импорте. А что пихать Dll в импорт, что добавлять секцию к файлу - равнозначно, но второе проще, поэтому выбрал этот вариант. Пока эта секция не мешает, но уже сейчас подхожу к ситуации, когда она нужна, а её ещё нет: восстановление съеденного стаба. Для анализа входов в ВМ и восстановления импорта она не нужна, но чтобы завершить распаковку файла нужно встать на OEP или близко к ней и запустить декодирование стаба (пока работать без секции не будет), и только затем можно сохранить дамп и получить рабочий файл. ----- Everything is relative...
progopis Ранг: 101.0 (ветеран), 344thx Активность: 1.15↘0 Статус: Участник	Создано: 24 марта 2010 17:40 · Личное сообщение · #17 Vamit пишет: к нему ничего Олькой не добавить И как же тогда OllyDbgScript работает? Надо взять контекст программы, изменить ESP, в стэк засунуть параметры VirtualAllocEx, EIP переставить на VirtualAllocEx, не забыв в качестве адреса возврата бряк воткнуть, в выделенную память можно запихнуть любой управляющий код (а можно и сразу ВМ), после чего весь мусор убирается, если он был, а EIP возвращается на точку входа.
kioresk Ранг: 154.2 (ветеран), 66thx Активность: 0.08↘0 Статус: Участник REVENGE Crew	Создано: 24 марта 2010 17:50 · Поправил: kioresk · Личное сообщение · #18 Если реверсер не сможет распаковать файл, то это уже не реверсер - ему и дальше делать нечего... А вы хотите, чтобы декомпилятор ещё и файл полностью распаковал..., нет, таких задач я не ставил. Вопрос не о знаниях реверсера (читай крутости), а об упрощении задачи и как следствие — экономии времени. Да всё пробовал, вся беда в том, что плагин может вносить изменения только после того как файл загружен в Ольку, но, после того как он уже загружен (EIP на точке входа), к нему ничего Олькой не добавить. Память должна видеться не программой, а именно Олькой, как контекст программы. Можно попробовать так: 1. забэкапить кусок кода на текущем EIP (c помощью Readmemory из SDK) 2. вставить туда шеллкод (c помощью Writememory из SDK), в котором будет вызываться VirtualAllocEx, а результат будет помещаться по оффсету EIP+xyz 3. далее шагам по шелкоду (или ставим бряк в конце и запускаем до бряка) 3. затем считываем результат из EIP+xyz, если там не ошибка — работаем с ним 4. восстанавливаем затертый кусок кода и значение EIP Добавлено progopis опередил, да еще и с более простым решением.
Vamit Ранг: 331.1 (мудрец), 561thx Активность: 0.19↘0.06 Статус: Участник	Создано: 24 марта 2010 20:30 · Личное сообщение · #19 Разобрался с VirtualAllocEx, оказалось, как всегда, всё гораздо проще - необходимо было в плагине после вызова VirtualAllocEx выполнить WriteProcessMemory и всё заработало... ----- Everything is relative...
Vamit Ранг: 331.1 (мудрец), 561thx Активность: 0.19↘0.06 Статус: Участник	Создано: 25 марта 2010 09:26 · Поправил: Vamit · Личное сообщение · #20 Проведя небольшой анализ VMProtect (до точки вызова обработчиков примитивов) выявил следующие отличия в его ВМ по сравнению с Ореановскими ВМ: 1. Инициализация ВМ (конечная точка – вход в цикл интерпретатора ВМ) Code: Описание VMProtect CodeVirtualizer Код инициализации ВМ обфусцирован явный Адрес таблицы пикода (дно стека) закодирован доступен Порядок сохранения нативных регистров в стеке произвольный фиксированный Расположение регистров ВМ в стеке в области кода Указатель на регистры ВМ EDI EDI Ключ кодирования инициализирован адресом пикода EBX EBX Указатель на стек программы EBP ESP 2. Интерпретатор ВМ (конечная точка – вызов обработчика примитива) Code: Описание VMProtect CodeVirtualizer Порядок просмотра пикода прямой/обратный прямой Таблица обработчиков примитивов в коде (256DW) в коде (<256DW) Адрес обработчика примитива закодирован доступен Выводы: 1. Реализовать в декомпиляторе один обработчик разных типов ВМ проблематично, но это и к лучшему. Проще под каждый тип ВМ сделать собственный обработчик на едином алгоритме, чем делать «солянку» в одном обработчике, по крайней мере, добавление обработчика нового типа ВМ не нарушит работу уже существующих. 2. Понятен общий принцип определения типа ВМ декомпилятором (сейчас он представляет из себя набор «жестких»условий, но на самом деле это не так): - найти точку входа в цикл интерпретатора ВМ при статическом анализе точки входа в ВМ из тела функции. - выявить анализатором моменты указанные в таблице 1 - дойти статическим анализом до точки вызова обработчика примитива - выявить анализатором моменты указанные в таблице 2 - подтвердить моменты таблицы 1 - определить алгоритм хеширования кода примитива - определить алгоритм хеширования адреса обработчика примитива А далее, после определения типа ВМ, идем по уже пройденной дорожке: - идентифицируем обработчики примитивов ВМ - «заменяем» интерпретатор ВМ с обработчиками примитивов промежуточным кодом и т.д., что уже было описано и реализовано ранее… ----- Everything is relative...
Vamit Ранг: 331.1 (мудрец), 561thx Активность: 0.19↘0.06 Статус: Участник	Создано: 25 марта 2010 13:25 · Поправил: Vamit · Личное сообщение · #21 Вернусь к старому вопросу с VirtualAllocEx, не получается так как надо с динамической памятью: память выделяется, Олька её видит, но в процессе декомпиляции выполняются рестарты программы и даже исключения в ней, затем принудительный рестарт - во всех этих случаях выделенный сегмент автоматом удаляется, если же создавать новый, то его адрес получается в большинстве случаев разный, следовательно код ассемблированный под определенный ip уже в этом сегменте не работает. ----- Everything is relative...
mak Ранг: 673.3 (! !), 400thx Активность: 0.4↘0.31 Статус: Участник CyberMonk	Создано: 26 марта 2010 11:29 · Личное сообщение · #22 Работа с Bin файлом не подходит ? Можно делать predump , можно вносить куски кода временные переменные, или хучить вылетание ольги , и запоминать что было последнее ... при перезапуске файл всегда один ----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube
Vamit Ранг: 331.1 (мудрец), 561thx Активность: 0.19↘0.06 Статус: Участник	Создано: 26 марта 2010 12:30 · Личное сообщение · #23 mak пишет: Работа с Bin файлом не подходит? Не понял, причем здесь bin файл, мне нужно не просто хранилище кода, на это добро и памяти хватает, а реально рабочий код, который добавляется к проге и который можно реально дебажить в Ольке в одном контексте с программой и который "не разрушается" при перезагрузке проги в Ольке. Фактически он, конечно, разрушается, но копия лежит у меня в памяти, а так как под него в проге отведен статический сегмент, то при перезагрузке проги он просто копируется из памяти в этот сегмент. ----- Everything is relative...
kioresk Ранг: 154.2 (ветеран), 66thx Активность: 0.08↘0 Статус: Участник REVENGE Crew	Создано: 26 марта 2010 13:12 · Личное сообщение · #24 Vamit сложно подсказать что-то конкретное не зная деталей, если бы приаттачил пример кода, размещаемого в этой памяти, и описал немного какая идет привязка между этой промежуточной областью и кодом жертвы, то было бы проще. А так, думаю, ты и сам понимаешь, что только базовонезависимый код поможет в этом случае.
progopis Ранг: 101.0 (ветеран), 344thx Активность: 1.15↘0 Статус: Участник	Создано: 26 марта 2010 13:16 · Личное сообщение · #25 mak пишет: хучить вылетание ольги , и запоминать что было последнее не задумывался почему в линуксе до сих пор нет корректного работающего hibernate (спящий режим)? Нет? Ну удачи. На хороших ВМ такой метод свалится на простейшей антиотладке. mak пишет: можно вносить куски кода временные переменные это на каком языке написано? Vamit пишет: который можно реально дебажить в Ольке в одном контексте с программой а зачем его дебажить? можно вообще не вязаться к ольке, а делать тулзу которая будет читать всё что нужно из памяти программы через ReadProcessMemory. Если уж очень сильно надо всё делать в ольке, надо разбираться почему происходят вылеты. Это явно либо некорректная работа декомпилятора, либо непрозрачность режима отладки (нарушение условий выполнения программы). Писать софт на костылях не имеет смысла. Хватает уже.
Vamit Ранг: 331.1 (мудрец), 561thx Активность: 0.19↘0.06 Статус: Участник	Создано: 26 марта 2010 14:17 · Поправил: Vamit · Личное сообщение · #26 kioresk пишет: сложно подсказать что-то конкретное не зная деталей Всем все детали выложены в обзоре и самом инструменте, и чтобы предметно разговаривать необходимо хотя-бы попробовать его работу - много вопросов и не нужных советов отпадут, а повторять то, что уже сказано, я не хочу. только базовонезависимый код поможет в этом случае. Промежуточный код не может быть базонезависимым, пример его есть в обзоре. progopis пишет: а зачем его дебажить? Юзеру, если этот код правильный, то конечно, незачем. Вспомним это Vamit пишет: Не всё гладко обстоит с определением реализаций ВМ, на сегодняшний день примерно каждая третья реализация автоматом не определяется, приходится под неё модернизировать плагин, т.к. не могу сразу предусмотреть все случаи "издевательств" ВМ с кодом примитивов. , т.ч. дебажить нужно мне и может быть тому кто хочет полностью восстановить съеденное тело функции, но декомпилятор пока в некоторых случаях это сделать не может. Промежуточный же код 100% получается рабочим. progopis пишет: можно вообще не вязаться к ольке, а делать тулзу которая будет читать всё что нужно из памяти программы Можно, но нужен ассемблер + дизассемблер + дебаггер, которые сам я писать не собираюсь, в обзоре обоснован выбор инструмента. progopis пишет: Если уж очень сильно надо всё делать в ольке, надо разбираться почему происходят вылеты. Да тут и так всё понятно, если прочитать обзор и хелп. Если с произвольного места программы переместить ip на New origin here и давануть F9, то вы должны предсказать что будет... Или другой пример, программа идет через семафор (условный переход) а мы принудительно переходим его в другое направление, которое может быть обработкой исключения... progopis пишет: Писать софт на костылях не имеет смысла. Хватает уже. А костылей здесь нет, то что сидит в плагине независимо от кода программы, поэтому с ней можно делать всё что захочется, а плагин будет просто за этим наблюдать и собирать нужную инфу, главное саму Ольку не перегружать. ----- Everything is relative...
progopis Ранг: 101.0 (ветеран), 344thx Активность: 1.15↘0 Статус: Участник	Создано: 26 марта 2010 14:34 · Поправил: Модератор · Личное сообщение · #27 Vamit пишет: нужен ассемблер + дизассемблер + дебаггер, которые сам я писать не собираюсь Разве это проблема? Ассемблер может быть, но вот дизасм движки хорошие уже написаны, прекрасно подходящие для задач RE. Наиболее хорошие примеры UDIS и Mediana. Есть ещё metasm, но не сильно изучал его на юзабельность (там есть ассемблирование вроде). С отладчиками сложнее, но если не сильно волнует проблема отсутствия UI, то движков существует огромное мн-во, в том числе наш (который пока ещё не отлажен до конца, но тем не менее написан и работает). Я не просто языком здесь трещу, у нас есть рабочий декомпиль который работает по этому принципу. Отладчика там нет, только декомпиляция и деобфускация.
Vamit Ранг: 331.1 (мудрец), 561thx Активность: 0.19↘0.06 Статус: Участник	Создано: 26 марта 2010 14:49 · Личное сообщение · #28 progopis пишет: Разве это проблема? Нет, это не проблема, но если есть наиболее легкий путь, то почему его не использовать? В Ольке есть всё, что мне необходимо и даже больше, чем надо... progopis пишет: в том числе наш (который пока ещё не отлажен до конца, но тем не менее написан и работает). А можно где-нибудь с вашим ознакомиться? ----- Everything is relative...
progopis Ранг: 101.0 (ветеран), 344thx Активность: 1.15↘0 Статус: Участник	Создано: 26 марта 2010 15:19 · Личное сообщение · #29 Vamit пишет: А можно где-нибудь с вашим ознакомиться? Отписал в ЛС.
Vamit Ранг: 331.1 (мудрец), 561thx Активность: 0.19↘0.06 Статус: Участник	Создано: 02 апреля 2010 12:35 · Поправил: Vamit · Личное сообщение · #30 В продолжение к посту (Таблица 1) привожу реальные слепки регистров и стека полученные декомпилятором на точке входа в цикл ВМ (сама точка так же распознается декомпилятором самостоятельно), для двух типов ВМ: 1. VMProtect regs Code: eax: 0 ecx: ecx edx: 0 ebx: 0x01A373F8 //hash key esp: 0x0012FEE8 //bottom VM stack ebp: 0x0012FFA8 //addr context app esi: [0x0012FFA8] + 0x01A373F8 //picode table edi: 0x0012FEE8 //addr VM regs efl: efl stack Code: 0012FEE8: empty //VM regs 0012FEEC: empty //... 0012FEF0: empty 0012FEF4: empty 0012FEF8: empty 0012FEFC: empty 0012FF00: empty 0012FF04: empty 0012FF08: empty 0012FF0C: empty 0012FF10: empty 0012FF14: empty 0012FF18: empty 0012FF1C: empty 0012FF20: empty 0012FF24: empty 0012FF28: empty 0012FF2C: empty 0012FF30: empty 0012FF34: empty 0012FF38: empty 0012FF3C: empty 0012FF40: empty 0012FF44: empty 0012FF48: empty 0012FF4C: empty 0012FF50: empty 0012FF54: empty 0012FF58: empty 0012FF5C: empty 0012FF60: empty 0012FF64: empty 0012FF68: empty 0012FF6C: empty 0012FF70: empty 0012FF74: empty //--- 0012FF78: esi 0012FF7C: edx 0012FF80: 0x0012FF84 0012FF84: eax 0012FF88: edx 0012FF8C: ecx 0012FF90: 1 0012FF94: 0xCECE39D0 0012FF98: 0x01A16CAB 0012FF9C: 0x0BFBDBC8 0012FFA0: 0x01A163D6 0012FFA4: eax 0012FFA8: 0 0012FFAC: edx //context app regs 0012FFB0: efl //... 0012FFB4: eax 0012FFB8: esi 0012FFBC: ebx 0012FFC0: edi 0012FFC4: ecx 0012FFC8: edi 0012FFCC: ebp //--- 0012FFD0: 0x01A17249 0012FFD4: 0x4087E194 //coded addr picode 0012FFD8: var0 //top context app stack 0012FFDC: var1 //... 0012FFE0: var2 2. Ореановские ВМ regs Code: eax: [14B342E] ecx: 1 edx: edx ebx: 0x014D1D37 //hash key esp: 0x0012FFB0 //bottom VM stack ebp: ebp esi: 0x014D1D37 //picode table edi: 0x014B33FE //addr VM regs efl: efl stack Code: 0012FFB0: efl //context app regs 0012FFB4: edi //... 0012FFB8: esi 0012FFBC: ebp 0012FFC0: 0x0012FFC4 0012FFC4: ebx 0012FFC8: edx 0012FFCC: ecx 0012FFD0: eax //--- 0012FFD4: 0x014D1D37 //addr picode 0012FFD8: var0 //top context app stack 0012FFDC: var1 //... 0012FFE0: var2 отсюда видно, что распознать тип ВМ автоматически достаточно просто... ----- Everything is relative...
progopis Ранг: 101.0 (ветеран), 344thx Активность: 1.15↘0 Статус: Участник	Создано: 06 апреля 2010 20:17 · Личное сообщение · #31 Почитал доку . Весь пикод хэширован определенным образом, ключом хэширования является адрес размещения пикода в памяти. Неверно с созданием сигнатурного шаблона каждого примитива Неверно Необходимость предпоследней операции будет обоснована ниже. Неверно то в нем ищется первый условный переход за пределы этого блока Обрадую вас, в вмпротект нет условных переходов, вообще. Что будете делать? Рассказать об алгоритмической сложности задачи перебора всех возможных состояний? Вывод: с мат. частью проблемы. Хорошие идеи есть и их очень много, но не уверен, что идеи авторские.

<< . 1 . 2 . 3 . 4 . 5 . 6 . 7 . 8 . 9 . 10 ... 23 . 24 . >>

Для печати