Шелл-код для ARM. Пишем на ассемблере свой реверс-шелл для устройств на ARM

ARM (Advanced RISC Machine) — это 32-бит­ная архи­тек­тура, раз­работан­ная ком­пани­ей Acorn Computers Ltd в 1983 году. Про­цес­соры ARM име­ют 32-раз­рядные регис­тры, но из них толь­ко 16 дос­тупны прог­раммис­ту. Эти­ми 16 так называ­емы­ми видимы­ми регис­тра­ми мож­но манипу­лиро­вать с помощью набора инс­трук­ций.

Они делят­ся на регис­тры обще­го наз­начения и спе­циали­зиро­ван­ные. К пер­вым отно­сят­ся регис­тры от R0 до R10, к спе­циали­зиро­ван­ным — сле­дующие:

• R11 — frame pointer (FP);
• R12 — intra-procedure (IP);
• R13 — ука­затель на стек (stack pointer, SP);
• R14 — свя­зующий регистр (link register, LR);
• R15 — счет­чик (program counter, PC). Гру­бо говоря, EIP/RIP.

Об ARM мож­но почитать на сай­те, пос­вящен­ном этим про­цес­сорам, или в Ви­кипе­дии. Так­же име­ются пуб­ликации об AArch64. Про ассем­блер под ARM советую сле­дующие кни­ги:

• Ас­сем­блер для Raspberry Pi. Прак­тичес­кое руководс­тво;
• Экс­плу­ата­ция сис­тем ARM Linux;
• Blue Fox: Arm Assembly Internals and Reverse Engineering.

Создание виртуальной машины в QEMU

QEMU — это эму­лятор раз­личных про­цес­сорных архи­тек­тур. Как пра­вило, он исполь­зует­ся для эму­ляции целого компь­юте­ра (то есть для запус­ка вир­туаль­ной машины), одна­ко для отладки одной прог­раммы это необя­затель­но. В Linux мож­но исполь­зовать эму­ляцию QEMU User-Mode, имен­но этот спо­соб и будет рас­смот­рен пер­вым.

На­ша конеч­ная цель — запус­кать ском­пилиро­ван­ные прог­раммы для ARM 64-bit. Для начала необ­ходимо уста­новить сам пакет эму­лято­ра:

Для AArch64 уста­нав­лива­ем сле­дующие ком­понен­ты:

Что­бы эму­лиро­вать про­цес­сор типа ARM64, необ­ходимо соз­дать две дирек­тории — deb11_inst и deb11_start: mkdir deb11_inst deb11_start. Затем перей­ти в deb11_inst и ска­чать два фай­ла — installer-linux и installer-initrd.gz.

Для это­го исполь­зуем сле­дующие коман­ды:

Даль­ше соз­даем диск для уста­нов­ки на него сис­темы:

Соз­даем файл instDebARM64.sh, в него необ­ходимо записать сле­дующий скрипт:

Здесь

• qemu-system-aarch64 — эму­ляция пол­ной сис­темы для архи­тек­туры;
• -M — выбор эму­лиру­емой машины;
• -m — объ­ем ОЗУ;
• -cpu — тип эму­лиру­емо­го про­цес­сора;
• -smp — количес­тво вир­туаль­ных ядер ЦП и их рас­пре­деле­ние по сокетам;
• -kernel — для исполь­зования ука­зан­ного обра­за ядра Linux;
• -initrd — для заг­рузки Linux;
• netdev/device и drive — опи­сание сетевой кар­ты и вир­туаль­ных дис­ков;
• if — опция ука­зыва­ет, через интерфейс какого типа под­клю­чен диск;
• file — опре­деля­ет, какой образ исполь­зовать для какого дис­ка;
• format — ука­зыва­ет явным образ фор­мат дис­ков, не исполь­зовать авто­опре­деле­ние;
• -display — выбор типа отоб­ражения, дос­тупно sdl, curses, gtk, none, vga;
• -no-reboot — отме­на перезаг­рузки.

Сох­раня­ем и запус­каем скрипт. Нач­нется клас­сичес­кая уста­нов­ка Debian 11. На пер­вом экра­не надо выб­рать англий­ский язык в качес­тве основно­го.

Да­лее необ­ходимо выб­рать UNITED STATES. Бли­же к завер­шению уста­нов­ки появит­ся ошиб­ка.

Вы­бира­ем Continue и дожида­емся окон­чания уста­нов­ки Debian. Перено­сим образ hda.img с уста­нов­ленной сис­темой в дирек­торию deb11_start. Затем соз­даем файл debARM64.sh, в который помес­тим сле­дующий скрипт:

