Ход атаки

1. Пользователь получал фишинговое письмо соссылкой наGoogle Drive.
2. Поссылке жертва скачивала вредоносный VBS-скрипт, который прописывал DLL-библиотеку для загрузки конечного пейлоада вреестр Windows изапускал PowerShell, чтобы исполнитьее.
3. DLL-библиотека внедряла конечный пейлоад собственно, один изиспользуемых злоумышленниками RAT всистемный процесс ипрописывала VBS-скрипт вавтозапуск, чтобы закрепиться взараженной машине.
4. Конечный пейлоад исполнялся всистемном процессе идавал злоумышленнику возможность управлять зараженным компьютером.
   

Анализ этапов атаки

Этап1. Фишинговая рассылка

Этап2. Работа VBS-скрипта

def decode_str(data_enc):       return binascii.unhexlify(''.join([data_enc[i:i+2] for i in range(0, len(data_enc), 3)]))

GetObject(winmgmts {impersonationLevel=impersonate}!\\.\root\default:StdRegProv)

Этап3. Работа DLL-библиотеки

[System.Threading.Thread]::GetDomain().Load((ItemProperty HKCU:\/\/\/Software\/\/\/<rnd_sub_key_name> ).<rnd_value_name>);[GUyyvmzVhebFCw]::EhwwK('WScript.ScriptFullName', 'rWZlgEtiZr', 'WScript.ScriptName'),0

• получала данные значения реестра сименем rnd_value_name эти данные представляли собой DLL-файл, написанный наплатформе .Net;
• загружала полученный .Net-модуль впамять процесса powershell.exeспомощью функции [System.Threading.Thread]::GetDomain().Load()(подробное описание функции Load() доступно насайте Microsoft);
• исполняла функциюGUyyvmzVhebFCw]::EhwwK() снее начиналось исполнение DLLбиблиотеки спараметрами vbsScriptPath, xorKey, vbsScriptName. Параметр xorKey хранил ключ для расшифровки конечного пейлоада, апараметры vbsScriptPathиvbsScriptName передавались для того, чтобы прописать VBS-скрипт вавтозапуск.

• осуществлял инжект пейлоада всистемный процесс (вданном примере это svchost.exe);
• прописывал VBS-скрипт вавтозапуск.

• расшифровывала два массива данных (array иarray2 наскриншоте). Первоначально они были сжаты спомощью gzip изашифрованы алгоритмом XOR сключом xorKey;
• копировала данные ввыделенные области памяти. Данные изarray вобласть памяти, накоторую указывал intPtr(payload pointer наскриншоте); данные изarray2 вобласть памяти, накоторую указывал intPtr2(shellcode pointer наскриншоте);
• вызывала функцию CallWindowProcA(описание этой функции есть насайте Microsoft) соследующими параметрами (ниже перечислены имена параметров, наскриншоте они идут втомже порядке, носрабочими значениями):
  
  • lpPrevWndFuncуказатель наданные из array2;
  • hWndуказатель настроку, содержащую путь кисполняемому файлу svchost.exe;
  • Msgуказатель наданные из array;
  • wParam,lParam параметры сообщения (вданном случае эти параметры неиспользовались иимели значения 0);
• создавала файл %AppData%\Microsoft\Windows\Start Menu\Programs\Startup\<name>.url, где <name> это первые 4символа параметра vbsScriptName(наскриншоте фрагмент кода сэтим действием начинается скоманды File.Copy). Таким образом вредонос добавлял URL-файл всписок файлов для автозапуска при входе пользователя всистему итем самым закреплялся назараженном компьютере. URL-файл содержал ссылку наскрипт:

[InternetShortcut]URL = file : ///<vbsScriptPath>

def decrypt(data, key):    return gzip.decompress(        bytearray([data[i] ^ key[i % len(key)] for i in range(len(data))])[4:])    

• array представлял собой PE-файл это иесть конечный пейлоад;
• array2 представлял собой шелл-код, необходимый для осуществления инжекта.

LRESULT WndFunc(  HWND    hWnd,  UINT    Msg,  WPARAM  wParam,  LPARAM  lParam);

• создавал процесс svchost.exe вприостановленном состоянии при помощи функции CreateProcessW;
• затем скрывал отображение секции вадресном пространстве процесса svchost.exeпри помощи функции NtUnmapViewOfSection. Таким образом программа освобождала память оригинального процесса svchost.exe, чтобы затем поэтому адресу выделить память для пейлоада;
• выделял память для пейлоада вадресном пространстве процесса svchost.exe при помощи функции VirtualAllocEx;

• записывал содержимое пейлоада вадресное пространство процесса svchost.exe при помощи функции WriteProcessMemory (как наскриншоте ниже);
• возобновлял процесс svchost.exe при помощи функции ResumeThread.

Загружаемое ВПО

Огруппировке

• осуществляют отложенное исполнение спомощью функции Sleep;
• используют WMI;
• прописывают тело исполняемого файла вкачестве параметра ключа реестра;
• исполняют этот файл при помощи PowerShell вегоже адресном пространстве.

((Get-ItemPropertyHKCU:\Software\NYANxCAT\).NYANxCAT);$text=-join$text[-1..-$text.Length];[AppDomain]::CurrentDomain.Load([Convert]::FromBase64String($text)).EntryPoint.Invoke($Null,$Null);

[System.Threading.Thread]::GetDomain().Load((ItemProperty HKCU:\/\/\/Software\/\/\/<rnd_sub_key_name> ).<rnd_value_name>);[GUyyvmzVhebFCw]::EhwwK('WScript.ScriptFullName', 'rWZlgEtiZr', 'WScript.ScriptName'),0

IoC

Привет, Хабровчане!
В конце августа в OTUS запускается 2 мощных курса по обратной разработке кода (реверс-инжиниринг). В связи с этим приглашаем вас на День Открытых дверей, где Артур Пакулов (Ex-вирусный аналитик в Kaspersky Lab.) расскажет подробнее о программах, особенностях онлайн-формата, навыках, компетенциях и перспективах, которые ждут выпускников после обучения. А также приглашаем вас принять участие в бесплатных открытых уроках: Анализ буткита и Анализ банковского трояна.

Предпосылки

Все описанное здесь основано на проекте, который я завершил в начале 2011 года, спустя аж несколько лет после его начала. Принимая участие в CanSecWest в 2009 году, Анибал Сакко и Альфредо Ортега из Core Security провели презентацию Persistent BIOS Infection, где продемонстрировали, как можно пропатчить BIOS, чтобы совершить некоторые неприятные/удивительные вещи. Можете ознакомится с их докладом здесь. На то время это действительно впечатляло, но мне так и не выпал шанс попробовать это на практике. Год спустя мне нужно было подготовить групповой проект для учебы, поэтому я решил вернуться к взлому BIOS и самостоятельно реализовать что-нибудь из этого.

За последние несколько лет в мире BIOS для ПК многое изменилось, и теперь подписанный встроенный BIOS является стандартом, а архитектура UEFI внесла множество изменений по сравнению с традиционным дизайном BIOS. Менее чем через год после того, как я завершил этот проект, были обнаружены первые признаки того, что вредоносные программы действительно заражают BIOS в несколько похожей манере (ссылка). Простые меры, такие как подпись обновлений BIOS, легко предотвратили бы модификации BIOS такого типа. Также уже были проведены некоторые исследования для поиска путей решения этой проблемы (например, презентация Attacking Intel BIOS Рафаля Войчука и Александра Терешкина). Поэтому стоит отметить, что ничего из того, что описано здесь, не предназначено для представления миру какой-либо новой уязвимости, а скорее является демонстрацией концепции, которую можно легко проверить и изменить.

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

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

Подход

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

В 2009 году было проведено исследование в смежной области безопасности, которая занимается руткитами загрузочного сектора. В отличие от BIOS-руткитов, разработки в этой области развивались очень быстрыми темпами, что привело к созданию и выпуску ряда различных MBR(master boot record)-руткитов. Этот тип руткитов был назван Bootkit, и, подобно BIOS-руткиту, он стремится загрузить себя до загрузки ОС. Это сходство побудило многих разработчиков буткитов отметить, что данная атака должна быть осуществимой непосредственно из BIOS, а не из MBR. Несмотря на комментарии и предложения о том, что код буткита можно было перенести для выполнения в BIOS, пока не было опубликовано ни одного примера такого кода.

Первым этапом реализации этого проекта было создание среды тестирования и разработки, в которой можно было бы вносить и отлаживать модификации BIOS. В своей статье об устойчивом заражении BIOS Сакко и Ортега подробно описывают, что они обнаружили, что VMware содержит BIOS ROM, а также GDB сервер, который можно использовать для отладки приложений, начиная с самого BIOS. После успешной работы в VMware была проделана работа по переносу модификаций BIOS VMware на другие подобные BIOS это будет описано во второй половине этой статьи.

Конфигурация VMware BIOS

Ладно, достаточно предыстории, займемся!

Первый необходимый шаг извлечь BIOS из самой VMware. В Windows это можно сделать, открыв исполняемый файл vmware-vmx.exe с помощью любого экстрактора ресурсов, например, Resource Hacker. В этом приложении объединено несколько различных двоичных ресурсов, и BIOS хранится в ресурсе с идентификатором 6006 (по крайней мере, в VMware 7). Это может разниться от версии к версии, но ключевым моментом является размер файла ресурса 512 КБ. На следующем изображении показано, как это выглядит в Resource Hacker:

Хотя этот BIOS-образ связан с приложением vmware-vmx.exe, его также можно использовать отдельно, без необходимости вносить правки в исполняемый файл VMware после каждого изменения. VMware позволяет указывать ряд скрытых параметров в файле настроек образа VMX. В какой-то момент я планирую документировать некоторые их них на вкладке Tools этого сайта, потому что они действительно очень полезны! Вот те, которые пригодятся для модификации и отладки BIOS:

bios440.filename = "BIOS.ROM"debugStub.listen.guest32 = "TRUE"debugStub.hideBreakpoint = "TRUE"monitor.debugOnStartGuest32 = "TRUE"

