SIGSEGV создан 32-битным приложением против 64-битного приложенияn - PullRequest
0 голосов
/ 24 марта 2020

Я изучал переполнения буфера и заметил что-то странное.

void vuln()
{
    char buf[180];

    gets(buf);
    puts(buf);

    return;
}

int main()
{
    __gid_t egid;

    setvbuf(stdout, 0x0, 2, 0);
    egid = getegid();
    setresgid(effective_gid, effective_gid, effective_gid);

    puts("You know who are 0xDiablos: ");
    vuln();
    return 0;
}

Я скомпилировал код как 64-битный и 32-битный.

gcc test.c -fno-stack-protector -o 64bit.o
gcc test.c -fno-stack-protector -o 32bit.o -m32 

Я передал более 180 А в качестве входных данных для 32-битного приложения под strace.

--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x41414141} ---
+++ killed by SIGSEGV (core dumped) +++

Затем я выполнил тот же тест на 64-битном приложении под strace.

--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} ---
+++ killed by SIGSEGV (core dumped) +++

Почему 64-битная версия показывает, что недопустимые ссылки на память были NULL, не должно ли это быть 0x41414141, как 32-битная SIGSEGV?

не уверен, имеет ли это значение, но у меня ядро ​​5.5.8.

1 Ответ

0 голосов
/ 24 марта 2020

Почему 64-битная версия показывает, что недопустимые ссылки на память были NULL, не должно ли это быть 0x41414141

Это показывает NULL, потому что процессор фактически не выполняет CALL, потому что адрес назначения не в канонической форме .

Простейшая программа, демонстрирующая это:

int main()
{
  int (*fn)(void) = (int(*)()) 0x4141414141414141;
  return fn();
}
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...