* 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).