MemoryHacker

[Shub-Nigurrath]

The intermittent x32 crashes were due to unsafe modeless-dialogue copying, where some windows were assigned through a custom operator=() that only copied m_hWnd. I removed that pattern, and the dialogue classes are now non-copyable, so the same bug cannot silently return in the future.

• Inspect Memory now supports Hex, ASCII, and UNICODE views, and patching works directly in all three modes with strict validation to prevent malformed writes.
• The x64 patching issue where VirtualProtectExA could fail with GetLastError() = 87 was narrowed down to invalid protection-range handling; the fix now uses VirtualQueryEx, validates committed memory, checks region boundaries, and aligns protection changes to page boundaries.
• The Memory Block window also now shows the owning DLL or mapped module name when available, with clear fallback labels for private or unresolved regions.

[CodeCracker]

Thank you.
It will be great if "Hex" option from Inspect Memory will show both Hex and ASCII or UNICODE, something like "Hex&Ascii" and also "Hex&Unicode".
"Inspect Memory" Patch button now show this error:
https://ibb.co/xqWMYhmR
"Inspect Memory" -> "Inspect Memory" button now does nothing, nothing happens when is pressed.

[Shub-Nigurrath]

OK, worked on that.

v1.2 fixes those issues and a couple of others you didn't spot (for example, the module selection). Now, double-clicking on the DLL or module selection does the job.

[CodeCracker]

Let me know if you are interest to develop it further.
For Ascii and Unicode will be great it will be two option checkboxes: case-sensitive (Where the case of letters matters) and case-intensive (Where the case of letters doesn't matter).
I've notice that the 32 bits MemoryHacker still crushes sometimes.
Do you know why Memory Block doesn't show low addresses? It start with 00D70000 address?
On "Memory inspect" "Split string len" value doesn't seems to matter while pressing Inspect.
On memory inspect chars ^^ ^^ will be great if it will not be there at all, like the space " ^^ ". Instead it will be much nicer if you will bold the target area. I don't know if you like the idea, let me know.
Winrar 64 bits textbox is limited to entering 8 hexadecimal numbers while in 64 bits should be 16 hexadecimal numbers; in Customize dialog.
"Get process state" doesn't look good; it is it too large.

[Shub-Nigurrath]

here is
Now changelog.md contains the list of additions I have made since the initial fork. For the moment, I'll freeze the project unless there are important bugs or excellent ideas :-P

best
Shub

[CodeCracker]

MemoryHacker Shub-fork v1.2.2
For MemoryHacker Shub-fork v1.2.1
see CHANGELOG.md for full details of changes made by Shub-Nigurrath

Read MemoryHackerReadMe.txt for how to use this tool.

MemoryHacker by Shub-Nigurrath and CodeCracker v1.2.2:
- Switched to VS Community 2017, Platform Toolset "Visual Studio 2017 - Windows XP (v141_xp)
- Mirror interface changes
- Now writes if MemoryHacker is 32 bits or 64 bits, now write "Administrator" if is runned as admninistrator
- Now you can patch with any hex/Ascii/Unicode in Inspect Memory,
but hex values lenght should be even (divisible by 2)

Left to do:
1. Inspect Memory dialog interface looks strange
2. Memory Block doesn't show low addresses
3. Adding an manifest to program, I don't know how to do this

For some reasons the 32 bits version gets compiled in Debug/Release folders
while 64 bits versions gets compiled in x64 folder

[Shub-Nigurrath]

Hi all
I like clean things. I therefore did some additional tweaks. I am compiling with VS 2026 and needed to modify the vsproj, so it compiles automatically on any installation, adapting to what's installed on the machine.

V 1.2.3
MemoryHacker 1.2.3 focuses on building reliability and finishing the remaining UI/configuration cleanup. The project now adapts to the toolchains actually installed on the system, builds cleanly in modern Visual Studio environments, embeds a proper application manifest, and keeps Win32/x64 outputs organised under x32 and x64 folders.

On the app side, the Inspect Memory window now has a corrected layout, and the Memory Block view was widened so addresses display properly on both 32-bit and 64-bit builds. Windows XP buildability is still possible with v141_xp installed, but modern v145 builds should not be assumed to be XP-compatible.
Hence, if you want to have it on XP, someone with an older version of Visual Studio needs to give it a compilation twist

edited
NEW v1.2.4
Fix memory problems. The main problems were unsafe parsing of remote PE headers in the modules view, fixed-size custom-range arrays that could overflow, an off-by-one bug when removing custom ranges, a fixed-size selected-index buffer that could corrupt heap memory when too many rows were selected, and suspend/resume code that assumed handles and ntdll exports were always valid.


Best
Shub

[Shub-Nigurrath]

v1.2.4 uploaded to the edited version of my previous post

[CodeCracker]

Hi. I found new problems with v1.2.4/v1.2.3: it can't even see some processes for example WinStore.App.exe; they are 64 bits processes - original build I've created works fine.

[Shub-Nigurrath]

v1.2.4 changed the process picker from a flat list into a parent/child tree, but only root nodes are expanded initially. Processes like WinStore.App.exe can be correctly enumerated yet buried under a collapsed parent, so they look missing .. that was an easy patch: I added an "Expand(treeItem, TVE_EXPAND)" in the opening

I also added two nice features:
- add: search incremental case-insensitive, with next/prev buttons for process name, ctrl-f also supported.
- add: drag & drop icon to select the process visually (like Process Explorer from sysinternals)
- fix: a message "searching .. please wait" in the memory search dialog

Attached the new version 1.2.5

[CodeCracker]

Ah, I got it the process is under wininit.exe -> services.exe -> svchost.exe
my bad.