Первая настройка позволяет BIOS ROM загружаться не из приложения vmware-vmx, а из файла. Следующие две строки подключают встроенный GDB сервер. Этот сервер прослушивает соединения через порт 8832, когда образ работает. Последняя строка указывает VMware остановить выполнение кода в первой строке гостевого образа BIOS. Это очень полезно, так как позволяет определять точки останова и проверять память до того, как произойдет какое-либо выполнение BIOS. Тестирование было выполнено с использованием IDA Pro в качестве GDB клиента. Пример гостевого образа VMware, остановленного на первой инструкции BIOS, можно увидеть на скриншоте ниже:

При первом использовании этой тестовой среды у меня были значительные проблемы с подключением IDA к GDB серверу. После долгих проб, ошибок и тестирования с различными GDB клиентами было выявлено, что виновата моя версия VMware. Версии 6 и 6.5, похоже, не очень хорошо работают с IDA, поэтому для большинства испытаний мной использовалась VMware 7. BIOS состоит из 16-битного кода, а не 32-битного кода по умолчанию для IDA, поэтому было необходимо определить Manual Memory Regions в параметрах отладки IDA. Это позволило адресам памяти быть определенным как 16-битный код, чтобы они правильно декомпилировались.

Воссоздание готовых наработок модификация VMware BIOS

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

Работа Сакко и Ортега довольно подробно описывает их сетап и методы тестирования. Установка VMware была завершена, как описано выше, и следующим шагом было внедрение кода модификации BIOS, который они предоставили. Предоставленный код требовал извлечения BIOS ROM в отдельные модули. BIOS ROM, входящий в комплект VMware, является Phoenix BIOS. Исследование говорит, что существует два основных инструмента для работы с этим типом BIOS, инструмент с открытым исходным кодом phxdeco, и коммерческий Phoenix BIOS Editor, который предоставляется непосредственно Phoenix. В работе Сакко и Ортега рекомендовано использовать приложение Phoenix BIOS Editor они разрабатывали свой код для использования под ним. Пробная версия была загружена мной из интернета, и, похоже, она обладает всеми функциями, необходимыми для этого проекта. Разыскивая ссылку для скачивания снова, я не могу найти ничего, что кажется даже наполовину легитимным, но Google предлагает большой список вариантов. Я просто предположу, что найти какую-нибудь легитимную пробную версию не составит труда. После того, как инструменты установлены, следующим шагом будет создание пользовательского BIOS.

Сначала я убедился, что небольшая модификация образа BIOS вступит в силу в VMware, что и произошло (изменился цвет логотипа VMware). Затем я запустил скрипт сборки на Python, предоставленный Сакко и Ортега для модификации BIOS. Помимо одной опечатки в питоновском скрипте сборки BIOS все работало отлично, и новый BIOS был сохранен на диск. Однако загрузка этого BIOS в VMware не привела к тому же самому успеху: VMware выдает сообщение о том, что в виртуальной машине что-то пошло не так и что оно закрывается. Отладка этой проблемы совершалась в IDA и GDB, но проблему было трудно отследить (плюс в IDA были проблемы с версией). В целях ускорения работы была загружена другая версия VMware, чтобы тестовая среда соответствовала среде Сакко и Ортега. После некоторых поисков была найдена и установлена точная версия VMware, которую они использовали. Это, к сожалению, не решило проблему, VMware сообщила о той же ошибке. Хотя я видел, как эта модификация BIOS работала, когда демонстрировалась как часть их презентации, теперь было ясно, что их пример кода потребует дополнительной модификации, прежде чем он сможет работать на какой-либо тестовой системе.

В результате отладки кода Сакко и Ортега было изучено много разных моментов, и в итоге проблема была в инструкции на ассемблере, которая выполняла far вызов абсолютного адреса, который не был правильным для используемой BIOS. После ввода правильного адреса код BIOS был успешно выполнен, и руткит начал искать на жестком диске файлы для изменения. Этот код требовал очень много времени для сканирования на жестком диске (который был всего 15 ГБ), и он запускался несколько раз до запуска системы. Код подтверждения концепции включал в себя возможность исправления notepad.exe, чтобы он отображал сообщение при запуске, или изменения файла /etc/passwd в системе Unix, чтобы root пароль был установлен на фиксированное значение. Это показало, что руткиты могут функционировать как в Windows системах, так и в Linux, даже если они используются только в простых целях.

Тестирование буткита

Значительно позже, в процессе работы над проектом, мной была также протестирована функциональность различных буткитов, и результаты были пересмотрены, чтобы определить, какой из них будет работать лучше не только в качестве буткита, но и как BIOS-руткит. Были исследованы четыре разных буткита: Stoned, Whistler, Vbootkit и Vbootkit2. Буткиты Stoned и Whistler были разработаны для того, чтобы функционировать в большей степени как вредоносные программы, нежели руткиты, и не отличались простотой структуры исходного кода. Vbootkit2 сильно выделялся, так как он в меньшей степени предполагал из себя вредоносное ПО и имел (относительно) хорошо документированный исходный код. Этот буткит предназначался для запуска с CD, но был протестирован только с бета-версией Windows 7. При использовании с коммерческой копией Windows 7, буткит просто не загружался, так как Windows использовала другие сигнатуры файлов. Я потратил некоторое время на определение новых сигнатур файлов, чтобы можно было протестировать этот буткит, но он все равно не загружался. В целях тестирования, я нашел бета-версию Windows 7. Когда Vbootkit2 запускался на бете Windows 7, все работало, как и ожидалось. Vbootkit2 включал в себя возможность повысить процесс до привилегий уровня системы (выше уровня администратора), чтобы захватывать нажатия клавиш и сбрасывать пароли пользователей. Все эти элементы были бы полезны для включения в руткит, но для переноса этого приложения в стандартный Windows 7 требовалась значительная работа. Далее был рассмотрен Vbootkit; он был разработан для работы с Windows 2003, XP и 2000. Хотя он не был собран так, чтобы его можно было запускать с компакт-диска, для добавления этой функциональности потребовались лишь незначительные изменения. Это программное обеспечение включало только возможность повышения привилегий процесса, но даже само по себе это уже очень ценная функция. Так этот программный пакет был выбран для использования с BIOS-руткитом, который описан в следующем разделе. NVLabs являются авторами этого буткита, который по большому счету представляет основную функциональность этого проекта, поэтому большое спасибо им за то, что они опубликовали свой код! Похоже, что исходный код больше не доступен на их веб-сайте, но его все еще можно скачать с Archive.org здесь.

Внедрение кода в BIOS посмотрим в следующей части. Следите за новостями!

Узнать подробнее о курсах: Реверс-инжиниринг. Продвинутый, Реверс-инжиниринг

Fake Instructions

Ptrace

ARM ELF

Часть 1. Что скрывают pagefile.sys

• если вы работаете с активной операционной системой, то для извлечения используем ПО FTK Imager или KAPE Эрика Циммермана
  
  
• если есть цифровая копия накопителя или же сам файл просто копируем файл или работаем с ним напрямую.

Важный момент, о котором стоит помнить: начиная со сборки 10525 Windows 10 используется компрессия файла подкачки. При нехватке памяти система сжимает неиспользуемые ресурсы памяти в каждом процессе, позволяя большему количеству приложений оставаться активными одновременно. Для декомпрессии такого файла необходимо использовать специализированное ПО.

Идем в поля

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

А что еще?

• sekurlsa::logonPasswords извлечение логинов и паролей учетной записи
• token::elevate повышение прав доступа до SYSTEM или поиск токена администратора домена
• lsadump::sam получение SysKey для расшифровки записей из файла реестра SAM
• log Result.txt файл, куда записываются результаты работы ПО (не забываем поискать этот файл в файловой системе):
  
  

С удовольствием и даже гордостью публикуем эту статью. Во-первых, потому что автор участница нашей программы Summ3r of h4ck, Nalen98. А во-вторых, потому что это исследовательская работа с продолжением, что вдвойне интереснее. Ссылка на первую часть.

Добрый день!

Прошлогодняя стажировка в Digital Security не оставила меня равнодушной к компании и новым исследованиям, так что в этом году я взялась поработать над проектом так же охотно. Темой летней стажировки Summer of Hack 2020 для меня стала Символьное исполнение в Ghidra. Нужно было изучить существующие движки символьного исполнения, выбрать один из них и реализовать его в интерфейсе Ghidra. Казалось бы, зачем, ведь в основном движки представляют собой самостоятельные решения? Этот вопрос будет возникать до тех пор, пока не попробовать то, что автоматизирует действия и сделает их наглядными. Это и стало целью разработки.

Статья в какой-то степени является еще и продолжением статьи моего наставника, Андрея Акимова, о решении Kaos Toy Project с Triton. Только сейчас нам не придется писать ни строчки кода решить крякми можно будет практически двумя кликами.

Итак, начнем по порядку.

Пара слов о символьном исполнении

Символьное исполнение представляет собой технику анализа программного обеспечения, которая позволяет найти все наборы входных данных, способствующие выполнению каждого из его возможных путей. Если говорить обобщенно, то во время символьного исполнения производится замена переменных/регистров их символьными значениями. Зависимость между переменной и ее символьным значением называется формулой. Единичные формулы объединяются в более сложные и подаются на вход SMT-решателю. Он, в свою очередь, ищет решение к логической формуле и выдает результат утверждение удовлетворяется (satisfied) или утверждение не удовлетворяется (unsatisfied). Во время символьного исполнения ветки будут расходиться, и произойдет создание форков и новых ограничений на символьные значения. Экспоненциальный рост числа форков является одной из главных проблем в этой области, поскольку для вычислений растущего числа веток требуются большие мощности.

Если говорить об общей классификации движков символьного исполнения, то среди них выделяют статические символьные движки (SSE, emulated) и динамические символьные движки (DSE, concolic). Достоинством статических движков является поддержка эмуляции как всей программы, так и конкретной ее части. И поскольку не происходит непосредственного запуска на CPU, а лишь эмулируются инструкции, открываются возможности для анализа разнообразных архитектур. Однако, страдает масштабируемость, и могут возникнуть определенные трудности со входами в сторонние библиотеки.

