• Автори:

  Баринов С.С., Шевченко О.Г.

• Година:
• Извор:

  Информатика и компјутерски технологии / Материјали на VI меѓународна научна и техничка конференција на студенти, постдипломци и млади научници - 23-25 ​​ноември 2010 година, Донецк, DonNTU. - 2010. - 448 стр.

прибелешка

Дадена е компаративна анализа на корисничкиот режим за дебагирање и режимот на јадрото во однос на оперативниот систем Мајкрософт Виндоус, истакнати се разликите и проблемите во организирањето на дебагирањето на вториот. Врз основа на добиените резултати, формулирани се главните барања за изградба на дебагери во режим на јадро во случај на итност и интерактивно дебагирање. Извршена е анализа на постоечките решенија за усогласеност со барањата. Посебно внимание се посветува на Microsoft Windows Debugger.

Главен дел

Дебагирање е процес на идентификување и елиминирање на причините за грешки во софтверот. Во некои проекти, дебагирањето трае до 50% од вкупното време за развој. Отстранувањето грешки може значително да се поедностави со користење на специјализирани алатки кои постојано се подобруваат. Главната таква алатка е дебагерот, кој ви овозможува да го контролирате извршувањето на софтверот, да го следите неговиот напредок и да се мешате со него. Алатките за дебагирање на јадрото првенствено се користат од развивачите на драјвери.

Пакетот алатки за развој на апликативен софтвер му нуди на програмерот широк опсег на можности. Секое интегрирано развојно опкружување исто така вклучува и можност за дебагирање без потреба од комунални услуги од трети страни. Ако зборуваме особено за системски софтвер и развој на драјвери, тогаш поради неговата специфичност, процесот на развој е исклучително тежок и малку автоматизиран. Сите фази на развој, вклучително и дебагирање, се одвоени. Секој од нив бара посебни услови: пишувањето програмски код се врши на полноправен компјутерски систем, дебагирање - на систем за дебагирање, тестирање - во зависност од околностите итн. Самиот дебагер на режим на јадро е потежок за учење и, соодветно, помалку пријателски.

Во принцип, можеме да зборуваме за недостаток на алатки за дебагирање на јадрото. Додека овие алатки се достапни, алтернативите често не се дискутираат. На пример, Microsoft Windows Debugger има влезен праг кој е премногу висок. Многу програмери зборуваат за првото негативно искуство кога ќе се запознаат со него, а повеќето негови карактеристики остануваат неподигнати.

Врз основа на структурата на виртуелниот адресен простор, ако некоја апликација направи грешка што предизвикува апликацијата да запише податоци на произволна мемориска локација, тогаш апликацијата само ќе ја оштети сопствената меморија и нема да влијае на работата на другите апликации и на оперативниот систем. Со оглед на тоа што кодот на режимот на јадрото може да ги корумпира важните структури на податоци на оперативниот систем, што неизбежно ќе доведе до општ неуспех. Неефикасно напишан драјвер, исто така, може да предизвика сериозна деградација на целиот оперативен систем.

Современите дебагери ја обезбедуваат следната основна функционалност:
• дебагирање на ниво на изворен код;
• управување со извршувањето;
• гледање и менување на меморијата;
• гледање и менување на содржината на регистрите на процесорот;
• приказ на стек за повикување.

За да се олесни работата со расклопен код, т.н. симболи за отстранување грешки. За време на работата на поврзувачот, покрај сликата на извршната датотека, може да се креира и датотека со податоци што содржи информации што не се потребни при извршување на програмата, но се исклучително корисни при дебагирање: имиња на функции, глобални променливи , и описи на структури. Симболите за дебагирање се достапни за сите извршни датотеки на оперативниот систем Windows.

Контролата на извршување се однесува на способноста да се прекине и да се продолжи со извршувањето на програмскиот код по постигнување на дадена инструкција во програмскиот код. Ако програмскиот код се извршува во режим чекор-по-чекор, се јавува прекин за секој токен на програмскиот јазик или при излегување од потпрограма. Со бесплатно извршување, прекинот на извршувањето се јавува во однапред одредени делови од кодот - места каде што се поставени точките на прекин.

