abrt-gdb-exploitable doc

Denys Vlasenko dvlasenk at redhat.com
Mon Jul 8 14:40:21 UTC 2013


Per Jiri's suggestion, here's a draft documentation
for abrt-gdb-exploitable.

I plan to put it into the header comment, as a minimum.

Where else it needs to be, in your opinion?

================================================


abrt-gdb-exploitable is a gdb plugin written in python.

To load it, use this gdb command:

        python execfile("[/path/to/]abrt-gdb-exploitable")

If it loads successfully, a new gdb command is made available:

        abrt-exploitable [RATING] [OUTFILE]

It can be run on a live process or a core dump.

If process didn't receive any signal, the command will emit a
"Can't get signal no and do exploitability analysis"
message to stderr.

If it is unable to make a guess about the reason why the
signal was received, then it will emit a "Exploitability
analysis came up empty" message to stderr.

Otherwise, it will emit the following message to stdout:

        Likely crash reason: STRING
        Exploitable rating (0-9 scale): N

where STRING explains why the signal was sent, and N
shows how likely is this to be a result of an exploitable
bug in the process. 0 means that it doesn't look dangerous at all,
9 means that the tool is virtually certain it is an exploitable bug.
For example, stack corrupting bugs are much more likely to be exploitable
than division by zero.

If RATING is specified, the message is only emitted if N >= RATING.

If OUTFILE is specified, the message is written to the OUTFILE
instead of stdout.

Of course, the tool is not an AI. It uses a relatively simple
heuristics to decide what has happened.

In order to be able to analyze core dumps, the tool needs that
the kernel which produced the core dump, and the gdb should
be sufficiently recent to provide $_siginfo variable.


More information about the Crash-catcher mailing list