DSE, в отличие от SSE, исполняет каждую ветку отдельно, и по своей сути он быстрее, поскольку символизирует не все подряд, а только входные данные пользователя (источник книга "Practical Binary Analysis" by Dennis Andriesse".

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

Выбор символьного движка

Первым наставники посоветовали изучить Triton. С ним хорошо получилось изучить теорию символьного исполнения. Движок может работать как в режиме SSE, так и в режиме DSE. Однако у него ограниченное количество поддерживаемых архитектур (x86, x86-64, ARM32, Arch64), и мне сложно было представить, каким образом можно реализовать его API в контексте интерфейса Ghidr-ы. Так что Triton пришлось отложить и ресерчить дальше.

Следующим подопытным стал KLEE. Он, несомненно, является самым мощным движком символьного исполнения, с его помощью можно работать с по-настоящему серьезными проектами и исследованиями. В контексте реализации архитектуры плагина здесь основной проблемой выступила генерация llvm-биткода. А все потому, что для полноценной работы KLEE необходимо подавать скомпилированные clang-ом в llvm-биткод (.bc) файлы исходников. Были идеи по передачи бинаря llvm-лифтеру (их ассортимент можно увидеть тут), однако ни один из этих вариантов не сработал, и KLEE выдавал ошибки. Говоря о наработках в области трансляции Pcode в llvm, есть лишь один Ghidra-to-LLVM. В рамках ресерча пришлось протестировать и его. Как оказалось, он не работает с 32-битными бинарями, и если и удавалось получить результат в виде .ll-файла, то после обработки llvm-ассемблером llvm-as и получения llvm-биткода KLEE все равно не хотел работать с подобным самопалом и выдавал ошибки. Так что KLEE также пришлось оставить, несмотря на его широкие возможности по символьному исполнению.

Наставники также посоветовали изучить движок S2E. Он расширяет возможности QEMU по трансляции бинарных инструкций в TCG и также транслирует сам TCG в LLVM. Это была заманчивая идея, однако для работы с ним требуется Python3. И, как известно, Ghidra использует старый Jython 2.x, что, казалось бы, полностью перекрывает поток возможностей по интеграции современных инструментов в Ghidr-у. Движок, который был выбран в итоге, тоже работает только с Python3, но в случае с ним возможно было придумать обходной вариант через системный интерпретатор. А поскольку S2E работает как отдельный инструмент, его использование из Ghidr-ы не представляется возможным.

На момент написания статьи вышел еще один движок символьного исполнения SymCC. Точнее, правильно его назвать оберткой компилятора для C-кода. Представьте: у вас на руках исходники, вы компилируете исполняемый файл, как в случае с KLEE и clang-ом, только здесь с SymCC. Компилятор интегрирует необходимый для символьного исполнения код и библиотеки в новоиспеченный исполняемый файл. После запуска получаем директорию с кейсами, сгенерированными во время выполнения. Все классно, но привязать такое к Ghidr-е невозможно, так как у нас на руках не исходники проекта, а результат дизассемблирования и декомпиляции.

Финальным выбором стал angr. Он популярен, у него доступный и подробно задокументированный API, и интегрировать данный движок было действительно реально. Конечно, как уже отмечалось, без Python3 никуда, в Ghidra его поддержка отсутствует, но в случае с angr-ом мне показалось возможным написать универсальный скрипт, который смог бы запускаться на системном интерпретаторе, решать заданный бинарь и передавать результат обратно в Ghidr-у. Вот такой был план.

Сердито. Костыльно. Канонично.

Реализовать получилось так: графический интерфейс плагина получает необходимую информацию от пользователя, создается буферный JSON-файл, куда записывается необходимая конфигурация для работы универсального angr-скрипта, плагин запускает скрипт на системном интерпретаторе, скрипт передает найденное решение обратно в графический интерфейс.

Если изучить принцип работы декомпилятора в Ghidra и его взаимодействие с GUI, то можно понять, что основе лежит схожий костыльный алгоритм. Дело в том, что Ghidra работает с декомпилятором через stdin и stdout потоки, используя классы DecompileProcess и DecompInterface. Так что архитектуру плагина можно считать вполне каноничной в контексте Ghidra.

На написание логики скрипта не ушло много времени. Он, по сути, собирает в себя базовые возможности angr-a по символьному исполнению для решения ctf-тасков. На графический интерфейс пришлось потратить львиную долю времени, и его разработку не могу назвать захватывающей. Как и Ghidra, графический интерфейс плагина написан на Java, в роли IDE по традиции выступил Eclipse.

Для GUI плагина было создано 4 файла:

• AngryGhidraPlugin.java в файле указывается основная информация о плагине и происходит его инициализация.
• AngryGhidraProvider.java самый объемный файл, который инициализирует компоненты графического интерфейса основного окна плагина; здесь прописана логика создания файла конфигурации для скрипта, происходят запуск скрипта и чтение результатов, их передача в интерфейс.
• AngryGhidraPopupMenu.java здесь прописаны дополнительные параметры контекстного меню окна дизассемблера Ghidr-ы. Благодаря этому файлу можно задавать необходимые адреса прямиком из окна дизассемблера, а также внедрять пропатченные байты памяти в контекст работы angr-а.
• HookCreation.java инициализирует окно создания хуков.

Итак, пара слов о функциональных возможностях плагина.

• Auto load libs определяет работу загрузчика необходимых библиотек для исполняемого файла. Пользователь определяет, нужна ему эта опция или нет.
• Find Address адрес, куда вы хотите попасть во время выполнения программы (например, на адрес вывода строки License key is validated!).
• Blank State адрес, с которого вы начинаете эмуляцию. Если не добавлять дополнительных параметров в дальнейшем, то по умолчанию все регистры и память обнулены. Удобно назначать на адресе точки входа или на адресе вызова функции проверки, если вы знаете ее расположение в коде и хотите ускорить процесс работы angr-a.
• Avoid addresses адрес/адреса, которые в ходе символьного исполнения нужно избежать. При их нахождении angr автоматически отметет соответствующие им ветки с меткой avoid и не пройдет дальше. Чем больше таких адресов указать, тем чаще angr будет отбрасывать ненужные ветки кода и найдет решение быстрее (если это решение существует).
• Arguments аргументы, поставляемые на вход программе (argv[1], argv[2] и т.д.). Иногда значение, которое необходимо сделать символьным, передается через аргумент(-ы) к программе.
• Hooks хуки позволяют перехватить указанные инструкции и внести определенные значения в регистры. Например, когда необходимо записать в регистры символьные вектора, это будет продемонстрировано в дальнейшем решении Kaos Toy Project.
• Store symbolic vector если необходимо создать символьный вектор в адресном пространстве определенной длины, а потом, например, поместить его в регистр. Если плагин найдет решение, он выведет содержимое созданного символьного вектора.
  
  • Write to memory иногда бывает необходимо, чтобы определенные участки памяти были заполнены конкретными значениями. Например, в случае Kaos Toy Project, это значение Installation ID, которое инициализируется по адресу 0x4093a8. Это поле окна плагина можно заполнить патчингом из Ghidr-ы, для этого необходимо пропатчить нужные вам байты, выделить их и открыть контекстное меню дизассемблера AngryGhidraPlugin -> Apply patched bytes.
• Registers те значения регистров, которые вы самостоятельно инициализируете при запуске эмуляции с заданного адреса. Здесь также можно создать и сохранить символьные вектора нужной длины.

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

Продолжаем хорошую традицию

Наконец, решим Kaos Toy Project плагином AngryGhidra.

Первое, что сделаем запустим toyproject.exe в любом отладчике и отследим, по какому адресу записываются байты Installation ID.

Взглянем на байты по адресу 0x4093a8, это и есть наш Installation ID.

Нужно учитывать тот факт, что отладчик в Ghidra отсутствует, а angr осуществляет эмуляцию бинаря (за это отвечают компоненты PyVEX и SimEngine). Это значит, что значение Installation ID инициализировано не будет, нам нужно сделать это самостоятельно. Наш ход патчинг байтов в Ghidra.

Найдем адрес 0x4093a8 и запатчим нулевые значения байтами Installation ID, выделим их и выберем в контекстном меню AngryGhidraPlugin -> ApplyPatchedBytes:

Теперь решим вопрос с адресами куда хотим попасть, чего следует избегать и с чего вообще начнем.

Строка Congratulations! Now write a keygen and tutorial! однозначно для нас искомая, так что адресом для поиска станет адрес помещения в стек этой строки для вызова окна с сообщением. Выберем адрес 0x40123b, для этого можно вписать его в поле Find Address или, открыв контекстное меню, выбрать AngryGhidraPlugin -> Set -> Find Address. Теперь адрес будет перекрашен в зеленый цвет.

Строка That is just wrong. Try harder! говорит о неверном введенном ключе, так что отметим адрес 0x401250 в качестве Avoid Address. Теперь он будет красным в окне дизассемблера.

Чтобы сократить время поиска решения будет удобно выбрать начальное состояние (Blank State) по адресу, где вызывается функция проверки введенного ключа. Это функция 0x4010ec. Выделим адрес вызова этой функции в качестве Blank State Address, и он перекрасится в голубой цвет.

С назначением адресов мы закончили:

Остался последний момент. Заглянем в функцию проверки ключа по адресу 0x4010ec и изучим, каким образом нам стоит передать две части ключа в плагин.

Как можно увидеть, две части ключа передаются в функцию проверки в качестве аргументов. Поскольку наше начальное состояние не предусматривает наличия аргументов, мы должны перехватить момент записи этих аргументов в регистры EDX и EBX и внести символьные значения самостоятельно. Но что они из себя представляют? Вернемся в основную функцию программы и изучим этот момент.

Можно заметить, что первоначально введенные две части ключа обрабатываются функцией по адресу 0x40109d:

Таким образом, каждая часть ключа имеет длину 4 байта, причем второй аргумент для функции проверки будет являться результатом xor-а первой и второй части ключа.

Откроем окно AngryGhidraPlugin и создадим хук по адресу 0x4010ff, чтобы заполнить значения регистров EDX и EBX символьными векторами длиной по 4 байта.

Теперь все готово к запуску, жмем Run и получаем результат!

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

И проверяем:

Ключ подошел! И ни строчки кода! Плагин AngryGhidra сделал все за нас.

Большое спасибо компании Digital Security за интересную стажировку, которая прошла для меня в удаленном формате, наставникам Андрею (@e13fter) и Саше (@dura_lex), отдельная благодарность за поддержку Виктору Склярову и Борису Рютину!

Плагин на Github: AngryGhidra.

• Немного языка Assembler
• Логика вместе с отладчиком (IDA PRO)

Осмотр пациента

Вскрытие больного

Время для лекарства

import randomdef gen_key_part():    # Генерация цифр    num1 = str(random.randint(0, 9))    num2 = str(random.randint(0, 9))    num3 = str(random.randint(0, 9))    num4 = str(random.randint(0, 9))    # Генерация части ключа (1 блок)    final = num1 + num2 + num3 + num4    return finaldef sum_ord(key_part):    # Раскладываем переданную часть ключа на цифры    num1 = key_part[0]    num2 = key_part[1]    num3 = key_part[2]    num4 = key_part[3]    # Алгорит сложения в crackme    sum = ord(num1) + ord(num2) + ord(num3) + ord(num4) + ord(num4) + ord(num4)    sum_final = ord(num4) + sum - 336    return sum_finaldef shr(key):    # Разбиваем ключ на блоки    a = key[0:4]    b = key[5:9]    c = key[10:14]    d = key[15:19]    # Алгоритм сдвига по битам в crackme    x = sum_ord(a) + sum_ord(b) + sum_ord(c) + sum_ord(d)    x = x >> 2    return xdef check_key(key):    i = 0 # Счётчик    while i != 4:        # Переменная i будет увеличиваться на 1 до 4. Это будет указатель на проверяемый символ        first = 0 + i        second = 5 + i        third = 10 + i        four = 15 + i        # Проверка ключа на соответсвие сдвига по битам и суммы чисел ( Обозначали, как A и B)        if sum_ord(key[0:4]) != shr(key) or sum_ord(key[5:9]) != shr(key) or sum_ord(key[10:14]) != shr(key) or sum_ord(key[15:19]) != shr(key):            return False        # Проверка ключа на совпадающие цифры        if int(key[first]) == int(key[second]):            return False        if int(key[second]) == int(key[third]):            return False        if int(key[third]) == int(key[four]):            return False        i += 1 # # Счётчик увеличиваемdef generate_key():    # Генерация ключа    key = gen_key_part() + '-' + gen_key_part() + '-' + gen_key_part() + '-' + gen_key_part()    # Проверяем ключ и печатаем true или false    while True: #        if check_key(key) == False:            # Генерация ключа если не верно            key = gen_key_part() + '-' + gen_key_part() + '-' + gen_key_part() + '-' + gen_key_part()            print('Checking this key -> ' + key)        else:            # Ключ правильный            print('This is the correct key -> ' + key)            break# Генерируем ключ, вызывая функциюif __name__ == "__main__":    generate_key()

• Лампа ремня безопасности контакт 3
• Лампа омывайки контакт 6
• Лампа аккумулятора контакт 4
• Лампа сигнализации контакт 5
• Работа спидометра:

A0 0F 00 0F 00 14 00 00 00 00 14 A1 0B 00 0B 00 6E 00 00 00 00 6E A2 0F 00 02 00 14 10 00 00 00 09 A3 07 00 00 00 6E 05 00 00 00 6C A4 0F 00 0C 40 34 3F 00 00 00 48 A5 02 00 0E 00 6E 01 08 00 00 6B A6 0C 00 01 00 14 1F 00 00 00 06 A7 00 00 0F 00 6E 00 00 00 00 61A8 00 00 00 00 14 00 00 00 00 14 A9 00 00 00 00 6E 00 00 00 00 6E

A0 0F 00 0F 00 14 00 00 00 00 14A1 0B 00 0B 00 6E 00 00 00 00 6EA2 0F 00 02 00 14 10 00 00 00 09A3 07 00 00 00 6E 05 00 00 00 6CA4 0F 00 0C 40 34 3F 00 00 00 48A5 02 00 0E 00 6E 01 08 00 00 6BA6 0C 00 01 00 14 1F 00 00 00 06A7 00 00 0F 00 6E 00 00 00 00 61A8 00 00 00 00 14 00 00 00 00 14A9 00 00 00 00 6E 00 00 00 00 6E

(Небольшой кусок от A0 до A9)A0 40 00 00 78 3F 00 00 00 00 07A1 00 00 00 10 00 00 00 00 00 10A2 40 00 00 78 3F 00 00 00 00 07A3 00 00 00 10 00 00 00 00 00 10A4 40 00 00 78 3F 00 00 00 00 07A5 00 00 00 10 00 00 00 00 00 10A6 40 00 00 78 3F 00 00 00 00 07A7 00 00 00 10 00 00 00 00 00 10A8 40 00 00 78 3F 00 00 00 00 07A9 00 00 00 10 00 00 00 00 00 10

Всем привет,

При работе в IDA мне, да и, наверняка, вам тоже, часто приходится иметь дело с приложениями, которые имеют достаточно большой объём кода, не имеют символьной информации и, к тому же, содержат много библиотечного кода. Зачастую, такой код нужно уметь отличать от написанного пользователем. И, если на вход библиотечного кода подаются только int, void *, да const char *, можно отделаться одними лишь сигнатурами (созданные с помощью FLAIR-утилит sig-файлы). Но, если нужны структуры, аргументы, их количество, тут без дополнительной магии не обойдёшься В качестве примера я буду работать с игрой для Sony Playstation 1, написанной с использованием PSYQ v4.7.

Дополнительная магия

Представим ситуацию: вам попалась прошивка от какой-нибудь железки. Обычный Bare-metal ROM (можно даже с RTOS). Или же ROM игры. В подобных случаях, скорее всего, при компиляции использовался какой-то SDK/DDK, у которого имеется набор LIB/H/OBJ файлов, которые вклеиваются линкером в итоговый файл.

Наш план действий будет примерно таким:

1. Взять все lib/obj-файлы, и создать из них сигнатуры (или набор сигнатур). Это поможет нам отделить статически влинкованный библиотечный код.
2. Взять все h-файлы и создать из них библиотеку типов. Эта библиотека хранит не только типы данных, но и информацию об именах и типах аргументов функций, в которых объявленные типы используются.
3. Применить сигнатуры, чтобы у нас определились библиотечные функции и их имена.
4. Применить библиотеки типов, чтобы применить прототипы функций и используемые типы данных.

Создаём sig-файлы

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

• pcf LIB/OBJ-parser, создаёт PAT-файл из COFF-объектных файлов
• pelf LIB/OBJ-парсер, создаёт PAT-файл из ELF-файлов (Unix)
• plb LIB/OBJ-parser, создаёт PAT-файл из OMF-объектных файлов
• pmacho MACH-O-парсер, создаёт PAT-файл из MACH-O-файлов (MacOS)
• ppsx OBJ-парсер, создаёт PAT-файл из библиотечных файлов PSYQ
• ptmobj OBJ-парсер, создаёт PAT-файл из библиотечных файлов Trimedia
• sigmake конвертирует ранее созданный PAT-файл в SIG-файл, перевариваемый IDA

В моём случае это ppsx. Собираю bat-файл, в котором перечисляю все lib- и obj-файлы, и добавляю к каждой строке вызов ppsx, чтобы получилось формирование итогового PAT-файла. Получилось следующее содержимое:

@echo offppsx -a 2MBYTE.OBJ psyq47.patppsx -a 8MBYTE.OBJ psyq47.patppsx -a LIBAPI.LIB psyq47.patppsx -a LIBC.LIB psyq47.patppsx -a LIBC2.LIB psyq47.patppsx -a LIBCARD.LIB psyq47.patppsx -a LIBCD.LIB psyq47.patppsx -a LIBCOMB.LIB psyq47.patppsx -a LIBDS.LIB psyq47.patppsx -a LIBETC.LIB psyq47.patppsx -a LIBGPU.LIB psyq47.patppsx -a LIBGS.LIB psyq47.patppsx -a LIBGTE.LIB psyq47.patppsx -a LIBGUN.LIB psyq47.patppsx -a LIBHMD.LIB psyq47.patppsx -a LIBMATH.LIB psyq47.patppsx -a LIBMCRD.LIB psyq47.patppsx -a LIBMCX.LIB psyq47.patppsx -a LIBPAD.LIB psyq47.patppsx -a LIBPRESS.LIB psyq47.patppsx -a LIBSIO.LIB psyq47.patppsx -a ashldi3.obj psyq47.patppsx -a ashrdi3.obj psyq47.patppsx -a CACHE.OBJ psyq47.patppsx -a clear_cache.obj psyq47.patppsx -a CLOSE.OBJ psyq47.patppsx -a cmpdi2.obj psyq47.patppsx -a CREAT.OBJ psyq47.patppsx -a ctors.obj psyq47.patppsx -a divdi3.obj psyq47.patppsx -a dummy.obj psyq47.patppsx -a eh.obj psyq47.patppsx -a eh_compat.obj psyq47.patppsx -a exit.obj psyq47.patppsx -a ffsdi2.obj psyq47.patppsx -a fixdfdi.obj psyq47.patppsx -a fixsfdi.obj psyq47.patppsx -a fixtfdi.obj psyq47.patppsx -a fixunsdfdi.obj psyq47.patppsx -a fixunsdfsi.obj psyq47.patppsx -a fixunssfdi.obj psyq47.patppsx -a fixunssfsi.obj psyq47.patppsx -a fixunstfdi.obj psyq47.patppsx -a fixunsxfdi.obj psyq47.patppsx -a fixunsxfsi.obj psyq47.patppsx -a fixxfdi.obj psyq47.patppsx -a floatdidf.obj psyq47.patppsx -a floatdisf.obj psyq47.patppsx -a floatditf.obj psyq47.patppsx -a floatdixf.obj psyq47.patppsx -a FSINIT.OBJ psyq47.patppsx -a gcc_bcmp.obj psyq47.patppsx -a LSEEK.OBJ psyq47.patppsx -a lshrdi3.obj psyq47.patppsx -a moddi3.obj psyq47.patppsx -a muldi3.obj psyq47.patppsx -a negdi2.obj psyq47.patppsx -a new_handler.obj psyq47.patppsx -a op_delete.obj psyq47.patppsx -a op_new.obj psyq47.patppsx -a op_vdel.obj psyq47.patppsx -a op_vnew.obj psyq47.patppsx -a OPEN.OBJ psyq47.patppsx -a PROFILE.OBJ psyq47.patppsx -a pure.obj psyq47.patppsx -a read.obj psyq47.patppsx -a shtab.obj psyq47.patppsx -a snctors.obj psyq47.patppsx -a SNDEF.OBJ psyq47.patppsx -a SNMAIN.OBJ psyq47.patppsx -a SNREAD.OBJ psyq47.patppsx -a SNWRITE.OBJ psyq47.patppsx -a trampoline.obj psyq47.patppsx -a ucmpdi2.obj psyq47.patppsx -a udiv_w_sdiv.obj psyq47.patppsx -a udivdi3.obj psyq47.patppsx -a udivmoddi4.obj psyq47.patppsx -a umoddi3.obj psyq47.patppsx -a varargs.obj psyq47.patppsx -a write.obj psyq47.patppsx -a LIBSND.LIB psyq47.patppsx -a LIBSPU.LIB psyq47.patppsx -a LIBTAP.LIB psyq47.patppsx -a LOW.OBJ psyq47.patppsx -a MCGUI.OBJ psyq47.patppsx -a MCGUI_E.OBJ psyq47.patppsx -a NOHEAP.OBJ psyq47.patppsx -a NONE3.OBJ psyq47.patppsx -a NOPRINT.OBJ psyq47.patppsx -a POWERON.OBJ psyq47.pat

LIBSN.LIB файл имеет формат, отличный от остальных библиотек, поэтому пришлось разложить его на OBJ-файлы утилитой PSYLIB2.EXE, которая входит в комплект PSYQ. Запускаем run_47.bat. Получаем следующий выхлоп:

2MBYTE.OBJ: skipped 0, total 18MBYTE.OBJ: skipped 0, total 1LIBAPI.LIB: skipped 0, total 89LIBC.LIB: skipped 0, total 55LIBC2.LIB: skipped 0, total 50LIBCARD.LIB: skipped 0, total 18LIBCD.LIB: skipped 0, total 51LIBCOMB.LIB: skipped 0, total 3LIBDS.LIB: skipped 0, total 36LIBETC.LIB: skipped 0, total 8LIBGPU.LIB: skipped 0, total 60LIBGS.LIB: skipped 0, total 167LIBGTE.LIB: skipped 0, total 535LIBGUN.LIB: skipped 0, total 2LIBHMD.LIB: skipped 0, total 585LIBMATH.LIB: skipped 0, total 59LIBMCRD.LIB: skipped 0, total 7LIBMCX.LIB: skipped 0, total 31LIBPAD.LIB: skipped 0, total 21LIBPRESS.LIB: skipped 0, total 7LIBSIO.LIB: skipped 0, total 4ashldi3.obj: skipped 0, total 1ashrdi3.obj: skipped 0, total 1CACHE.OBJ: skipped 0, total 1clear_cache.obj: skipped 0, total 1CLOSE.OBJ: skipped 0, total 1cmpdi2.obj: skipped 0, total 1CREAT.OBJ: skipped 0, total 1ctors.obj: skipped 0, total 0divdi3.obj: skipped 0, total 1dummy.obj: skipped 0, total 1Fatal: Illegal relocation information at file pos 0000022Deh_compat.obj: skipped 0, total 1exit.obj: skipped 0, total 1ffsdi2.obj: skipped 0, total 1fixdfdi.obj: skipped 0, total 1fixsfdi.obj: skipped 0, total 1fixtfdi.obj: skipped 0, total 0fixunsdfdi.obj: skipped 0, total 1fixunsdfsi.obj: skipped 0, total 1fixunssfdi.obj: skipped 0, total 1fixunssfsi.obj: skipped 0, total 1fixunstfdi.obj: skipped 0, total 0fixunsxfdi.obj: skipped 0, total 0fixunsxfsi.obj: skipped 0, total 0fixxfdi.obj: skipped 0, total 0floatdidf.obj: skipped 0, total 1floatdisf.obj: skipped 0, total 1floatditf.obj: skipped 0, total 0floatdixf.obj: skipped 0, total 0FSINIT.OBJ: skipped 0, total 1gcc_bcmp.obj: skipped 0, total 1LSEEK.OBJ: skipped 0, total 1lshrdi3.obj: skipped 0, total 1moddi3.obj: skipped 0, total 1muldi3.obj: skipped 0, total 1negdi2.obj: skipped 0, total 1Fatal: Illegal relocation information at file pos 0000013Dop_delete.obj: skipped 0, total 1op_new.obj: skipped 0, total 1op_vdel.obj: skipped 0, total 1op_vnew.obj: skipped 0, total 1OPEN.OBJ: skipped 0, total 1PROFILE.OBJ: skipped 0, total 1pure.obj: skipped 0, total 1Fatal: Unknown record type 60 at 0000015Fshtab.obj: skipped 0, total 0Fatal: Unknown record type 60 at 000000EESNDEF.OBJ: skipped 0, total 0SNMAIN.OBJ: skipped 0, total 1SNREAD.OBJ: skipped 0, total 1SNWRITE.OBJ: skipped 0, total 1trampoline.obj: skipped 0, total 0ucmpdi2.obj: skipped 0, total 1udiv_w_sdiv.obj: skipped 0, total 1udivdi3.obj: skipped 0, total 1udivmoddi4.obj: skipped 0, total 1umoddi3.obj: skipped 0, total 1varargs.obj: skipped 0, total 1Fatal: Unknown record type 60 at 00000160LIBSND.LIB: skipped 0, total 223LIBSPU.LIB: skipped 0, total 126LIBTAP.LIB: skipped 0, total 1LOW.OBJ: skipped 0, total 1Fatal: can't find symbol F003MCGUI_E.OBJ: skipped 0, total 1NOHEAP.OBJ: skipped 0, total 1NONE3.OBJ: skipped 0, total 1NOPRINT.OBJ: skipped 0, total 1POWERON.OBJ: skipped 0, total 1

Видим некоторое количество ошибок парсинга, но, в тех файлах всего 1 сигнатура (total 1), поэтому, думаю, что это не критично. Далее преобразовываем PAT-файл в SIG-файл:

sigmake -n"PsyQ v4.7" psyq47.pat psyq47.sigpsyq47.sig: modules/leaves: 1345/2177, COLLISIONS: 21See the documentation to learn how to resolve collisions.

В итоге получаем следующий список файлов:

• psyq47.err его не трогаем
• psyq47.exc его нужно будет отредактировать
• psyq47.pat его тоже не трогаем

Открываем на редактирование .exc-файл. Видим:

;--------- (delete these lines to allow sigmake to read this file); add '+' at the start of a line to select a module; add '-' if you are not sure about the selection; do nothing if you want to exclude all modules

Если удалить ---------, всё, что содержится в файле ниже, будет учитываться. Давайте взглянем на то, что там есть. Вот пример:

CdPosToInt                                          60 A21C 0000839001008690022903008010050021104500401002000F00633021104300DsPosToInt                                          60 A21C 0000839001008690022903008010050021104500401002000F00633021104300

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

В итоге, если всё сделано правильно, получаем SIG-файл. Его нужно положить в соответствующую папку в каталоге установка IDA.

Создаём til-файлы

Эти файлы нужны для хранения информации о типах, об аргументах функций и т.п. По-умолчанию. Создаются они с помощью утилиты tilib, которую необходимо положить в каталог с Идой (ей, почему-то, нужен ida.hlp файл).

Данной утилите нужно скормить include-файлы вашего SDK/DDK. При том парсинг этой утилитой отличается от такового средством "Parse C header file..." в самой IDA. Вот описание из readme:

Its functionality overlaps with "Parse C header file..." from IDA Pro.
However, this utility is easier to use and provides more control
over the output. Also, it can handle the preprocessor symbols, while
the built-in command ignores them.

У этой утилиты есть один нюанс: она по умолчанию использует режим, когда символы заманглены, либо имеют стоящее в начале имени нижнее подчёркивание. В случае работы со статически влинкованным кодом этот режим нужно выключить флагом -Gn.

По-умолчанию, данная утилита принимает на вход только один include-файл. Если же файлов много, нужно соорудить include-файл следующего содержания:

#include "header1.h"#include "header2.h"#include "header3.h"// ...

Этот файл передаётся с помощью флага -hFileName.h. Далее, передаём путь поиска остальных header-файлов и получаем следующую командую строку:

tilib -c -Gn -I. -hpsyq47.h psyq47.til

На выходе получаем til-файл, пригодный для использования. Кладём его в соответствующий каталог IDA: sig\mips.

Проверяем результат

Закидываем ROM-файл в IDA, дожидаемся окончания анализа. Далее, необходимо указать компилятор. Для этого заходим в Options->Compiler:

Теперь просто меняем Unknown на GNU C++ (в случае PSX). Остальное оставляем как есть:

Теперь жмём Shift+F5 (либо меню View->Open subviews->Signatures), жмём Insert и выбираем нужный файл сигнатур:

Жмём OK и ждём, пока применяются сигнатуры (у меня получилось 482 распознанных функции).

Далее необходимо применить библиотеку типов (til-файл). Для этого жмём Shift+F11 (либо View->Open subviews->Type libraries) и понимаем, что IDA не может определить компилятор (не смотря на то, что мы его уже указали):

Но это нам всё равно не помешает выбрать til-файл (всё так же, через Insert):

Получаем то, что так хотели:

Теперь декомпилятор успешно подхватывает информацию о типах, и выхлоп становится куда лучше:

P.S.

Надеюсь, эта информация окажется для вас полезной. Удачного реверс-инжиниринга!

Как работает ПЛИС?

Конфигурируемые логические боки (CLB, Configurable Logic Block)

Таблицы просмотра

Таблицы просмотра в XC2064 это нечто более сложное, чем просто таблицы. Каждый CLB содержит две трёхвходовые таблицы просмотра. Входы таблиц в XC2064 имеют программируемые мультиплексоры, позволяя выбрать 4 различных потенциальных входа. Вдобавок, две таблицы просмотра могут быть объединены для получения функции четырёх переменных и других комбинаций.


Логические функции в ПЛИС XC2064 реализованы с помощью таблиц просмотра. Из документации.

Соединения

Реализация

Фотография кристалла

Для анализа XC2064 я использовал моё собственное фото кристалла XC20186, а также фото кристаллов XC2064 и XC2018 с siliconpr0n. Трудно анализировать ПЛИС по снимкам с оптического микроскопа, так как они имеют два слоя металлизации. John McMaster использовал электронный микроскоп, чтобы устранить неоднозначность, вносимую этими слоями. Фото ниже показывает, как верхний слой металлизации выглядит под электронным микроскопом.


Фото XC2064 под электронным микроскопом, с любезного разрешения John McMaster.

XC2018

ПЛИС Xilinx XC2018 (на фото ниже) имеет 100 ячеек, таких же, как в XC2064. Внутри она использует те же самые плитки, что и XC2064 с 64 ячейками, но они объединены в сетку 10х10, а не 8х8. Формат битстрима XC2018 очень похож, но больше по размеру.


ПЛИС XC2018. Справа корпус удалён, видно кремниевый кристалл. На кристалле слабо виден рисунок плиток.

На фото ниже можно видеть сравнение кристалла XC2064 и XC2018. Кристаллы очень похожи, за исключением того, что больший чип имеет две дополнительных строки и два дополнительных столбца на кристалле.


Сравнение кристаллов XC2064 и XC2018. Изображения масштабированы так, что размеры плиток совпадают, я не знаю, как соотносятся физические размеры кристаллов. Фото кристаллов взяты с siliconpr0n.

Внутри плитки

Транзисторы

Битовый поток и память конфигурации

Битстрим

Хотя битстрим напрямую отображается на аппаратные ячейки памяти, файл битстрима (.RBT) имеет некоторое форматирование, показанное ниже.


Формат данных битстрима, из документации.

Ячейка SRAM

Память конфигурации реализована на ячейках статической памяти (SRAM). Технически, эта память не является RAM, так как доступ производится последовательно, через регистр сдвига, но люди всё равно называют её SRAM. Эти ячейки памяти имеют пять транзисторов, и известны как 5T SRAM.

Остаётся под вопросом, есть ли в битстриме неиспользуемые биты. Вероятно, многие биты не используются. Например, каждая плитка имеет блок 18х18 бит, из которых 27 бит не используются. Просмотр кристалла показывает, что ячейки памяти, соответствующие неиспользованным битам, удалены полностью, и их место на кристалле использовано для других цепей. Фото кристалла внизу показывает 9 использованных бит и один пропущенный.


Ячейки памяти, показан промежуток, в котором одна ячейка пропущена. Взято с siliconpr0n.

Мультиплексоры таблицы просмотра

Триггер

Восьмивыводная матрица переключателя

Соединения входов

Заключение

Примечание

Я разобрался в том, как сконфигурирована большая часть битстрима XC2064 (см. примечание 11), и я написал программу для генерации информации CLB из файла битстрима. К сожалению, это один из тех проектов, в которых последние 20% поглощают большую часть времени, и работа до сих пор не закончена. Одна из проблем управление портами ввода-вывода, которые совершенно нерегулярны и имеют свою собственную конфигурацию межсоединений. Другой проблемой является то, что плитки по краям имеют другую конфигурацию. Объединение отдельных узлов трассировки в общий нетлист также требует некоторых громоздких вычислений на графах.

Следующая таблица обобщает смысл каждого бита в плитке, в части битстрима размером 818. Каждая строка в таблице соответствует одному биту в битстриме, и показывает, какая часть ПЛИС управляется этим битом. Пустые строки соответствуют неиспользованным битам.



Первые два столбца таблицы соответствуют переключающей матрице. Есть две переключающие матрицы, обозначенные как #1 (красная) и #2 (зелёная) на рисунке ниже. 8 выходов матрицы #1 пронумерованы от 1 до 8 по часовой стрелке. Переключатель #2 пронумерован так же, но не хватило места для номеров. Например, "#2: 1-3" обозначает, что этот бит соединяет выводы 1 и 3 на переключателе #2. Следующий столбец определяет ND, ненаправленные связи, прямоугольники ниже пурпурных цифр около переключательных матриц. каждый бит ND в таблице управляет соответствующим соединением ND.



Схема межсоединений показывает схему нумерации, которую я сделал для таблицы битстрима. Следующие две колонки описывают то, что я называю PIP соединения, сплошные прямоугольники, на линиях выше. Соединения с выхода Х (коричневые) управляются отдельными битами (Х1, Х2, С3), аналогично для соединения с выхода Y (желтый). Соединения к входу В (светло-пурпурный) устроены по-другому. Только одно из входных соединений может быть активно, и они кодируются множеством бит, с использованием мультиплексоров. Вход С (голубой), D (синий), и A (зелёный) похожи. Остальные столбцы в таблице описывают CLB, обратитесь к документации за подробностями. Биты управляют тактовым сигналом, установкой и линией сброса. Выходы X и Y могут быть выбраны из таблиц (LUT) F и G. Последние два столбца определяют LUT. Есть три входа для LUT F и три входа для LUT G, мультиплексоры управляют входами. Наконец, 8 бит для каждого LUT определяются, задавая выход для определённой комбинации трёх входов.

sudo apt install build-essential

sudo apt install libopenal-dev libglew-dev libglfw3-dev libmpg123-dev

mkdir glfw-buildcd glfw-buildcmake -DBUILD_SHARED_LIBS=ON ../make -j2sudo checkinstall

git clone --recursive -b miami https://github.com/GTAmodding/re3.git reVC

./premake5Linux --with-librw gmake2

make config=debug_linux-amd64-librw_gl3_glfw-oal

git clone --recursive https://github.com/GTAmodding/re3.git

Часть вторая

Полезные ссылки

• Официальная документация с MSDN: docs.microsoft.com/en-us/windows/win32/fileio/reparse-points
• М. Руссинович, Д. Соломон, А. Ионеску, Внутреннее устройство Microsoft Windows. 6-е изд. Основные подсистемы ОС. Стр 535.
• Короткий и удобный гайд: hex.pp.ua/reparse-point-custom.php
• Очень классный проект использующий RP: github.com/aleksk/LazyCopy
• Решение задачи, которую мы разберем ниже: github.com/Dabudabot/injection-monitor

Теория

typedef struct _REPARSE_GUID_DATA_BUFFER {  ULONG  ReparseTag;  USHORT ReparseDataLength;  USHORT Reserved;  GUID   ReparseGuid;  struct {    UCHAR DataBuffer[1];  } GenericReparseBuffer;} REPARSE_GUID_DATA_BUFFER, *PREPARSE_GUID_DATA_BUFFER;

• Небольшое приложение с привилегиями SE_BACKUP_NAME или SE_RESTORE_NAME, которое будет создавать файл содержащий структуру RP, устанавливать обязательное поле ReparseTag и заполнять DataBuffer
• Драйвер режима ядра, который будет читать данные буфера и обрабатывать обращения к этому файлу.

Создадим свой файл с RP

void GetPrivilege(LPCTSTR priv){HANDLE hToken;TOKEN_PRIVILEGES tp;OpenProcessToken(GetCurrentProcess(),TOKEN_ADJUST_PRIVILEGES, &hToken);LookupPrivilegeValue(NULL, priv, &tp.Privileges[0].Luid);tp.PrivilegeCount = 1;tp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;AdjustTokenPrivileges(hToken, FALSE, &tp,sizeof(TOKEN_PRIVILEGES), NULL, NULL);CloseHandle(hToken);}GetPrivilege(SE_BACKUP_NAME);GetPrivilege(SE_RESTORE_NAME);GetPrivilege(SE_CREATE_SYMBOLIC_LINK_NAME);

TCHAR data[] = _T("My reparse data");BYTE reparseBuffer[sizeof(REPARSE_GUID_DATA_BUFFER) + sizeof(data)];PREPARSE_GUID_DATA_BUFFER rd = (PREPARSE_GUID_DATA_BUFFER) reparseBuffer;ZeroMemory(reparseBuffer, sizeof(REPARSE_GUID_DATA_BUFFER) + sizeof(data));// {07A869CB-F647-451F-840D-964A3AF8C0B6}static const GUID my_guid = { 0x7a869cb, 0xf647, 0x451f, { 0x84, 0xd, 0x96, 0x4a, 0x3a, 0xf8, 0xc0, 0xb6 }};rd->ReparseTag = 0xFF00;rd->ReparseDataLength = sizeof(data);rd->Reserved = 0;rd->ReparseGuid = my_guid;memcpy(rd->GenericReparseBuffer.DataBuffer, &data, sizeof(data));

LPCTSTR name = _T("TestReparseFile");_tprintf(_T("Creating empty file\n"));HANDLE hFile = CreateFile(name,GENERIC_READ | GENERIC_WRITE, 0, NULL,CREATE_NEW, FILE_FLAG_OPEN_REPARSE_POINT | FILE_FLAG_BACKUP_SEMANTICS,NULL);if (INVALID_HANDLE_VALUE == hFile){_tprintf(_T("Failed to create file\n"));return -1;}

_tprintf(_T("Creating reparse\n"));if (!DeviceIoControl(hFile, FSCTL_SET_REPARSE_POINT, rd, rd->ReparseDataLength + REPARSE_GUID_DATA_BUFFER_HEADER_SIZE, NULL, 0, &dwLen, NULL)){CloseHandle(hFile);DeleteFile(name);_tprintf(_T("Failed to create reparse\n"));return -1;}CloseHandle(hFile);

Обработка RP

// todo конечно стоит проверить наш ли это тэг, а не только его наличиеif (Data->TagData != NULL) {if ((Data->Iopb->Parameters.Create.Options & FILE_OPEN_REPARSE_POINT) != FILE_OPEN_REPARSE_POINT)    {      Data->Iopb->Parameters.Create.Options |= FILE_OPEN_REPARSE_POINT;      FltSetCallbackDataDirty(Data);      FltReissueSynchronousIo(FltObjects->Instance, Data);    }    status = FltFsControlFile(      FltObjects->Instance,       FltObjects->FileObject,       FSCTL_GET_REPARSE_POINT,       NULL,       0,       reparseData,      reparseDataLength,      NULL    );}

// Operations.c - PostCreateOperationCallbackNT_IF_FAIL_LEAVE(LcGetReparsePointData(FltObjects, &fileSize, &remotePath, &useCustomHandler));NT_IF_FAIL_LEAVE(LcFindOrCreateStreamContext(Data, TRUE, &fileSize, &remotePath, useCustomHandler, &streamContext, &contextCreated));// Operations.c - PreReadWriteOperationCallbackstatus = LcGetStreamContext(Data, &context);NT_IF_FAIL_LEAVE(LcGetFileLock(&nameInfo->Name, &fileLockEvent));NT_IF_FAIL_LEAVE(LcFetchRemoteFile(FltObjects, &context->RemoteFilePath, &nameInfo->Name, context->UseCustomHandler, &bytesFetched));NT_IF_FAIL_LEAVE(LcUntagFile(FltObjects, &nameInfo->Name));NT_IF_FAIL_LEAVE(FltDeleteStreamContext(FltObjects->Instance, FltObjects->FileObject, NULL));

Задачка

Решение

NT_IF_FAIL_LEAVE(PsSetCreateProcessNotifyRoutine(IMCreateProcessNotifyRoutine, FALSE));

NT_IF_FAIL_LEAVE(PsLookupProcessByProcessId(ProcessId, &eProcess));NT_IF_FAIL_LEAVE(ObOpenObjectByPointer(eProcess, OBJ_KERNEL_HANDLE, NULL, 0, 0, KernelMode, &hProcess));NT_IF_FAIL_LEAVE(ZwQueryInformationProcess(hProcess,                                               ProcessImageFileName,                                               buffer,                                               returnedLength,                                               &returnedLength));

target = &Globals.TargetProcessInfo[i];if (RtlCompareUnicodeString(&processNameInfo->Name, &target->TargetName, TRUE) == 0){      target->NameInfo = processNameInfo;      target->isActive = TRUE;      target->ProcessId = ProcessId;      LOG(("[IM] Found process creation: %wZ\n", &processNameInfo->Name));}

status = FltGetFileNameInformation(Data, FLT_FILE_NAME_OPENED | FLT_FILE_NAME_QUERY_FILESYSTEM_ONLY | FLT_FILE_NAME_ALLOW_QUERY_ON_REPARSE, &fileNameInfo);

// may be it is swif (RtlCompareUnicodeString(&FileNameInfo->Name, &strSw, TRUE) == 0){// concatNT_IF_FAIL_LEAVE(IMConcatStrings(&replacement, &FileNameInfo->ParentDir, &strHw));// then need to changeNT_IF_FAIL_LEAVE(IoReplaceFileObjectName(FileObject, replacement.Buffer, replacement.Length));}Data->IoStatus.Status = STATUS_REPARSE;Data->IoStatus.Information = IO_REPARSE;return FLT_PREOP_COMPLETE;

Тестируем

// testapp.exe#include "TestHeader.h"int main(){TestFunction();return 0;}// testdll0.dll#include "../include/TestHeader.h"#include <iostream>// This is an example of an exported function.int TestFunction(){std::cout << "hello from test dll 0" << std::endl;return 0;}// testdll1.dll#include "../include/TestHeader.h"#include <iostream>// This is an example of an exported function.int TestFunction(){std::cout << "hello from test dll 1" << std::endl;return 0;}

Last Epoch это однопользовательская ARPG на Unity и C#. В игре присутствует система крафта игрок находит модификаторы, которые затем применяет к экипировке. С каждым модификатором накапливается "нестабильность", которая увеличивает шанс поломки предмета

Я преследовал две цели:

• Убрать "поломку" предмета в результате применения модификаторов
• Не расходовать модификаторы при крафте

Вот так выглядит окно крафта в игре

Часть первая, где мы редактируем .NET код без регистрации и смс

Для начала я опишу процесс модификации старой версии игры (0.7.8)

После компиляции C# превращается в IL (Intermediate Language) код. IL-код напоминает ассемблер высокого уровня абстракции и замечательно декомпилируется. В Unity проектах IL-код игры как правило находится в <GameFolder>/Managed/Assembly-CSharp.dll

Для редактирования IL-кода мы будем использовать dnSpy лучший из всех инструментов подобного рода для .NET, что я встречал. dnSpy делает работу со скомпилированными .NET приложениями настолько легкой, что ее можно спутать с разработкой в обычной IDE

Ищем логику крафта

Итак, запускаем dnSpy и открываем Assembly-CSharp.dll

Мы сразу видим невероятно длинный список классов. В данном случае целью является модификация системы крафта, поэтому поступаю просто ищу классы, в названии которых встречается Craft и просматриваю их логику по диагонали

После непродолжительных поисков мы нашли искомое класс CraftingSlotManager

А именно метод Forge() в данном классе

// CraftingSlotManager// Token: 0x06002552 RID: 9554 RVA: 0x0015E958 File Offset: 0x0015CB58public void Forge(){    if (!this.forging)    {        this.forging = true;        base.StartCoroutine(this.ForgeBlocker(10));        bool flag = false;        int num = -1;        if (this.main.HasContent())        {            int num2 = 0;            int num3 = 0;            if (this.debugNoFracture)            {                num3 = -10;            }            float num4 = 1f;            int num5 = -1;            bool flag2 = false;            ItemData data = this.main.GetContent()[0].data;            ItemData itemData = null;            if (this.support.HasContent())            {                itemData = this.support.GetContent()[0].data;                num5 = (int)itemData.subType;                if (itemData.subType == 0)                {                    num3--;                    flag2 = true;                }                else if (itemData.subType == 1)                {                    num4 = UnityEngine.Random.Range(0.4f, 1f);                    flag2 = true;                }            }            if (this.appliedAffixID >= 0)            {                Debug.Log("applied ID: " + this.appliedAffixID.ToString());                if (this.forgeButtonText.text == "Forge")                {                    if (data.AddAffixTier(this.appliedAffixID, Mathf.RoundToInt((float)(5 + num2) * num4), num3))                    {                        num = this.appliedAffixID;                        flag = true;                    }                    GlobalDataTracker.instance.CheckForShard(this.appliedAffixID);                    if (flag2)                    {                        this.support.Clear();                    }                    if (!GlobalDataTracker.instance.CheckForShard(this.appliedAffixID))                    {                        this.DeselectAffixID();                    }                }            }            else if (this.modifier.HasContent())            {                Debug.Log("modifier lets go");                ItemData data2 = this.modifier.GetContent()[0].data;                if (data2.itemType == 102)                {                    if (data2.subType == 0)                    {                        Debug.Log("shatter it");                        Notifications.CraftingOutcome(data.Shatter());                        if (num5 == 0)                        {                            flag2 = false;                        }                        this.main.Clear();                        flag = true;                        this.ResetAffixList();                    }                    else if (data2.subType == 1)                    {                        Debug.Log("refine it");                        if (data.AddInstability(Mathf.RoundToInt((float)(2 + num2) * num4), num3, 0))                        {                            data.ReRollAffixRolls();                        }                        flag = true;                    }                    else if (data2.subType == 2 && data.affixes.Count > 0)                    {                        Debug.Log("remove it");                        if (data.AddInstability(Mathf.RoundToInt((float)(2 + num2) * num4), num3, 0))                        {                            ItemAffix affixToRemove = data.affixes[UnityEngine.Random.Range(0, data.affixes.Count)];                            data.RemoveAffix(affixToRemove);                        }                        flag = true;                    }                    else if (data2.subType == 3 && data.affixes.Count > 0)                    {                        Debug.Log("cleanse it");                        List<ItemAffix> list = new List<ItemAffix>();                        foreach (ItemAffix item in data.affixes)                        {                            list.Add(item);                        }                        foreach (ItemAffix affixToRemove2 in list)                        {                            data.RemoveAffix(affixToRemove2);                        }                        if (num5 == 0)                        {                            flag2 = false;                        }                        data.SetInstability((int)((Mathf.Clamp(UnityEngine.Random.Range(5f, 15f), 0f, (float)data.instability) + (float)num2) * num4));                        flag = true;                    }                    else if (data2.subType == 4 && data.sockets == 0)                    {                        Debug.Log("socket it");                        data.AddSocket(1);                        data.SetInstability((int)((Mathf.Clamp(UnityEngine.Random.Range(5f, 15f), 0f, (float)data.instability) + (float)num2) * num4));                        flag = true;                    }                }            }            if (flag)            {                UISounds.playSound(UISounds.UISoundLabel.CraftingSuccess);                if (this.modifier.HasContent())                {                    ItemData data3 = this.modifier.GetContent()[0].data;                    this.modifier.Clear();                    if (num >= 0 && GlobalDataTracker.instance.CheckForShard(num))                    {                        this.PopShardToModifierSlot(num);                    }                    else if (data3.itemType == 102)                    {                        foreach (SingleSubTypeContainer singleSubTypeContainer in ItemContainersManager.instance.materials.Containers)                        {                            if (singleSubTypeContainer.CanAddItemType((int)data3.itemType) && singleSubTypeContainer.allowedSubID == (int)data3.subType && singleSubTypeContainer.HasContent())                            {                                singleSubTypeContainer.MoveItemTo(singleSubTypeContainer.GetContent()[0], 1, this.modifier, new IntVector2?(IntVector2.Zero), Context.SILENT);                                break;                            }                        }                    }                    if (num >= 0 && this.prefixTierVFXObjects.Length != 0 && this.suffixTierVFXObjects.Length != 0)                    {                        ItemData itemData2 = null;                        if (this.main.HasContent())                        {                            itemData2 = this.main.GetContent()[0].data;                        }                        if (itemData2 != null && this.main.HasContent())                        {                            List<ItemAffix> list2 = new List<ItemAffix>();                            List<ItemAffix> list3 = new List<ItemAffix>();                            foreach (ItemAffix itemAffix in itemData2.affixes)                            {                                if (itemAffix.affixType == AffixList.AffixType.PREFIX)                                {                                    list2.Add(itemAffix);                                }                                else                                {                                    list3.Add(itemAffix);                                }                            }                            for (int i = 0; i < list2.Count; i++)                            {                                if ((int)list2[i].affixId == num && this.prefixTierVFXObjects[i])                                {                                    this.prefixTierVFXObjects[i].SetActive(true);                                }                            }                            for (int j = 0; j < list3.Count; j++)                            {                                if ((int)list3[j].affixId == num && this.suffixTierVFXObjects[j])                                {                                    this.suffixTierVFXObjects[j].SetActive(true);                                }                            }                        }                    }                }                if (!flag2)                {                    goto IL_6B3;                }                this.support.Clear();                using (List<SingleSubTypeContainer>.Enumerator enumerator2 = ItemContainersManager.instance.materials.Containers.GetEnumerator())                {                    while (enumerator2.MoveNext())                    {                        SingleSubTypeContainer singleSubTypeContainer2 = enumerator2.Current;                        if (singleSubTypeContainer2.CanAddItemType((int)itemData.itemType) && singleSubTypeContainer2.allowedSubID == (int)itemData.subType && singleSubTypeContainer2.HasContent())                        {                            singleSubTypeContainer2.MoveItemTo(singleSubTypeContainer2.GetContent()[0], 1, this.support, new IntVector2?(IntVector2.Zero), Context.SILENT);                            break;                        }                    }                    goto IL_6B3;                }            }            this.modifier.Clear();            this.support.Clear();        }        IL_6B3:        if (!flag)        {            UISounds.playSound(UISounds.UISoundLabel.CraftingFailure);        }        this.slamVFX.SetActive(true);        this.UpdateItemInfo();        this.UpdateFractureChanceDisplay();        this.UpdateForgeButton();        ShardCountText.UpdateAll();    }}

С моей точки зрения данный код выглядит не так уж и плохо. Даже и не скажешь сразу, что это декомпелированная версия (выдают только названия переменных в духе num1, num2...). Есть даже логирование, которое позволяет легче понять назначение веток

После изучения кода я выяснил примерный механизм работы у нас есть несколько CraftingSlot'ов, в которые мы помещаем предмет крафта и модификаторы. CraftingSlotManager соответсвенно управляет взаимодействием этих слотов и в целом отвечает за логику крафта

Отключаем расходование ресурсов при крафте

Нас интересуют две переменные: this.modifier и this.support
Это слоты для модификаторов, которые используются во время крафта

Как оказалось уничтожение модификаторов происходит в процессе следующих вызовов:

this.modifier.Clear();this.support.Clear();

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

Удаляем все вызовы this.modifier.Clear(); и this.support.Clear(); из кода функции и радуемся

Процесс редактирования в dnSpy просто фантастика просто поправили код и сохранили в .dll все изменения будут скомпилированы автоматически

Убираем поломку предмета в процессе крафта

В игре поломка предмета в процессе крафта называется Fracture, поэтому мне сразу бросился в глаза данный кусок кода

И действительно модификация вида int num3 = -10; полностью отключает поломку спасибо разработчикам за оставленный дебаг флаг :)

