разница в поведении gdb и прямого выполнения при попытке эксплойта с ROP

Недавно я изучил кое-что о ROP.
и выполнял задания на некоторых веб-сайтах, предоставивших исходный код.

#include <stdio.h>
#include <string.h>

int main (int argc, char ** argv){
    char message[20];

    if (argc != 2){
        printf ("Usage: %s <message>\n", argv[0]);
        return -1;
    }

    strcpy (message, argv[1]);
    printf ("Your message: %s\n", message);
    return 0;
}

стек не является исполняемым, поэтому в основном я пытаюсь переопределить адрес возврата адресом системной функции libc, aslr не используется.
Я использую переменную среды SHELL, я нашел адрес с помощью gdb.< br> расстояние между адресом сообщения и обратным адресом составляет 32 байта.
поэтому мой шеллкод следующий: 'a' rep32 + @ofSystem + '4byteJUNK' + @SHELL

Проблема в том, что когда я использую этот шеллкод напрямую, я получаю ошибку сегментации, потому что системная функция вызывается успешно, но не с удобным аргументом "/bin/bash", который предоставляется переменной среды, она вызывается с другой непечатаемой строкой, но когда я использую gdb, я проверяю, что соглашения о вызовах соблюдаются (аргументы передаются в стек), и оболочка успешно вызывается с соответствующей строкой "/bin/bash".
Я не смог найти способ проверить источник проблемы, потому что поведение на gdb и без gdb не то же самое.


exploit reverse-engineering gdb
person T0u4at1-05ema    schedule 09.12.2018    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Проблема в том, что когда я использую этот шеллкод напрямую, я получаю ошибку сегментации, потому что системная функция вызывается успешно, но не с удобным аргументом /bin/bash...

Я не смог найти способ проверить источник проблемы, потому что поведение на gdb и без gdb неодинаково.

Возможно, есть много небольших различий между запуском программы внутри и вне GDB.

Например, GDB имеет тенденцию вызывать программу через полный путь, то есть:

gdb a.out
(gdb) run
... invokes /full/path/to/a.out

Окружение, такое как $_, тоже может быть другим.

Вам нужно проявить немного больше творчества, чтобы решить вашу проблему. Вы можете попытаться свести к минимуму различия (например, использовать /full/path/to/a.out при вызове программы вне GDB) или включить core дамп и копировать ядро, которое будет сгенерировано вне GDB, чтобы вы могли понять, в чем различия (а также найти расстояние вы нашли в GDB -- это, вероятно, будет изменено при работе вне GDB).

person Employed Russian    schedule 09.12.2018