Фундаментальные основы хакерства. Затрудняем анализ программ

Содержание статьи

• Приемы против отладчиков
• Немного истории
• Как работает отладчик
• Обработка исключений в реальном и защищенном режимах
• Как хакеры ломают программы?
• Как защитить свои программы?
• Как противостоять трассировке
• Как противостоять контрольным точкам останова
• Итоги

Под хакерс­твом обыч­но понима­ют изу­чение дизас­сем­бли­рован­ного кода при­ложе­ний с целью их взло­ма. Сегод­ня мы зай­мем про­тиво­полож­ную сто­рону бар­рикад — изу­чим при­емы защиты. Нас­тала пора осно­ватель­но разоб­рать­ся в устрой­стве исполь­зуемых хакера­ми инс­тру­мен­тов, фун­кци­ональ­ной под­дер­жке со сто­роны опе­раци­онной сис­темы и про­цес­сора, что­бы про­тивос­тоять взлом­щику, скрыть свои сек­реты и не стать лег­кой наживой для зло­умыш­ленни­ка!

Фундаментальные основы хакерства

Пят­надцать лет назад эпи­чес­кий труд Кри­са Кас­пер­ски «Фун­дамен­таль­ные осно­вы хакерс­тва» был нас­толь­ной кни­гой каж­дого начина­юще­го иссле­дова­теля в области компь­ютер­ной безопас­ности. Одна­ко вре­мя идет, и зна­ния, опуб­ликован­ные Кри­сом, теря­ют акту­аль­ность. Редак­торы «Хакера» попыта­лись обно­вить этот объ­емный труд и перенес­ти его из вре­мен Windows 2000 и Visual Studio 6.0 во вре­мена Windows 10 и Visual Studio 2019.

Ссыл­ки на дру­гие статьи из это­го цик­ла ищи на стра­нице авто­ра.

Три основных эта­па взло­ма защит­ных механиз­мов — это локали­зация кода защиты в коде при­ложе­ния, ана­лиз алго­рит­ма его работы и собс­твен­но сам взлом. Все эта­пы оди­нако­во важ­ны: если, нап­ример, не будет прой­ден вто­рой из них — за взлом нечего брать­ся.

Мож­но клас­сифици­ровать защиты по типу «эта­па прет­кно­вения». Нап­ример, шиф­ры и крип­тозащи­ты опи­рают­ся на тре­тий этап — алго­ритм их работы обыч­но обще­дос­тупен, хорошо докумен­тирован и в общем слу­чае известен хакеру, но это не силь­но облегча­ет взлом (раз­ве что упро­щает написа­ние перебор­щика). Механиз­мы с исполь­зовани­ем регис­тра­цион­ных номеров, нап­ротив, дела­ют упор на засек­речива­нии алго­рит­ма генера­ции, а так­же зат­рудне­нии его поис­ка и ана­лиза в коде прог­раммы (еще бы, зная алго­ритм, мож­но лег­ко написать кей­ген).

Од­нако даже если защита пос­тро­ена с при­мене­нием крип­тогра­фичес­ких методов, ска­жем шиф­рует тело кри­тичес­ки важ­ных фун­кций крип­тостой­ким методом по непомер­но длин­ному клю­чу, она может быть «отвя­зана» от клю­ча, нап­ример копиро­вани­ем дам­па прог­раммы пос­ле рас­шифров­ки. Еще про­ще — рас­простра­нять прог­рамму вмес­те с клю­чом (обыч­ная так­тика пиратов). Один из спо­собов вос­пре­пятс­тво­вать такому бес­пре­делу — заложить в ключ зашиф­рован­ную при­вяз­ку к компь­юте­ру или про­верять «чис­тоту» копии через интернет (мож­но даже и вти­хомол­ку — скры­то от поль­зовате­ля, хотя это счи­тает­ся дур­ным тоном). Но что помеша­ет хакеру, вла­деюще­му лицен­зион­ной копи­ей прог­раммы, рас­шифро­вать ее сво­им клю­чом и выкусить все про­вер­ки чего бы там ни было?

