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











up vote
7
down vote

favorite
1












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
    1












    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
      1









      up vote
      7
      down vote

      favorite
      1






      1





      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










          New contributor




          Clint is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.


















          • 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
            yesterday


















          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
              yesterday











            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










            New contributor




            Clint is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.


















            • 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
              yesterday















            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










            New contributor




            Clint is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.


















            • 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
              yesterday













            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










            New contributor




            Clint is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.









            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










            New contributor




            Clint is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.









            share|improve this answer



            share|improve this answer








            edited Nov 29 at 22:15









            T.Todua

            22419




            22419






            New contributor




            Clint is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.









            answered Nov 29 at 20:48









            Clint

            1163




            1163




            New contributor




            Clint is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.





            New contributor





            Clint is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.






            Clint is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.












            • 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
              yesterday


















            • 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
              yesterday
















            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
            yesterday




            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
            yesterday










            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
                      yesterday















                    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
                      yesterday













                    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 yesterday









                    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
                      yesterday


















                    • ouch, i didn't know the person helped me with other questions too, is the main dev of x64. thnx ;)
                      – T.Todua
                      yesterday
















                    ouch, i didn't know the person helped me with other questions too, is the main dev of x64. thnx ;)
                    – T.Todua
                    yesterday




                    ouch, i didn't know the person helped me with other questions too, is the main dev of x64. thnx ;)
                    – T.Todua
                    yesterday


















                    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







                    Popular posts from this blog

                    Актюбинская область

                    QoS: MAC-Priority for clients behind a repeater

                    AnyDesk - Fatal Program Failure