Щел­каем на соз­данном дис­ке hda.img пра­вой кла­вишей мыши и мон­тиру­ем его: «Открыть с помощью → Мон­тирова­ние дис­кового обра­за». На смон­тирован­ном дис­ке нас инте­ресу­ют два фай­ла: initrd.img-5.10.0-20-arm64 и vmlinuz-5.10.0-20-arm64 (ну а в общем слу­чае initrd.img-xxxxxxx-arm64 и vmlinuz-xxxxxxx-arm64). Вер­сии сис­темы дол­жны быть оди­нако­выми! Запус­каем файл debARM64.sh:

Для нас­трой­ки сети в скрипт debARM64.sh нуж­но добавить строч­ку -net user,hostfwd=tcp::10022-:22. Эта строч­ка соз­даст еще и SSH-под­клю­чение.

Docker

Есть и аль­тер­натив­ный вари­ант: эму­ляция Raspberry Pi с исполь­зовани­ем Docker. Для это­го нуж­но уста­новить Docker:

За­тем ска­чать соот­ветс­тву­ющий образ:

Как толь­ко все прог­рузит­ся, вво­дим коман­ду

В качес­тве имя_для_контейнера мож­но выб­рать любое, я назову свой ap_security. Пос­ле это­го нач­нется рас­паков­ка и запуск Raspberry Pi.

Ито­гом успешно­го запус­ка будет такое окно.

Учет­ные дан­ные для вхо­да в сис­тему стан­дар­тны: pi:raspberry. Собс­твен­но, всё. Теперь в нашей вир­туаль­ной лабора­тории есть Raspberry Pi. Что­бы вык­лючить устрой­ство, исполь­зуй коман­ду sudo poweroff, а что­бы запус­тить — docker start -ai имя_для_контейнера, где имя_для_контейнера — выб­ранное тобой имя кон­тей­нера.

Установка GDB и PEDA/GEF

Ус­танов­ка GDB и пла­гина PEDA доволь­но прос­та. Для GDB исполь­зуем коман­ду

Для уста­нов­ки PEDA коман­ды такие:

GEF уста­новим коман­дой

От­ладку я буду выпол­нять в основном в GEF.

Пробуем GDB и пишем первую программу

Что­бы написать прог­рамму на ассем­бле­ре, пот­ребу­ются три инс­тру­мен­та:

• тек­сто­вый редак­тор — nano;
• прог­рамма для соз­дания объ­ектно­го фай­ла — as;
• прог­рамма для динами­чес­кой при­вяз­ки — ld.

Тек­сто­вый редак­тор — это вку­сов­щина. Мно­гие пишут в Vim, мне удоб­нее в nano, поэто­му код я буду писать там. Прог­рамма as соз­дает объ­ектный файл, а ld выпол­няет динами­чес­кую при­вяз­ку. Работать с эти­ми прог­рамма­ми нуж­но сле­дующим обра­зом:

1. Пи­шем коман­ду as source.asm -o source.o, которая соз­дает объ­ектный файл с наз­вани­ем source.o.
2. Свя­зыва­ем объ­ектный файл и пре­обра­зуем его в исполня­емый с помощью коман­ды ld source.o -o source.bin.

У любого фай­ла с кодом на язы­ке ассем­бле­ра дол­жна быть точ­ка, с которой начина­ется прог­рамма. Она выг­лядит так:

Эта точ­ка опре­деля­ется как гло­баль­ное имя для всей прог­раммы. Каж­дый опе­ратор име­ет сле­дующий син­таксис:

Первая программа

В пер­вой прог­рамме, по клас­сике, реали­зован вывод при­ветс­твен­ной строч­ки — H3ll0, ][akep!:

Здесь

• r7 — номер про­цеду­ры;
• r0 опре­деля­ет поток (stdin/stdout/stderr);
• r2 — количес­тво выводи­мых сим­волов;
• r1 хра­нит адрес стро­ки.

Все это схо­же с ассем­бле­ром для i386. В ARM регис­тры для вза­имо­дей­ствия такие:

• r7 — номер сис­темно­го вызова;
• r0 — аргу­мент 1;
• r1 — аргу­мент 2;
• r2 — аргу­мент 3;
• r3 — аргу­мент 4;
• r4 — аргу­мент 5;
• r5 — аргу­мент 6;
• r0 — воз­вра­щаемое зна­чение или код ошиб­ки.

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

Ком­пилиру­ем при­ложе­ние и запус­каем.

Здесь -g — ключ для вклю­чения отла­доч­ной информа­ции. Пос­ле запус­ка уви­дим сле­дующее:

Поп­робу­ем про­деба­жить это при­ложе­ние.

Первый опыт в отладке

За­пус­каем GDB и заг­ружа­ем в него бинар­ный файл, пос­ле чего перехо­дим к раз­делу start:

Пос­тавим точ­ку оста­нова на пер­вой инс­трук­ции и запус­тим прог­рамму:

Ок­но отладки GDB-GEF выг­лядит так.

Шпар­галку по GDB-коман­дам мож­но най­ти в до­кумен­тации, опуб­ликован­ной на сай­те Darkdust.