Та­ким обра­зом, любая защита дол­жна уметь эффектив­но пре­пятс­тво­вать сво­ему обна­руже­нию, ана­лизу, попут­но отравляя жизнь дизас­сем­бле­ру и отладчи­ку — основным инс­тру­мен­там взлом­щика. Без это­го защита не защита.

В эпо­ху царс­тво­вания MS-DOS в основном исполь­зовались прог­раммы реаль­ного режима, которые монополь­но рас­поряжа­ются про­цес­сором, памятью и аппа­рату­рой, в любой момент бес­пре­пятс­твен­но перехо­дят в защищен­ный режим и воз­вра­щают­ся обратно. Отладчи­ки в то вре­мя (еще хлип­кие, немощ­ные, нежиз­неспо­соб­ные) лег­ко обма­ныва­лись, сру­бались и завеши­вались три­виаль­ными при­ема­ми прог­рамми­рова­ния, активно исполь­зуемы­ми защита­ми. Дру­гими сло­вами, дизас­сем­бле­ры тог­да были очень глу­пыми и впа­дали в сту­пор от одно­го толь­ко вида зашиф­рован­ного или самомо­дифи­циру­юще­гося кода. Сло­вом, нас­тоящий рай для раз­работ­чиков защит.

Се­год­ня все изме­нилось. Преж­де все­го, прик­ладной прог­рамме под Windows осо­бо выделы­вать­ся ник­то не даст. С защищен­ным режимом теперь слиш­ком не раз­гонишь­ся — исполь­зуй про­заичес­кие неп­ривиле­гиро­ван­ные инс­трук­ции, а о раз­ных хит­ростях не помыш­ляй. Та же неболь­шая часть защит­ных при­емов, что может фун­кци­они­ровать даже в такой ори­енти­рован­ной на поль­зовате­ля сре­де, натал­кива­ется на силь­но поум­невшие отладчи­ки и дизас­сем­бле­ры.

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

Су­щес­тву­ют и отладчи­ки‑эму­лято­ры, фак­тичес­ки нас­тоящие вир­туаль­ные машины, самос­тоятель­но исполня­ющие код, вмес­то того что­бы пус­тить его на «живой» про­цес­сор. При этом эму­лятор всег­да исполня­ется в режиме супер­визора даже по отно­шению к отла­жива­емо­му коду нулево­го коль­ца. У защиты очень мало шан­сов обна­ружить отладчик или помешать его работе (да и то если эму­лятор реали­зован с ошиб­ками).

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

Да­же на уров­не нулево­го коль­ца в Windows очень труд­но что‑либо скрыть. Что­бы обес­печить сов­мести­мость со всем пар­ком Windows-подоб­ных опе­раци­онных сис­тем, при­ходит­ся исполь­зовать толь­ко докумен­тирован­ные воз­можнос­ти. Стро­ить в «окнах» защиту — все рав­но что пытать­ся заб­лудить­ся в пар­ке. Будь там хоть мил­лион деревь­ев, все они геомет­ричес­ки пра­виль­но рас­положе­ны и обиль­но уве­шаны таб­личка­ми «Выход — там».

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

Приемы против отладчиков

Немного истории

Рань­ше всех появил­ся debug.com — пародия, которая отда­лен­но напоми­нает отладчик, зато вхо­дит в штат­ную пос­тавку MS-DOS. Сегод­ня этот инс­тру­мент годит­ся раз­ве что для забавы и изу­чения ассем­бле­ра. Впро­чем, и тог­да от него мало кто был в вос­торге, и новые отладчи­ки рос­ли как гри­бы пос­ле дож­дя. Прав­да, боль­шинс­тво из них недале­ко ушло от сво­его про­тоти­па, отли­чаясь от ори­гина­ла раз­ве что интерфей­сом.

