 |
| Главная |
| Программы |
| Статьи |
| Разное |
| Форум |
| Контакты |
Декомпилируем p-code в уме
Тонкости исследования команд виртуальной машины VBВведение
Думаю все мы знакомы с программами на пикоде. Даже если реверсер в жизни не видел VB и его компилятор, то все равно хотя бы раз он сталкивался с пикодом. В отличии от стандартного машинного кода, исполняемого напрямую процессором, p-code это набор мнемоник VM, которые исполняются движком msvbvmXX.dll. Olly тут не особый помощник (хотя для кого как), IDA тем более. Тут нужен либо декомпилятор, либо мозги. Надеюсь что второе есть точно у всех, кто читает эти строки. Именно поэтому листинги из декомпилятора я буду приводить в статье лишь для наглядности, основной же упор будет на декомпилирование, используя в работе только HIEW.
Немного о структурах
Пикод еще нам придется поискать в EXE файле - он так просто не лежит. Для этого придется разобраться хотябы с частью структур VB, которые зашиты в EXE файл. Начнем с рассмотрения оригинальной точки входа в программу. Чтобы на нее перейти из HEX редактора HIEW нам потребуется лишь загрузить EXE’шник в данный HEX редактор и нажать поочереди Enter, Enter, F8, F5. У кого хиев купленный знают как оптимизировать эту операцию до командной строки, но эт так к слову. Нашему взгляду будет представлено примерно следующее:
| CODE NOW! |
| push 0004042E8 ;’VB5!’ call ThunRTMain ;MSVBVM60 --?2 |
P-Code Inside :)
Весь смысл этой мегасложной строчки заключается в вызове функции ThunRTMain из MSVBVM60. В параметрах этой функции передается указатель на VB Header. Вот его примерный вид:
Структура VBHeader
| CODE NOW! |
| Поле Тип Описание Signature String * 4 Сигнатура "VB5!" RuntimeBuild Integer Показатель рантаймовости LanguageDLL String * 14 Языковая библиотека BackupLanguageDLL String * 14 Не влияет на работу EXE RuntimeDLLVersion Integer Версия рантайм библиотеки LanguageID Long Язык программы BackupLanguageID Long Используется совместно с LanguageDLL aSubMain Long Main процедура, запускаемая при старте EXE. Если отсутствует, то при загрузке грузится самая первая форма aProjectInfo Long Указатель на структуру ProjectInfo fMDLIntObjs Long fMDLIntObjs2 Long ThreadFlags Long Флаги потока ThreadCount Long Число потоков (смысл малопонятен, так как VB не позволяет создавать многопоточные программы) FormCount Integer Число форм в данном файле ExternalComponentCount Integer Число внешних OCX компонентов ThunkCount Long aGUITable Long Указатель на GUITable aExternalComponentTable Long Указатель на ExternalComponentTable aComRegisterData Long Указатель на ComRegisterData oProjectExename Long Адрес строки с именем EXE файла oProjectTitle Long Адрес строки с заголовком проекта oHelpFile Long Адрес строки с именем Help файла oProjectName Long Адрес строки с именем проекта |
ThunRTMain из описанной структуры получает все необходимые данные и адреса структур необходимые для настройки и запуска EXE. Функция ProcCallEngine в случае присутствия поля aSubMain запускает функцию, расположенную по адресу, указанному в этом поле структуры, которая является главной в проекте и не равна 0 если в EXE файле присутствовал модуль с функцией Main. Если данная функция отсутствует, то грузится первая форма и управление передается функции Form_Initialize, а если она отсутствует то Form_Load. Соотвественно если и этой функции нет и вообще в форме события не используются, то запускается WindowProc цикл ожидания событий как в любой программе (ассемблерщики меня поймут). Нам из этой структуры потребуются лишь aSubMain и структура ProjectInfo. Последняя имеет вид:
Структура ProjectInfo
| CODE NOW! |
| lTemplateVersion Long Версия VB совместимости aObjectTable Long Указатель на aObjectTable lNull1 Long aStartOfCode Long Начало кода (нам бесполезно) aEndOfCode Long Конец кода (нам бесполезно) lDataBufferSize Long Размер буфера для хранения различных данных aThreadSpace Long Пространство потока aVBAExceptionhandler Long Указатель на функцию обработки ошибок aNativeCode Long Если не равно нулю, то это Native Code, иначе P-Code uIncludeID 527 Byte aExternalTable Long Указатель на таблицу API функций lExternalCount Long Число импортируемых API функций |
Обозначенная таблица для нас как распутье. Продолжать далее имеет смысл только если в aNativeCode стоит 0. Это означает что все функции в программе на пикоде и имеет смысл с ними разобраться. Все полезные нам данные мы получим из aObjectTable это указатель на структуру объектов (форм модулей и так далее), среди прочих данных в которой можно найти адреса процедур и событий.
Структура ObjectTable
| CODE NOW! |
| lNull1 Long aExecProj Long aProjectInfo2 Long lConst1 Long lNull2 Long aProjectObject Long uuidObjectTable Long Flag2 Long Flag3 Long Flag4 Long fCompileType Integer iObjectsCount Integer Число объектов iCompiledObjects Integer iObjectsInUse Integer aObjectsArray Long Указатель на массив объектов (единственное что для нас в этой структуре важно помимо iObjectsCount) lNull3 Long lNull4 Long lNull5 Long aNTSProjectName Long lLcID1 Long lLcID2 Long lNull6 Long lTemplateVersion Long |
Теперь когда мы определились с таблицей объектов давай посмотрим поподробнее на массив этих самых объектов. ObjectsArray это массив структур TObject. Число элементов массива определяется полем iObjectsCount. Рассмотрим ка поподробнее структуру TObject и производную от нее TObjectInfo.
Структура TObject
| CODE NOW! |
| aObjectInfo Long Указатель на структуру ObjectInfo lConst1 Long aPublicBytes Long Указатель на массив публичных переменных aStaticBytes Long Указатель на массив статических переменных aModulePublic Long Указатель на публичные переменных aModuleStatic Long Указатель на статические переменные aNTSObjectName Long Указатель на имя объекта lMethodCount Long Число методов объекта aMethodNameTable Long Указатель на массив адресов функций oStaticVars Long Смещение на переменные из aModuleStatic lObjectType Long Тип объекта lNull2 Long |
Как видишь эта структура уже поинтереснее. Поле aNTSObjectName означает что это собственно за модуль. Если это поле содержит адрес на frmRegister то эт уже может нам намекнуть что функции, находящиеся в массиве из следующей структуры отвечают за процесс проверки серийника :)
Структура TObjectInfo
| CODE NOW! |
| iConst1 Integer iObjectIndex Integer Индекс объекта aObjectTable Long Указатель на таблицу объектов (требуется для разбора форм и лежащих на них объектов... нам же в данной статье не потребуется) lNull1 Long aObjectDescriptor Long lConst2 Long lNull2 Long aObjectHeader Long Указатель на ObjectHeader aObjectData Long Указатель на ObjectData следующие члены валидны только если программа скомпилирована в пикод iMethodCount Integer Число методов iNull3 Integer aMethodTable Long Указатель на массив указателей на методы iConstantsCount Integer Число констант iMaxConstants Integer Максимальновозможное число констант lNull4 Long lFlag1 Long aConstantTable Long Указатель на массив указателей на константы |
Если не брать во внимание ивенты объектов на форме, а только созданные пользователем функции, то для все их адреса можно найти в таблице, на которую указывает aMethodTable. Эта таблица для каждого модуля или формы конечно своя, это логично. Потому чтобы получить доступ ко всем функциям необходимо перебрать все формы и модули (а также классмодули, юзерконтролы...). В общем если у тебя много свободного времени, можешь уже сейчас писать плагин для HIEW, который будет это все автоматизировать, я же лишь рассмотрю что же всетаки находится по адресам из таблицы методов. А находится там собственно не пикод, и не ассемблерные команды, как многие могут подумать. Там очередная структура, коими любит нас потчевать микрософт.
Структура ProcDscInfo
| CODE NOW! |
| ProcTable Long field_4 Integer FrameSize Integer ProcSize Integer ... |
Я преднамеренно урезал эту структуру, так как нам из нее потребуется только ProcSize и адрес на таблицу ProcTable. Из таблицы ProcTable нам потребуется в свою очередь только адрес на блок данных. Об этом блоке данных думаю надо поговорить поподробнее. Все опкоды пикода которые так или иначе оперируют с данными (будь то строки, API функции и так далее) ссылаются на них не по абсолютному а по относительному адресу. Относительный этот адрес именно от начала блока данных. Так что не зная адреса на блок данных мы по сути не сможем ничего декомпилировать. Отсюда рассмотрим следующую структуру, расположенную по адресу ProcTable:
Структура ProcTable
| CODE NOW! |
| SomeTemp String*52 DataConst Long |
SomeTemp это просто набор ненужных нам полей, которые я объединил дабы немного сэкономить места в статье. Они нам не потребуются, для нас важен только адрес DataConst. Теперь думаю логично задаться вопросом а что мы узнали? Только размер пикодовой процедуры и адрес на блок данных. А где же сама пикодовая процедура? Ааа, вот тут билли гатес засюрпризил нам еще одну подлянку. Адрес пикодовой процедуры напрямую нигде не прописан, зато мы его можем получить вычитанием из адреса начала структуры ProcDscInfo поля sProcDscInfo.ProcSize. Как видно пикод идет прямо перед структурой ProcDscInfo. Чтож теперь когда мы знаем откуда брать методы (про ивенты я умолчу всвязи в ограничением объема статьи) можно приступать исследовать этот самый пикод.
Как исследовать
Узнали мы адрес начала блока пикода а что дальше? А дальше что бы хоть как-то понять пикод нам потребуется таблица назначения опкодов. Ее можно найти в приложении к статье. Заранее предупрежу таблица эта неполная, так как публичная и имеет кое какие ошибки (их крайне мало), потому доверять ей на все 100 не советую, хотя это всетаки лучшее, что можно добыть в инете на данный момент. Таблица представлена в виде:
| CODE NOW! |
| <опкод>tab<размер>tab<название> |
Опкод может состоять из одного или двух байт. До FBh опкода невключительно идут однобайтовые. Далее идут двухбайтовые. Так что если ты встретишь к примеру FEh, то следующий за ним байт также относится к опкоду. <размер> в таблице это число параметров - 1. Из одного ли байта состоит опкод или из двух, все равно -1 :) Не знаю зачем так сделали составители таблицы, главное нам это придется учитывать при разборе кода (само собой я сделал для себя иную таблицу, гораздо более продвинутую, но по коммерческим соображениям публиковать ее не буду). Теперь посмотрим на пример пикодового блока:
| CODE NOW! |
| 00 00 00 00-00 00 00 00-00 00 00 00-F4 00 2B 6E FF F5 00 00-00 00 F5 00-00 00 00 1B-0C 00 04 70 FF 34 6C 70-FF 1B 0D 00-04 74 FF 34-6C 74 FF F5 00 00 00 00-59 78 FF 0A-0E 00 18 00-3C 32 04 00 74 FF 70 FF-13 00 00 00 |
Пикод в нашем блоке начинается с F4. Посмотрим по таблице, чтоже означает этот опкод. Согласно таблице это LitI2_Byte и имеет один байт в параметрах. Запомни раз и навсегда, Lit это всегда push. I2 это 2х байтный integer. Вот небольшая табличка всех возможных значений дабы было дальше проще исследовать:
Типы данных
| CODE NOW! |
| UI1 Byte Bool Boolean I2 Integer I4 Long R4 Single R8 Double Cy Currency Var Variant Str String |
Так как после F4 идет 0, то логично предположить, что эта команда push 0. Продолжим далее. 2B - это PopTmpLdAd2. Читать следует так Pop from stack to Temp variable and Load Address to stack. Пишу по английски, так как на русском это будет малопонятно. Итак эта переменная всеголишь резервирует содержимое верхней ячейки стека во временную переменную - нам это не потребуется, так как мы не исполняем код а декомпилируем. Но для понятности расскажу. Следующие 2 байта это та самая временная переменная FF6E. Если это число из открицательного перевести в положительное, то получится 92. Мой декомилятор в этом случае выведет var_92. Если бы число было положительным, то это была бы не локальная а глобальная переменная. Думаю теперь все ясно :) приступим к следующей команде. F5 - LitI4. Понимаем как push следующие 4 байта, то есть push 0 :) Далее опять идет push 0. Теперь 1B - LitStr. Этот опкод заносит строку в стэк. Не зря я тебе рассказал про адрес на блок данных, именно от него и отсчитываются следующие два байта в параметрах, то есть:
адрес строки = ProcTable.DataConst + следующие за командой 2 байта
Строка представлена в юникоде и заканчивается двумя нулями. Допустим что там строка "Test", следовательно имеем push "Test". 04 - FLdRfVar, то есть push переменная. Переменная вычисляется как и раньше FF70 = var_90. 34 - CStr2Ansi. Считывает из стека два элемента и первому присваивает второй, то есть в стэке на данный момент переменная var_90 и строка "Test", следовательно эту команду можно читать как var_90 = "Test". У этого опкода параметров нет следовательно далее идет уже другой опкод 6C - ILdRf. Понимается он как push переменная. То есть следующие два байта FF70 декомпятся как var_90 и вставляются в команду как push var_90. 1B снова заносит уже другую строку в стэк, пусть это будет "Test2", 04 опять создает переменную и заносит ее в стэк, а 34 присваивает "Test2" этой переменной. В частности FF74 это var_8C. 6C заносит эту переменную в стэк по накатаннойб стандартной схеме. Затем идет F5, про него мы уже говорили - он заносит в стэк следующие 4 байта. Далее уже поинтереснее 59 - PopTmpLdAdStr. Резервирует в переменной var_88 содержимое верхней ячейки стэка, при этом занося заново это содержимое на вершину стэка дабы оно не терялось. 0A - ImpAdCallFPR4. Вот тут уже запахло чем то вкусным... мы видим чистой воды Call на функцию, адрес которой отсчитывается от блока данных по традиции. Пока не забыл - это два байта прежде чем суммироваться с адресом блока данных умножаются на 4 - и это правило действует всегда. Зачем так сделали создатели VM - я не знаю, но это надо учитывать. Итак что же мы имеем в блоке данных? А имеем мы VA на следующую заглушку:
| CODE NOW! |
| A1A0634000 mov eax,[004063A0] 0BC0 or eax,eax 7402 je .000402A77 FFE0 jmp eax 68542A4000 push 000402A54 B870104000 mov eax,000401070 FFD0 call eax |
В этой конструкции нам важен push 402A54. Виртуальный адрес 402A54 указывает на структуру вида:
Структура CallAPI
| CODE NOW! |
| strLibraryName Long strFunctionName Long |
Эти два виртуальных адреса указывают на имя Dll и имя функции, которая должна быть вызвана. Вот разработчики намудрили с виртуальной машиной, правда?
Разбор переходников на API
Теперь то мы знаем, почему VB так тормозит. Чтобы вызвать любую API функцию необходимо пройти немыслимое количество структур и заглушек, что тратит золотые такты процессора и жутко снижает скорость. Как видишь - никакой таблицы импорта нет. Мы имеем дело с именем Dll и функции, которые вызываются динамически функцией DllFunctionCall, которая экспортируется из всеми ними замусоленной msvbvm60.dll. Поэтому строки из блока, что был указан выше:
| CODE NOW! |
| B870104000 mov eax,000401070 --?3 FFD0 call eax |
именно, получают адрес на переходник:
| CODE NOW! |
| jmp DllFunctionCall |
и вызывают его через call eax. Что находится в функции DllFunctionCall думаю и так понятно:
| CODE NOW! |
| hLib = GetModuleHandle(strLibraryName) hProc = GetProcAddress(hLib, strFunctionName) Call hProc |
Это в упрощенном виде, для наглядности :) В нашем же случае strLibraryName это user32.dll, а strFunctionName - это ShellExecute. Теперь то думаю ясно, зачем в пикоде было столько push’е и резервирования. Это всеголишь подготовка стэка для вызова ShellExecuteю Поэтому если свернуть все полученные нами данные то выйдет чтото вроде:
| CODE NOW! |
| loc_4043F1: var_90 = "Test" loc_4043FB: var_8C = "Test2" loc_404407: ShellExecute(0, var_8C, var_90, 0, 0, 0) |
Ну что продолжим исследовать пикод. 3C - SetLastSystemErrorю Тут все просто - это всеголишь переходник на API. Нам он не потребуется, так как он юзается виртульной машиной для отслеживания ошибок и не дает нам никаких важных данных для анализа пикода. 32 - FFreeStr. Очень интересная команда. Число ее параметров всегда переменно и определяется первыми двумя байтами. В данном случае первые два байта - 4, следовательно следующие 4 байта - две двухбайтовые переменные. В частности FF74 и FF70. Команда FFreeStr обнуляет эти строковые переменные: var_8C и var_90. То есть на нормальном языке это выглядит так:
| CODE NOW! |
| var_8C = "" var_90 = "" |
Следующий и последний опкод 13 - ExitProcHresult. Как понятно из названия он завершает процедуру, что значит что после него идет уже известная нам структура ProcDscInfo. Вот мы и разобрались как декомпилировать пикод в уме. Теперь пора поговорить о реальных задачах по исследованию, для которых исследование в уме слишком долгое и геморное, потому исследовать будем в моем декомпиляторе.
Срубаем NAG скрины
Злостные наги
В любой программе есть две проблемы - триал и нагскрины. Если триал обычно можно обойти лишь найдя ключ в реестре, который отвечает за счетчик дней и написав простенький инлайн патч, который будет перед запуском EXE обнулять этот ключ, то с нагами такой номер не пройдет. Они надоедают либо до покупки проги либо до отрубания этих злостных трюков :) Думаю лучшим примером нагскрина ввиде мессаги будет простенький крякми на пикоде. Не уверен что ты найдешь его в интернете, потому бери с диска, я его назвал "AC_Crackme_01.exe". Откроем ка мы его в декомпиляторедабы посмотреть с чем имеем дело. Видим две процедуры, одна закрывает приложение по кнопке, а вторая, та что Form_Load:
| CODE NOW! |
| loc_401A48: LitVar_Missing var_104 loc_401A4B: LitVar_Missing var_E4 loc_401A4E: LitVar_Missing var_C4 loc_401A51: LitI4 0 loc_401A56: LitVarStr var_94, "NAG" loc_401A5B: FStVarCopyObj var_A4 loc_401A5E: FLdRfVar var_A4 loc_401A61: ImpAdCallFPR4 MsgBox(, , , , ) loc_401A66: FFreeVar var_A4 = "": var_C4 = "": var_E4 = "" loc_401A71: ExitProcHresult |
Видим вызов MsgBox по адресу 401A61. Как ты понимаешь, нам его нужно убрать. Тут есть несколько путей. Так как в данном случае вся функция это NAG, то можно просто сделать выход в самом начале функции, то есть по адресу loc_401A48 вбить опкод ExitProcHresult. Красиво, оригинально и работает :) Посмотрим теперь крякми посложнее "AC_Crackme_01_A.exe":
| CODE NOW! |
| loc_401DE8: LitVar_Missing var_104 loc_401DEB: LitVar_Missing var_E4 loc_401DEE: LitVar_Missing var_C4 loc_401DF1: LitI4 0 loc_401DF6: LitVarStr var_94, "Another NAG" loc_401DFB: FStVarCopyObj var_A4 loc_401DFE: FLdRfVar var_A4 loc_401E01: ImpAdCallFPR4 MsgBox(, , , , ) loc_401E06: FFreeVar var_A4 = "": var_C4 = "": var_E4 = "" loc_401E11: FLdPr arg_8 loc_401E14: Me.Hide loc_401E19: LitVar_Missing var_B4 loc_401E1C: PopAdLdVar loc_401E1D: LitVar_Missing var_94 loc_401E20: PopAdLdVar loc_401E21: ImpAdLdRf unk_4019F4 loc_401E24: NewIfNullPr loc_401E27: Me.Show from_stack_1 from_stack_2 loc_401E2C: ExitProcHresult loc_401E2D: ILdPr |
Видим что по адресу 401E01 выводится один наг с помощью MsgBox, затем 401E14 скрывается форма и 401E27 происходит загрузка основного окна. Здесь я рассмотрю сначала как можно обойти мессагу, а уж потом поговорим про форму. Как же обойти этот вызов MsgBox? А как бы мы его обошли в программировании? Наверное логичным по адресу 401DE8 прописать GoTo на адрес 401E11. Это мы и сделаем. В качестве GoTo используется BranchF а адрес рассчитывается относительно адреса начала данной функции. То есть начальный адрес 401DE8, а нам нужно перейти на 401E11, следовательно 401E11h-401DE8h=29h следовательно в начало функции надо приписать 1E2900 :) Запускаем - нага как не бывало, осталось убрать форму нага - но это будет домашним заданием - думаю ты спрашишься без проблем.
Ломаем запрос пароля
Хорошим примером на эту тему будет крякми "AC_Crackme_02_A.exe". В нем нужно ввести верный серийник. Если серийник неверный то выводится "fuxxor". Давай посмотрим его в декомпиляторе:
| CODE NOW! |
| loc_401D4C: FLdRfVar var_94 loc_401D4F: FLdPrThis loc_401D50: VCallAd Crackme.Frame1 loc_401D53: FStAdFunc var_90 loc_401D56: FLdPr var_90 loc_401D59: from_stack_1 = TextBox.Text loc_401D5E: FLdZeroAd var_94 loc_401D61: FStStr var_8C loc_401D64: FFree1Ad var_90 loc_401D67: LitStr "ExDec_Roxx" loc_401D6A: FStStrCopy var_88 loc_401D6D: ILdRf var_88 loc_401D70: ILdRf var_8C loc_401D73: EqStr loc_401D75: BranchF loc_401DA4 loc_401D78: LitVar_Missing var_114 loc_401D7B: LitVar_Missing var_F4 loc_401D7E: LitVar_Missing var_D4 loc_401D81: LitI4 0 loc_401D86: LitVarStr var_A4, "yess" loc_401D8B: FStVarCopyObj var_B4 loc_401D8E: FLdRfVar var_B4 loc_401D91: ImpAdCallFPR4 MsgBox(, , , , ) loc_401D96: FFreeVar var_B4 = "": var_D4 = "": var_F4 = "" loc_401DA1: Branch loc_401DCD loc_401DA4: ’ Referenced from: 401D75 loc_401DA4: LitVar_Missing var_114 loc_401DA7: LitVar_Missing var_F4 loc_401DAA: LitVar_Missing var_D4 loc_401DAD: LitI4 0 loc_401DB2: LitVarStr var_A4, "fuxxor" loc_401DB7: FStVarCopyObj var_B4 loc_401DBA: FLdRfVar var_B4 loc_401DBD: ImpAdCallFPR4 MsgBox(, , , , ) loc_401DC2: FFreeVar var_B4 = "": var_D4 = "": var_F4 = "" loc_401DCD: ’ Referenced from: 401DA1 loc_401DCD: ExitProcHresult loc_401DCE: ImpAdLdFPR4 |
Просмотрев внимательно код видим сравнение в самом начале
| CODE NOW! |
| loc_401D67: LitStr "ExDec_Roxx" loc_401D6A: FStStrCopy var_88 loc_401D6D: ILdRf var_88 loc_401D70: ILdRf var_8C loc_401D73: EqStr loc_401D75: BranchF loc_401DA4 |
Понимать этот код следует примерно так:
| CODE NOW! |
| var_88="ExDec_Roxx" if (var_88=var_8C) then |
Затем видим мессагу, что пасс верный. Собственно пасс то мы узнали, да вот нам то крякнуть надобы, чтобы любой пароль подходил неверный :) BranchF по адресу 401D75 джампается на вывод инфы о неверном пароле, следовательно он понимается, как jne, то есть если EqStr возвращает что строки различны, то джампаемся. Вывод - инвертировать инструкцию. Слудует понимать что в VB всего три типа переходов, два из которых условные - 1C и 1D. ТО есть для инвертирования нам надо 1C заменить на 1D или наоборот. Меняем и о чудо - мессаги больше нет.
Более сложные приемы
Ну вот, крякам мы научились, пора бы попробовать себя в реально сложном деле - написать кейген. В качестве примера возьмем кейгенми "KeygenMe.exe". Тут нам больше потребуется Pro версия декомпилятора, так как для анализа кода лучше смотреть на подобие исходникак, нежеле на сотни строк пикодовых опкодов. Потребуется движок сворачивания команд и стэка, который прекрасно реализован в VB Decompiler Pro. Посмотрим на кейгенми под декомпилятором:
| CODE NOW! |
| loc_405825: var_88 = TextBox_764.Text loc_40583F: var_90 = TextBox_768.Text loc_40585B: If (var_94 Or (var_94 = "")) Then ’405892 loc_40587F: MsgBox("Incorrect username or password!", 16, "Keygenme", var_F4, var_114) loc_40588F: GoTo loc_405D22 loc_405892: End If |
Сразу бросается в глаза проверку на пустоту одного из текстовых полей. Для нас это малокритично, так что смотрим дальше:
| CODE NOW! |
| loc_40589F: var_88 = TextBox_764.Text loc_4058B4: If (Len(var_8C) > 2) Then ’405CF1 |
Теперь узнаем что имя не может быть менее 2х символов. Нам на это пофиг... анализируем далее:
| CODE NOW! |
| loc_405944: var_88 = TextBox_768.Text loc_40594C: var_B4 = CVar(var_8C) ’String loc_40595B: If Not(IsNumeric(var_B4)) Then ’405992 loc_40597F: MsgBox("No access!", 16, "Keygenme", var_F4, var_114) loc_40598F: GoTo loc_405B11 loc_405992: End If |
Если пароль не число - прога ругается. Чтож нам то лучше, уже знаем что пароль както вычисляется и представляет собой результат вычислений над числами. Проверим наше предположение, поглядим ниже:
| CODE NOW! |
| loc_405A53: If (CDbl(var_8C) = CDbl((CLng((Asc(CStr(Left(CVar(TextBox_768.Text), 1))) * Asc(CStr(Right(CVar(CStr(TextBox_768.Text)), 1))))) * Len(TextBox_764.Text)))) Then ’405AE0 loc_405ABE: MsgBox("Thanks for registration!" & Chr(10) & Chr(10) & "Registered to:" & CVar(TextBox_764.Text), 64, "Keygenme", var_180, var_1A0) |
Сразу видно что одно из текстовых полей пароль второе имя... догадаться какое текстовое поле пароль несложно. Видим что пароль есть результат умножения кодов 1 и последнего символа имени и длины имени. Попробуем:
имя: GPcH
пароль: 20448
Школа кейгенеров :)
Кейген на том же VB будет выглядеть примерно так:
| CODE NOW! |
| strName="GPcH" strPass=Asc(Left$(strName,1)) * Asc(Right$(strName,1)) * Len(strName) |
Примерно таким же методом можно закейгенить и другие алгоритмы, но тут без исследования, анализа и плотного разбора алго не обойтись - рассмотренный выше пример слишком идеален и врядли встретится в реальной программе. Но поверь - главное желание, а разобрать можно любой сложности алгоритм был бы декомпиялтор. А что если Pro версии моего декомпилятора нет, а прогу крякнуть нужно? Поисследуем этот же кейгенми под Lite версией и поглядим что можно крякнуть:
| CODE NOW! |
| loc_405A31: EqR4 loc_405A32: FFreeStr var_118 = "": var_124 = "": var_12C = "" loc_405A3D: FFreeAd var_88 = "": var_90 = "": var_120 = "" loc_405A48: FFreeVar var_B4 = "": var_D4 = "": var_F4 = "" loc_405A53: BranchF loc_405AE0 |
Видим сравнение пароля с рассчетным эталоном оператором EqR4, затем идет переход на адрес 405AE0 если пароль неверен. Меняем этот переход с 1C на 1D и наш кейгенми будет регаться на любой числовой пароль. Теперь поглядим enm ранее если пароль проверяется на то что он состоит только из чисел:
| CODE NOW! |
| loc_40594F: ImpAdCallI2 IsNumeric() loc_405954: NotI4 loc_405955: FFree1Ad var_88 loc_405958: FFree1Var var_B4 = "" loc_40595B: BranchF loc_405992 |
Опять меняем 1С на 1D и можем в качестве пароля вводить все что угодно :) Менять само собой надо по указанному адресу открыв кейгенми в любом HEX редакторе, хотя я советую юзать лючший на мой взгляд продукт для этих целей - hiew от sen’а.
Заключение
Вот мы и научились с тобой находить пикод в EXE файле, декомпилировать его в уме и в декомпиляторе, познакомились с основными опкодами P-Code и теперь можем анализировать что угодно. Будь то вирус с целью написания для него антивируса, будь то прога которая не регается без ключа или банально для повышения своего скилла. И не верь тем кто говорит что пикода нигде уже нет... я видел проги с гвардантом и хаспом в пикоде, а немало огромных проектов, скомпилированных в пикод. А уж троев и червей на VB полно и чтобы их анализировать обязательно нужен декомпилятор или знания, которые я думаю ты получил, прочитав данную статью. Удачи тебе!
[Декомпилятор VB]
[Приложения к статье]
PS: Не забывате, что исследование чужих приложений это всегда нехорошо. Потому поглядывате хоть изредка не запрещено ли это лицензией, чтобы избежать непланового геморроя :)
| Добавил: Admin Дата: 25.08.2006 Приложения к статье: http://www.dotfix.net/df_doc/reversing_pcode.rar Сайт декомпилятора: http://www.vb-decompiler.org |
| :: Последние обновления :: |
| 04.09.2011 Долгожданный релиз VB Decompiler. Масса улучшений декомпиляции Native Code. Значительно расширенна и обновлена справочная система на русском и английском языках. |
| 20.12.2010 DotFix Software поздравляет наших клиентов и посетителей сайта с наступающим Новым Годом и рождеством! Желаем приятно провести праздники и успехов в новом году! |
| 28.11.2010 Выпущена новая версия защиты DotFix NiceProtect. Основные изменения коснулись обфускатора Delphi программ. Теперь имеется полная поддержка Tab и Page контролов на формах, что обеспечивает максимальную совместимость обфускации с Delphi XE программами. |
| 21.10.2010 Обновлен декомпилятор Visual Basic программ до версии 8.1. Декомпиляция P-Code программ становится все более идеальной, также проделана большая работа по улучшению анализа Native Code и .NET приложений. |
| 16.09.2009 Полностью обновлен движок сайта! Теперь все ссылки имеют читаемый понятный вид, разного рода глюки на страницах убраны. И теперь сайт полноценно работает на второй версии нашего движка. |
Движок сайта: DotFix Engine v0.2 Администрация сайта: |