Прекинувањето на кодот за режим на јадро ја покренува следната дилема. Дебагерот го користи корисничкиот интерфејс за да комуницира со програмерот. Оние. барем видливиот дел од дебагерот работи во кориснички режим и природно користи интерфејс за програмирање на апликации (Windows API) за да го изгради, кој пак се потпира на модулите на режимот на јадрото. Така, суспендирањето на кодот на режимот на јадрото може да доведе до ќор-сокак: системот нема да реагира на корисникот.

Делови од дебагерот мора да работат и во режим на јадро за да пристапат до меморијата на јадрото. Ова доведува до два проблеми одеднаш, кои се очигледна последица на организацијата на меморијата во заштитениот режим на процесорот.

Првиот проблем се однесува на преводот на адресите на виртуелната меморија. Возачите постојано комуницираат со апликациите во кориснички режим со пристап до нивната меморија. Оперативниот систем Виндоус ги преведува виртуелните адреси во физички адреси врз основа на концептот на контекстот на нишката. Контекст на нишка - структура која ја одразува состојбата на нишката и вклучува, особено, збир на регистри и некои други информации. Кога контролата се префрла на друга нишка, се појавува контекстуален прекинувач кој зачувува информации за една нишка и ги враќа информациите за друга. Префрлањето на контекстот на нишка во нишка од друг процес, исто така, го префрла директориумот на страници што се користи за преведување на виртуелни адреси во физички.

Особеноста е што при испраќање системски повици, оперативниот систем Виндоус не го менува контекстот. Ова му овозможува на кодот на режимот на јадрото да користи виртуелни адреси во кориснички режим.

Ситуацијата е различна кога се прекинува испраќањето или извршувањето на системските нишки. Прекинот може да се случи во секое време, така што не постои начин да се предвиди кој контекст на нишка ќе се користи. Системските нишки, од друга страна, не припаѓаат на ниту еден процес и не можат да преведат виртуелни адреси во кориснички режим. Следи дека во овие ситуации не може да се пристапи до меморијата на кориснички режим.

Вториот проблем е пристап до меморија што може да се премести. Голем дел од информациите во меморијата може да се преместат и може да се преместат од физичка меморија на тврдиот диск во секое време во датотека со страница. Ако се пристапи до страница која не е во физичка меморија, процесорот вообичаено ќе генерира прекин на Page Fault, со кој ќе управува менаџерот на меморијата и како резултат на тоа, страницата ќе се чита од датотеката на страницата и ќе се вчита во физичката меморија.

Ова однесување е скршено ако кодот за отстранување грешки е принуден да користи високи нивоа на барање за прекин (IRQL). Ако IRQL е еднаков или поголем од IRQL на менаџерот за меморија, тој нема да може да ја вчита страницата што недостасува, бидејќи оперативниот систем ќе го блокира прекинот на Page Fault. Ова ќе го урне оперативниот систем.

Дебагирањето обично се дели на интерактивно и итно. Со интерактивно локално отстранување грешки, дебагерот работи на истиот систем како и објектот за отстранување грешки. Во интерактивно далечинско отстранување грешки, дебагерот и објектот за отстранување грешки работат на различни системи. При дебагирање на кодот на јадрото, системот мора да се контролира уште од првите фази на неговото подигање, кога мрежата сè уште не функционира, па затоа се користат едноставни сериски интерфејси како COM, FireWire, USB за поврзување на системи. Неодамна, благодарение на развојните трендови на виртуелизација на софтвер на различни нивоа на апстракција, виртуелните машини се повеќе се привлекуваат. Гостинскиот оперативен систем делува како дебагиран оперативен систем, оперативниот систем домаќин вклучува кориснички интерфејс за дебагер.

Затоа, за итно дебагирање не е потребно да се инсталира алатка за дебагирање на тест компјутерот. Дистрибуцијата на оперативниот систем Виндоус вклучува механизми за спроведување на итни дебагирање. Пред да се рестартира, оперативниот систем може да зачува информации за неговата состојба, кои развивачот може да ги анализира и да ја открие причината. Оваа информација зачувана во датотека се нарекува мемориска депонија.

