Отладка по хардкору. Реверсим ARM-приложение для QNX в QEMU

Ког­да x86 и Windows уже при­елись, а уют­ный x64dbg боль­ше не раду­ет глаз, пора перехо­дить к нас­тояще­му хар­дко­ру. ARM, QNX, эму­лятор QEMU и ста­рый доб­рый GDB — вот инс­тру­мен­ты для тех, кто не ищет лег­ких путей. Сегод­ня мы запус­тим экзо­тичес­кую ОС, под­клю­чим­ся к ней через вир­туаль­ный адап­тер и шаг за шагом раз­берем логику прог­раммы пря­мо на лету, без лиш­него ком­форта, но с изрядной долей азар­та.

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

Вир­туал­ки, каюсь, мною охва­чены в мень­шей сте­пени по весь­ма ува­житель­ной при­чине: задачи под них очень неудоб­но отла­живать в динами­ке и при­ходит­ся огра­ничи­вать­ся ста­тичес­ким ана­лизом. Одна­ко при желании всег­да мож­но най­ти выход, даже такой нес­тандар­тный, как исполь­зование раз­личных эму­лято­ров. Ты, веро­ятно, пом­нишь мои статьи, пос­вящен­ные эму­лято­рам SheepShaver для Mac OS или BlueStacks под Android. На этот раз я хочу обра­тить твое вни­мание на леген­дарный эму­лятор QEMU, при помощи которо­го мы будем ана­лизи­ровать при­ложе­ния, реали­зован­ные под ARM QNX.

До это­го мы уже стал­кивались и с ARM, но иссле­дова­ли его исклю­читель­но в дизас­сем­бле­ре, сегод­ня у нас появи­лась счас­тли­вая воз­можность про­щупать его в динами­ке, при­чем на PC и даже из‑под Windows.

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

По усло­вию нашей задачи фай­ловая сис­тема устрой­ства уже заг­ружена в QEMU и успешно там фун­кци­они­рует. В окон­чатель­ной фор­мулиров­ке наша цель выг­лядит так: путем пат­ча или кей­гена добить­ся валид­ности акти­ваци­онно­го кода (на скрин­шоте выделе­но голубым) в акти­ваци­онной стро­ке (выделе­но крас­ным), которую скар­мли­вают прог­рамме при помощи спе­циаль­ного акти­ваци­онно­го Lua-скрип­та. На пред­став­ленном ниже изоб­ражении резуль­тат про­вер­ки выделен жел­тым.

Нач­нем с под­клю­чения отладчи­ка GDB. Об этом тоже написа­но мно­го раз­ных ста­тей, но почему‑то все они как‑то стыд­ливо умал­чива­ют о нас­трой­ке сетево­го под­клю­чения. У непод­готов­ленно­го поль­зовате­ля может сло­жить­ся лож­ное впе­чат­ление, что опции -s -S впол­не дос­таточ­но, что­бы GDB уви­дел QEMU по 1234-му пор­ту.

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

Для начала нам тре­бует­ся соз­дать новое сетевое под­клю­чение с име­нем tap0 (Панель управле­ния → Сеть и Интернет → Сетевые под­клю­чения).

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

Пос­ле это­го добав­ляем в коман­дную стро­ку QEMU опцию -nic tap,ifname=tap0,id=hub0, и мож­но тес­тировать под­клю­чение отладчи­ков к эму­лято­ру. Я понимаю, что ты уже при­вык к удоб­ному уют­ному x64dbg и, самое смеш­ное, что с его помощью тоже мож­но отла­живать при­ложе­ния в эму­лято­ре, но мы, навер­ное, оста­вим такую стран­ную экзо­тику для какой‑нибудь сле­дующей статьи. В этот раз мы нач­нем с самого удоб­ного спо­соба отладки — при помощи уже хорошо извес­тно­го нам дизас­сем­бле­ра IDA.

Для тебя, веро­ятно, уже не новость, что этот дизас­сем­блер осна­щен собс­твен­ным отладчи­ком. Хотя, конеч­но, все уни­вер­саль­ное хуже спе­циаль­ного, и он силь­но про­игры­вает в удобс­тве и надеж­ности x64dbg. Но в дан­ном слу­чае это самое мень­шее из всех зол.

Во­обще‑то про­цесс под­клю­чения IDA к QEMU через GDB под­робно и с цвет­ными кар­тинка­ми опи­сан на сай­те Hex-Rays, одна­ко я сно­ва поп­робую изло­жить его сво­ими сло­вами, пос­коль­ку там тоже есть нюан­сы.

Итак, пос­ле опи­сан­ной выше нас­трой­ки QEMU и его запус­ка мы вво­дим в его кон­соль коман­ду pdebug 1234. Затем откры­ваем в IDA меню Debugger → Attach → Remote GDB debugger и перехо­дим к окну нас­тро­ек под­клю­чения, в которое (исхо­дя из выб­ранных выше нас­тро­ек) вво­дим сле­дующую информа­цию.

Да­лее в окне GDB configuration (Debugger options → Set specific options) нуж­но обя­затель­но ука­зать тип про­цес­сора (в нашем слу­чае это ARM Little-endian), ина­че IDA, ско­рее все­го, рух­нет при атта­че.

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

При попыт­ке выб­рать про­цесс 0 IDA успешно кон­нектит­ся к эму­лято­ру, и хотя бы это раду­ет: зна­чит, мы всё сде­лали пра­виль­но.

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