Update to current C style?

[stianhoiland]

(long shot) Would love to see this utility updated to your well-evolved style :)

Oh, and a feature request: A command/arg to simply read-&-print value at address.

[skeeto]

I appreciate your interest, but I haven't used this tool in years. My need of it is so little that I don't even have it "installed" (i.e. on my PATH) on any of my current systems. So I'm unmotivated to do any work on it. If you'd like to take a crack at it, I can give you some of my thoughts about how I'd approach this today (imagine if I could send this back in time!): * Already visible is some shape of a platform layer, so that's the first place to start carving out platform-agnostic parts from the platform. Each platform should have its own entry point, not share main. * Drop os_thread*. Replicating a thread-spawning abstraction like hosts' threading APIs is a common mistake. I didn't know better. The application layer shouldn't manage thread handles or spawning its own threads. That's low-level platform layer gunk. Instead either the platform should present a job completion interface (e.g. no explicit threads), or the application should have multiple entry points. The latter is most appropriate for memdig. Notice how memdig_init() starts a thread? That could just be a secondary worker thread entry point instead, which would greatly simplify the whole threading interface. (No more os_stub, struct os_thread, etc.) * I'm unsure how much I could cut back on the mutex API. Ideally that could be reduced to spinlocks, which wouldn't require platform layer support, but it would be bad to hold a spinlock while calling into the platform layer. They're good for, say, swapping out pointers to update some shared data, but not for blocking. A better solution might emerge while fixing up the dumb threading issues. (If a mutex is necessary, ideally the platform layer can provide it using something better than the crummy APIs (pthreads, CRTICIAL_SECTION) I actually used. Namely, locks either wouldn't require destruction (futex, SRW), or they they could be destroyed while locked so that the platform layer could abruptly "cancel" the worker thread without danger after, say, a test completes. If we explicitly control all the locks, we *can* safely cancel threads!) * memdig_free: another common beginner-intermediate mistake. Why am I wasting time and code "cleaning up" before exiting? I was taught poorly. In general joining threads is a related smell, a sign that the author of a program isn't thinking clearly. Don't join threads. Just exit the process when it's done. Don't launch threads dynamically, but park a fixed number of threads in a pool/queue, so you never need to clean them up. Joining is another unnecessary piece of the "os" API, and so much code can be trivially deleted with a simpler design. * Return structs, not this *_init() nonsense. Too much early C material thoughtlessly warns beginners away from returning structs. I thoroughly fell into that trap at this point. Again, I was taught poorly. * Get all the libc crap out of the application layer. Especially no stdio in the application. Switch to custom, group-based allocation. * Don't expose process handles through the platform API. The application only has one debuggee at a time, and opening a process should implicitly close the previously-open process. Without a handle, the platform API no longer needs a "close" interface for those handles. And, as discussed, there's no reason to close handles before exiting. That's a whole lot of code that could be deleted. (Like with threads, notice how much simpler things are when the application layer doesn't deal with handles!) * The platform layer functions should accept an opaque context pointer, a pointer passed into the entry point, so that the platform layer doesn't need to use global variables. (See u-config.) That's where the OS process handle would likely live, hidden from the application layer. * Replace each "os" iterator with a single call that returns a collection of results using arena allocation. At the time I was fixated on "iterator" interfaces (see my trie repository, from this same era), in part because I was stuck in the traditional memory management paradigm. So optimistically the platform layer is now just 5-ish functions, hundreds of lines of code deleted (maybe up to a third of the total?), the program is more efficient as a whole, and the doors are opened to add tests over a virtual OS.

[stianhoiland]

Instructive as always. I appreciate you taking the time to formulate those reflections.

This seems a little above my paygrade, unfortunately. For now, anyway.

Lately I've gotten involved with a little reverse engineering for an old game I love but which needs some tweaks, and after trying many tools I'm hungering for a terminal tool to assist me in the Sea of Hex—it could maybe really accelerate me. I just thought I'd fire off a little search for WriteProcessMemory on GitHub and what do you know! Top of the result list is your project. "Of course you made something like this", I thought.

My idea was just to make an incredibly simple wrapper over Read/WriteProcessMemory so that I could use it in some scripts (I'm huge on shell scripting). To be honest I got a little discouraged to make my own when I saw your much cleverer utility. If I thought I could match your style and actually implement what you've described above, I would. But again, I think it's above my capacity atm.