Memory Search about dbgshell HOT 6 OPEN

Now this is looking a lot like what my heart desires 😁

> Search-DbgMemory 010203a0 | Read-DbgMemory -LengthInBytes 4
VirtualAlloc 007f0000 - 008f0000  MEM_PRIVATE  Heap 007f0000
Heap entry body 008242f0 size 0x2000 Busy
00825d60  010203a0
008ce458  010203a0

VirtualAlloc 06c70000 - 06d70000  MEM_PRIVATE  Heap 007f0000
Heap entry body 06cc9340 size 0x690 Busy
06cc9348  010203a0
06cca1e8  010203a0

from dbgshell.

Cool!

For 1) and 2) I am not very familiar with dbgeng's memory searching... I'll have to read up on that. By far the best memory searching functionality I've seen were in a debugger extension called !pde, but I'm not sure if that's available externally. I'll look into it.

For 3) Can grouping be done without accumulating? Yes, the grouping done by the alternate formatting engine in DbgShell operates on a streaming basis--it evaluates each item against the grouping criteria, and when it comes back different, it's a new group.

from dbgshell.

Here's where you can get PDE: https://channel9.msdn.com/Shows/Defrag-Tools -> follow link to OneDrive for downloads. Here is the video about string searching.

The source is not available externally unfortunately.

from dbgshell.

Just had need of it and I am indeed rather impressed with the string searching. Don't suppose you could get me the public debug symbols for it, nearly as good as source 😉

from dbgshell.

Getting closer to what I want :)

>Search-DbgMemory 04244c8b | Read-DbgMemory -LengthInBytes 4
VirtualAlloc 75b10000 - 75d6c000  MEM_IMAGE  combase
75b6ade4  04244c8b

VirtualAlloc 75f50000 - 760dd000  MEM_IMAGE  user32
75f8df60  04244c8b
75f8e180  04244c8b

VirtualAlloc 76170000 - 7628e000  MEM_IMAGE  ucrtbase
761b68e0  04244c8b
761b6ed0  04244c8b
761b6f40  04244c8b

(Hmmm, only just now occurred to me that "VirtualAlloc" is not a very good label for MEM_IMAGE/MEM_MAPPED regions...)

(BTW GroupByResultIsDifferent doesn't really work as intended; == on two object references will only test reference equality. Zhentar@f212ff0 has a rewrite of it, including sequence comparison)

from dbgshell.

I was wondering how !PDE.spx manages to be so much faster than SearchVirtual2, so I took a look at how they work.

• PDE.spx fetches one page at a time using ReadVirtual (filtering by virtual region attributes), casts to a pointer-size array, and indexes through that looking for matches.
• SearchVirtual2 fetches one page at a time using ReadVirtual, searching for matching byte patterns and rejecting matches with inappropriate alignment.

Hmmm, so my desire to "play nice" and use SearchVirtual2 led me to wrap it in a second layer of exactly the same weaknesses. Meanwhile, PDE.spx takes exactly the same approach my fuzzy-searching prototype used, and that prototype was both easier & more intuitive to use and more capable than my first Search-DbgMemory attempt.

Which leads me to conclude that PDE achieves it's much better search experience because it rightly separates searching into two distinct tasks: aligned power-of-2 byte sized searches, and arbitrary size byte/character array searches. And also that using ReadVirtual to read page sized blocks and search them rather than using SearchVirtual2 is a totally reasonable and well performing approach.

So, my start on round 2:

> Search-DbgMemory 010203a0 -SearchMask 0xFFFFFF03
VirtualAlloc 007f0000 - 008f0000  MEM_PRIVATE  Heap 007f0000
Heap entry body 008242f0 size 0x2000 Busy
00825d60  010203a0                             ....

VirtualAlloc 52010000 - 5274e000  MEM_IMAGE  System_Xml_ni
5235d714  0102036b                             k...
5269344c  01020390                             ....

from dbgshell.