[Vrtule]

now when i test with process hacker x64 (driver disabled) and check strings then mapped, private i can clearly see the memory of my dll and the name but searching for handle/dll in process hacker returns no result. question is am i missing something here?

VADs will not help you in case of 32-bit processes since it is possible to find all valid memory just by trying to access one page after another (maybe, accessing every possible 64 KB region will do). I am not sure whether a similar technique can be applied to 64-bit processes (well, you probably cannot go through the whole address space but it might be possible to walk only the locations where DLLs are usually mapped, if such locations exist).

[kerpow1]

Thanks. I went ahead and added obregistercallbacks on the process I inject the dll into and now there are no results in phacker so my theory is the vad hiding was fine but as the dll still exist on disk it can be reviewed by such tools but the callback now denies that. Not entirely confident though.

I was informed that vad was a very reliable technique for dlls, btw the dll and spawned process is 32bit but on a 64bit system but vad is protecting from kernel and has pointers for both levels.

[Microwave89]

I guess you and that Blackbone project are using kernel patching in order to modify the VAD trees?
And seemingly it is not being detected by PatchGuard yet?
What I was always wondering, why do you need to hide your DLL so well if you already have rights as high as in a driver?

Best Regards - Microwave89

[kerpow1]

Well in certain cases you want a local module/process that can do certain things easier, say open a handle and read/write memory. You then use the higher level of a driver to protect that module or process but it becomes difficult in these scenarios when there are equally powerful prevention/evasion techniques.

I am not patching like BlackBone does, I am enumerating through the VAD, locating my loaded module and then nulling the string entry ("blabla".dll) and is PG safe and should remain that way. I believe the issue is due to not using obRegisterCallbacks correctly in this environment so after initating that and restricting access to my process that the module is cloaked into results are now as expected for all tools checked.

Ofcourse Device\\PhyiscalMemory access or indeed VMMAP type solutions won't be prevented with this method.

Its also good to open this type of discussion I think.

Attachment of view of strings in memory now, seems that ObRegisterCallbacks was the issue.