Abnormal presence of code after __stack_chk

I have an 64-bits ELF binary. I don't have its source code, don't know with which parameters it was compiled, and am not allowed to provide it here. The only relevant information I have is that the source is a .c file (so no hand-crafted assembly), compiled through a Makefile.

While reversing this binary using IDA, I stumbled upon an extremely weird construction I have never seen before and absolutely cannot explain. Here is the raw decompilation of one function with IDA syntax:

mov    rax, [rsp var_20]
xor    rax, fs:28h
jnz    location
add    rsp, 28h
pop    rbx
pop    rbp
retn

location:
call    __stack_chk_fail
nop     dword ptr [rax]
db      2Eh
nop     word ptr [rax rax 00000000h]
...then dozens of instructions of normal and functional code

Here, we have a simple canary check, where we return if it is valid, and call __stack_chk_fail otherwise. Everything is perfectly normal. But after this check, there is still assembly, and of fully-functional code.

Looking at the manual of __stack_chk_fail, I made sure that this function does exit the program, and that there is no edge case where it could continue:

Description

The interface __stack_chk_fail() shall abort the function that called it with a message that a stack overflow has been detected. The program that called the function shall then exit.

I also tried to write this small C program, to search for a method to reproduce this:

#include <stdio.h>
#include <stdlib.h>

int foo()
{
        int a = 3;
        printf("%d\n", a);

        return 0;

        int b = 7;
        printf("%d\n", b);
}

int main()
{
        foo();
        return 0;
}

But the code after the return is simply omitted by gcc.

It does not appear either that my binary is vulnerable to a buffer overflow that I could exploit to control rip and jump to the code after the canary check. I also inspected every call and jumps using objdump, and this code seems to never be called.

Could someone explain what is going on? How was this code generated in the first place? Is it a joke from the author of the binary?

CodePudding user response：

I suspect you are looking at padding, followed by an unrelated function that IDA does not have a name for.

To test this hypothesis, I need the following additional information:

The address of the byte immediately after call __stack_chk_fail.
The next higher address that is the target of a call or jump instruction.
A raw hex dump of the bytes in between those two addresses.
The disassembly of four or five instructions starting at the next higher address that is the target of a call or jump instruction.