|
Linux server.jmdstrack.com 3.10.0-1160.119.1.el7.tuxcare.els10.x86_64 #1 SMP Fri Oct 11 21:40:41 UTC 2024 x86_64
/ usr/ bin/ |
|
|
#!/bin/sh
# Do we have the tools we need?
# If no, exit silently.
type gdb >/dev/null 2>&1 || exit 0
type eu-readelf >/dev/null 2>&1 || exit 0
# Do we have coredump?
test -r coredump || {
echo 'No file "coredump" in current directory' >&2
exit 1
}
# Find "cursig: N" and extract N.
# This gets used by abrt-exploitable as a fallback
# if gdb and/or kernel is uncooperative.
# "grep -m1": take the first match (on Linux, every thread has its own
# prstatus struct in the coredump, but the signal number which killed us
# must be the same in all these structs).
SIGNO_OF_THE_COREDUMP=$(eu-readelf -n coredump | grep -m1 -o 'cursig: *[0-9]*' | sed 's/[^0-9]//g')
export SIGNO_OF_THE_COREDUMP
# Run gdb, hiding its messages. Example:
# Missing separate debuginfo for the main executable file
# Core was generated by...
# Program terminated with signal 11, Segmentation fault.
# #0 0x09fa5348 in ?? ()
# We don't want to see all this.
# abrt-exploitable plugin is instructed to create ./exploitable file
# with explanation if severity is >= 4
GDBOUT=$(
gdb --batch \
-ex 'python execfile("/usr/libexec/abrt-gdb-exploitable")' \
-ex 'core-file ./coredump' \
-ex 'abrt-exploitable 4 ./exploitable' \
2>&1 \
) && exit 0
# There was an error. Show the messages.
printf "Error while running gdb:\n%s\n" "$GDBOUT"
exit 1