Часть вторая, где мы испытываем боль и страдания

Начиная с версии 0.7.9 разработчики начали использовать IL2CPP для того, чтобы собирать проект напрямую в нативный бинарник под нужную платформу. В результате у нас больше нет IL-кода, а есть лишь хардкорный ассемблер но кого это останавливало?

Ищем иголку в стоге Гидры

Итак, из папки игры пропали все старые .dll-ки и мы взамен получили один огромный GameAssembly.dll весом в 55 мегабайт. Наши цели не изменились, но теперь все будет намного сложнее.

Первым делом загружаем dll-ку в Ghidra'у и соглашаемся на все виды анализа, которые она предлагает (анализ занимает довольно много времени и в дальнейшем я останавливал его на стадии Analyze Address Table)

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

К счастью погуглив на тему IL2CPP я нашел утилиту Il2CppDumper, которая позволяет частично восстановить информацию на основе метадата-файла (который обнаружился по пути <GameFolder>/il2cpp_data/Metadata/global-metadata.dat). Не знаю является ли данный файл необходимостью или разработчики просто забыли убрать его, но он сильно облегчил нашу задачу

Скармливаем утилите наши файлы dll и метадаты и получаем набор восстановленных данных

В папке DummyDll находятся восстановленные dll-ки с частично восстановленным IL-кодом. Загружаем восстановленный Assembly-CSharp.dll в dnSpy и идем в наш любимый CraftingSlotManager

