Create 2024-07-28-Analysis-memory-access-pattern-has-never-been-easie…

[torusrxxx]

…r-now.md

[mrexodia]

I think it's a nice post, but it would be good to have some example application/crackme and some screenshots/diagrams. I'm happy to work on that, just need a good example use case that people would resonate with.

[torusrxxx]

I don't have time to write a crackme tutorial now, there isn't any crackme on my Github profile. Finding a good example use case shouldn't be hard. For example, it makes it possible to dump a self modifying executable even when you don't know OEP before tracing. It also accelerates many common operations, like jumping to the last iteration of a loop.

This feature aligns with the general trend that you just leave the computer to record everything, have a cup of coffee, and then analyze the trace recording with more powerful tools available: the default xref analysis can never be better than this one based on tracing.

[mrexodia]

Didn't forget about this, just need to find some time to create screenshots to add to the post and then share it on social media.

[torusrxxx]

Half a year later, it's no longer news

[mrexodia]

My apologies, I completely forgot about this post 🤦‍♂️.
I think it’s still relevant to explain new features and workflows, many people do not keep up with the latest developments and I think it will be news for them!

[torusrxxx]

It looks like more and more users are interested in this technology!

[mrexodia]

Totally forgot about it again 😅 If you're good with publishing it as-is I can adjust the filename and publish it. For me it reads a bit like a 'wall of text' without any concrete use case or screenshots etc, but up to you!

[torusrxxx]

If you have a better idea, I'm looking forward to that. I'm not a good crackme tutorial writer.

[mrexodia]

For me personally the issue is that I have never actually used x64dbg's tracing myself outside of testing it/reproducing bugs, so it's a bit difficult to come up with examples 😅

I obviously see the use of the memory view, we could demo that easily with some basic XOR encryption thingy and then show that you can see the memory update 'live' and you click through the trace.

For the cross-reference search I already struggle a bit to find a realistic use case. Would the idea be to breakpoint on some API (WriteFile) where you get the address of the buffer and then do a cross-reference to that address in the trace? In practice nobody will trace more than 1-10 million instructions (which takes 2-20 minutes). You would instead look at the call stack on the breakpoint to try and reduce the scope of the analysis.

For the pattern search one idea I came up with is where a syscall instruction is decrypted, executed, re-encrypted, so you could look for the opcode to see when it first appears. But practically it would be easier to search for the instruction in the trace? Just difficult to see where you would get the pattern to search for without knowing the address. Maybe you have an API that is dynamically resolved, then stored (encrypted) for later, then a bunch of unrelated/fake code and then API address fetched from memory, decrypted and executed?

Ages ago there was a 'Run trace' tutorial posted on the OllyDbg website (https://ollydbg.de/Tut_rtr.htm) there the use case is that the stack was wiped and a crash was difficult to recover, but even this post mentions needing 10 minutes to collect the trace 😬

Did you use the tracing for some personal reverse engineering projects? Could be helpful to come up with a simpler example that could fit in the post...

Edit: a friend of mine also mentioned 'catching a buffer overrun' as a potentially practical example. Could be a simple arena allocator and then something like:

overflow_buf = arena.allocate(100)
hello_buf = arena.allocate(25)
strcpy(hello_buf, "Hello!")
puts(hello_buf)
something_long(overflow_buf)
puts(hello_buf) # prints something else now

Then you can jump to the last write on hello_buf[0] to find where the overflow happened.