Главните алатки за дебагирање во режим на јадро се обезбедени од производителот на оперативниот систем Windows како дел од слободно дистрибуираниот пакет Алатки за дебагирање за Windows. Алатките вклучуваат графички и конзолни дебагери WinDbg и KD, соодветно (во натамошниот текст како Windows Debugger). Работата на овие дебагери се заснова на механизмите обезбедени од развивачите на оперативниот систем и вградени во неговото јадро.

Главниот режим за Windows Debugger е режимот на преведувач на команди. Поради својата модуларна структура, заедно со командите обезбедени од развивачите, Windows Debugger поддржува модули од трети страни наречени екстензии. Всушност, повеќето од вградените команди се форматирани како екстензии.

Windows Debugger е фокусиран на далечинско интерактивно и итно дебагирање, со што се откриваат сите негови способности. Во исто време, полноправното локално интерактивно отстранување грешки не е поддржано: дебагерот ви овозможува само прегледување на некои структури на кернелот.

Постои екстензија за Windows Debugger наречена LiveKD, креирана од Марк Русинович, која имплементира локално интерактивно дебагирање во извесна смисла. LiveKD создава мемориска депонија на работниот систем во движење и ја користи за дебагирање.

Алатките за дебагирање за Windows редовно се ажурираат и ги поддржуваат сите модерни оперативни системи на Windows.

Дебагерот на кернелот SoftICE, објавен од Compuware во софтверскиот пакет DriverStudio, традиционално делува како алтернатива на пакетот Алатки за дебагирање за Windows. Карактеристика на SoftICE беше имплементацијата на локално интерактивно дебагирање на поддржан хардвер. Дебагерот може речиси целосно да ја контролира работата на оперативниот систем.

Од 3 април 2006 година, семејството на производи DriverStudio е прекинато поради „многу технички и деловни проблеми, како и општи услови на пазарот“. Најновата верзија на поддржаниот оперативен систем е Windows XP Service Pack 2. Општо земено, сервисните пакети не го менуваат API-то на оперативниот систем, но броевите на системските повици и другите недокументирани информации може да се променат. Дебагерот SoftICE се потпираше на тврдокодирани адреси на внатрешни структури на податоци. Како резултат на тоа, со објавувањето на Service Pack 3, компатибилноста беше нарушена. Очигледно, подоцнежните верзии на оперативниот систем Виндоус исто така не се поддржани.

Syser Kernel Debugger беше креиран од мала кинеска компанија Sysersoft како замена за SoftICE дебагерот. Првата финална верзија беше објавена во 2007 година. Како и SoftICE, Syser Kernel Debugger е способен за интерактивно дебагирање на активен систем. Поддржани се само 32-битни изданија на модерни верзии на Windows.

Windows Debugger моментално е главната алатка меѓу развивачите на модули на кернелот. Го користи и тимот за развој на јадрото на оперативниот систем Виндоус.

Оваа серија на написи настана од две причини. Прво, ми се допаѓа да работам со проектот HackSysExtremeVulnerableDriver. Второ, добив многу желбида се истакне оваа тема.

Целиот код што се користи при пишувањето на оваа серија е во мојот .

Во оваа серија написи, ќе разгледаме пишување експлоатирања на ниво на јадро во Windows. Важно е да се напомене дека ќе се занимаваме со познати пропусти и нема потреба од обратно инженерство (барем не за возач).

Се претпоставува дека откако ќе ги прочитате сите написи, ќе ги знаете сите најчести класи на прекршувања и методи на експлоатација, како и дека ќе можете да пренесете експлоатации од архитектурата x86 во архитектурата x64 (ако е можно) и да се запознаете со новата заштита методи во Windows 10.

Шема за отстранување грешки на јадрото

За разлика од дебагирањето на ниво на корисник, кога еден процес е суспендиран, целиот систем е вклучен на ниво на јадрото и нема да можеме да го користиме овој метод. Соодветно на тоа, потребна е посебна машина за дебагирање која може да комуницира со системот каде што се дебагира кернелот, да ја прегледува меморијата и структурите на јадрото, а исто така да фати падови на системот.

Дополнителен материјал за проучување:

Експлоатација на ранливости на кернелот

Овој процес е многу позабавен од експлоатацијата на ниво на корисник Ј.

