Generation & Analyzing Cores Files or Core Dump

Help out the underdog! Beat the Cybercrime learn how.

Introduction
Core file or Core dump generation is a standard unix feature. A core file is simply a snap-shot of a running process’s memory at the time of generating the core. This is collected by the kernel when it decides to snap the process or task. You can consider this as memory photograph of a process in question. This is generated which process crashes or can be generated on user demand for various purposes example: debugging.

The core contains the memory contents of the process at the point of the seg-fault including its code segment, data segment, stack segment and heap segment. So, we can analyze why the particular crash happened.

This can be generated using following commands:

kill -ABORT <pid>

Under GDB:

gcore <filename>, Or  
generate-core-file <filename>

Parameters that control core file generation

In linux, we have

• Resource limits of the process.
  Every process has various limits associated with it. Read man setrlimit for these. Bash offers a built-in ulimit through which we can edit these. These control the limits of future process spawned from this bash-shell. Core-file max-size (ulimit -c/RLIMIT_CORE) controls the maximum core file size that can be generated when the process snaps.
• Kernel core file pattern.
  Linux offers a proc file hook — /proc/sys/kernel/core_pattern, which contains the format for the name of the core-file. It allows using some format specifiers

%p: pid
 %: '%' is dropped
 %%: output one '%'
 %u: uid
 %g: gid
 %s: signal number
 %t: UNIX time of dump
 %h: hostname
 %e: executable filename
 %: both are dropped

In addition using ‘/’ as part of the names helps to move the core-file location to a directory other than pwd (relative or absolute depending on if start is a ‘/’). In addition, if the patter starts with a pipe (‘|’), linux will pipe the core file into the stdin of the program that follows next! One can permanently set this in a linux machine by adding kernel.core_pattern in /etc/sysctl.conf.

# ulimit -c
0

If the output is 0, this suggest that core dump is disabled by default. Else, you will get resource limits using ‘ulimit –a’

Checking goodness of the core generated fine

ubuntu@:~$ ulimit -c unlimited
ubuntu@:~$ ulimit -a  
core file size                    (blocks, -c) unlimited  
data seg size                           (kbytes, -d) unlimited  
scheduling priority                     (-e) 0  
file size                               (blocks, -f) unlimited  
pending signals                         (-i) 15926  
max locked memory                       (kbytes, -l) 64  
max memory size                         (kbytes, -m) unlimited  
open files                              (-n) 1024  
pipe size                               (512 bytes, -p) 8  
POSIX message queues                    (bytes, -q) 819200  
real-time priority                      (-r) 0  
stack size                              (kbytes, -s) 8192  
cpu time                                (seconds, -t) unlimited  
max user processes                      (-u) 15926  
virtual memory                          (kbytes, -v) unlimited  
file locks                              (-x) unlimited
ubuntu@:~$ vim abc.c  
#include <stdio.h>
int main()  
{
int *ptr = NULL; // NULL pointer.  
*null_p = 10;    // This is invalid assignment.
printf("%s", "SW-VERSION=0.1");  
return 0;  
}
ubuntu@:~$ gcc abc.c -o abc  
ubuntu@:~$ ./abc Segmentation fault (core dumped) ubuntu@:~$ ls abc  abc.c  core

At times due to various reasons core file corrupts and and GDB is not happy with it, to really validate this fact is is important to check the consistence of the core file.

Good Core file
A corrupted core-file will give a different o/p with objdump and will give warnings when tested with readelf. The readelf check is usually more reliable than objdump.

ubuntu@:~$ objdump -a core  
core:     file format elf64-x86-64  
Core  
ubuntu@:~$ readelf -a core 2>&1 | grep -i warn  
ubuntu@:~$

If you have printable stings in your code like Version Number, Software Release, etc. You can print them to validate the correct version of core file you are debugging is like this:

ubuntu@:~$ strings abc | grep SW-VERSION  
SW-VERSION=1.0

GDB

Make sure GDB doesn’t complain about the else it may give warning like “warning: exec file is newer than core file.” or something related to mismatch of core Vs executable.

GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1  
Copyright (C) 2014 Free Software Foundation, Inc.  
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>  
This is free software: you are free to change and redistribute it.  
There is NO WARRANTY, to the extent permitted by law.  Type “show copying”  
and “show warranty” for details.  
This GDB was configured as “x86_64-linux-gnu”.  
Type “show configuration” for configuration details.  
For bug reporting instructions, please see:  
<http://www.gnu.org/software/gdb/bugs/>.  
Find the GDB manual and other documentation resources online at:  
<http://www.gnu.org/software/gdb/documentation/>.  
For help, type “help”.  
Type “apropos word” to search for commands related to “word”…  
Reading symbols from abc…(no debugging symbols found)…done.  
[New LWP 23678]
Core was generated by `./abc’.  
Program terminated with signal SIGSEGV, Segmentation fault.  
#0  0x0000000000400541 in main ()
(gdb) bt
#0  0x0000000000400541 in main ()
(gdb)

Code debugging improves system understanding and its behavior, hence do it often even if you do not get crashes.