OllyDbg vs x64dbg – Is there anything in OllyDbg that is not available in x64dbg?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP

up vote
7
down vote

favorite

2

OllyDbg had been nice in the past, but as it was frozen, x32dbg/x64dbg era came.
However, some people still use OllyDbg. Are there any reasons to use the old OllyDbg still? Doesn’t x32dbg/64dbg covers all needed things?

share|improve this question

    up vote
    7
    down vote

    favorite

    2

    OllyDbg had been nice in the past, but as it was frozen, x32dbg/x64dbg era came.
    However, some people still use OllyDbg. Are there any reasons to use the old OllyDbg still? Doesn’t x32dbg/64dbg covers all needed things?

    share|improve this question

      up vote
      7
      down vote

      favorite

      2

      up vote
      7
      down vote

      favorite

      2
      2

      OllyDbg had been nice in the past, but as it was frozen, x32dbg/x64dbg era came.
      However, some people still use OllyDbg. Are there any reasons to use the old OllyDbg still? Doesn’t x32dbg/64dbg covers all needed things?

      share|improve this question

      OllyDbg had been nice in the past, but as it was frozen, x32dbg/x64dbg era came.
      However, some people still use OllyDbg. Are there any reasons to use the old OllyDbg still? Doesn’t x32dbg/64dbg covers all needed things?

      ollydbg debuggers x64dbg

      share|improve this question

      share|improve this question

      share|improve this question

      share|improve this question

      edited Nov 30 at 8:20

      asked Nov 29 at 16:46

      T.Todua

      22419

      22419

          3 Answers
          3

          active

          oldest

          votes

          up vote
          10
          down vote

          accepted

          Debugging software with a combination of managed and unmanaged code:

          Ollydbg debugs and runs managed code very well (of course in this case it only runs as a native debugger and not like DnSpy which shows the .Net functions and code perfectly).

          There are times when, if the malware makes a lot of calls to unmanaged code (native code DLLs) it is far more convenient to use a debugger like OLLY to track down the transition to the native DLLs.

          This is not possible in x32dbg/x64dbg at all and it crashes when dealing with managed code.

          Compatibility with 32-bit systems:

          ScyllaHide for x32dbg is not very good and fails on Windows 7 and Windows 10 (32-bit). (It absolutely does not work on Windows XP SP3 and keeps giving us the UNKNOWN SYSCALL error – So I am not even bothering to mention Win XP in this context).

          I see that there is an open issue on GitHub regarding this (for 32-bit Windows 7 and Windows 10), but the only answer there seems to advise that we should migrate to 64-bit Windows.

          While this is true, there are many times where we need to work on 32-bit systems for a variety of reasons.

          Without a good system in place to hide the debugger from the anti-debugg calls of most malware, the debugger is basically of very little use.

          Scripting Engines:

          The plugins for scripting on x32dbg/x64dbg are very slow when compared to the Olly Script engine. So is the python scripting.

          Patching Issues:
          In my experience, the patching using x32dbg/x64dbg is very buggy when dealing with some executable and I find that I need to revert back to Olly to ensure that the executable gets reliably patched.

          Issue with Updates:
          Every update of the x32dbg/x64dbg debuggers brings its own bugs with it and in a way, this reminds one of Windows 10 with its constant updates 😉

          When debugging a target, we should really not need to keep thinking constantly as to whether it was a fault in the debugger or the target program that contributed to the crash!

          In an nutshell, the main problem seems to be that too many programmers have been and are (still) working on x32dbg/x64dbg each in their own programming styles and there seems to a lack of direction in the overall structure of the debugger.

          This was not the case for Olly where a single programmer had created it and therefore has a clean crisp structure that is very difficult to define or described in simple terms.

          This is not to say that x32dbg/x64dbg is bad. Just saying that there is a lot more room for improvement to make it run as reliably as Olly.

          These are just a few of the issues that I could remember the top of my head that constantly caused me to dust my old Olly and re-use it again and again.

          share|improve this answer

          • Could you elaborate on the issues with x64dbg (patching/crashes/whatever). The current focus is stability and I feel things have been pretty good as of recently. Also for 32 bit systems you can easily use TitanHide which uses a kernel driver instead of user mode hooks. It often happens that people say that x64dbg is “unstable” because they used it in 2016 and didn’t report any issues or ever try again.
            – mrexodia
            Dec 1 at 23:04

          up vote
          3
          down vote

          Outside of maybe custom plug-ins or perhaps buried features and usability differences, there’s really no incentive to use OllyDbg over x32dbg/x64dbg. Since OllyDbg was the debugger of choice for so many years, it will take awhile to run its course.

          That said, it’s still extremely capable for a 32-bit debugger with a rich support/plug-in ecosystem (even if a bit outdated now), so there’s absolutely nothing wrong with using it if you prefer it over any other debugger for 32-bit applications.

          Personally, I migrated to x32dbg/x64dbg quite awhile back and haven’t missed OllyDbg ever since. In fact, the switch is so easy that one could presumably get up to snuff with using debuggers via OllyDbg, then bop right over to x32dbg/x64dbg with very little differences to compensate for.

          share|improve this answer

            up vote
            1
            down vote

            Disclaimer: I am the main developer of x64dbg, take that into account 🙂

            I would say that the main difference between OllyDbg and x64dbg is that there is no 64 bit (os) support at all in OllyDbg. If you are working on a modern system I think x64dbg is a better choice because it was designed to work there.

            That said, x64dbg isn’t better in all aspects. One main difference is that OllyDbg has a very solid tracing system, whereas x64dbg has something, but still requires a lot of work. I am using x64dbg for my job, but I am familiar with the source code so I can make improvements as I need them.

            Another big difference is that you can contribute to x64dbg directly. Either by reporting bugs, or simply fixing them yourself. To me this is a big advantage, as many plugins for OllyDbg hook the internal functions to fix bugs or add features.

            share|improve this answer

            • ouch, i didn’t know the person helped me with other questions too, is the main dev of x64. thnx 😉
              – T.Todua
              Dec 2 at 9:55

            Your Answer

            StackExchange.ready(function() {
            var channelOptions = {
            tags: “”.split(” “),
            id: “489”
            };
            initTagRenderer(“”.split(” “), “”.split(” “), channelOptions);

            StackExchange.using(“externalEditor”, function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using(“snippets”, function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: ‘answer’,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: “”,
            imageUploader: {
            brandingHtml: “Powered by u003ca class=”icon-imgur-white” href=”https://imgur.com/”u003eu003c/au003e”,
            contentPolicyHtml: “User contributions licensed under u003ca href=”https://creativecommons.org/licenses/by-sa/3.0/”u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href=”https://stackoverflow.com/legal/content-policy”u003e(content policy)u003c/au003e”,
            allowUrls: true
            },
            noCode: true, onDemand: true,
            discardSelector: “.discard-answer”
            ,immediatelyShowMarkdownHelp:true
            });

            }
            });

            draft saved
            draft discarded

            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin(‘.new-post-login’, ‘https%3a%2f%2freverseengineering.stackexchange.com%2fquestions%2f20004%2follydbg-vs-x64dbg-is-there-anything-in-ollydbg-that-is-not-available-in-x64dbg%23new-answer’, ‘question_page’);
            }
            );

            Post as a guest

            Required, but never shown

            3 Answers
            3

            active

            oldest

            votes

            3 Answers
            3

            active

            oldest

            votes

            active

            oldest

            votes

            active

            oldest

            votes

            up vote
            10
            down vote

            accepted

            Debugging software with a combination of managed and unmanaged code:

            Ollydbg debugs and runs managed code very well (of course in this case it only runs as a native debugger and not like DnSpy which shows the .Net functions and code perfectly).

            There are times when, if the malware makes a lot of calls to unmanaged code (native code DLLs) it is far more convenient to use a debugger like OLLY to track down the transition to the native DLLs.

            This is not possible in x32dbg/x64dbg at all and it crashes when dealing with managed code.

            Compatibility with 32-bit systems:

            ScyllaHide for x32dbg is not very good and fails on Windows 7 and Windows 10 (32-bit). (It absolutely does not work on Windows XP SP3 and keeps giving us the UNKNOWN SYSCALL error – So I am not even bothering to mention Win XP in this context).

            I see that there is an open issue on GitHub regarding this (for 32-bit Windows 7 and Windows 10), but the only answer there seems to advise that we should migrate to 64-bit Windows.

            While this is true, there are many times where we need to work on 32-bit systems for a variety of reasons.

            Without a good system in place to hide the debugger from the anti-debugg calls of most malware, the debugger is basically of very little use.

            Scripting Engines:

            The plugins for scripting on x32dbg/x64dbg are very slow when compared to the Olly Script engine. So is the python scripting.

            Patching Issues:
            In my experience, the patching using x32dbg/x64dbg is very buggy when dealing with some executable and I find that I need to revert back to Olly to ensure that the executable gets reliably patched.

            Issue with Updates:
            Every update of the x32dbg/x64dbg debuggers brings its own bugs with it and in a way, this reminds one of Windows 10 with its constant updates 😉

            When debugging a target, we should really not need to keep thinking constantly as to whether it was a fault in the debugger or the target program that contributed to the crash!

            In an nutshell, the main problem seems to be that too many programmers have been and are (still) working on x32dbg/x64dbg each in their own programming styles and there seems to a lack of direction in the overall structure of the debugger.

            This was not the case for Olly where a single programmer had created it and therefore has a clean crisp structure that is very difficult to define or described in simple terms.

            This is not to say that x32dbg/x64dbg is bad. Just saying that there is a lot more room for improvement to make it run as reliably as Olly.

            These are just a few of the issues that I could remember the top of my head that constantly caused me to dust my old Olly and re-use it again and again.

            share|improve this answer

            • Could you elaborate on the issues with x64dbg (patching/crashes/whatever). The current focus is stability and I feel things have been pretty good as of recently. Also for 32 bit systems you can easily use TitanHide which uses a kernel driver instead of user mode hooks. It often happens that people say that x64dbg is “unstable” because they used it in 2016 and didn’t report any issues or ever try again.
              – mrexodia
              Dec 1 at 23:04

            up vote
            10
            down vote

            accepted

            Debugging software with a combination of managed and unmanaged code:

            Ollydbg debugs and runs managed code very well (of course in this case it only runs as a native debugger and not like DnSpy which shows the .Net functions and code perfectly).

            There are times when, if the malware makes a lot of calls to unmanaged code (native code DLLs) it is far more convenient to use a debugger like OLLY to track down the transition to the native DLLs.

            This is not possible in x32dbg/x64dbg at all and it crashes when dealing with managed code.

            Compatibility with 32-bit systems:

            ScyllaHide for x32dbg is not very good and fails on Windows 7 and Windows 10 (32-bit). (It absolutely does not work on Windows XP SP3 and keeps giving us the UNKNOWN SYSCALL error – So I am not even bothering to mention Win XP in this context).

            I see that there is an open issue on GitHub regarding this (for 32-bit Windows 7 and Windows 10), but the only answer there seems to advise that we should migrate to 64-bit Windows.

            While this is true, there are many times where we need to work on 32-bit systems for a variety of reasons.

            Without a good system in place to hide the debugger from the anti-debugg calls of most malware, the debugger is basically of very little use.

            Scripting Engines:

            The plugins for scripting on x32dbg/x64dbg are very slow when compared to the Olly Script engine. So is the python scripting.

            Patching Issues:
            In my experience, the patching using x32dbg/x64dbg is very buggy when dealing with some executable and I find that I need to revert back to Olly to ensure that the executable gets reliably patched.

            Issue with Updates:
            Every update of the x32dbg/x64dbg debuggers brings its own bugs with it and in a way, this reminds one of Windows 10 with its constant updates 😉

            When debugging a target, we should really not need to keep thinking constantly as to whether it was a fault in the debugger or the target program that contributed to the crash!

            In an nutshell, the main problem seems to be that too many programmers have been and are (still) working on x32dbg/x64dbg each in their own programming styles and there seems to a lack of direction in the overall structure of the debugger.

            This was not the case for Olly where a single programmer had created it and therefore has a clean crisp structure that is very difficult to define or described in simple terms.

            This is not to say that x32dbg/x64dbg is bad. Just saying that there is a lot more room for improvement to make it run as reliably as Olly.

            These are just a few of the issues that I could remember the top of my head that constantly caused me to dust my old Olly and re-use it again and again.

            share|improve this answer

            • Could you elaborate on the issues with x64dbg (patching/crashes/whatever). The current focus is stability and I feel things have been pretty good as of recently. Also for 32 bit systems you can easily use TitanHide which uses a kernel driver instead of user mode hooks. It often happens that people say that x64dbg is “unstable” because they used it in 2016 and didn’t report any issues or ever try again.
              – mrexodia
              Dec 1 at 23:04

            up vote
            10
            down vote

            accepted

            up vote
            10
            down vote

            accepted

            Debugging software with a combination of managed and unmanaged code:

            Ollydbg debugs and runs managed code very well (of course in this case it only runs as a native debugger and not like DnSpy which shows the .Net functions and code perfectly).

            There are times when, if the malware makes a lot of calls to unmanaged code (native code DLLs) it is far more convenient to use a debugger like OLLY to track down the transition to the native DLLs.

            This is not possible in x32dbg/x64dbg at all and it crashes when dealing with managed code.

            Compatibility with 32-bit systems:

            ScyllaHide for x32dbg is not very good and fails on Windows 7 and Windows 10 (32-bit). (It absolutely does not work on Windows XP SP3 and keeps giving us the UNKNOWN SYSCALL error – So I am not even bothering to mention Win XP in this context).

            I see that there is an open issue on GitHub regarding this (for 32-bit Windows 7 and Windows 10), but the only answer there seems to advise that we should migrate to 64-bit Windows.

            While this is true, there are many times where we need to work on 32-bit systems for a variety of reasons.

            Without a good system in place to hide the debugger from the anti-debugg calls of most malware, the debugger is basically of very little use.

            Scripting Engines:

            The plugins for scripting on x32dbg/x64dbg are very slow when compared to the Olly Script engine. So is the python scripting.

            Patching Issues:
            In my experience, the patching using x32dbg/x64dbg is very buggy when dealing with some executable and I find that I need to revert back to Olly to ensure that the executable gets reliably patched.

            Issue with Updates:
            Every update of the x32dbg/x64dbg debuggers brings its own bugs with it and in a way, this reminds one of Windows 10 with its constant updates 😉

            When debugging a target, we should really not need to keep thinking constantly as to whether it was a fault in the debugger or the target program that contributed to the crash!

            In an nutshell, the main problem seems to be that too many programmers have been and are (still) working on x32dbg/x64dbg each in their own programming styles and there seems to a lack of direction in the overall structure of the debugger.

            This was not the case for Olly where a single programmer had created it and therefore has a clean crisp structure that is very difficult to define or described in simple terms.

            This is not to say that x32dbg/x64dbg is bad. Just saying that there is a lot more room for improvement to make it run as reliably as Olly.

            These are just a few of the issues that I could remember the top of my head that constantly caused me to dust my old Olly and re-use it again and again.

            share|improve this answer

            Debugging software with a combination of managed and unmanaged code:

            Ollydbg debugs and runs managed code very well (of course in this case it only runs as a native debugger and not like DnSpy which shows the .Net functions and code perfectly).

            There are times when, if the malware makes a lot of calls to unmanaged code (native code DLLs) it is far more convenient to use a debugger like OLLY to track down the transition to the native DLLs.

            This is not possible in x32dbg/x64dbg at all and it crashes when dealing with managed code.

            Compatibility with 32-bit systems:

            ScyllaHide for x32dbg is not very good and fails on Windows 7 and Windows 10 (32-bit). (It absolutely does not work on Windows XP SP3 and keeps giving us the UNKNOWN SYSCALL error – So I am not even bothering to mention Win XP in this context).

            I see that there is an open issue on GitHub regarding this (for 32-bit Windows 7 and Windows 10), but the only answer there seems to advise that we should migrate to 64-bit Windows.

            While this is true, there are many times where we need to work on 32-bit systems for a variety of reasons.

            Without a good system in place to hide the debugger from the anti-debugg calls of most malware, the debugger is basically of very little use.

            Scripting Engines:

            The plugins for scripting on x32dbg/x64dbg are very slow when compared to the Olly Script engine. So is the python scripting.

            Patching Issues:
            In my experience, the patching using x32dbg/x64dbg is very buggy when dealing with some executable and I find that I need to revert back to Olly to ensure that the executable gets reliably patched.

            Issue with Updates:
            Every update of the x32dbg/x64dbg debuggers brings its own bugs with it and in a way, this reminds one of Windows 10 with its constant updates 😉

            When debugging a target, we should really not need to keep thinking constantly as to whether it was a fault in the debugger or the target program that contributed to the crash!

            In an nutshell, the main problem seems to be that too many programmers have been and are (still) working on x32dbg/x64dbg each in their own programming styles and there seems to a lack of direction in the overall structure of the debugger.

            This was not the case for Olly where a single programmer had created it and therefore has a clean crisp structure that is very difficult to define or described in simple terms.

            This is not to say that x32dbg/x64dbg is bad. Just saying that there is a lot more room for improvement to make it run as reliably as Olly.

            These are just a few of the issues that I could remember the top of my head that constantly caused me to dust my old Olly and re-use it again and again.

            share|improve this answer

            share|improve this answer

            share|improve this answer

            edited Nov 29 at 22:15

            T.Todua

            22419

            22419

            answered Nov 29 at 20:48

            Clint

            1163

            1163

            • Could you elaborate on the issues with x64dbg (patching/crashes/whatever). The current focus is stability and I feel things have been pretty good as of recently. Also for 32 bit systems you can easily use TitanHide which uses a kernel driver instead of user mode hooks. It often happens that people say that x64dbg is “unstable” because they used it in 2016 and didn’t report any issues or ever try again.
              – mrexodia
              Dec 1 at 23:04

            • Could you elaborate on the issues with x64dbg (patching/crashes/whatever). The current focus is stability and I feel things have been pretty good as of recently. Also for 32 bit systems you can easily use TitanHide which uses a kernel driver instead of user mode hooks. It often happens that people say that x64dbg is “unstable” because they used it in 2016 and didn’t report any issues or ever try again.
              – mrexodia
              Dec 1 at 23:04

            Could you elaborate on the issues with x64dbg (patching/crashes/whatever). The current focus is stability and I feel things have been pretty good as of recently. Also for 32 bit systems you can easily use TitanHide which uses a kernel driver instead of user mode hooks. It often happens that people say that x64dbg is “unstable” because they used it in 2016 and didn’t report any issues or ever try again.
            – mrexodia
            Dec 1 at 23:04

            Could you elaborate on the issues with x64dbg (patching/crashes/whatever). The current focus is stability and I feel things have been pretty good as of recently. Also for 32 bit systems you can easily use TitanHide which uses a kernel driver instead of user mode hooks. It often happens that people say that x64dbg is “unstable” because they used it in 2016 and didn’t report any issues or ever try again.
            – mrexodia
            Dec 1 at 23:04

            up vote
            3
            down vote

            Outside of maybe custom plug-ins or perhaps buried features and usability differences, there’s really no incentive to use OllyDbg over x32dbg/x64dbg. Since OllyDbg was the debugger of choice for so many years, it will take awhile to run its course.

            That said, it’s still extremely capable for a 32-bit debugger with a rich support/plug-in ecosystem (even if a bit outdated now), so there’s absolutely nothing wrong with using it if you prefer it over any other debugger for 32-bit applications.

            Personally, I migrated to x32dbg/x64dbg quite awhile back and haven’t missed OllyDbg ever since. In fact, the switch is so easy that one could presumably get up to snuff with using debuggers via OllyDbg, then bop right over to x32dbg/x64dbg with very little differences to compensate for.

            share|improve this answer

              up vote
              3
              down vote

              Outside of maybe custom plug-ins or perhaps buried features and usability differences, there’s really no incentive to use OllyDbg over x32dbg/x64dbg. Since OllyDbg was the debugger of choice for so many years, it will take awhile to run its course.

              That said, it’s still extremely capable for a 32-bit debugger with a rich support/plug-in ecosystem (even if a bit outdated now), so there’s absolutely nothing wrong with using it if you prefer it over any other debugger for 32-bit applications.

              Personally, I migrated to x32dbg/x64dbg quite awhile back and haven’t missed OllyDbg ever since. In fact, the switch is so easy that one could presumably get up to snuff with using debuggers via OllyDbg, then bop right over to x32dbg/x64dbg with very little differences to compensate for.

              share|improve this answer

                up vote
                3
                down vote

                up vote
                3
                down vote

                Outside of maybe custom plug-ins or perhaps buried features and usability differences, there’s really no incentive to use OllyDbg over x32dbg/x64dbg. Since OllyDbg was the debugger of choice for so many years, it will take awhile to run its course.

                That said, it’s still extremely capable for a 32-bit debugger with a rich support/plug-in ecosystem (even if a bit outdated now), so there’s absolutely nothing wrong with using it if you prefer it over any other debugger for 32-bit applications.

                Personally, I migrated to x32dbg/x64dbg quite awhile back and haven’t missed OllyDbg ever since. In fact, the switch is so easy that one could presumably get up to snuff with using debuggers via OllyDbg, then bop right over to x32dbg/x64dbg with very little differences to compensate for.

                share|improve this answer

                Outside of maybe custom plug-ins or perhaps buried features and usability differences, there’s really no incentive to use OllyDbg over x32dbg/x64dbg. Since OllyDbg was the debugger of choice for so many years, it will take awhile to run its course.

                That said, it’s still extremely capable for a 32-bit debugger with a rich support/plug-in ecosystem (even if a bit outdated now), so there’s absolutely nothing wrong with using it if you prefer it over any other debugger for 32-bit applications.

                Personally, I migrated to x32dbg/x64dbg quite awhile back and haven’t missed OllyDbg ever since. In fact, the switch is so easy that one could presumably get up to snuff with using debuggers via OllyDbg, then bop right over to x32dbg/x64dbg with very little differences to compensate for.

                share|improve this answer

                share|improve this answer

                share|improve this answer

                edited Nov 29 at 19:14

                T.Todua

                22419

                22419

                answered Nov 29 at 18:14

                dsasmblr

                1,839217

                1,839217

                    up vote
                    1
                    down vote

                    Disclaimer: I am the main developer of x64dbg, take that into account 🙂

                    I would say that the main difference between OllyDbg and x64dbg is that there is no 64 bit (os) support at all in OllyDbg. If you are working on a modern system I think x64dbg is a better choice because it was designed to work there.

                    That said, x64dbg isn’t better in all aspects. One main difference is that OllyDbg has a very solid tracing system, whereas x64dbg has something, but still requires a lot of work. I am using x64dbg for my job, but I am familiar with the source code so I can make improvements as I need them.

                    Another big difference is that you can contribute to x64dbg directly. Either by reporting bugs, or simply fixing them yourself. To me this is a big advantage, as many plugins for OllyDbg hook the internal functions to fix bugs or add features.

                    share|improve this answer

                    • ouch, i didn’t know the person helped me with other questions too, is the main dev of x64. thnx 😉
                      – T.Todua
                      Dec 2 at 9:55

                    up vote
                    1
                    down vote

                    Disclaimer: I am the main developer of x64dbg, take that into account 🙂

                    I would say that the main difference between OllyDbg and x64dbg is that there is no 64 bit (os) support at all in OllyDbg. If you are working on a modern system I think x64dbg is a better choice because it was designed to work there.

                    That said, x64dbg isn’t better in all aspects. One main difference is that OllyDbg has a very solid tracing system, whereas x64dbg has something, but still requires a lot of work. I am using x64dbg for my job, but I am familiar with the source code so I can make improvements as I need them.

                    Another big difference is that you can contribute to x64dbg directly. Either by reporting bugs, or simply fixing them yourself. To me this is a big advantage, as many plugins for OllyDbg hook the internal functions to fix bugs or add features.

                    share|improve this answer

                    • ouch, i didn’t know the person helped me with other questions too, is the main dev of x64. thnx 😉
                      – T.Todua
                      Dec 2 at 9:55

                    up vote
                    1
                    down vote

                    up vote
                    1
                    down vote

                    Disclaimer: I am the main developer of x64dbg, take that into account 🙂

                    I would say that the main difference between OllyDbg and x64dbg is that there is no 64 bit (os) support at all in OllyDbg. If you are working on a modern system I think x64dbg is a better choice because it was designed to work there.

                    That said, x64dbg isn’t better in all aspects. One main difference is that OllyDbg has a very solid tracing system, whereas x64dbg has something, but still requires a lot of work. I am using x64dbg for my job, but I am familiar with the source code so I can make improvements as I need them.

                    Another big difference is that you can contribute to x64dbg directly. Either by reporting bugs, or simply fixing them yourself. To me this is a big advantage, as many plugins for OllyDbg hook the internal functions to fix bugs or add features.

                    share|improve this answer

                    Disclaimer: I am the main developer of x64dbg, take that into account 🙂

                    I would say that the main difference between OllyDbg and x64dbg is that there is no 64 bit (os) support at all in OllyDbg. If you are working on a modern system I think x64dbg is a better choice because it was designed to work there.

                    That said, x64dbg isn’t better in all aspects. One main difference is that OllyDbg has a very solid tracing system, whereas x64dbg has something, but still requires a lot of work. I am using x64dbg for my job, but I am familiar with the source code so I can make improvements as I need them.

                    Another big difference is that you can contribute to x64dbg directly. Either by reporting bugs, or simply fixing them yourself. To me this is a big advantage, as many plugins for OllyDbg hook the internal functions to fix bugs or add features.

                    share|improve this answer

                    share|improve this answer

                    share|improve this answer

                    answered Dec 1 at 23:09

                    mrexodia

                    1,007614

                    1,007614

                    • ouch, i didn’t know the person helped me with other questions too, is the main dev of x64. thnx 😉
                      – T.Todua
                      Dec 2 at 9:55

                    • ouch, i didn’t know the person helped me with other questions too, is the main dev of x64. thnx 😉
                      – T.Todua
                      Dec 2 at 9:55

                    ouch, i didn’t know the person helped me with other questions too, is the main dev of x64. thnx 😉
                    – T.Todua
                    Dec 2 at 9:55

                    ouch, i didn’t know the person helped me with other questions too, is the main dev of x64. thnx 😉
                    – T.Todua
                    Dec 2 at 9:55

                    draft saved
                    draft discarded

                    Thanks for contributing an answer to Reverse Engineering Stack Exchange!

                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid

                    • Asking for help, clarification, or responding to other answers.
                    • Making statements based on opinion; back them up with references or personal experience.

                    To learn more, see our tips on writing great answers.

                    Some of your past answers have not been well-received, and you’re in danger of being blocked from answering.

                    Please pay close attention to the following guidance:

                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid

                    • Asking for help, clarification, or responding to other answers.
                    • Making statements based on opinion; back them up with references or personal experience.

                    To learn more, see our tips on writing great answers.

                    draft saved

                    draft discarded

                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin(‘.new-post-login’, ‘https%3a%2f%2freverseengineering.stackexchange.com%2fquestions%2f20004%2follydbg-vs-x64dbg-is-there-anything-in-ollydbg-that-is-not-available-in-x64dbg%23new-answer’, ‘question_page’);
                    }
                    );

                    Post as a guest

                    Required, but never shown

                    Required, but never shown

                    Required, but never shown

                    Required, but never shown

                    Required, but never shown

                    Required, but never shown

                    Required, but never shown

                    Required, but never shown

                    Required, but never shown

                    Related Post

                    Leave a Reply

                    Your email address will not be published. Required fields are marked *