Главната цел е да се постигне привилегирано извршување во контекст на кернелот. И тогаш сè зависи од нашата имагинација, почнувајќи од гозба со домашно пиво и завршувајќи со воведување на малициозен софтвер спонзориран од државата.
Во принцип, нашата задача е да добиеме школка со системски привилегии.

Теми на написи од оваа серија

• Дел 1: Поставување на работната средина
• Конфигурирање на три виртуелни машини и систем кој ќе делува како дебагер.
• Конфигурирање на дебагерот WinDBG.
• Дел 2: Товари
• Истражете ги најчестите носивост. Следните делови ќе се однесуваат на одредени пропусти и ќе обезбедат врски до овој напис доколку е потребно.
• Останатите делови.
• Разгледување на ранливости.

Животен циклус на развој на експлоат на ниво на јадро

• Наоѓање на ранливост. Оваа тема нема да биде опфатена во оваа серија, бидејќи веќе знаеме точно каде се празнините.
• Пресретнување на текот на извршувањето. Некои пропусти вклучуваат извршување на код, некои имаат дополнителни барања.
• Проширување на привилегијата. Главната цел е да се добие школка со системски привилегии.
• Враќање на протокот на извршување. Исклучоците што не се ракуваат на ниво на кернел предизвикуваат паѓање на системот. Ако нема да напишете експлоатација за DoS напад, треба да го земете предвид овој факт.

Видови целни системи

Ќе работиме со пропусти во следните системи (конкретната верзија не е критична):

• Win7 x86 VM
• Win7 x64 VM
• Win10 x64 VM

Да почнеме со архитектурата x86, а потоа ќе го пренесеме експлоатот во системот Win7 x64. Некои експлоатирања нема да работат на машините Win10 поради присуството на нови заштити. Во овој случај, или ќе ја промениме логиката на експлоатацијата, или ќе користиме сосема поинаков пристап.

Користениот софтвер:

• Хипервизор (многу опции).
• Windows 7 x86 VM
• Windows 7 x64 VM
• Windows 10 x64 VM

Поставување системи за дебагирање

Системите за отстранување грешки со кои ќе комуницираме се дизајнирани да вчитаат ранлив драјвер. Честопати ќе се случат падови на овие машини, бидејќи повеќето исклучоци во кернелот придонесуваат за ваква работа. Мора да одвоите доволно RAM меморија за овие системи.

На секоја машина што ќе се дебагира, треба да го направите следново:

• Внатре во директориумот VirtualKD, стартувајте ја датотеката target\vminstall.exe. Ќе се додаде нов запис за подигање и ќе бидат достапни функциите за дебагирање и автоматско поврзување со серверот VirtualKD инсталиран на системот што дејствува како дебагер.

Во случај на Windows 10 VM, мора да го овозможите режимот за потпишување тест, кој овозможува непотпишани драјвери да се вчитаат во јадрото.

По извршувањето на bcdedit /set testsinging при команда и рестартирање, „Test Mode“ ќе се појави на работната површина.

Краток опис на HEVD модулот

Процедурата DriverEntry е почетната за секој возач:

