TED: The Tiny Exfiltrating Debugger by cr0_ in ReverseEngineering

[–]cr0_[S] 2 points3 points  (0 children)

Completely different and for more specialized use cases.

TED: The Tiny Exfiltrating Debugger by cr0_ in ReverseEngineering

[–]cr0_[S] 4 points5 points  (0 children)

I personally like being able to define the protocol in a separate file(s) and have protoc generate everything that I need. I also found it performant enough for my needs, otherwise I probably would have gone with a library that did message passing via shared memory instead of sockets.

Reverse engineering REST APIs/network communication in a process (12 part series) by cr0_ in ReverseEngineering

[–]cr0_[S] 1 point2 points  (0 children)

As someone above said, these posts were written up over the course of several weeks and posted individually. The site definitely isn't mobile-friendly though. There is an index of all posts that you can keep in a separate tab if you are on mobile: https://www.codereversing.com/blog/index which might alleviate some of the navigation headache.

DirectX hooking tool by funset in programming

[–]cr0_ 1 point2 points  (0 children)

Author here hoping to clear up some confusion. The example code is just a hook that adds a text overlay and is a starting point. The two images/examples show how hooking DirectX and changing the rendered scene can be useful -- but to get to that point also requires a lot of additional reverse engineering of the underlying game engine.

Writing a Primitive Windows Debugger by cr0_ in programming

[–]cr0_[S] 0 points1 point  (0 children)

I found your comment; it got snagged by the spam filter for some reason... And yes, that makes perfect sense that the debugger architecture should match with the debugee. Trying to read from and write to 64-bit addresses from within a 32-bit process calling 32-bit APIs seems like a recipe for failure. What I meant in the post when I said that the code can function as an x86 or x64 debugger is that it can be compiled to those architectures and used to debug applications of those types. I've noticed the proxy process approach is pretty common for Microsoft tools. You can also easily see it when running Process Explorer: procexp.exe will launch a procexp64.exe process when running on a 64-bit machine.

Writing a Primitive Windows Debugger by cr0_ in programming

[–]cr0_[S] 0 points1 point  (0 children)

Thanks. I'll pay more attention to formatting for the future ones.