2

I have x64dbg and ghidra synchronized via ret-sync. I found an interesting point in ghidra:

1800382b1   4d 8b e0      MOV              R12,rebitData
1800382b4   48 63 f2      MOVSXD           packetSize_,packetSize

in the listing view; the file my.dll starts at 180000000. So, then in x64dbg I add a dll break for my.dll, and when I'm in, I go to the file offset with ctrl+shift+g and enter 328b4, but I end up at (first line):

00007FF8B2FB32B4 | 06                       | ???             
00007FF8B2FB32B5 | E9 80000000              | jmp my.7FF8B2FB333A    
00007FF8B2FB32BA | 45:8BC6                  | mov r8d,r14d        
00007FF8B2FB32BD | EB 7B                    | jmp my.7FF8B2FB333A   
00007FF8B2FB32BF | 3BFB                     | cmp edi,ebx 
00007FF8B2FB32C1 | 73 22                    | jae my.7FF8B2FB32E5 
00007FF8B2FB32C3 | 41:3BDB                  | cmp ebx,r11d 
00007FF8B2FB32C6 | 76 18                    | jbe my.7FF8B2FB32E0

where in x64dbg, the file starts at: 00007FF8B2F81000 (CPU tab, module my.dll, main thread X, PID Y).

Obviously the instructions are not the same. (I believe I did the rebase correctly)

How can I make the correspondance ghidra -> x64dbg and break in x64dbg at the "same place" ie., same instructions ?

Soleil
  • 6,404
  • 5
  • 41
  • 61
  • This question might also be better suited for the RE stack exchange, but you already know about that so I am assuming you intentionally posted it here? – Florian Magin Jan 19 '21 at 08:53
  • @FlorianMagin Yes I know. But the choice of debugging vs reversing is arbitrary here, hence I chose to make it more general and picked debugging, which is better on SO. I recognize that the usage of ghidra may strongly suggest reversing, or eventually analysing. – Soleil Jan 19 '21 at 18:21
  • Ah, good reasoning, and makes it clearer what the focus of your question is. I agree if the focus is on the general debugging aspect, than SO might be better suited. – Florian Magin Jan 20 '21 at 13:54

2 Answers2

4

However, this does not work with ret-sync being built in release, only in debug version. This is a bug.

  • For manual rebase+jump, from x64dbg it is possible to enter the offset (current offset - base offset) in expression in x64dbg calculator, and ask follow in disassembler to jump directly to the offset. One can calculate an expression that does a rebase or a more complex function (eg., offset + sizeof X * Ntimes).

  • If the final offset is known, another way to jump to the desired offset in x64dbg is ctrl+shift+g (go to file offset), if the desired module is in the CPU disassembly. If not, one need to go to symbols, and follow the module of interest in the CPU disassembly and then go to file offset.

Soleil
  • 6,404
  • 5
  • 41
  • 61
3

You said you wanted to go to 328b4 but your second snippet is at ...32B4 and looks like you ended up in the middle of an instruction. I would expect the correct address to be 0x00007FF8B2F81000 + 0x328b4 = 0x7ff8b2fb38b4.

I am not aware of ret-sync supporting setting breakpoints, but you can do the address translation more easily by either getting the relative offset by hovering enter image description here

Source: https://twitter.com/dev747368/status/1347360276476293125

and then adding the x64dbg offset of 00007FF8B2F81000 to offset (2008h in the screenshot, in your case 328b4h )

Or you can script this by running currentAddress.subtract(currentProgram.imageBase) in the shell to get the relative offset for the current address (again 328b4h in your example) and then adding the x64dbg offset. So the complete command would be: currentAddress.subtract(currentProgram.imageBase).add(0x00007FF8B2F81000) Run this in the Python REPL and the correct x64dbg address for the current address should result.

Florian Magin
  • 576
  • 3
  • 6
  • So, ctrl+shift+g (go to file offset) is not the right way to go where I want (with automatic rebase) ? Why is that ? don't we have a copy of the program in the process memory space ? – Soleil Jan 19 '21 at 19:19
  • `ctrl+shift+g` in `x64dbg`? I have actually never used windows debugger outside IDA, I mostly do static RE with ghidra. If `x64dbg` can do the `pam_xauth.so + 2008h` translation itself then it gets even easier and you can just pass the offset of `0x2008` to `x64dbg` in whatever way makes sense – Florian Magin Jan 20 '21 at 13:57
  • There is a "command" textbox in x64dbg, but it did not take your python REPL command (I did not find it). Hence remain two option: "go to file offset" and the calculator, in which I put the strting offset + the desired offset in dll (taken from ghidra),and then ask "follow in disassembler", which gives the result I want. – Soleil Jan 20 '21 at 18:02
  • 2
    Ah, my Python REPL command is for the Ghidra Python REPL. `currentAddress` is a magic variable that will have the value of the address that you are currently located at in Ghidra. So if you are at an interesting address in Ghidra, you can run this command in Ghidra and will get the resulting address in `x64dbg`, or just the offset inside the file if you leave out the last `.add()` part – Florian Magin Jan 20 '21 at 18:54