[EP_X0FF]

my driver preventing any kind of injection

so winxp sp1 and sp2 can have diferent callback indexes? damn :(

Then I can only suggest to filter access to process you are trying to protect. IDK if they are different from SP to SP, but they are different for XP/2003/Vista/7. Check symbols.

[listito]

actually I was thinking about to protect all processes from and specific dll to be injected, that could be acomplished with a notify kernel callback registration i guess, i dont have much experience in ring0 but i'm gonna try to do it :)

[Brock]

Keep in mind of modules in which are loaded without the aid of the Windows PE loader, custom written loaders ;)
I guess for better understanding I mean the documented Windows API requires a module prior to loading to reside on disk, memory loading is an entire different story.

[listito]

well, that reminds me a thing i tried to do some time ago with no success, it was unmapping a dll from memory, freelibrary can't do that, how can we force the dll to be unmapped from the current process address space?

[Brock]

That is a forced FreeLibrary you refer to. FreeLibrary API needs a valid module handle, more importantly, a module which a PE header is not say zeroed out for example or modified. Some might try and decommit the pages and free them via the loaded module base, but this will just cause issues in the end. Freeing a library which you have not loaded can be unpredictable. You could however, if no PEB hacks or header hacks exist, zero out the entry point (LdrMod + 0x1C (x86)) and then try FreeLibrary, but if a hook is installed this will also cause a crash when that respective API is called, since the module is now freed the memory area will now most likely not be resident anymore (you can allocate virtual pages outside the DLL space however and copy your hook code). I guess what I mean to say is, freeing a library which you do not own is never a safe thing to do, period.

[listito]

That is a forced FreeLibrary you refer to. FreeLibrary API needs a valid module handle, more importantly, a module which a PE header is not say zeroed out for example or modified. Some might try and decommit the pages and free them via the loaded module base, but this will just cause issues in the end. Freeing a library which you have not loaded can be unpredictable. You could however, if no PEB hacks or header hacks exist, zero out the entry point (LdrMod + 0x1C) and then try FreeLibrary, but if a hook is installed this will also cause a crash when that respective API is called, since the module is now freed the memory area will now most likely not be resident anymore. I guess what I mean to say is, freeing a library which you do not own is never a safe thing to do, period.

thanks brock, but which would be the safest, decommiting+free or calling freelibrary with zero out entrypoint?

another thing that comes to my mind now, i just tried ntillusion method to make a dll stealth, but didn't work against process explorer, what if i want to rename the dll which is already loaded using a simillar method(overwriting the structure), would that work?( sorry for the questions, but i got tons of questions in my mind )

[Brock]

Stability wise, calling FreeLibrary/LdrUnloadDll(hModule) would be the safest bet since the LdrLock would be engaged and the DLL would receive DLL_PROCESS_DETACH events (i.e> cleanup of something like a hook if installed to unregister it, if author has planned for dynamic loading/unloading... otherwise LoL). If that does not work, suspect would be code within the DLLMain, if present. So, NULLing out the Entrypoint and repeating the process could possibly be an alternative. Any decommitting and/or freeing of pages behind a loaded module's back is unwise from a "stability" perspective. Again, to clarify, none of this would lead to a stable module unloading since a lot of code could be executing within that loaded module.

The main principle for stability is, do not access/modify memory that u have not previously allocated or attempt to free it without said previous ownership. Anything out of your allocation control is subject to act unreliably. But of course, that is not fun huh ;)

[Brock]

I believe Process Explorer uses the GetMappedFileNameA/W API exported from psapi.dll or it uses NtQueryVirtualMemory directly. Anyhow, ntdll.dll!NtQueryVirtualMemory can check for the memory section name of the loaded module even when the PEB entries are erased. VAD node / leaf erasing or linked-list reassignment in kernel mode can bypass this easily when it comes to enumerating for said module(s).

My own version of GetMappedFileName looks like this in a nutshell:

Code: Select all

function GetMappedFileName(const hProcess: ULONG; lpV: Pointer; lpFileName: PAnsiChar; nSize: ULONG): ULONG; stdcall;
var
   Ret: ULONG;
    us: PUNICODE_STRING;
const
    MEM_SECTION_NAME = 2;
    AllocSz = (MAX_PATH * sizeof(WCHAR)) + (sizeof(WORD) * 2) + sizeof(DWORD);
begin
     result := 0;
     if (hProcess > 0) and (nSize > 0) and (lpFileName <> nil) then
     begin
      us := VirtualAlloc(nil, AllocSz, MEM_COMMIT, PAGE_READWRITE);
     if us <> nil then
     begin
      if (NtQueryVirtualMemory(hProcess, lpV, MEM_SECTION_NAME, us, AllocSz, @Ret) = 0) and (Ret <> DWORD(-1)) then
      begin
        if (nSize >= (us^.Len div sizeof(WCHAR))) then
         result := WideCharToMultiByte(CP_ACP, 0, us^.Buf, -1, lpFileName, us^.Len, nil, nil) - 1
      else
         SetLastError(ERROR_INSUFFICIENT_BUFFER);
      end;
      VirtualFree(us, 0, MEM_RELEASE);
      end;
   end;
end;

[listito]

i'd never expect a win internals pro coding in dephi hehe, just kidding, thanks brock

[Brock]

Quite welcome, just as proficient in asm and c too :lol: The new Delphi XE2 compiler has support for 32/64-bit Windows native compilation as well as support for x-platforms such as iOS (Apple OS) and even Mac OS. I definitely enjoy Delphi as I've been at it since the mid-90's.