Это было золотое вре­мя для раз­работ­чиков защит. Сто­ило лишь «запереть» кла­виату­ру, зап­ретить пре­рыва­ния, сбро­сить флаг трас­сиров­ки, и отладка прог­раммы ста­нови­лась невоз­можной.

Пер­вые мало‑маль­ски при­год­ные для взло­ма отладчи­ки появи­лись толь­ко пос­ле осна­щения компь­юте­ров про­цес­сором 80286. В памяти хакеров нав­сегда оста­нут­ся AFD PRO, написан­ный в 1987 году AdTec GmbH, зна­мени­тый Turbo Debugger, соз­данный годом поз­же брать­ями Кри­сом и Ричем Виль­ямса­ми, пер­вый эму­лиру­ющий отладчик Сер­гея Пач­ковки, написан­ный, прав­да, с боль­шим опоз­дани­ем — в 1991 году. Раз­работ­чики защит кряк­нули, но выдер­жали — эти отладчи­ки по‑преж­нему поз­воляли отла­жива­емой прог­рамме зах­ватить над собой кон­троль и очень пло­хо перено­сили «извра­щения» со сте­ком, экра­ном, кла­виату­рой…

Си­туация изме­нилась с выходом про­цес­сора 80386 — рез­кое усложне­ние прог­рам­мно­го обес­печения и, как следс­твие, огромные слож­ности с его отладкой дик­товали необ­ходимость наличия раз­витых отла­доч­ных средств в самом про­цес­соре. И в 386 они появи­лись! С это­го момен­та раз­работ­чикам защит ста­ли нас­тупать на пят­ки.

Мас­ла в огонь под­лила NuMega, выпус­тившая в кон­це вось­мидеся­тых годов свой замеча­тель­ный SoftICE, поль­зовав­ший­ся у хакеров огромной популяр­ностью, а поз­же пор­тирован­ный на Windows 9x и Windows NT. Он дол­гое вре­мя оста­вал­ся бес­спор­ным фавори­том (хотя не без кон­курен­ции). Впро­чем, невер­но было бы счи­тать, что NuMega — кри­миналь­ная фир­ма, а SoftICE исклю­читель­но хакер­ский про­дукт. Этот отладчик пред­назна­чен в пер­вую оче­редь для раз­работ­чиков драй­веров и для легаль­ных иссле­дова­телей опе­раци­онной сис­темы (не раз­бира­ясь во внут­реннос­тях ОС, с драй­верами осо­бо не раз­гонишь­ся).

Но так или ина­че, SoftICE задал копоти всем защитам и их раз­работ­чикам. Пус­кай он не был пол­ностью невиди­мым для отла­жива­емых прог­рамм Stealth-отладчи­ком, имел ряд оши­бок, поз­воля­ющих себя обна­ружить, и давал защите воз­можность выр­вать­ся из‑под кон­тро­ля, но в уме­лых руках отладчик справ­лялся со все­ми эти­ми огра­ниче­ниями и обхо­дил забот­ливо рас­став­ленные «кап­каны». И с каж­дой вер­сией SoftICE про­тивос­тоять ему ста­нови­лось все труд­нее и труд­нее (ста­рые ошиб­ки устра­нялись быс­трее, чем вно­сились новые).

Пос­тепен­но мода на анти­отла­доч­ные при­емы сош­ла на нет и уж сов­сем заг­лохла под побед­ное шес­твие Windows XP SP3. Пос­коль­ку одновре­мен­но с ее выходом SoftICE перес­тал кор­рек­тно работать, пол­ностью завеши­вая сис­тему без воз­можнос­ти даль­нейше­го фун­кци­они­рова­ния. Все ука­зыва­ет на то, что такой же эффект был в Windows Vista, вышед­шей годом ранее, но на ней я самолич­но SoftICE не про­верял.

К тому момен­ту NuMega уже была при­обре­тена ком­пани­ей Compuware, и SoftICE рас­простра­нял­ся как часть пакета для раз­работ­ки драй­веров DriverStudio. Пос­ледняя вер­сия SoftICE была выпуще­на в апре­ле 2006 года. Service Pack 3 для Windows XP появил­ся дву­мя годами поз­днее.

