Re: Is GDB just for bug hunting?

[Joel Sherrill <joel@rtems.org>]

On Wed, Apr 14, 2021, 1:48 PM Paul Koning via Gdb <gdb@sourceware.org>
wrote:

>
>
> > On Apr 14, 2021, at 2:37 PM, Jason Long <hack3rcon@yahoo.com> wrote:
> >
> > Thank you for your useful info.
> > If a program is close source, then code review canceled. Thus, how a
> security researcher finds a vulnerability in a program?
>
> Agreed, code review only applies if the source is visible.  More
> precisely, if the source is allowed to be disclosed; researchers looking at
> the code while under NDA does not count and serves no significant purpose.
>
> In those case, you're left with test stimuli and reverse engineering.  For
> "never seen before" defects, you either need luck (an existing test happens
> to catch it) or a different kind of luck (you created a new test that
> happens to catch it) or lots of skill (you saw the issue during a reverse
> engineering session).
>
> GDB can help with reverse engineering.  It's probably not ideal for
> disassembly let alone decompiling, but it does offer disassembly and it
> also gives you insight into the state of the running application and how it
> changes during execution.
>

If you have source, you can use a trick I like. You can look at constant
data in a nice format even for cross compiled programs without attaching to
a target. Sometimes this is a good way to make sure your data structures
are right without really debugging.

I suppose with the Python scripting you could do a lot of you knew the
source. I've always wanted some scripting to analyse the state of an RTEMS
system via gdb to find priority inversions, etc. You could potentially do
some really powerful introspection.

But without application source, things become harder.

--joel



>         paul
>
>