OllyDbg vs x64dbg - Is there anything in OllyDbg that is not available in x64dbg?
up vote
7
down vote
favorite
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
add a comment |
up vote
7
down vote
favorite
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
add a comment |
up vote
7
down vote
favorite
up vote
7
down vote
favorite
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
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
ollydbg debuggers x64dbg
edited Nov 30 at 8:20
asked Nov 29 at 16:46
T.Todua
22419
22419
add a comment |
add a comment |
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.
New contributor
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
add a comment |
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.
add a comment |
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.
ouch, i didn't know the person helped me with other questions too, is the main dev of x64. thnx ;)
– T.Todua
yesterday
add a comment |
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.
New contributor
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
add a comment |
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.
New contributor
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
add a comment |
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.
New contributor
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.
New contributor
edited Nov 29 at 22:15
T.Todua
22419
22419
New contributor
answered Nov 29 at 20:48
Clint
1163
1163
New contributor
New contributor
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
add a comment |
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
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited Nov 29 at 19:14
T.Todua
22419
22419
answered Nov 29 at 18:14
dsasmblr
1,839217
1,839217
add a comment |
add a comment |
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.
ouch, i didn't know the person helped me with other questions too, is the main dev of x64. thnx ;)
– T.Todua
yesterday
add a comment |
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.
ouch, i didn't know the person helped me with other questions too, is the main dev of x64. thnx ;)
– T.Todua
yesterday
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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