We know that x64dbg will mark the changes as red color after we step an assembly instruction, so how can I get all changes without scroll monitor windows?

x64dbg 32bit version trace: enter image description here


x32dbg only display one change for memory when calls a function which modify at least 16 bytes:

Source code:

enter image description here

x32dbg CPU monitor:

enter image description here

x32dbg Trace monitor:

enter image description here

The function testmem.test should have 4 bytes changes, how to get those changes?

  • You can use the trace feature. Start a trace from the trace tab and then just step around. In the trace tab you can see the changes in the context menu.
    – mrexodia
    Commented Nov 9, 2018 at 10:36
  • @mrexodia Can I trace changes in memory? This is what I really want.
    – A.J
    Commented Nov 12, 2018 at 1:09
  • You can only see changes to memory if the instruction that changes the memory is in the trace.
    – mrexodia
    Commented Nov 12, 2018 at 13:00
  • @mrexodia As my upload picture shows, I only found changes to registers, how to see changes to memory?
    – A.J
    Commented Nov 13, 2018 at 2:52
  • The instruction you selected does not make any changes to memory. You can see the memory changes if you highlight an instruction that makes memory changes. Example: i.imgur.com/oOBXlnf.png
    – mrexodia
    Commented Nov 18, 2018 at 17:49

1 Answer 1


Based on the code screenshot you posted it appears you are looking for differences between two memory snap shots. That is you want to know what all changed in the process address space after you step over the call to test.test().

I hope you understand anything can change anywhere when you step over a single unknown arbitrary function over the whole process memory.

For example,

  1. A global variable may be modified which would normally reside in the writable section of a binary.

  2. Stack contents may be modified.

  3. A third / nth module/s may be loaded and whole blocks of memory may be added which didn't exist prior to executing the function.

etc ..... etc ....

You can't reliably look for what changed between one single step of a function.

x64dbg on the trace window provides you what changed on each execution, you have to scroll and look what changed for each instruction.

Or, if you can limit your lookup to a certain memory range you can dump the memory to a file and diff them.

x64dbg provides you one command to save a block of memory

savedata :memdump: , 0x400000 , 0x1000  

or for that matter all debugger will provide you a mechanism to dump raw data at some address of some size to a file.

windbg .writemem 
ida makesnapshot
ollydbg binary -> backup  or dump in memory map gui
x64dbg savedata (scriptcommand) or dumpmem in GUI memory map

You can use a hexeditor like hxd to byte compare two dumps for looking at all changes to a certain region of memory.

As a real world example you can set a breakpoint as you have set in the specific code on the screenshot. Dump two snapshots one prior to step and one after step

What was dumped

Page Information=Thread 3F8 Stack 
Allocation Type=PRV 
Current Protection=-RW-G 
Allocation Protection=-RW-- 

dumped prior and renamed the dumpfile

0024D000[3000] written to "xxx\pre" !

single stepped

INT3 breakpoint at test.01071076 (01071076)!

dumped post and renamed the dumpfile

0024D000[3000] written to "xxx\post" !

notice all the changes viz 1111,2222,3333

:\>ls -lg
total 24
-rw-rw-rw-  1 0 12288 2018-11-21 03:02 post.bin
-rw-rw-rw-  1 0 12288 2018-11-21 03:01 pre.bin

:\>fc /b pre.bin post.bin
Comparing files pre.bin and POST.BIN
00002D68: 6A 76
00002D70: 0B 00
00002D71: E1 00
00002D72: 08 00
00002D73: 01 00
00002D74: 00 11
00002D75: 00 11
00002D78: 00 22
00002D79: 00 22
00002D7C: 20 33
00002D7D: E1 33
00002D7E: 08 00
00002D7F: 01 00

:\>xxd -g4 -s 0x2d68 -l 0x20 pre.bin
0002d68: 6a100701 70fd2400 0be10801 00000000  j...p.$.........
0002d78: 00000000 20e10801 04e08442 ccfd2400  .... ......B..$.

:\>xxd -g4 -s 0x2d68 -l 0x20 post.bin
0002d68: 76100701 70fd2400 00000000 11110000  v...p.$.........
0002d78: 22220000 33330000 04e08442 ccfd2400  ""..33.....B..$.

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.