Ну что же, кода у нас больше нет, зато у нас есть адрес! В аннотации

Address(RVA = "0x5B9FC0", Offset = "0x5B89C0", VA = "0x1805B9FC0")

Нам нужно значение VA это оффест, по которому мы найдем нашу функцию в Гидре

Теперь мы хотя бы нашли начало нашей функции, что уже неплохо

Можно ли сделать лучше? Вспоминаем, что Il2CppDumper генерирует данные, котрые можно импортировать в Гидру копируем скрипт в папку скриптов Гидры, запускаем ghidra.py и скармливаем ему script.json, сгенерированный из нашей метадаты. Теперь у всех функций, которые были объявлены в исходном коде, появились имена

Отключаем расходование ресурсов при крафте

Мы уже знаем, что нам достаточно убрать вызовы this.modifier.Clear(); и this.support.Clear();. Осталось найти их в коде. К счастью восстановленные имена функций помогают решить эту задачу довольно просто

Ломать не строить. Чтобы убрать вызов функции нам достаточно заменить все байты, участвующие в CALL на NOP

Разбиваем команду на отдельные байты (выделив ее и нажав C, или Clear Code Bytes), затем в бинарном представлении просто впечатываем 90 пять раз. Готово!

Такую операцию повторяем для всех вызвов OneSlotItemContainer$$Clear() из нашей функции Forge() (На самом деле это нужно делать не для всех вызовов, потому что в коде есть один вызов this.main.Clear(); Но мне было слишком лениво выискивать конкретное исключение в ассемблерной каше, поэтому я убрал все вызовы)