Так как SoftICE исполь­зовал недоку­мен­тирован­ные воз­можнос­ти Windows, с выходом новой вер­сии вин­ды он перес­тавал работать. Как было ска­зано ранее, пос­ле 2006 года SoftICE перес­тал получать обновле­ния, затем был про­дан ком­пании Micro Focus и ею же окон­чатель­но похоро­нен. Веро­ятно, глав­ную роль в смер­ти SoftICE сыг­рали деловые раз­ногла­сия соз­дателей отладчи­ка с Microsoft, а не тех­ничес­кие проб­лемы, как при­нято счи­тать. Похоже, SoftICE исполь­зовал какие‑то осо­бые механиз­мы опе­раци­онной сис­темы, которые Microsoft пос­читала «неудоб­ными».

При сра­баты­вании пос­тавлен­ной точ­ки оста­нова SoftICE завеши­вал сис­тему, поз­воляя поль­зовате­лю (в дан­ном слу­чае хакеру) про­дол­жать вза­имо­дей­ство­вать с компь­юте­ром через свою прос­лой­ку меж­ду аппа­рат­ным обес­печени­ем и ОС. Поэто­му пос­ле завеши­вания сис­темы взлом­щик мог спо­кой­но возоб­новить ее работу, а она, в свою оче­редь, о зависа­нии даже не подоз­ревала. У нее даже отста­вало сис­темное вре­мя на тот пери­од, пока она находи­лась в «отключ­ке» — в завис­шем сос­тоянии.

Свя­то мес­то пус­то не быва­ет. В качес­тве отладчи­ка поль­зователь­ско­го уров­ня популяр­ным стал OllyDbg. Одна­ко сей­час по дан­ным с офи­циаль­ного сай­та раз­работ­ка отладчи­ка заморо­жена.

Пред­при­имчи­вые китай­цы выпус­тили отладчик уров­ня ядра под наз­вани­ем Syser, по сво­им воз­можнос­тям во мно­гом схо­жий с испустив­шим дух SoftICE. Толь­ко энту­зиаз­ма хва­тило ненадол­го, и уже сов­сем ско­ро раз­работ­ка была прек­ращена. Сей­час его не най­ти даже на фай­ловых помой­ках.

За­то Microsoft с течени­ем вре­мени прев­ратила свой захуда­лый отладчик WinDbg в дей­стви­тель­но мощ­ный и полез­ный для сис­темных прог­раммис­тов и хакеров инс­тру­мент. Гру­бо говоря, WinDbg пред­став­ляет собой обо­лоч­ку для отладки с помощью движ­ка dbgeng.dll, который вклю­чен непос­редс­твен­но в опе­раци­онную сис­тему. WinDbg может исполь­зовать­ся как отладчик либо поль­зователь­ско­го режима, либо режима ядра, но не одновре­мен­но.

Вмес­те с гибелью SoftICE рас­простра­нилось совер­шенно нелепое убеж­дение, что под Windows на прик­ладном уров­не дер­нуть хвост челове­ку с отладчи­ком невоз­можно. Это вызыва­ет ухмылку про­фес­сиона­лов, эпи­зоди­чес­ки встра­ивающих раз­ные ловуш­ки в свои прог­раммы — так, боль­ше для раз­минки (дабы моз­ги жиром не зап­лыли), чем для серь­езной борь­бы с хакера­ми.

Бо­роть­ся с хакера­ми при сов­ремен­ном уров­не средств ана­лиза при­ложе­ний нес­коль­ко наив­но — те и от тиг­ра хвост отор­вут. Но сегод­ня, кро­ме хакеров, серь­езную угро­зу пред­став­ляют и вче­раш­ние жел­торотые поль­зовате­ли, начитав­шиеся спра­воч­ных руководств о том, «как ломать прог­раммы» (бла­го сей­час они дос­тупны всем и каж­дому), и теперь толь­ко и ищу­щие, на чем бы испы­тать свою силуш­ку богатыр­скую.

