2

I was just wondering if there was a way to force an interpretation of a block of code in x64dbg.

The section im analyzing fluctuates between this:

enter image description here

and this:

enter image description here

5
  • It's not quite clear what are you asking. Please clarify your question and what you want to achieve. Also, please mention what you already tried.
    – Megabeets
    Commented Jun 15, 2018 at 12:16
  • My question might be completely bogus - I'm not too sure but essentially: When i scroll up and down, sometimes sections of code appear as data instead of commands and they seem to swap. Is there any way for me to force x64dbg to interpret a section as code in a specific way so that instead of interpreting it like this: puu.sh/AFKL1/46fcdf5c8d.png it is interpreted as this: puu.sh/AFKMI/5259abad45.png (I tried to get the same addresses)
    – Xymistic
    Commented Jun 15, 2018 at 12:41
  • I haven't tried much either because I'm not too sure what exactly is happening (why the code interpretation changes?).
    – Xymistic
    Commented Jun 15, 2018 at 12:48
  • Seems like the code isn't aligned correctly. Give a try to right-click and then choose an option from the "Analysis" menu. For example, "Analyze module (CTRL+A)"
    – Megabeets
    Commented Jun 15, 2018 at 13:14
  • Thanks for the suggestion, however analysing the module doesn't seem to help.
    – Xymistic
    Commented Jun 15, 2018 at 13:59

1 Answer 1

4

You are encountering the issue of backwards disassembly. When you give x64dbg an address to disassemble at it will start decoding at exactly this address, go to the next instruction, etc.

For example if you have the bytes:

EB 00 48 83 C4 38 C3

And you start disassembling at the first byte you will see:

0 | EB 00       | jmp 2
2 | 48 83 C4 38 | add rsp,38
6 | C3          | ret

If you start disassembling at the second byte you will see:

1 | 00 48 83    | add byte ptr ds:[rax-7D],cl
4 | C4          | ???
5 | 38 C3       | cmp bl,al

The reason you are seeing garbage like this when scolling up is that x64dbg has no idea about instruction starts and tries to heuristically determine what the previous instruction was based on the bytes. If the result of this algorithm is wrong x64dbg will disassemble at an incorrect location causing strange looking instructions. You can find the implementation of that algorithm here. It is based on the algorithm used inside OllyDbg.

As some users suggested you can use analysis, but the results of this are not used during backwards disassembly because generally everything works fine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.