Убираем поломку предмета в процессе крафта

Изначально мы делали int num3 = -10; и благодарили разработчика за оставленный дебаг флаг в качестве подсказки. Теперь это не кажется такой простой задачей сложно понять, какая из ~60 локальных переменных, найденных Гидрой, является нужной. После 15 минут поиска мне наконец удалось понять, что зубодробительная строчка на скриншоте ниже является той самой проверкой дебаг флага и вычитанием из переменной

К сожалению моих знаний Ассемблера не хватило, чтобы понять как именно это работает (судя по Гидре этот процесс занимает 4 команды начиная с MOVZX и заканчивая на AND), поэтому деликатно изменить эту часть я не смог. Другого способа изменить эту переменную я тоже не нашел в силу своих ограниченных знаний, поэтому я изменил подход

Посмотрев еще раз в замечательный (после работы с Гидрой) код старой версии игры в dnSpy я увидел, что за накопление "нестабильности" отвечает метод AddInstability

public bool AddInstability(int addedInstability, int fractureTierModifier = 0, int affixTier = 0)    {        int num = this.RollFractureTier(fractureTierModifier, affixTier);        if (num > 0)        {            this.Fracture(num); // <----- Предмет ломается тут            return false;        }        this.instability = ((int)this.instability + addedInstability).clampToByte();        this.RebuildID();        return true;    }

Гидра радует нас относитлеьно простым кодом данной функции

По коду мы видим, что сначала происходит вызов CALL ItemData$$RollFractureTier, затем мы проверяем результат TEST EAX и прыгаем в нужную ветку

Нам нужно, чтобы мы всегда шли по ветке uVar3 < 1. Тут можно сделать разные исправления например (могу ошибаться) поменять JG(Jump short if greater) на JLE(Jump short if less or equal)

Я решил вопрос иначе просто сделаем проверяемый регистр равным нулю и тогда остальной код будет работать как надо. Меняем CALL на XOR EAX, EAX (самый просто способ обнулить регистр в Ассемблере), который занимает два байта и оставшиеся три байта заполняем NOP'ами

Готово! Сохраняем, заменяем существующий GameAssembly.dll (почему-то Гидра в процессе экспорта файла всегда добавляет расширение .bin и его нужно удалять) и чувствуем себя хакерами

Выводы

Для многих компиляция является "путем в один конец", а бинарные файлы представляются неуязвимыми бастионами, которые способны пасть только перед лучшими хакерами

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

И, хотя нативные бинарники и могут представлять опасность для ваших глаз и мозга, повехрностных знаний о том, как работают программы на уровне, близком к железу, зачастую бывает достаточно в связке с современными open-source инструментами для небольших модификаций

Аренда WhatsApp API у неофициального провайдера

Реализация собственного WhatsApp API через веб-обертку

Взлом WhatsApp на уровне сокет-соединения

Жёлтая карточка

Бонусы

Рождение Сверхзелёной

Что дальше?