Как работает отладчик

Бо­роть­ся с отладчи­ком, не пред­став­ляя себе, как он работа­ет, было бы по мень­шей мере некуль­тур­но. Поэто­му ниже мы рас­смот­рим базовые прин­ципы, лежащие в его осно­ве. Это изло­жение не явля­ется все­объ­емлю­щим, тем не менее оно поз­воля­ет сос­тавить общее пред­став­ление о воп­росе. Тех­ничес­кие под­робнос­ти исчерпы­вающе изло­жены в 17-й гла­ве Debug, Branch Profile, Tsc, And Resource Monitoring Features тех­ничес­кого руководс­тва Intel 64 and IA-32 Architectures Software Developer’s Manual, Volume 3B: System Programming Guide, Part 2 (PDF), которое бес­плат­но рас­простра­няет фир­ма Intel.

Все отладчи­ки мож­но раз­делить на две катего­рии: пер­вые исполь­зуют отла­доч­ные средс­тва про­цес­сора, а вто­рые самос­тоятель­но эму­лиру­ют про­цес­сор, пол­ностью кон­тро­лируя выпол­нение «подопыт­ной» прог­раммы.

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

Да и есть ли смысл их соз­давать? Мик­ропро­цес­соры линей­ки Core пре­дос­тавля­ют в рас­поряже­ние раз­работ­чика богатей­шие отла­доч­ные воз­можнос­ти, поз­воля­ющие кон­тро­лиро­вать даже при­виле­гиро­ван­ный код! Они под­держи­вают пошаго­вое исполне­ние прог­раммы, отсле­жива­ют выпол­нение инс­трук­ции по задан­ному адре­су, кон­тро­лиру­ют обра­щения к нуж­ным ячей­кам памяти (или пор­там вво­да‑вывода), сиг­нализи­руют о перек­лючени­ях задач и так далее.

В общей слож­ности мик­ропро­цес­соры серии x86, начиная с модели x386, содер­жат восемь отла­доч­ных 32-бит­ных регис­тров. В обновлен­ной архи­тек­туре x86-64 количес­тво отла­доч­ных регис­тров не изме­нилось, одна­ко они уве­личи­лись в раз­мере до 64 бит.

Че­тыре отла­доч­ных регис­тра DR0 — DR3 хра­нят линей­ные адре­са четырех кон­троль­ных точек, а управля­ющий регистр DR7 содер­жит для каж­дой из них усло­вие, при выпол­нении которо­го про­цес­сор генери­рует исклю­чение INT 0x1, переда­вая управле­ние отладчи­ку. Все­го сущес­тву­ет четыре раз­личных усло­вия: пре­рыва­ние при выпол­нении коман­ды, пре­рыва­ние при модифи­кации ячей­ки памяти, пре­рыва­ние при чте­нии или модифи­кации, но не исполне­нии ячей­ки памяти и пре­рыва­ние при обра­щении к пор­ту вво­да‑вывода.

От­ладоч­ные регис­тры для линей­ных адре­сов точек оста­нова в зависи­мос­ти от архи­тек­туры про­цес­сора име­ют раз­меры 32 или 64 бита.

Ре­гис­тры DR4 и DR5 зарезер­вирова­ны для исполь­зования в будущем. Фла­ги регис­тра DR6 уста­нав­лива­ются в зависи­мос­ти от про­исхо­дящих исклю­чений. Нап­ример, пер­вые четыре фла­га уста­нав­лива­ются в зависи­мос­ти от сра­баты­вания соот­ветс­тву­ющих точек оста­нова в регис­трах DR0 — DR3. Фла­ги регис­тра DR7 поз­воля­ют вклю­чать или отклю­чать уста­нов­ленные в регис­трах DR0 — DR3 точ­ки оста­нова, а так­же опре­делять усло­вия сра­баты­вания пре­рыва­ний.

