* Debugging vs Reverse Engineering
[not found] <2065504698.3252109.1695560949235.ref@mail.yahoo.com>
@ 2023-09-24 13:09 ` Jason Long
2023-09-24 13:23 ` Guinevere Larsen
0 siblings, 1 reply; 6+ messages in thread
From: Jason Long @ 2023-09-24 13:09 UTC (permalink / raw)
To: SCOTT FIELDS via Gdb
[-- Attachment #1: Type: text/plain, Size: 253 bytes --]
Hello folks,I have two questions:
1- Can a debugger like GDB be used to find the vulnerability?
2- When a hacker finds a vulnerability in a program, has that hacker used debugging techniques or reverse engineering?
Any idea welcomed.
Thank you.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Debugging vs Reverse Engineering
2023-09-24 13:09 ` Debugging vs Reverse Engineering Jason Long
@ 2023-09-24 13:23 ` Guinevere Larsen
2023-09-24 18:12 ` Jason Long
0 siblings, 1 reply; 6+ messages in thread
From: Guinevere Larsen @ 2023-09-24 13:23 UTC (permalink / raw)
To: Jason Long, SCOTT FIELDS via Gdb
On 24/09/2023 15:09, Jason Long via Gdb wrote:
> Hello folks,I have two questions:
Hello, thanks for the questions!
> 1- Can a debugger like GDB be used to find the vulnerability?
Yes, you could use GDB to find some security vulnerabilities, though it
is hardly the best tool for this job. The kind of stuff you'd find with
GDB is a logic mistake that leads to information leaks or similar. In my
experience, though, GDB is more useful to look at one unexpected
behavior and figure out if that leads to a security vulnerability or
not, rather than going form scratch and giving the program unexpected or
malicious inputs.
>
> 2- When a hacker finds a vulnerability in a program, has that hacker used debugging techniques or reverse engineering?
Reverse engineering doesn't necessarily have to do with security.
Reverse engineering is the act of getting something that is not
understood and trying to understand it without having access to any kind
of documentation. I don't recommend running unknown binaries in your
machine, since GDB doesn't provide any security, but if you are doing
that, stepping slowly and trying to understand how the program works,
you are doing reverse engineering. It doesn't have to relate at all to
security.
With that in mind, the answer to your question is "it depends". The
stuff you can find with GDB alone will always involve debugging
techinques, but with regards to reverse engineering techniques, the
question is does the vulnerability come in from the fact that the
attacker knows the internal mechanisms for the program or not? If it
does, then yes you could say you found a vulnerability by reverse
engineering.
> Any idea welcomed.
>
> Thank you.
>
I hope this helps!
--
Cheers,
Guinevere Larsen
She/Her/Hers
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Debugging vs Reverse Engineering
2023-09-24 13:23 ` Guinevere Larsen
@ 2023-09-24 18:12 ` Jason Long
2023-09-26 13:33 ` Guinevere Larsen
0 siblings, 1 reply; 6+ messages in thread
From: Jason Long @ 2023-09-24 18:12 UTC (permalink / raw)
To: Guinevere Larsen, SCOTT FIELDS via Gdb
[-- Attachment #1: Type: text/plain, Size: 2354 bytes --]
Hi Larsen,Thank you so much for your reply.Your answer raised other questions in my mind.
What do you mean by "Giving the program unexpected or malicious inputs."? Do you mean Fuzzing?
Please take a look at these vulnerabilities:
https://www.cvedetails.com/cve/CVE-2022-31705/
https://www.cvedetails.com/cve/CVE-2023-32209/
What technique did the person who found these vulnerabilities use? Debugging or Reverse Engineering?
On Sun, Sep 24, 2023 at 4:53 PM, Guinevere Larsen<blarsen@redhat.com> wrote: On 24/09/2023 15:09, Jason Long via Gdb wrote:
> Hello folks,I have two questions:
Hello, thanks for the questions!
> 1- Can a debugger like GDB be used to find the vulnerability?
Yes, you could use GDB to find some security vulnerabilities, though it
is hardly the best tool for this job. The kind of stuff you'd find with
GDB is a logic mistake that leads to information leaks or similar. In my
experience, though, GDB is more useful to look at one unexpected
behavior and figure out if that leads to a security vulnerability or
not, rather than going form scratch and giving the program unexpected or
malicious inputs.
>
> 2- When a hacker finds a vulnerability in a program, has that hacker used debugging techniques or reverse engineering?
Reverse engineering doesn't necessarily have to do with security.
Reverse engineering is the act of getting something that is not
understood and trying to understand it without having access to any kind
of documentation. I don't recommend running unknown binaries in your
machine, since GDB doesn't provide any security, but if you are doing
that, stepping slowly and trying to understand how the program works,
you are doing reverse engineering. It doesn't have to relate at all to
security.
With that in mind, the answer to your question is "it depends". The
stuff you can find with GDB alone will always involve debugging
techinques, but with regards to reverse engineering techniques, the
question is does the vulnerability come in from the fact that the
attacker knows the internal mechanisms for the program or not? If it
does, then yes you could say you found a vulnerability by reverse
engineering.
> Any idea welcomed.
>
> Thank you.
>
I hope this helps!
--
Cheers,
Guinevere Larsen
She/Her/Hers
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Debugging vs Reverse Engineering
2023-09-24 18:12 ` Jason Long
@ 2023-09-26 13:33 ` Guinevere Larsen
2023-09-27 8:24 ` Jason Long
0 siblings, 1 reply; 6+ messages in thread
From: Guinevere Larsen @ 2023-09-26 13:33 UTC (permalink / raw)
To: Jason Long, SCOTT FIELDS via Gdb
On 24/09/2023 20:12, Jason Long wrote:
>
> Hi Larsen,
You can call me Guinevere, or Gwen :)
> Thank you so much for your reply.
> Your answer raised other questions in my mind.
> What do you mean by "Giving the program unexpected or malicious
> inputs."? Do you mean Fuzzing?
Fuzzing is one way to get a malicious input, but not the only one. For
instance, look at the following example code:
char* get_name() {
char* name;
int name_size;
printf("Please enter the length of your name:\n");
scanf("%d", &name_size);
/* Vulnerable code here: */
name = (char*) malloc (name_size * sizeof(char));
printf("enter your name:\n");
scanf("%s", name);
return name;
}
int main() {
printf("Hello %s", get_name());
}
For people used to looking for vulnerabilities, this has a very obvious
issue in not verifying the size of input when reading a string, so you
can just visually see that the input "1 AAAAAAAA" is enough to crash the
program, so that would also be considered a malicious input. However, if
you have a very big codebase, more complicated situations, or just
aren't used to it, you might need a fuzzer to generate random inputs to
see what makes your program crash.
The way you get to the answer is not important, the reason something is
called a "malicious input" is if the person who designed it had
malicious (evil) intent.
>
> Please take a look at these vulnerabilities:
> https://www.cvedetails.com/cve/CVE-2022-31705/
>
> https://www.cvedetails.com/cve/CVE-2023-32209/
>
> What technique did the person who found these vulnerabilities use?
> Debugging or Reverse Engineering?
There isn't really a way to tell after the fact. I am reasonably sure
the firefox one wasn't reverse engineering, since all the code is open
source, so you don't need to reverse engineer it.
Quite likely both cases were just a fuzzer, and then some debugging was
involved to understand exactly why the program crashed and if it was
indeed a vulnerability or not, but there is no way to tell after the
fact, and honestly if it was a real vulnerability, I don't think it
really matters.
If you don't mind, why are you so interested in the distinction? I might
be able to explain better in that case.
--
Cheers,
Guinevere Larsen
She/Her/Hers
>
>
>
> On Sun, Sep 24, 2023 at 4:53 PM, Guinevere Larsen
> <blarsen@redhat.com> wrote:
> On 24/09/2023 15:09, Jason Long via Gdb wrote:
> > Hello folks,I have two questions:
> Hello, thanks for the questions!
> > 1- Can a debugger like GDB be used to find the vulnerability?
>
> Yes, you could use GDB to find some security vulnerabilities,
> though it
> is hardly the best tool for this job. The kind of stuff you'd find
> with
> GDB is a logic mistake that leads to information leaks or similar.
> In my
> experience, though, GDB is more useful to look at one unexpected
> behavior and figure out if that leads to a security vulnerability or
> not, rather than going form scratch and giving the program
> unexpected or
> malicious inputs.
>
> >
> > 2- When a hacker finds a vulnerability in a program, has that
> hacker used debugging techniques or reverse engineering?
>
> Reverse engineering doesn't necessarily have to do with security.
> Reverse engineering is the act of getting something that is not
> understood and trying to understand it without having access to
> any kind
> of documentation. I don't recommend running unknown binaries in your
> machine, since GDB doesn't provide any security, but if you are doing
> that, stepping slowly and trying to understand how the program works,
> you are doing reverse engineering. It doesn't have to relate at
> all to
> security.
>
> With that in mind, the answer to your question is "it depends". The
> stuff you can find with GDB alone will always involve debugging
> techinques, but with regards to reverse engineering techniques, the
> question is does the vulnerability come in from the fact that the
> attacker knows the internal mechanisms for the program or not? If it
> does, then yes you could say you found a vulnerability by reverse
>
> engineering.
>
> > Any idea welcomed.
> >
> > Thank you.
>
> >
> I hope this helps!
>
> --
> Cheers,
> Guinevere Larsen
> She/Her/Hers
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Debugging vs Reverse Engineering
2023-09-26 13:33 ` Guinevere Larsen
@ 2023-09-27 8:24 ` Jason Long
2023-09-27 8:31 ` Guinevere Larsen
0 siblings, 1 reply; 6+ messages in thread
From: Jason Long @ 2023-09-27 8:24 UTC (permalink / raw)
To: SCOTT FIELDS via Gdb, Guinevere Larsen
Hi Gwen,
Thanks again.
Can I send you a private email?
On Tuesday, September 26, 2023 at 05:03:51 PM GMT+3:30, Guinevere Larsen <blarsen@redhat.com> wrote:
On 24/09/2023 20:12, Jason Long wrote:
>
> Hi Larsen,
You can call me Guinevere, or Gwen :)
> Thank you so much for your reply.
> Your answer raised other questions in my mind.
> What do you mean by "Giving the program unexpected or malicious
> inputs."? Do you mean Fuzzing?
Fuzzing is one way to get a malicious input, but not the only one. For
instance, look at the following example code:
char* get_name() {
char* name;
int name_size;
printf("Please enter the length of your name:\n");
scanf("%d", &name_size);
/* Vulnerable code here: */
name = (char*) malloc (name_size * sizeof(char));
printf("enter your name:\n");
scanf("%s", name);
return name;
}
int main() {
printf("Hello %s", get_name());
}
For people used to looking for vulnerabilities, this has a very obvious
issue in not verifying the size of input when reading a string, so you
can just visually see that the input "1 AAAAAAAA" is enough to crash the
program, so that would also be considered a malicious input. However, if
you have a very big codebase, more complicated situations, or just
aren't used to it, you might need a fuzzer to generate random inputs to
see what makes your program crash.
The way you get to the answer is not important, the reason something is
called a "malicious input" is if the person who designed it had
malicious (evil) intent.
>
> Please take a look at these vulnerabilities:
> https://www.cvedetails.com/cve/CVE-2022-31705/
>
> https://www.cvedetails.com/cve/CVE-2023-32209/
>
> What technique did the person who found these vulnerabilities use?
> Debugging or Reverse Engineering?
There isn't really a way to tell after the fact. I am reasonably sure
the firefox one wasn't reverse engineering, since all the code is open
source, so you don't need to reverse engineer it.
Quite likely both cases were just a fuzzer, and then some debugging was
involved to understand exactly why the program crashed and if it was
indeed a vulnerability or not, but there is no way to tell after the
fact, and honestly if it was a real vulnerability, I don't think it
really matters.
If you don't mind, why are you so interested in the distinction? I might
be able to explain better in that case.
--
Cheers,
Guinevere Larsen
She/Her/Hers
>
>
>
> On Sun, Sep 24, 2023 at 4:53 PM, Guinevere Larsen
> <blarsen@redhat.com> wrote:
> On 24/09/2023 15:09, Jason Long via Gdb wrote:
> > Hello folks,I have two questions:
> Hello, thanks for the questions!
> > 1- Can a debugger like GDB be used to find the vulnerability?
>
> Yes, you could use GDB to find some security vulnerabilities,
> though it
> is hardly the best tool for this job. The kind of stuff you'd find
> with
> GDB is a logic mistake that leads to information leaks or similar.
> In my
> experience, though, GDB is more useful to look at one unexpected
> behavior and figure out if that leads to a security vulnerability or
> not, rather than going form scratch and giving the program
> unexpected or
> malicious inputs.
>
> >
> > 2- When a hacker finds a vulnerability in a program, has that
> hacker used debugging techniques or reverse engineering?
>
> Reverse engineering doesn't necessarily have to do with security.
> Reverse engineering is the act of getting something that is not
> understood and trying to understand it without having access to
> any kind
> of documentation. I don't recommend running unknown binaries in your
> machine, since GDB doesn't provide any security, but if you are doing
> that, stepping slowly and trying to understand how the program works,
> you are doing reverse engineering. It doesn't have to relate at
> all to
> security.
>
> With that in mind, the answer to your question is "it depends". The
> stuff you can find with GDB alone will always involve debugging
> techinques, but with regards to reverse engineering techniques, the
> question is does the vulnerability come in from the fact that the
> attacker knows the internal mechanisms for the program or not? If it
> does, then yes you could say you found a vulnerability by reverse
>
> engineering.
>
> > Any idea welcomed.
> >
> > Thank you.
>
> >
> I hope this helps!
>
> --
> Cheers,
> Guinevere Larsen
> She/Her/Hers
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Debugging vs Reverse Engineering
2023-09-27 8:24 ` Jason Long
@ 2023-09-27 8:31 ` Guinevere Larsen
0 siblings, 0 replies; 6+ messages in thread
From: Guinevere Larsen @ 2023-09-27 8:31 UTC (permalink / raw)
To: Jason Long, SCOTT FIELDS via Gdb
On 27/09/2023 10:24, Jason Long wrote:
> Hi Gwen,
> Thanks again.
> Can I send you a private email?
Sure, go ahead
--
Cheers,
Guinevere Larsen
She/Her/Hers
>
>
> On Tuesday, September 26, 2023 at 05:03:51 PM GMT+3:30, Guinevere Larsen <blarsen@redhat.com> wrote:
>
> On 24/09/2023 20:12, Jason Long wrote:
>> Hi Larsen,
> You can call me Guinevere, or Gwen :)
>> Thank you so much for your reply.
>> Your answer raised other questions in my mind.
>> What do you mean by "Giving the program unexpected or malicious
>> inputs."? Do you mean Fuzzing?
> Fuzzing is one way to get a malicious input, but not the only one. For
> instance, look at the following example code:
>
> char* get_name() {
> char* name;
> int name_size;
> printf("Please enter the length of your name:\n");
> scanf("%d", &name_size);
> /* Vulnerable code here: */
> name = (char*) malloc (name_size * sizeof(char));
> printf("enter your name:\n");
> scanf("%s", name);
> return name;
> }
>
> int main() {
> printf("Hello %s", get_name());
> }
>
> For people used to looking for vulnerabilities, this has a very obvious
> issue in not verifying the size of input when reading a string, so you
> can just visually see that the input "1 AAAAAAAA" is enough to crash the
> program, so that would also be considered a malicious input. However, if
> you have a very big codebase, more complicated situations, or just
> aren't used to it, you might need a fuzzer to generate random inputs to
> see what makes your program crash.
>
> The way you get to the answer is not important, the reason something is
> called a "malicious input" is if the person who designed it had
> malicious (evil) intent.
>
>> Please take a look at these vulnerabilities:
>> https://www.cvedetails.com/cve/CVE-2022-31705/
>>
>> https://www.cvedetails.com/cve/CVE-2023-32209/
>>
>> What technique did the person who found these vulnerabilities use?
>> Debugging or Reverse Engineering?
> There isn't really a way to tell after the fact. I am reasonably sure
> the firefox one wasn't reverse engineering, since all the code is open
> source, so you don't need to reverse engineer it.
>
> Quite likely both cases were just a fuzzer, and then some debugging was
> involved to understand exactly why the program crashed and if it was
> indeed a vulnerability or not, but there is no way to tell after the
> fact, and honestly if it was a real vulnerability, I don't think it
> really matters.
>
> If you don't mind, why are you so interested in the distinction? I might
> be able to explain better in that case.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-09-27 8:31 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <2065504698.3252109.1695560949235.ref@mail.yahoo.com>
2023-09-24 13:09 ` Debugging vs Reverse Engineering Jason Long
2023-09-24 13:23 ` Guinevere Larsen
2023-09-24 18:12 ` Jason Long
2023-09-26 13:33 ` Guinevere Larsen
2023-09-27 8:24 ` Jason Long
2023-09-27 8:31 ` Guinevere Larsen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).