什么是Core Dump?怎么使用？

一.首先什么是core dump？

Core的本身意思是内存, Dump的本身意思是扔堆出来。

当我们汪悉开发并且使用 Unix程序时, 有时程序会down了, 却没有任何的提示这时候你可以查看一下有没有样子像困祥乎core.进程号的文件生成, 这个文件是 *** 作系统把程序down掉时的内存内容扔出来生成的, 它可以做为调试程序的参考。

总的来说core dump其实叫核心转储, 它是当程序运行过程中发生异常,  由 *** 作系统把程序当前的内存状况存储在宴雹一个core文件中, 所以叫core dump。

二.怎么使用Core Dump？

首先我们打开Linux下，然后使用： 

#gdb -c core.pid program_name 

就可以进入gdb模式。 

输入where，就可以指出是在哪一行被Down掉，哪个function内，怎么调用等等。 

(gdb) where 

或者输入 bt。 

(gdb) bt 。

经过分析发现系统默认的core文件生成路径是/var/logs，但/var/logs目录并非系统自带的，系统初始安装默认自带的是/var/log，最终导致该系统出现core dump后并没能生成core文件，因此如何查询和修改系统默认的core dump文件生产路径呢？

方法如下：一. 查询core dump文件路径：

方法1： # cat /proc/sys/kerne怠珐糙貉孬股茬瘫长凯l/core_pattern。

方法2： # /sbin/sysctl kernel.core_pattern二. 修改core dump文件路径：

方法1：临时修改/proc/sys/kernel/core_pattern文件，但/proc目录本身是动态加载的，每次系统重启都会重新加载，因此这种方法只能作为临时修改。 /proc/sys/kernel/core_pattern 例：echo ‘/var/log/%e.core.%p’ >/proc/sys/kernel/core_pattern

方法2：永久修改：使戚睁辩用sysctl -w name=value命令。 例：高缺/sbin/sysctl -w kernel.core_pattern=/var/log/%e.core.%p为了更详尽的记录core dump当时的系统状态，可通过以下参数来丰富core文件的命早敬名： %% 单个%字符。

CHECK THE MESSAGE "(core dumped)" and the generation of the 'core' file.

If you do not see the message or the core file on crash,

please run the following command again, and also check the current working

directory.

This command will open a gdb session at the crash point. The coredump file

contains a system's status at the crash point, which includes memory,

register, type of signal on crash (mostly SIGSEGV), etc.

You cannot execute (e.g., using r, ni, si) because the execution was

terminated, but you can still check the memory.

Core was generated by

Program terminated with signal SIGSEGV, Segmentation fault.

This output means that the coredump is generated by './frame-pointer-32',

and the program crashed at 0x8048635 with the signal SIGSEGV.

You can see that the program uses the stack address around 0xffffd5c0,

and the frame pointer (%ebp) has been changed to 0x41414141.

And to check the cause of the crash, let's check what is the current instruction.

x/i means that "examine instruction", and the eip, actually).

Because the value of %ebp is 0x41414141, which is an invalid address,

SIGSEGV was raised on running leave instruction because it will change

%esp = 0x41414141 then run "pop %ebp" (dereferencing 0x41414141).

You already know that this challenge is about changing the frame pointer (%ebp)

to control the execution (return address) at the end.

The important part of launching such attack is to know where the start of my

input buffer is on the stack.

Some of you are suffering the problem that your attack works on the samples

binary but does not work with challenges binarythis is because the stack

layout could be different on each program execution, so the starting address

of your buffer could be different in challenge binary than the sample binary.

To get the exact address in the challenge binary, you can get the 'corefile'

of the challenge binary by running it and generating the crash because

corefile contains the exact content at the crash point. In other words,

if you get the address of your buffer in the corefile, the same address

was being used on its execution!

Let's check how to get that in the corefile.

You can start with the current stack (%esp), however, there are two function

calls (non_main_func() ->input_func()). While your input resides in the

local stack of input_func(), your current execution is on the non_main_func()

(frame-pointer attack returns twice, and crash by invalid %ebp requires

two returns to generate SIGSEGV).

We can presume that stack has moved up little bit, because there is the code for

leaveret, which rolls back the local stack of input_func().

So let's examine the stack values from somewhere below the stack (%esp)

x/100x $esp - 0x200 this command will display upto 100 4-byte integer values

from the address %esp-0x200 (the location 0x200 before the espyou can use +

to see upwards).

While we were injecting the input of "A"*200, which will be lots of 0x41414141,

I cannot see that on the stack. Let's move upwards (pressing the enter again).

Ah, now I can see several 0x41414141s .

It seems the buffer starts at 0xffffd560 (for the samples/frame-pointer-32) binary.

Then, what if I run the program in the challenges directory?

Let's check with the core.

-- GDB --

Core was generated by `../challenges/frame-pointer/frame-pointer-32'.

Program terminated with signal SIGSEGV, Segmentation fault.

Ah, now you can see that the address starts at 0xffffd510 (contains 0x41414141).

Previously, it was 0xffffd560 but now it is 0xffffd510 (changed!).

In a subsequent running of the challenge program, this address value will be

the same if your running command is the same

(i.e., runs ../challenges/frame-pointer/frame-pointer-32,

not in the different path or something).

A shortcut to have a correct address value is that, when you are using

pwntools (writing a python script), the program execution within pwntools

will also generate a corefile to your directory.

---