26 Jun 2018

x64dbg – 2 years later..

Almost 2 years ago I wrote a post about x64dbg and why I don't use it in my work. People still comment on the article, so I decided to revisit x64dbg and see if anything has changed in past two years.

Improvements

Some menus are slightly cleaned up. Not by much, though.

Now you can customize the context menus and hide all the crap you don't need or want. I'd preferred to have the crud removed altogether but it is a really nice feature:

Feature bloat

It's getting slightly better. Instead of three different assembler engines we have "just" two. However, other useless features like "Help on mnemonic" are still there. What for?

And some of the big bloat is still there (eg. Snowman and Yara). Those are standalone tools, not core features. In my opinion, it would make much more sense to have them as plugins so the user can choose whether to have them or not.

But it's still buggy

I tried to use x64dbg for one day - for doing actual work. And during that day, I encountered several serious bugs which seriously affected my work.

Assembler is buggy

Have you ever tried to assemble a simple instruction using x64dbg? For example, mov rax,1 ? You might get a different instruction instead..

As of time of writing, this is the latest x64dbg build available for download. The bug is reproducible on older builds as well.


Why is that? I'd say it's because of the feature bloat. There are 2 assembler engines and apparently at least one of them is not tested properly.

Can I work around it? Yes. Once I know that AsmJit is broken, I can use XEDParse all the time. But it shouldn't be like that in the first place!

Ignored exceptions are not ignored.

Ever tried ignoring exceptions? It kinda works. Sometimes. But not always. From what I see, it's totally random - but 100% reproducible.

Again - using the latest build, x32dbg this time:

Sounds like a minor annoyance to you? Try debugging executable that uses "int 3" as an anti-debug measure everywhere. It's basically impossible with x32dbg.

Conclusion

Some things have improved. But overall, it's still the same product it was 2 years ago - good for some simple tasks, unreliable for an actual work.

6 thoughts on “x64dbg – 2 years later..

  1. Hello Kao
    i'm really a big fan of yours
    can you please tell us what tools you us like what debugger you prefer , etc ...
    thanks

  2. Hey Kao,

    The things you mention are interesting, but not unexpected behavior :)

    Asmjit optimizes for size, because mov rax,1 and mov eax,1 are semantically equivalent it chooses the shorter instruction. This could be changed, but so far it has not been a big issue: {hidden link}.

    The skipping of exceptions is limited to 10k skips because there was an exploit that would keep the debugger in an infinite loop. To prevent users from losing their data I added a (configurable) limit: {hidden link}.

    Duncan

  3. Hi, kao,
    Can you post a new review for x64dbg and maybe a comparison between ollydbg2 and x32dbg?
    Thanks mate.

  4. Dear Kao,
    Thanks a lot for your information. However I guess many ones are expecting a newer review by an experienced user like you.

Leave a Reply to Coldzer0 Cancel reply

  • Be nice to me and everyone else.
  • If you are reporting a problem in my tool, please upload the file which causes the problem.
    I can`t help you without seeing the file.
  • Links in comments are visible only to me. Other visitors cannot see them.

Your email address will not be published.

 −  1  =  seven