Ре­гис­тры отладки в про­цес­сорах на архи­тек­туре IA-32

Ре­гис­тры отладки в про­цес­сорах на архи­тек­туре AMD64

Ес­ли бит трас­сиров­ки регис­тра фла­гов уста­нов­лен, то пос­ле выпол­нения каж­дой машин­ной инс­трук­ции авто­мати­чес­ки генери­рует­ся отла­доч­ное исклю­чение INT 1 и управле­ние переда­ется отладчи­ку. Отла­жива­емый код может обна­ружить трас­сиров­ку ана­лизом регис­тра фла­гов, поэто­му для обес­печения собс­твен­ной невиди­мос­ти отладчик дол­жен рас­позна­вать коман­ды чте­ния регис­тра фла­гов и эму­лиро­вать их выпол­нение, воз­вра­щая нулевое зна­чение фла­га трас­сиров­ки.

Сле­дует обра­тить вни­мание на одно важ­ное обсто­ятель­ство: пос­ле выпол­нения коман­ды, модифи­циру­ющей зна­чение регис­тра SS, отла­доч­ное исклю­чение не генери­рует­ся! Отладчик дол­жен уметь рас­позна­вать такую ситу­ацию и самос­тоятель­но уста­нав­ливать точ­ку оста­нова на сле­дующую инс­трук­цию. В про­тив­ном слу­чае вой­ти в про­цеду­ру, пред­варен­ную инс­трук­цией POP SS, авто­мати­чес­кий трас­сиров­щик не смо­жет:

PUSH SSPOP SSCALL MySecretProc

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

Ус­танов­кой спе­циаль­ного бита мож­но добить­ся генера­ции отла­доч­ного исклю­чения при вся­ком обра­щении к отла­доч­ным регис­трам, которое воз­ника­ет даже в том слу­чае, если их пыта­ется про­честь (модифи­циро­вать) при­виле­гиро­ван­ный код. Гра­мот­но спро­екти­рован­ный отладчик может скрыть факт сво­его при­сутс­твия, не поз­воляя отла­жива­емо­му коду себя обна­ружить, какие бы ни были у него при­виле­гии. Прав­да, если «подопыт­ный» код отла­жива­ет сам себя, задей­ство­вав все четыре кон­троль­ные точ­ки, отладчик не смо­жет работать.

Ес­ли бит Т в TSS отла­жива­емой задачи уста­нов­лен, то при каж­дом перек­лючении на нее будет генери­ровать­ся отла­доч­ное исклю­чение до выпол­нения пер­вой коман­ды задачи. Что­бы пре­дот­вра­тить собс­твен­ное обна­руже­ние, отладчик может отсле­живать вся­кие обра­щения к TSS и воз­вра­щать прог­рамме под­ложные дан­ные. Необ­ходимо заметить: Windows NT по сооб­ражени­ям про­изво­дитель­нос­ти не исполь­зует TSS (точ­нее, исполь­зует, но все­го один) и эта отла­доч­ная воз­можность для нее совер­шенно бес­полез­на.

Прог­рам­мная точ­ка оста­нова — единс­твен­ное, что нель­зя замас­кировать, не при­бегая к написа­нию пол­ноцен­ного эму­лято­ра про­цес­сора. Она пред­став­ляет собой одно­бай­товый код 0xCC, который, если его помес­тить в начало инс­трук­ции, вызыва­ет исклю­чение INT 0x3 при попыт­ке ее выпол­нения. Отла­жива­емой прог­рамме дос­таточ­но под­счи­тать свою кон­троль­ную сум­му, что­бы выяс­нить, была ли уста­нов­лена хоть одна точ­ка оста­нова или нет. Для дос­тижения этой цели она может вос­поль­зовать­ся коман­дами MOV, MOVS, LODS, POP, CMP, CMPS или любыми дру­гими, ни один отладчик не в сос­тоянии их все отсле­дить и эму­лиро­вать.

