Manual Mapped Dll's

[how02]

Hook NtQueryVirtualMemory, ive never looked at VAC but there should be a pluthera of solutions for your problem.

VAC call NtQueryVirtualMemory, and if they find something "suspect", they call NtReadVirtualMemory

1118.29443359 [Driver] NtQueryVirtualMemory (Address: 0x22DBE000, Size: 0x1C)
1118.29443359 [Driver] NtQueryVirtualMemory (Address: 0x22DC0000, Size: 0x1C)
1118.29443359 [Driver] NtQueryVirtualMemory (Address: 0x22DC0000, Size: 0x1C)
1118.29443359 [Driver] NtQueryVirtualMemory (Address: 0x22DC0000, Size: 0x1C)
1118.29443359 [Driver] NtQueryVirtualMemory (Address: 0x22DC0000, Size: 0x1C)
1118.29443359 [Driver] NtQueryVirtualMemory (Address: 0x22DFF000, Size: 0x1C)
1118.29443359 [Driver] NtQueryVirtualMemory Warning (Address: 0x22EC0000, Size: 0x1C)
1118.29443359 [Driver] NtQueryVirtualMemory Warning (Address: 0x22EC0000, Size: 0x1C)
1118.29443359 [Driver] NtQueryVirtualMemory Warning (Address: 0x22EC0000, Size: 0x1C)
1118.29443359 [Driver] NtQueryVirtualMemory Warning (Address: 0x22EC0000, Size: 0x1C)
1118.29443359 [Driver] NtQueryVirtualMemory Warning (Address: 0x22EC1000, Size: 0x1C)
1118.29443359 [Driver] NtQueryVirtualMemory Warning (Address: 0x22F2A000, Size: 0x1C)
1118.29443359 [Driver] NtQueryVirtualMemory Warning (Address: 0x22F62000, Size: 0x1C)
1118.29455566 [Driver] NtQueryVirtualMemory Warning (Address: 0x22EC0000, Size: 0x210)
1118.29455566 [Driver] NtReadVirtualMemory Warning (Address: 0x22EC0000, Size: 0x2000)
1118.29455566 [Driver] NtQueryVirtualMemory Warning (Address: 0x22F62000, Size: 0x1C)
1118.29455566 [Driver] NtQueryVirtualMemory (Address: 0x23000000, Size: 0x1C)
1118.29455566 [Driver] NtQueryVirtualMemory (Address: 0x23000000, Size: 0x1C)
1118.29455566 [Driver] NtQueryVirtualMemory (Address: 0x23000000, Size: 0x1C)
1118.29455566 [Driver] NtQueryVirtualMemory (Address: 0x230FD000, Size: 0x1C)
1118.29455566 [Driver] NtQueryVirtualMemory (Address: 0x230FE000, Size: 0x1C)

Here is what you get if you log NtQueryVirtualMemory and NtReadVirtualMemory calls. (the "Warning" region is where my mapped module was).

[wav]

Didn't differentiate between VAC2/3. See that large scan for 2 pages? Probably looking to find a pe header. So I'd bet that's VAC2, Scan Gate 0xF. Besides logging the size is a moot point and rather useless ( VirtualQuery ).

@ how did you leave your pages explicitly set to RWE ?

[how02]

I didn't map PE headers.

I do this for each section:

DWORD dwOldProtect;
MEMORY_BASIC_INFORMATION mbi;
VirtualQueryEx(this->hProcess, MakePtr(LPVOID, this->dwModuleBase, header->VirtualAddress), &mbi, sizeof(mbi));
VirtualProtectEx(this->hProcess, mbi.BaseAddress, mbi.RegionSize, header->Characteristics & 0x00FFFFFF, &dwOldProtect);
FlushInstructionCache(this->hProcess, mbi.BaseAddress, mbi.RegionSize); 

PS: for the logs I was returning the real value (not hiding anything).

[wav]

I didn't map PE headers.

I do this for each section:

DWORD dwOldProtect;
MEMORY_BASIC_INFORMATION mbi;
VirtualQueryEx(this->hProcess, MakePtr(LPVOID, this->dwModuleBase, header->VirtualAddress), &mbi, sizeof(mbi));
VirtualProtectEx(this->hProcess, mbi.BaseAddress, mbi.RegionSize, header->Characteristics & 0x00FFFFFF, &dwOldProtect);
FlushInstructionCache(this->hProcess, mbi.BaseAddress, mbi.RegionSize); 

PS: for the logs I was returning the real value (not hiding anything).

Well of course the pe header shouldn't be mapped, neither should the .reloc section. Is each section of the file mapped independently or as one large allocation?

[everdox]

yeh so just hook it and filter out the mbi buffer to your liking. though why are you using a driver? have they mapped the ntdll call stubs for manually accessing system services? I can see if it were 32 bit windows with no KPP that's probably a viable approach though if you were looking to make your hack portable maybe you could just find where they map it to

otherwise another non portable approach could be hooking outside of the wow64 thunk layer provided they don't check and build a 64 bit stack to access a system service (yes ive seen that done but pretty rare).

[wav]

yeh so just hook it and filter out the mbi buffer to your liking. though why are you using a driver? have they mapped the ntdll call stubs for manually accessing system services? I can see if it were 32 bit windows with no KPP that's probably a viable approach though if you were looking to make your hack portable maybe you could just find where they map it to

otherwise another non portable approach could be hooking outside of the wow64 thunk layer provided they don't check and build a 64 bit stack to access a system service (yes ive seen that done but pretty rare).

KPP is easy to bypass :/

[everdox]

KPP is easy to bypass :/

indeed it is ;p

but i think a time comes for everyone when they just want the quickest way out. and since im sure you already know with x64 system service table only branching at 32 bit boundaries that leaves people with having to use inline hooks. just easier to hook the wow64 dispatcher sometimes

[how02]

Well of course the pe header shouldn't be mapped, neither should the .reloc section. Is each section of the file mapped independently or as one large allocation?

Oh I didn't know about the .reloc, thanks
I do 1 alloc for the size of the image, and then for each section:

WriteProcessMemory(this->hProcess, MakePtr(LPVOID, this->dwModuleBase, header->VirtualAddress), MakePtr(LPCVOID, this->bDll, header->PointerToRawData), header->SizeOfRawData, NULL); 

[wav]

Oh I didn't know about the .reloc, thanks
I do 1 alloc for the size of the image, and then for each section:

WriteProcessMemory(this->hProcess, MakePtr(LPVOID, this->dwModuleBase, header->VirtualAddress), MakePtr(LPCVOID, this->bDll, header->PointerToRawData), header->SizeOfRawData, NULL); 

You should adjust the protections based on each section to avoid bunching the memory regions together, preferably insert dummy regions in between filled with garbage or VirtualFree.

In reality you shouldn't have a .rdata section at all. All you should have is a mapped .text section and a mapped .data section.