Научете как да използвате крак, да правите обратен инженеринг и да анализирате злонамерен софтуер с помощта на динамични двоични инструменти и корекции с 64-битови API извиквания и двоични файлове на Windows.
Добре дошли в моето ръководство за динамична двоична апаратура (DBI). В тази статия ще научим еволюцията на общите методи за двоичен анализ и как да изпълняваме някои често срещани процедури, използвани от изследователите по сигурността. DBI сам по себе си е мощен начин за придобиване на видимост, промяна на поведението и размиване на двоични файлове със затворен код, без да се налага повторно компилиране или стартиране на самия оригинален код. Всъщност има случаи на употреба, при които инженерите са „оптимизирали“ производителността на кода чрез използване на инструментариум. Ако някога сте чували за "hot patching" или "function hooking"; точно това прави DBI.
След като прочетете тази статия, трябва да можете да:
- Разберете общите методологии за двоичен анализ и техните разлики
- Как работи динамичното двоично оборудване (DBI).
- Да може да изследва свойствата на статичните файлове
- Използвайте дебъгери за „кракване“ или корекция на преносим изпълним файл („PE“)
- Използвайте DBI рамки за модифициране на поведението на приложение с помощта на инжектирани кукички
Методи за анализ
Когато анализирате зловреден софтуер или двоични файлове като цяло; трябва да имате предвид, че това е итеративен процес и че няма „шаблон“, който да пасва на всяка проба или приложение, което ще анализирате. Въпреки това, като обща насока, много анализатори и инженери започват с методи, които включват най-малко сложно взаимодействие и продължават напред. Понякога те трябва да се върнат назад, за да препратят към нова информация, за да получат сцепление в своя анализ. Като цяло тези техники са:
- Разглеждане на статични свойства на файла
- Анализ на статичен код
- Динамичен анализ
- Динамична двоична апаратура (DBI)
- Емулация по време на изпълнение
Имайте предвид, че ако проучвате зловреден софтуер; че пясъчната кутия за детониране може да използва множество техники за анализ, но с ограничени тестови случаи и контрол. Това ще включва наблюдения на поведението на мрежата. Изследователите все още изпълняват тези методи ръчно поради степента на контрол, който имат върху поведението на кода. Едно притеснение е, че не бихме искали проба да избяга от вашата лаборатория в публичния интернет или евентуално да се „обади у дома“, за да уведоми нападателя, че я анализирате.
Статични свойства на файла
Това е една от най-често използваните техники, която включва анализиране на „низове“, метаданни, импортиране на библиотека и друга лесно достъпна информация за файла, като например ентропия. Това осигурява най-малко количество видимост и информация за това какво прави извадката. Това е особено случаят, когато двоичните файлове са „опаковани“, което обикновено включва криптиране. Това все още си струва да проучите, защото трябва да знаете неща като архитектурата на двоичното време за изпълнение, възможно импортиране на некриптирани библиотеки и способността ни да изключваме „динамично базиране“. Нека да продължим и да покажем това в CFF explorer с нашия PE пример:
Както можете да видите от горното, имаме изброени много статични свойства. Имаме също нашите секции за импортиране и ходене на зависимости, до които ще стигнем. За отбелязване е, че знаем, че работим с 64-битов двоичен файл на Windows, защото той е PE, а не ELF. Отидете до „Заглавки на секции“ и можем също да видим, че нищо не е криптирано, което означава, че най-вероятно не сме опаковани. Въпреки това, това варира в имената и какви знаци виждате ще зависи от вашия двоичен файл. Един пример е UPX, който е обикновен легитимен и не толкова легитимен опаковчик и е най-известен с етикетирането на своите секции с „UPX“. Също така не е необходимо да използвате CFF Explorer; за зловреден софтуер можете също да използвате PEStudio. В нашия пример ние не сме опаковани, както можете да видите по-долу, като нашата информация за „магията на файла“ остава непокътната:
Но това, което е по-интересно за нас, когато се подготвяме да изпълняваме DBI, е, че трябва да знаем импортирането на библиотеки. CFF Explorer има инструмент за разходка на зависимости, който не само ще изброява импортиранията, но също така ще ви покаже някои от другите библиотеки или функции, които „могат“ да бъдат извикани. Не забравяйте, че все още не знаем кои точно, защото не сме проверили действителния код или не сме го изпълнили.
Едно важно нещо, което трябва да направим, е да изключим поддръжката за повторно базиране (ASLR) за нашите импортирания, защото бихме искали адресното пространство на паметта на нашата система да бъде едно и също за всяко време на изпълнение. Можем едновременно да използваме статичен, динамичен и DBI анализ в кръстосани препратки. За да направите това, отидете в раздела за заглавка по избор и изберете характеристиките на DLL характеристиките. Премахнете отметката от „Dll може да се движи“:
Анализ на статичен код
След статичните свойства обикновено искаме да преминем към анализ на статичен код. Все още не изпълняваме двоичния код, а проверяваме информацията за разглобяване за функции и общата структура. Въпреки че нямаме време в тази статия да ви научим на основите на асемблирането; „работилниците“ за обратно инженерство 101 и 102, предоставени от името на „@malwareunicorn““ са изключително полезни за новодошлите. Засега просто ще разгледаме бързо зареждането му в Ghidra за по-лесно показване:
При зареждане на нашия примерен 64-битов PE в кодовия браузър виждаме нашите стандартни дисплеи на дървета и разглобяване в основния визуализатор по линеен начин. Превъртайки надолу, можем да видим, че се извиква „LoadStringW“ Windows API, което означава, че потенциално приемаме низови данни от може би въведени от потребителя. Ghidra също така идентифицира подпрограмата за зареждане на низ в рамките на по-голяма функция, която все още не е идентифицирана, както виждаме в изгледа за декомпилиране:
Сега, след като идентифицирахме поне една функция, която превърта надолу прозореца за разглобяване по реда на изпълнение, ние включваме изгледа „функционална графика“ и сега виждаме общата структура на PE. Това е доста прост набор от разклонения, който изглежда изпълнява нещо в условен цикъл или изход. Това е показано долу вдясно с хубави цветно кодирани блокове:
На този етап, тъй като знаем, че нашият двоичен файл е доста прост с няколко условни прехода и извиквания на функции, които могат да приемат въвеждане от потребителя. В анализа на зловреден софтуер и истинското обратно инженерство; това е мястото, където ще започнете да правите вашите бележки за историята на изпълнението и да се опитате да създадете еквивалентен код на „C“ за функции, които не могат да бъдат идентифицирани чрез изследване на асемблирането. Вие също бихте заснели повече низове, където е приложимо.
Анализ на динамичен код
Нека да преминем към динамичен анализ (все още не инструментариум) с помощта на инструмента x64dbg, който е 64-битов съвместим дебъгер за Windows. За Linux ELF файлове можете да използвате GDB и други инструменти за динамичен анализ. Когато мислите за динамичен анализ, помислете за дебъгери. Това е мястото, където всъщност изпълняваме оригиналния код на примера; трябва да се внимава за изследователите на зловреден софтуер.
Нека да продължим и да заредим нашия пример в x64dbg с правилния екземпляр на архитектура. Натиснете менюто „Опции“ и се уверете, че вашите настройки „Събития“ включват основните точки на прекъсване, включително „Входна точка на прекъсване“, което е съкратено като EOP“ в много приложения. Ако също така забелязвате, ние сме 64-битови, защото виждаме CPU регистъра „RIP“ за разлика от „EIP“ в основната секция за разглобяване. Намираме се в „системна“ точка на прекъсване, спряна точно в зареждащото устройство на Windows NT преди време на изпълнение:
Нека да стартираме нашето приложение и да видим за какво става дума от нашия предишен статичен анализ като улики:
Това има смисъл от нашия предишен анализ, че виждаме поле за въвеждане на потребител от извиканите рутинни функции и че имаме бутон „проверка“, който би бил нашето условие, последвано от нашия бутон за изход, който също видяхме в блоковата диаграма на кода от Ghidra. Преди няколко години намерих този двоичен файл някъде в едно предизвикателство за пример „crackme“, но забравих откъде го взех. *Ако вие сте авторът, моля, свържете се с мен, за да мога правилно да реферирам работата ви.
По-долу можем да видим, че отгатването на паролата няма да ни отведе до никъде, след като достигнем входната точка (EOP), където се изгражда нашата стекова рамка:
Трябва да има по-умен начин да се справим с това. Тъй като знаем, че нещата не са криптирани; нека направим търсене на препратки към низове във всички наши модули, за да видим какво намираме. Щракнете с десния бутон навсякъде във вашия дизасемблер и след това направете „Търсене“, „Всички модули“, „Препратки към низове“ и го оставете да работи. След като приключите, нека въведете филтъра за „парола“ в долната част на прозореца:
Това съобщение „Валидна парола“ изглежда като добро място за начало. Кликнете два пъти върху низа и ще преминете към тази област от паметта. Виждаме условните скокове „jne“, което означава, че скокът не е равен и това, което изглежда като зареден MD5 хеш като наша парола. Има много начини да решим проблема си; но нека поемем по мързеливия начин. Виждаме кратки скокове и обаждания между адреси. Нека просто да ги пренебрегнем, така че автоматично да игнорираме условието и да достигнем желаната крайна точка, която е съобщение за „валидна парола“:
Кликнете два пъти върху инструкцията JNE, за да получите редактора на асемблиране:
Изтрийте всичко и просто поставете думата „NOP““, така че просто да оставим процесора да премине през инструкцията и да не правим нищо:
След като натиснете OK, трябва да видите стандартните шестнадесетични операционни кодове 0x90 за NOP код за разглобяване:
Нека коригираме тази промяна в двоичния файл, като отидем на „Файл“ и „Файл за корекция“:
Ще се появи нов прозорец с молба да потвърдите съответните промени в стойността на адреса. Продължете и завършете корекцията и не забравяйте да запазите файла:
Сега можете да стартирате примерния PE с всякаква парола и това няма да има значение. Никога не трябваше да обръщаме нашия MD5 хеш:
Бърза бележка за двоичните файлове на .NET: тъй като .NET framework сама по себе си е абстрахиран междинен език; всички неопаковани или криптирани двоични файлове, които намерите, могат да бъдат изследвани чрез декомпилатор като „събития“. Един такъв инструмент е Dotpeek и можете да извършите същия тип корекция, без да се налага да използвате пълен дебъгер. Други инструменти включват IL Decompiler. Няма да преминавам през пълното използване на Visual Studio IL Decompiler и .NET patching, но ще ви покажа някои екранни снимки, тъй като предпоставката е същата.
Ако искате да го изпробвате сами, не се колебайте да изтеглите двоичните файлове от моето repo. Забележка: Работех за екипа на RSA Advanced Cyber Defense и затова направих тези двоични файлове в свободното си време, за да помогна на клиенти и приятели да обучават двоични корекции на Windows. Те също са лицензирани под GPL-2.0. Ще видите съществуващите ми метаданни на следващите екранни снимки. Примерният фрагмент от изходния код е показан по-долу:
Можете да го разгледате в DotPeek или помощна програма IL DASM:
В IL DASM, за съжаление, не можете да правите директни редакции; така че ще трябва да използвате CFF Explorer и да проверите кръстосано относителния виртуален адрес (RVA) на функцията за събитие и да направите промените в шестнадесетичен редактор в подходящия малък формат, за да анулирате изискването за парола:
Ако успеете, не трябва да използвате паролата „rsatraining“, но вместо това всичко ще свърши работа:
Емулация по време на изпълнение
Ще разгледам накратко емулацията; въпреки това си струва да се спомене, че пълната емулация по време на изпълнение е допълнителен слой, който постига повече „прозрачност“, отколкото DBI, защото се подигравате с действителна операционна система, включително поведение на паметта, често срещани зареждания на драйвери и библиотеки и типа на файловата структура. Мислете за емулацията като за DBI, само че „подсилена“. Това е най-полезно за двоични файлове, базирани на антикриминалистика, като злонамерен софтуер. Един такъв инструмент с лесна употреба е „Binee“ на Carbon Black. За съжаление, той обработва само 32-битови библиотеки на Windows без поддръжка за 64-битови импортирания.
Демонстрации и обяснения за него бяха представени на Def Con 27. Аз съм мързелив анализатор и затова реших да го изпробвам в Remux v7. Поради изискванията за използване на 32-битови двоични файлове на Windows; няма да навлизаме твърде много в Binee. Много съвременни операционни системи са 64-битови, включително по-късните издания на Windows 10. (Да, знам, че „Windows 10 32 бита“ беше пуснат веднъж, но вече не се поддържа или актуализира.)
Емулацията се счита за подобрение в сравнение с обикновените инструменти, защото има способността да имитира естествена среда на двоичното изображение, без да се налага да изпълнява оригиналния код с инжекции. Архитектура на високо ниво за това как се случва това е показана по-долу от тази презентация:
За да видите Binee в най-основното му действие, просто го стартирайте с обикновен превключвател, за да ви покаже импортиранията с техните аргументи и адреса:
Това не използва напълно реалното емулиране на каквото и да било; все пак показва някои страхотни функции, извикани в техния относителен импорт. Когато стартирате Binee в режим на симулация; дори с 2 GB DLL от 32-битова виртуална машина с Windows 10, все още виждаме, че ни липсват някои импортирания или API, които се извикват в горната част на изображението. Независимо от това, функциите бяха проследени дори с проба с активиран антидебъгер:
Въпреки че това е чудесно за общо отстраняване на грешки и по-автоматизиран подход към анализа на зловреден софтуер; това не директнони ни помага при „кракване“ или модифициране на поведение на двоично изпълнение. Това е мястото, където инструментите се връщат.
Динамична двоична апаратура
DBI предоставя на инженерите и изследователите инструменти за взаимодействие с приложения без изходен код и най-честият случай на употреба е за „закачане“ на функции, модифициране на памет или регистри на процесора и други аспекти на времето за изпълнение на двоичния файл. Има и размити случаи, които трябва да се проучат, къде входовете могат да преминават между подпрограми при проследяване и тестване за „замърсяване“. Има много рамки за DBI и ето някои общи за тези, които тепърва започват:
Как работи DBI? Нека да разгледаме илюстрациите, предоставени от „@mxmssh” от неговата „презентация” за Fuzzing с помощта на DBI. Въпреки че е представен DynamoRIO, по същество всички DBI рамки работят по един и същи начин в следните стъпки:
- Рамката ще стартира и спре оригиналното двоично изображение и ще се закачи за входните точки
- След това се създава копие от кеша на кода на оригиналния код (ако рамката е стартирана в режим точно навреме (JIT), за разлика от стандартния „скачане на „трамплини““, специфичен само за функции)
- Кешът на кода също се инжектира и закача за различни функции въз основа на изискванията за време на изпълнение на инструмента за щифтове, така че инструментите винаги да контролират изпълнението
- След това се изпълнява кеш с контролиран код, осигуряващ на инженера видимостта и желаните рутинни процедури на двоичното време за изпълнение въз основа на компилиран специфичен инструментариум
Ако сте объркани, помислете за инструментите като хирург, който оперира пациент. Хирургът използва инструменти за извършване на специфични действия в рамките на рутинна операция, докато пациентът се поддържа в живо или работещо състояние; модифициране на неговото или нейното съществуващо „време за изпълнение“.
За нашата практика; Ще се съсредоточа върху Frida в тази статия поради нейната лекота на използване и API за абстракция. Струва си обаче да се отбележи, че когато чуете диалог относно използването на „инструменти за щифтове“, знайте, че инженерите наричат това като цяло всеки инструмент за измерване. Intel Pin излезе на широката публика през 2004 г. и стана популярен поради своята преносимост и „относителна“ лекота на използване.
Моят опит е различен както в DynamoRIO, така и в Intel Pin с ограничен успех при компилирането и изпълнението на помощните програми в Windows 10 x64 битови и виртуализирани среди на Kali 2020.2 x64. Най-новите инструменти за щифтове са склонни да се сриват (за мен на напълно закърпена система с изключен защитник) при различни повреди, илюстрирани накратко по-долу, дори когато се изпълняват 32-битови и 64-битови компилирани инструменти и двоични файлове, както е показано по-долу:
След много часове тестване на проби и грешки; Открих, че Фрида е по-плодотворна в моите експерименти. Въпреки това дори скриптовете „Frida-discover“ не работят за моята инсталация. Това е добре, ще заобиколим това малко, като използваме друг скрипт и набор от параметри. Просто исках да подчертая, че никой инструмент не е перфектен за всяка възможна среда. Като всяко въвеждане на нови приложения във вашата среда; трябва да тествате в непроизводствен режим. Ето пример за неправилно проследяване на функции на Frida-Discover, които се извикват в рамките на 64-битов Notepad:
И същият проблем в общия 64-битов двоичен файл, който коригирахме с NOP по-рано в статията:
Ще предоставя примерни кодове и синтаксис, от които можете да копирате и поставяте. Имайте предвид, че за да инсталирате Frida, на Windows 10 x64; моля, използвайте най-новото издание на 3.8.x или по-високо 64-битов Python, така че да се инсталира с „pip“. Един прост „pip install Frida-tools“ ще улови тяхната основна система и техните компилирани от Windows двоични инструменти в папката по подразбиране на вашата инсталация на Python под „скриптове“. Надяваме се, че няма да се притеснявате за това, ако сте добавили Python към променливата на пътя на вашата среда.
Сега да се върнем към опитите ни да извлечем извиквания на функции за различни двоични файлове. Е, виждаме, че Frida-discover не намери нищо. Можем да използваме Frida-trace, но всеки пример ни показва, че трябва вече да знаем „донякъде“ какво търсим от дадена функция. Едно нещо, за да заобиколите това, но ще бъде изключително шумно, е да направите заместващ знак за всяка функция за проследяване, извикана от импортирането. За съжаление всичко това записва много шаблонни javascript (JS) файлове в изпълняваната директория, за да ги сортирате по-късно, както е показано по-долу:
Трябва да има по-добър начин. За жалост; това е, когато трябва да изтеглите помощна програма за наблюдение или прихващане на API, което означава, че трябва да изпълнявате код без контрол на инструментите. Не мисля и за ProcMon на Systinternal, защото той не ви показва всички стойности на повикванията, нито разрешава всички документирани популярни Windows API; въпреки че можете да извършите основно проследяване на стека с него; подобно на „strace“ и „ltrace“ в Linux. Ще ни трябва нещо по-тежко и това е API Monitor v2.0 alpha.
Голяма част от работата по разрешаването е извършена и изисква много предположения за функциите за проследяване, които искаме да инжектираме и закачим. В сценарий за анализ на зловреден софтуер; това е нещо, което бихте искали да направите в краен случай, тъй като изпълнявате двоичния файл неконтролирано чрез добре познат API снифър. Не планираме да използваме зловреден софтуер в нашите предстоящи упражнения, така че това трябва да е наред. Нека помислим за сценарий, при който можем да използваме инструментите за добро.
Реален случай на използване на инструментариум
Преди няколко години, за клиент, имах разработчик, който обвини скорошно внедряване на защитна стена и IPS, когато приложение спря да работи мистериозно с мрежова свързаност. Прихващане на пакети (PCAP) опроверга твърдението й, че нещо в мрежата кара крайната й точка да не работи. Оказа се, че нейната „ODBC“ връзка не се установява и тя потвърди, че нейната твърдо кодирана комбинация от IP и порт е там завинаги, въпреки че PCAP показва друго.
Тя нямаше нито един от оригиналния си изходен код и всичко вече беше 32-битово компилирано в дните на стария Windows XP/2000. DBI можеше да помогне в този сценарий (ако знаех за него по това време), където щяхме да инжектираме нейния двоичен файл на Windows, осъществявайки извикванията за връзка и променяйки поведението му в реално време, за да инжектира правилно правилната твърдо кодирана двойка IP портове. Наистина подозирам, че приложението е спряло да работи поради неналожен IP конфликт от предишната настройка на комутатора и рутера. Но въпреки това Фрида щеше да е полезна. Нека да видим как бихме го използвали за еквивалентна мрежова програма като Windows „ping.exe“ в лабораторен еквивалент.
Нашият лабораторен сценарий е, че искаме да гарантираме, че имаме достъп до основния сървър на Cloudflare Public DNS, който е 1.1.1.1. Въпреки това наскоро превключихме желаното от нас DNS наблюдение на Google public DNS, което е 8.8.8.8 и вече нямаме достъп до скриптовете, нашият изходен код, който е твърдо кодиран, извиквайки ‹ping.exe 1.1.1.1› от наше име. „Можем“ да настроим HOST файлове или да извършим някакво вътрешно DNS пренасочване с фалшиви статични PTR и A записи, но това очевидно е супер лоша практика. Не, не — ще използваме динамични инструменти за спасяване с Фрида.
Първо, трябва да преодолеем липсата на видимост на API повикванията, като анализираме не само импортиранията за Ping.exe, но и действителните специфични за Windows API извиквания, за да определим как планираме да променим адреса от 1.1.1.1 на 8.8.8.8 и просто за забавление , улавя полезния товар на ICMP ехо заявката, който Windows 10 x64 bit ще изпраща, без да се налага да стартирате PCAP. Стартирайте API Monitor v2 и най-вляво изберете категориите „Networking“, „Scripting Runtime Library“ и „Windows Application UI Development“ под приспособлението за филтриране за „Всички модули“, както е показано по-долу:
След това близо до средата на „Наблюдавани процеси“ добавете нов процес и задайте следното изображение на процеса да бъде: „c:\windows\system32\ping.exe“ и неговия подходящ аргумент от 1.1.1.1, както е показано по-долу:
След като натиснете OK, това ще изпълни двоичния файл. За нас ping.exe по подразбиране излиза след 3 опита за ехо заявки до местоназначението си, спестявайки ни неудобството да поставяме на пауза или спираме нашето подслушване по време на изпълнение. Вашият прозорец трябва да се запълни с много спретнати артефакти. Един по-специално, който изглежда като нещо интересно „icmpSendEcho2Ex“ и го виждаме да работи 3 различни пъти, което съвпада с нашето очаквано поведение по подразбиране.
Забележете, че не се разрешава до известен модул за импортиране в API Monitor. Не, не идва от ping.exe в статичен свързан DLL, както ще видим по-късно. Това е API Monitor, който не успява да го разреши в колоната „Модул“. По-късно ще видим, че правилният DLL наистина е посочен в раздела Параметри по някаква странна причина.
В нашата Windows MSDN документация виждаме следната C++ конструкция на целевия адрес като част от аргументите:
IPHLPAPI_DLL_LINKAGE DWORD IcmpSendEcho2Ex( HANDLE IcmpHandle, HANDLE Event, PIO_APC_ROUTINE ApcRoutine, PVOID ApcContext, IPAddr SourceAddress, IPAddr DestinationAddress, LPVOID RequestData, WORD RequestSize, PIP_OPTION_INFORMATION RequestOptions, LPVOID ReplyBuffer, DWORD ReplySize, DWORD Timeout );
Четейки по-надолу в страницата под раздела за забележки, виждаме, че в Windows Server 2008 или по-нова тази функция се извиква и препраща към заглавния файл ICMPAPI.H и свързания с него DLL, който е „Iphlpapi.dll“, който също е кръстосано препратен в не -NT наследена функция IcmpSendEcho.
Полезен съвет: Всеки път, когато видите „EX“ в края на API функция на Microsoft; това означава „разширено“ и което означава, че новата функция заменя по-старото издание „EX“, но е несъвместимо с оригиналното издание „EX“. Интересно е, че в съвременния Windows 10 с всички най-нови актуализации 64-битовата версия на ping.exe ще използва разширената наследена функция.
Тъй като искаме да променим IP адреса на дестинацията на нашия аргумент; ще изследваме аргумента „DestinationAddress“ с „type“ като „IN_ADDR“ структурен формат, който също се използва и вижда в C библиотеки за Linux. Това се описва IPv4 стойности като два неподписани къси или единичен неподписан дълъг формат. Това съвпада с разделителната способност на API монитора на нашата функция, ако погледнете вашата област с параметри, виждаме аргумент 6 (5, когато го препращаме, защото започваме с масива от 0):
Забележете, че DestinationAddress в стойността преди извикване, която е попълнен буфер от нашия аргумент, е „1.1.1.1“ в шестнадесетичен и изобщо не е мутирана в стойността след извикване. И за пълнота, нека проверим нашия шестнадесетичен буфер и ще видим нашия полезен товар от азбуката, която е стандартна за Windows ping заявки:
Трябва да разполагаме с цялата информация, от която се нуждаем, за да „застрашим“ правилно нашия двоичен файл, без да модифицираме самия оригинален код, променяйки нашия дестинационен хост на 8.8.8.8, проверете нашия полезен товар, който видяхме на горната фигура; и за забавление - ние също така ще създадем инструментариум за инжектиране на функция след действие за създаване на файл в директория.
Нека започнем със скелетен скрипт за Frida, като закачим точната функция и импортираме, от което се нуждаем, като създадем променлива и след това използваме API на Frida's Interceptor, за да се прикрепим към тази функция, когато повикващият инициира заявката за API, ние ще изпратим съобщение към конзолата, показваща успешната JIT кука:
//create object pointer to function to reference in the interceptor
var IcmpSendEcho2Ex = Module.findExportByName('Iphlpapi.dll', 'IcmpSendEcho2Ex')
//hook into the pointer of our target function
Interceptor.attach(IcmpSendEcho2Ex, {
onEnter: function (args) {
send("[+] IcmpSendEcho2Ex API hooked!");
В същата подпрограма с отстъп „onEnter“ ще изпратим и копие на нашия ICMP ехо полезен товар на екрана за аргумент „6“; не забравяйте, че е с един по-малко от нашия човешки брой, защото компютърните масиви започват от 0. Ние също така ще зададем целевия IP аргумент на стойност на „указател“ от 8.8.8.8. Обърнете внимание, че използването на указател като част от аргумента е част от „документацията“ на Frida и е специфично за „дерефериране след преобразуване“ към очакваната стойност на структурния тип IN_ADDR. Също така изпращаме потвърждение на екрана на нашата конзола.
//snoop on the payload
//this.RequestData = args[6];
send("Payload: " + args[6].readAnsiString());
//change ip address from 1.1.1.1 to google.com
args[5] = ptr("0x08080808");
send("New address: " + args[5]);
},
Това е незадължителна рутина; но можем също така да инжектираме кука след функцията, когато функцията се върне с помощта на „onLeave“. Тук за забавление създаваме примерно заключване на състоянието на файла на диска, за разлика от mutex или флаг за семафор, защото сме „мързеливи“ анализатори на инструментите:
onLeave: function (args) {
//you dont need anything here unless you want post function routines
//create a file on the file system for fun
var file = new File("c:\\SFTP_Root\\foobar.txt", "w");
file.write("My name is Dennis and I'm learning instrumentation...");
file.close();
}
});
Събирайки всичко заедно, можете да копирате и поставите този скрипт в нещо като ‹ping_tamperhook.js›
//example Friday hook script by Dennis Chow dchow[AT]xtecsystems.com
//GPLv2.0 31-Jul-2020
//create object pointer to function to reference in the interceptor
var IcmpSendEcho2Ex = Module.findExportByName('Iphlpapi.dll', 'IcmpSendEcho2Ex')
//hook into the pointer of our target function
Interceptor.attach(IcmpSendEcho2Ex, {
onEnter: function (args) {
send("[+] IcmpSendEcho2Ex API hooked!");
//snoop on the payload
//this.RequestData = args[6];
send("Payload: " + args[6].readAnsiString());
//change ip address from 1.1.1.1 to google.com
args[5] = ptr("0x08080808");
send("New address: " + args[5]);
},
onLeave: function (args) {
//you dont need anything here unless you want post function routines
//create a file on the file system for fun
var file = new File("c:\\SFTP_Root\\foobar.txt", "w");
file.write("My name is Dennis and I'm learning instrumentation...");
file.close();
}
});
Готови ли сте за гореща корекция ping.exe? Нека да видим как работи това. Преди да стартираме Frida core, не забравяйте да създадете файл с „1.1.1.1“ в него като аргумент за ping.exe. Frida не поддържа вградени аргументи към момента на писане. Нашият окончателен синтаксис ще бъде „Frida -l tamperhook.js -f „c:\windows\system32\ping.exe“ -O „pingoptions.txt“.
Това, което прави, е да създаде Frida в режим на прихващане с JIT корекция, след като напишем командата „%resume“, за да следваме ping.exe до основната му функция, върху която сме установили контрол на кеша на кода. Можем да видим в прозореца на конзолата, че сме закачили нашия полезен товар и успешно сменихме „1.1.1.1“ с „8.8.8.8“ и можем да надушим нашия полезен товар по-долу.
Всъщност можете също да видите стандартния изход на ping при всеки опит, показващ отговора от „8.8.8.8“ и близо до края за статистика, ping.exe все още препраща към оригиналния буферен низ „1.1.1.1“. И разбира се, трябва да видим и нашия симулиран файл за състояние на заключване „foobar.txt“.
Затваряне
Надявам се, че сте се насладили на нашето кратко въведение в инструментариума и двоичното корекции. Има толкова много полезни приложения за използването на тези методи, освен заобикаляне на кука и „къс скок“. Насърчавам ви да продължите да изследвате рамката Frida за инструменти, тъй като абстракциите на API са много мощни. Всъщност можете дори да напишете „пин инструменти“ точно като програма за отстраняване на грешки, като замените или промените стойностите в стека, купчината и регистрите на процесора. Както винаги, ако имате нужда от услуги за киберсигурност, не се колебайте да ми пишете на www.scissecurity.com
Денис Чоу, CISO на SCIS Security