NTSTATUS DriverEntry(IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath) (
UINT32 i = 0;
PDEVICE_OBJECT DeviceObject = NULL;
NTSTATUS Статус = STATUS_НЕУСПЕШЕН;
UNICODE_STRING Име на уред, DosDeviceName = (0);

UNREFERENCED_PARAMETER (RegistryPath);
PAGED_CODE();

RtlInitUnicodeString(&DeviceName, L"\\Device\\HackSysExtremeVulnerableDriver");
RtlInitUnicodeString(&DosDeviceName, L"\\DosDevices\\HackSysExtremeVulnerableDriver");

// Креирајте го уредот
Статус = IoCreateDevice(DriverObject,
0,
&Име на уред,
FILE_DEVICE_НЕПОЗНАТ,
FILE_DEVICE_SECURE_OPEN,
лажни,
&DeviceObject);

• Оваа постапка содржи повик до функцијата IoCreateDevice што го содржи името на двигателот што ќе го користиме за време на комуникацијата.
• Потребните структури и покажувачи на функции ќе се додадат во објектот DriverObject.
• Она што ни е важно е покажувачот на функцијата поврзан со процедурата DriverObject->MajorFunction , која е одговорна за ракување со IOCTL (I / O Control; контрола на влез / излез);
• Во HEVD, оваа функција се нарекува IrpDeviceIoCtlHandler, што е голем условен израз со многу гранки за секој IOCTL. Секоја ранливост има уникатен IOCTL.

Пример: HACKSYS_EVD_IOCTL_STACK_OVERFLOW е IOCTL што се користи за активирање на ранливост за прелевање на стек.

Ова го завршува првиот дел. Во следната статија ќе зборуваме за носивост. Во моментов е достапен само товарот за крадење на токени, кој ќе се користи во третиот дел.

П.С. Разбирам дека има многу суптилности и проблеми со кои може да наидете. Бидејќи овој циклус се фокусира на развој на експлоатација, ќе мора сами да ги решите сите проблеми на патот. Сепак, можете да поставите какви било прашања во коментарите.

Како да го стартувате дебагерот на јадрото?

Одговор на мајсторот:

Има еден многу важен дел од процесот на развој на софтвер, а тоа е дебагирање. Во однос на апликативните програми, тоа се спроведува со средства кои работат во режим на корисник и често се вградени во IDE. За да можете да дебагирате, на пример, драјвери, треба да го извршите дебагерот на јадрото.

Треба да го вклучите cmd процесорот. Отворете го менито Start од лентата со задачи. Во прозорецот што се појавува, кликнете на ставката „Стартувај ...“. Ќе се појави прозорецот „Програма за стартување“. Внесете cmd во полето за текст, а потоа кликнете OK.

Сега направете резервна копија од датотеката boot.ini. Прво, дознајте ја патеката за инсталација на вашата тековна копија на Windows користејќи ја командата: echo %SystemRoot%

Следно, одете на дискот со инсталираниот оперативен систем со внесување на буквите на уредот, а по нив со ставање две точки. Користејќи ја командата cd, сменете се во root директориумот. Сега, користејќи ја командата attrib, отстранете ги скриените, само за читање и системските атрибути од датотеката boot.ini. Користете ја командата за копирање за да креирате резервна копија и потоа поставете ги атрибутите на место.

За да ја прикажете тековната листа на опции за подигање, користете ја командата bootcfg /query. Погледнете низ списокот и одредете кој елемент ќе биде основа за создавање нови поставки со можност за дебагирање во режим на кернел. Треба да се запомни ID-то за влез за подигање.

Користете ја командата bootcfg/copy за да креирате запис за подигање. Користете ја опцијата /id за да го наведете ID на објавата што сакате да ја копирате. Користете ја опцијата /d за да го наведете името на записот што треба да се прикаже. Сега треба повторно да отидете на списокот со опции за подигање користејќи ја командата bootcfg /query и да го погледнете ID-то на записот што е додаден.

Сега треба да ги вклучиме опциите за стартување на дебагерот на јадрото во записот за подигање што го создадовме претходно. Ако дебагирате на целната машина, само треба да ја додадете опцијата /debug.

Ако сакате да извршите далечинско дебагирање со целниот компјутер поврзан со машината-домаќин преку com-портата, тогаш користете ги опциите /port и /baud за да го одредите бројот на портата и брзината на бауд.

Ако правите далечинско отстранување грешки со конекција преку кабел FireWire (ИЕЕЕ 1394 интерфејс), тогаш користете ја опцијата /dbg1394 за да го овозможите соодветниот режим и користете ја опцијата /ch за да го одредите бројот на каналот.

За да потврдите дека промените се направени, проверете ги датотеките за подигање користејќи ја командата bootcfg со опцијата /query. Откако ќе ја извршите командата за излез, затворете го прозорецот на школка.

Доколку е потребно, сменете ги опциите за подигање на оперативниот систем. Отворете ја контролната табла преку менито "Start", а веќе во неа отворете ја ставката "System". Во прозорецот Својства на системот што се отвора, изберете го табот Напредно. Во ова јазиче, изберете го делот наречен „Преземи и обновување“ и кликнете на копчето „Опции“ во него. Во прозорецот „Стартување и обновување“ што се појавува, треба да ја активирате опцијата „Прикажи листа на оперативни системи“. Затворете ги двата дијалог-кутија со копчето ОК.

Рестартирајте го компјутерот. Изберете подигање со дебагер. Најавете се и почнете да работите на целната машина или започнете далечинско отстранување грешки. Искористете ги предностите на алатките како што се WinDbg и KD.

Понекогаш имам ситуација кога Windows чека време за подигање за дебагерот на кернелот. Го гледате текстот „Windows start“, но не и логото.

Ако сега го прикачам дебагерот, се репродуцира анимацијата со логото на Windows 7. После тоа, логото почнува да пулсира. Во овој момент, процесот на преземање повеќе не напредува. Користењето на процесорот е сведено на минимум. Обично чекам неколку минути, но ништо не се случува.

Ова не се случува секогаш. Меѓутоа, ако тоа се случи, ресетирањето на VM нема да помогне. За да го поправам овој проблем, треба да користам поправка за стартување. За жал, ова трае вечно.

Дали имате идеја што можам да направам освен да извршам поправка при стартување?

Благодарам однапред!

3

2 одговори

За да го решите проблемот што го доживувате, едноставно притиснете F10 за време на подигањето. И отстранете/дебагирај и сродни опции. Потоа притиснете enter.

Предлог: Не користете ја опцијата /debug за стандардното мени за подигање. Копирајте ја конфигурацијата за подигање на нов запис. Потоа поставете го во режим за отстранување грешки. Windows не знае кога ќе го користите дебагерот. Затоа тој мора да почека.

Терминот „дебагирање на кернелот“ значи испитување на внатрешната структура на податоци на кернелот и/или чекорење низ функциите во кернелот. Ова дебагирање е многу корисен начин за истражување на внатрешните делови на Windows, бидејќи обезбедува прикажување на информации за внатрешниот систем што не се достапни на кој било друг начин, и ви дава јасен приказ за напредокот на кодот во кернелот.

Пред да ги разгледаме различните начини за дебагирање на кернелот, ајде да го истражиме множеството датотеки што ќе бидат потребни за да се изврши каков било вид такво дебагирање.

Симболи за дебагирање на јадрото

Датотеките со симболи ги содржат имињата на функциите и променливите, како и шемата и форматот на структурите на податоци. Тие се генерирани од програмата за поврзување и се користат од дебагерите за да се однесуваат на овие имиња и да се прикажат за време на сесија за отстранување грешки. Оваа информација обично не се чува во бинарно бидејќи не е потребна кога кодот се извршува. Ова значи дека без него, бинарното станува помало и работи побрзо. Но, тоа исто така значи дека при дебагирање, треба да бидете сигурни дека дебагерот има пристап до датотеките со симболи поврзани со бинарните слики што се референцирани за време на сесијата за отстранување грешки.

За да користите која било алатка за отстранување грешки во режимот на јадрото за да ја испитате внатрешната структура на податочната структура на кернелот на Windows (список на процеси, блокови на нишки, листа на вчитани драјвери, информации за користење на меморијата итн.), потребни ви се соодветни датотеки со симболи и барем датотека со симболи за бинарната слика на јадрото, Ntoskrnl.exe. Датотеките на табелата со симболи мора да одговараат на верзијата на бинарната слика од која се извлечени. На пример, ако сте го инсталирале Windows Service Pack или некоја лепенка за ажурирање на кернелот, треба да добиете соодветно ажурирани датотеки со симболи.

Лесно е да се преземат и инсталираат симболи за различни верзии на Windows, но не е секогаш можно да се ажурираат симболите за жешки поправки. Најлесен начин да се добие точната верзија на симболите за дебагирање е да се користи посветен сервер за симболи на Microsoft, користејќи ја специјалната синтакса за патеката на симболот наведена во дебагерот. На пример, следнава патека за симболи предизвикува дебагерот да презема симболи од сервер со симболи на Интернет и да складира локална копија во c:\symbols:srv*c:\symbols*http://msdl.microsoft.com/download/symbols

Детални упатства за користење на серверот за знаци може да се најдат во датотеката за помош на алатките за отстранување грешки или на Интернет на http://msdn.microsoft.com/en-us/windows/hardware/gg462988.aspx.