Реверс-инжиниринг PWN-тасков или эксплуатируем бинарные уязвимости (Часть 4 / Stack3)

Всем доброго времени суток! Набираем обороты… Сегодня мы будем ‘пывнить» stack3.exe (ссылочка на файл, как обычно, на Github).

Stack3

Закидываем в Ghidra:

Анализируем…

Получаем декомпилированный код. Нас встречает все тот же массив из 64-х байт. Небезопасная функция gets(). Функция gets() считывает строку символов из стандартного потока ввода (stdin) и помещает ее в массив local_54. Также в коде есть указатель (local_14) на функцию и проверка (if), не является ли local_14 — NULL. Т.е. если мы «перезапишем» local_14, то попадем в ветку THEN и получим сообщение «calling function pointer, jumping to…», а также перейдем по адресу, которым мы перезапишем local_14:

Вроде бы все понятно, но есть ощущение, что чего-то нехватает? 🙂

Обращаем внимание на функцию «win»:

Функция «win» просто выводит сообщение «code flow successfully changed»:

Фактически, нам нужно использовать BOF, чтобы изменить значение указателя функции, сделав так, чтобы он указывал на адрес функции «win» (это и будет успешным прохождением таска «Stack3»).

Переходим к «динамике». Делаем поиск по strings:

Кликаем по строчке с «code flow successfully changed» и смотрим адрес инструкции «push ebp» (З.Ы. Это начало функции «win». Кому интересно, почему так, читайте про пролог/эпилог процедуры):

Супер! Адрес есть. Давайте посмотрим на наш «пейлоад», который мы подадим на стандартный поток ввода (stdin):

Эксплуатируем. Указатель изменён и мы попали в функцию «win» (о чем говорит сообщение «code flow successfully changed»):

Всем спасибо за внимание! Если понравилась статья, буду рад «пальцу вверх»!