Нас­тоятель­но рекомен­дую исполь­зовать прог­рам­мные точ­ки оста­нова в тех и толь­ко в тех слу­чаях, ког­да аппа­рат­ных уже не хва­тает. Как мы уви­дели выше, в про­цес­сорах x86-64 име­ется четыре аппа­рат­ные точ­ки оста­нова. Мно­го это или мало — зависит от слу­чая и отла­жива­емой прог­раммы. Одна­ко прак­тичес­ки все сов­ремен­ные отладчи­ки всег­да уста­нав­лива­ют прог­рам­мные, а не аппа­рат­ные точ­ки оста­нова. Это обсто­ятель­ство может быть с успе­хом исполь­зовано в защит­ных механиз­мах, при­меры реали­заций которых при­веде­ны в раз­деле «Как про­тивос­тоять трас­сиров­ке».

Обработка исключений в реальном и защищенном режимах

Ког­да воз­ника­ет отла­доч­ное исклю­чение (как, впро­чем, и любое дру­гое), про­цес­сор заносит в стек регистр фла­гов, адрес сле­дующей (или текущей — в зависи­мос­ти от рода исклю­чения) выпол­няемой инс­трук­ции и лишь затем переда­ет управле­ние отладчи­ку.

В реаль­ном режиме фла­ги с адре­сом воз­вра­та заносят­ся в стек отла­жива­емой прог­раммы, поэто­му факт отладки обна­ружить очень прос­то — дос­таточ­но кон­тро­лиро­вать целос­тность содер­жимого, лежаще­го выше ука­зате­ля сте­ка. Или, как вари­ант, уста­новить ука­затель на его вер­шину, тог­да добав­ление новых дан­ных в стек ока­жет­ся невоз­можным и отладчик не смо­жет фун­кци­они­ровать.

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

Как хакеры ломают программы?

Вскрыть защит­ный механизм в общем слу­чае не сос­тавля­ет проб­лемы. Куда слож­нее най­ти этот самый механизм в коде лома­емо­го при­ложе­ния. Сегод­ня мало кто исполь­зует для этой цели авто­мати­чес­кую трас­сиров­ку — на сме­ну ей приш­ли аппа­рат­ные кон­троль­ные точ­ки.

Пусть некая защита зап­рашива­ет пароль, затем каким‑то обра­зом удос­товеря­ется в его под­линнос­ти (нап­ример, срав­нива­ет с ори­гина­лом) и в зависи­мос­ти от резуль­татов про­вер­ки переда­ет управле­ние соот­ветс­тву­ющей вет­ке прог­раммы. Вскрыть такую защиту взлом­щик может, даже не вни­кая в алго­ритм аутен­тифика­ции! Он прос­то вве­дет пер­вый при­шед­ший ему на ум пароль (необя­затель­но сов­пада­ющий с пра­виль­ным), най­дет его в памяти, уста­новит кон­троль­ную точ­ку на пер­вый сим­вол стро­ки сво­его пароля, дож­дется «всплы­тия» отладчи­ка, отсле­див­шего обра­щение к паролю, вый­дет из срав­нива­ющей про­цеду­ры и «под­пра­вит» усло­вие перехо­да так, что­бы управле­ние всег­да получа­ла нуж­ная ветвь прог­раммы.

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

Как защитить свои программы?

От­куда бы ни бра­лась клю­чевая информа­ция — из реес­тра, фай­ла или с кла­виату­ры, взлом­щик может прак­тичес­ки мгно­вен­но локали­зовать ее мес­тополо­жение в памяти и уста­новить кон­троль­ную точ­ку. Помешать это­му нель­зя, но не сос­тавит тру­да под­ложить хакеру сюр­приз — пусть клю­чевая информа­ция ана­лизи­рует­ся не сра­зу же пос­ле получе­ния, а переда­ется в качес­тве аргу­мен­та мно­жес­тву фун­кций, которые что‑то с ней дела­ют и затем переда­ют дру­гим фун­кци­ям, а те, в свою оче­редь, сле­дующим.

Источник: xakep.ru