Всем доброго времени суток! Набираем обороты... Сегодня мы будем 'пывнить" 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):

*64 байта "A" + адрес инструкции "push ebp" в LE*

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

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

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