1

Topic: The list of loaded DLL units

All kind time of days! OS Win 8.1 x64 Is 2 utilities: ProcessHacker and ListDlls64 from Russinovicha. ListDlls64 reads the list loaded in process DLL from PEB'a, and ProcessHacker receives the process list through NtQueryVirtualMemory (MemoryBasicInformation), i.e. through VAD. These lists differ. There is a sensation that some DLL  on address space of process, instead of are loaded through LoadLibrary... For example, at process svchost.exe are present wevtapi.dll, winlogon.exe, tquery.dll, which miss in PEB. Such piece is tracked on all OS since Vista. On XP the such did not note. Somebody can prompt for what and how it is made? Thankful in advance!

2

Re: The list of loaded DLL units

Can they were are loaded by means of LoadLibraryEx with new flags which were not supported earlier?

3

Re: The list of loaded DLL units

Hello, VTT, you wrote: VTT> Can they were are loaded by means of LoadLibraryEx with new flags which were not supported earlier? Probably... Looked more in detail, ProcessHacker them like highlights as Relocated Dlls.

4

Re: The list of loaded DLL units

Hello, - prus - you wrote: P> <...> P> Such piece is tracked on all OS since Vista. On XP the such did not note. P> Somebody can prompt for what and how it is made? Such behavior was always. In PEB are not located DLL, loaded, for example, with flag LOAD_LIBRARY_AS_DATAFILE (2). Also such files to separate addresses (as are not intended for execution) are projected: if to load library LOAD_LIBRARY_AS_DATAFILE, and then normal LoadLibrary (...) That in PEB' will be record from the second loading, and in address space two areas anchored to one file (loading two address): 0:001>! peb PEB at 000007fffffda000 <...> Ldr. Initialized: Yes Ldr. InInitializationOrderModuleList: 00000000002b5760. 0000000000323830 Ldr. InLoadOrderModuleList: 00000000002b5650. 0000000000323cb0 Ldr. InMemoryOrderModuleList: 00000000002b5660. 0000000000323cc0 Base TimeStamp Module <...> 7fefefb0000 57d2fd80 Sep 09 9:20:48 PM 2016 C:\Windows\system32\advapi32.dll <...> 0:001>! address BaseAddress EndAddress+1 RegionSize Type State Protect Usage-------------------------------------------------------------------------------------------------------------------------- <...> 0 ` 00418000 0 ` 004b0000 0 ` 00098000 MEM_PRIVATE MEM_RESERVE Heap [ID: 3; Handle: 0000000000240000; Type: Segment] + 0 ` 004b0000 0 ` 00587000 0 ` 000d7000 MEM_MAPPED MEM_COMMIT PAGE_READONLY MappedFile "\Device\HarddiskVolume1\Windows\System32\advapi32.dll" + 0 ` 00587000 0 ` 00590000 0 ` 00009000 MEM_FREE PAGE_NOACCESS Free <...> + 7fe ` febbd000 7fe ` fefb0000 0 ` 003f3000 MEM_FREE PAGE_NOACCESS Free + 7fe ` fefb0000 7fe ` fefb1000 0 ` 00001000 MEM_IMAGE MEM_COMMIT PAGE_READONLY Image [advapi32; "C:\Windows\system32\advapi32.dll"] 7fe ` fefb1000 7fe ` ff026000 0 ` 00075000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READ Image [advapi32; "C:\Windows\system32\advapi32.dll"] 7fe ` ff026000 7fe ` ff058000 0 ` 00032000 MEM_IMAGE MEM_COMMIT PAGE_READONLY Image [advapi32; "C:\Windows\system32\advapi32.dll"] 7fe ` ff058000 7fe ` ff05d000 0 ` 00005000 MEM_IMAGE MEM_COMMIT PAGE_READWRITE Image [advapi32; "C:\Windows\system32\advapi32.dll"] 7fe ` ff05d000 7fe ` ff08b000 0 ` 0002e000 MEM_IMAGE MEM_COMMIT PAGE_READONLY Image [advapi32;" C:\Windows\system32\advapi32.dll "] + 7fe ` ff08b000 7fe ` ff310000 0 ` 00285000 MEM_FREE PAGE_NOACCESS Free <...>

5

Re: The list of loaded DLL units

Hello, EreTIk, you wrote: ETI> Such behavior was always. In PEB are not located DLL, loaded, for example, with flag LOAD_LIBRARY_AS_DATAFILE (2). And most it is program possible to learn somehow, what DLL it is loaded with flag LOAD_LIBRARY_AS_DATAFILE?

6

Re: The list of loaded DLL units

Hello, - prus - you wrote: P> Hello, EreTIk, you wrote: ETI>> Such behavior was always. In PEB are not located DLL, loaded, for example, with flag LOAD_LIBRARY_AS_DATAFILE (2). P> And most it is program possible to learn somehow, what DLL it is loaded with flag LOAD_LIBRARY_AS_DATAFILE? At this storage MEMORY_BASIC_INFORMATION:: Type will be not MEM_IMAGE, and MEM_MAPPED (exhaust WinDbg above, a command see! address, column Type).

7

Re: The list of loaded DLL units

Hello, EreTIk, you wrote: ETI> At this storage MEMORY_BASIC_INFORMATION:: Type will be not MEM_IMAGE, and MEM_MAPPED (exhaust WinDbg above, a command see! address, column Type). The strange business then.... I at myself check if ((Mbi. State and MEM_COMMIT) && (Mbi. Type and MEM_IMAGE))) {NtQueryVirtualMemory (MemoryMappedFilenameInformation)} but all the same in PEB there are no these DLL which describes MEMORY_BASIC_INFORMATION.

8

Re: The list of loaded DLL units

Hello, - prus - you wrote: P> the Strange business then.... I at myself check P> P> if ((Mbi. State and MEM_COMMIT) && (Mbi. Type and MEM_IMAGE))) P> {P> NtQueryVirtualMemory (MemoryMappedFilenameInformation) P>} P> P> but all the same in PEB there are no these DLL which describes MEMORY_BASIC_INFORMATION. Then, probably, it is loading with flag LOAD_LIBRARY_AS_IMAGE_RESOURCE. By my machine (Win2k8R2): 0:001>! peb PEB at 000007fffffd9000 <...> Ldr. InMemoryOrderModuleList: 00000000001556c0. 0000000000155ca0 Base TimeStamp Module 13fb40000 58188a32 Nov 01 3:27:30 PM 2016 D:\Projects\Test.exe 77680000 57d2fde1 Sep 09 9:22:25 PM 2016 C:\Windows\SYSTEM32\ntdll.dll 77460000 57d2fe26 Sep 09 9:23:34 PM 2016 C:\Windows\system32\kernel32.dll 7fefd410000 57d2fe27 Sep 09 9:23:35 PM 2016 C:\Windows\system32\KERNELBASE.dll SubSystemData: 0000000000000000 <...> 0:001>! address <. .> + 7fe ` fd47a000 7fe ` fefb0000 0 ` 01b36000 MEM_FREE PAGE_NOACCESS Free + 7fe ` fefb0000 7fe ` fefb1000 0 ` 00001000 MEM_IMAGE MEM_COMMIT PAGE_READONLY <unknown> [MZ..............] 7fe ` fefb1000 7fe ` ff026000 0 ` 00075000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READ <unknown> [H.......... i. H.] 7fe ` ff026000 7fe ` ff058000 0 ` 00032000 MEM_IMAGE MEM_COMMIT PAGE_READONLY <unknown> [................] 7fe ` ff058000 7fe ` ff05d000 0 ` 00005000 MEM_IMAGE MEM_COMMIT PAGE_WRITECOPY <unknown> [X......] 7fe ` ff05d000 7fe ` ff08b000 0 ` 0002e000 MEM_IMAGE MEM_COMMIT PAGE_READONLY <unknown> [.... D....... D...] + 7fe ` ff08b000 7fe ` ff9a0000 0 ` 00915000 MEM_FREE PAGE_NOACCESS Free <...> I do not know, why WinDbg cannot define a name but: it precisely advapi32.dll 0:001>! dh 7fe ` fefb0000 File Type: DLL FILE HEADER VALUES <...> Debug Directories (2) Type Size Address Pointer cv 25 75c34 75034 Format: RSDS, guid, 2, advapi32.pdb (10 4 75c30 75030 <...> Call NtQueryVirtualMemory (..., MemoryMappedFilenameInformation...) on this section returns: "\Device\HarddiskVolume1\Windows\System32\advapi32.dll" P.S. How to understand that it is a call was LOAD_LIBRARY_AS_IMAGE_RESOURCE - I do not know.

9

Re: The list of loaded DLL units

Hello, EreTIk, you wrote: ETI> Then, probably, it is loading with flag LOAD_LIBRARY_AS_IMAGE_RESOURCE. By my machine (Win2k8R2): ETI> P.S. How to understand that it is a call was LOAD_LIBRARY_AS_IMAGE_RESOURCE - I do not know. I will try  still. Thanks anyway.

10

Re: The list of loaded DLL units

Hello, EreTIk, you wrote: ETI> Then, probably, it is loading with flag LOAD_LIBRARY_AS_IMAGE_RESOURCE. By my machine (Win2k8R2): ETI> P.S. How to understand that it is a call was LOAD_LIBRARY_AS_IMAGE_RESOURCE - I do not know. In docks at MS there are three macroes: #define LDR_IS_DATAFILE (handle) (((ULONG_PTR) (handle)) and (ULONG_PTR) 1) #define LDR_IS_IMAGEMAPPING (handle) (((ULONG_PTR) (handle)) and (ULONG_PTR) 2) #define LDR_IS_RESOURCE (handle) (LDR_IS_IMAGEMAPPING (handle) || LDR_IS_DATAFILE (handle)) Looked the Internet found that to these macroes feed result of call GetModuleHandle () (or LoadLibraryEx ()): HMODULE hKernel =:: GetModuleHandle (L "kernel32.dll"); if (! hKernel || LDR_IS_RESOURCE (hKernel)) {_ASSERTE (hKernel &&! LDR_IS_RESOURCE (hKernel)); return 0;} It what is necessary? However I in a kernel need to do such feint so to me it is necessary GetModuleHandle () in a kernel? While it found only. It can serve as a starting point? Or it at all there I look?

11

Re: The list of loaded DLL units

Hello, - prus - you wrote: P> Hello, EreTIk, you wrote: ETI>> Then, probably, it is loading with flag LOAD_LIBRARY_AS_IMAGE_RESOURCE. By my machine (Win2k8R2): ETI>> P.S. How to understand that it is a call was LOAD_LIBRARY_AS_IMAGE_RESOURCE - I do not know. P> in docks at MS there are three macroes: P> P>#define LDR_IS_DATAFILE (handle) (((ULONG_PTR) (handle)) and (ULONG_PTR) 1) P>#define LDR_IS_IMAGEMAPPING (handle) (((ULONG_PTR) (handle)) and (ULONG_PTR) 2) P>#define LDR_IS_RESOURCE (handle) (LDR_IS_IMAGEMAPPING (handle) || LDR_IS_DATAFILE (handle)) P> P> Looked the Internet found that to these macroes feed result of call GetModuleHandle () (or LoadLibraryEx ()): P> P> HMODULE hKernel =:: GetModuleHandle (L "kernel32.dll"); P> if (! hKernel || LDR_IS_RESOURCE (hKernel)) P> {P> _ASSERTE (hKernel &&! LDR_IS_RESOURCE (hKernel)); P> return 0; P>} P> P> It what is necessary? Aha, it is similar to that P> However me in a kernel it is necessary to do such feint so to me it is necessary GetModuleHandle () in a kernel? While it found only. It can serve as a starting point? P> or it at all there I look? Not there. These are functions of operation with the units loaded in a kernel (for units of a kernel there is no loading "as a resource"). It takes necessary to look whence user-mod'naja function GetModuleHandle (...) this flag and to read it from this a source.

12

Re: The list of loaded DLL units

Hello, EreTIk, you wrote: ETI> It is necessary to look whence user-mod'naja function GetModuleHandle (...) Takes this flag and to read it from this a source.  KernelBase.dll, in particular LoadLibraryEx (). There if the call happens to flags LOAD_LIBRARY_AS_DATAFILE, LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE or LOAD_LIBRARY_AS_IMAGE_RESOURCE further this DLL is loaded through BasepLoadLibraryAsDataFileInternal (). In it to basic addresses it is added either 1, or 2:... v6 = (unsigned int) BaseAddress | 2;...... v6 = (unsigned int) BaseAddress | 1;... But in my case at DLL which are not present in PEB, the basic address, for example, 0x6F070000 or 0x01130000. Tried to load itself DLL through LoadLibraryEx (LOAD_LIBRARY_AS_IMAGE_RESOURCE) and then to me it was really returned HMODULE=0x0f100002. It turns out, what they still are somehow loaded? Simply ? I can not while for what to be hooked...

13

Re: The list of loaded DLL units

Hello, - prus - you wrote: P>... P> But in my case at DLL which are not present in PEB, the basic address, for example, 0x6F070000 or 0x01130000. P> Tried to load itself DLL through LoadLibraryEx (LOAD_LIBRARY_AS_IMAGE_RESOURCE) and then to me it was really returned HMODULE=0x0f100002. P> it turns out, what they still are somehow loaded? Simply ? I can not while for what to be hooked... Values 1 and 2 it is a flag which is returned as a result of call LoadLibraryEx. Really DLL are loaded with  addresses (that is at reset 0x0f100002 from LoadLibraryEx the real address of loading - 0x0f100000). Once again re-read: P> Looked at the Internet found that to these macroes feed result of call GetModuleHandle () (or LoadLibraryEx ()): P> P> HMODULE hKernel =:: GetModuleHandle (L "kernel32.dll"); P> if (! hKernel || LDR_IS_RESOURCE (hKernel)) P> {P> _ASSERTE (hKernel &&! LDR_IS_RESOURCE (hKernel)); P> return 0; P>} P> P> It what is necessary? No, this incorrect applied a macro from description LoadLibraryEx (...) to GetModuleHandle (...). GetModuleHandle does not return the address of loading for DLL, loaded with flag LOAD_LIBRARY_AS_IMAGE_RESOURCE (checked up experimentally). Moreover, at attempt of repeated same loading DLL with the same flag LOAD_LIBRARY_AS_IMAGE_RESOURCE the file is again projected to the new address. Of what it is possible to make the assumption that user mode does not store list DLL, loaded LOAD_LIBRARY_AS_IMAGE_RESOURCE. Otherwise it would be logical to assume that at repeated attempt of loading happens  the counter and reset of the address first loading (as it becomes for normal LoadLibrary).

14

Re: The list of loaded DLL units

Hello, EreTIk, you wrote: ETI> Moreover, at attempt of repeated same loading DLL with the same flag LOAD_LIBRARY_AS_IMAGE_RESOURCE the file is again projected to the new address. Of what it is possible to make the assumption that user mode does not store list DLL, loaded LOAD_LIBRARY_AS_IMAGE_RESOURCE. Otherwise it would be logical to assume that at repeated attempt of loading happens  the counter and reset of the address first loading (as it becomes for normal LoadLibrary). As a result, how I understood, being transited on VAD, I cannot cut these here units in any way which in PEB are not present?

15

Re: The list of loaded DLL units

Hello, - prus - you wrote: ETI>> Moreover, at attempt of repeated same loading DLL with the same flag LOAD_LIBRARY_AS_IMAGE_RESOURCE the file is again projected to the new address. Of what it is possible to make the assumption that user mode does not store list DLL, loaded LOAD_LIBRARY_AS_IMAGE_RESOURCE. Otherwise it would be logical to assume that at repeated attempt of loading happens  the counter and reset of the address first loading (as it becomes for normal LoadLibrary). P> As a result how I understood, being transited on VAD, I cannot cut these here units in any way which in PEB are not present? To me such method is not known.

16

Re: The list of loaded DLL units

Hello, EreTIk, you wrote: ETI> To me such method is not known. Thanks, very much helped!

17

Re: The list of loaded DLL units

P> Thankful in advance! Besides mentioned  for LoadLibraryEx  could be created direct call CreateFileMapping (SEC_IMAGE)/MapViewOfFile. Well or ntdll! NtCreateSection/NtMapViewOfSection. What for so to do - a question separate. But I did it for app virtualization.

18

Re: The list of loaded DLL units

Hello, - prus - you wrote: P> Such piece is tracked on all OS since Vista. On XP the such did not note. P> Somebody can prompt for what and how it is made? How like to ask on  forums - and what for the task you generally solve? What you want "being transited on VAD, to cut units which in PEB are not present" clearly, but it is necessary for the decision of what task, if not a secret certainly?

19

Re: The list of loaded DLL units

Hello, rumit7, you wrote: R> As like to ask on  forums - and what for the task you generally solve? R> what you want "being transited on VAD, to cut units which in PEB are not present" clearly, but it is necessary for the decision of what task, if not a secret certainly? Yes, , it was necessary to make it at once...  for a long time I needed to search hidden of PEB (DLL units. Decided that to me will enough compare the list in PEB and the list which I receive being transited on VAD with determination of a name of the unit to which posesses pages through NtQueryVirtualMemory (MemoryMappedFilenameInformation). Ononim like then still told that idea not so sensible, but nevertheless... Since Vista appear DLL which are not present in PEB and they look as hidden in my logic. Simply wanted to correct and try to cut as-nibut these most legitimate units. Somehow so.

20

Re: The list of loaded DLL units

R>> As like to ask on  forums - and what for the task you generally solve? R>> what you want "being transited on VAD, to cut units which in PEB are not present" clearly, but it is necessary for the decision of what task, if not a secret certainly? P> yes, , it was necessary to make it at once... P> Davnym for a long time I needed to search hidden of PEB (DLL units. Decided that to me will enough compare the list in PEB and the list which I receive being transited on VAD with determination of a name of the unit to which posesses pages through NtQueryVirtualMemory (MemoryMappedFilenameInformation). Ononim like then still told that idea not so sensible, but nevertheless... P> Since Vista appear DLL which are not present in PEB and they look as hidden in my logic. Simply wanted to correct and try to cut as-nibut these most legitimate units. Somehow so. Well, if these units absolutely standard and , I advise to receive stupidly ways to these files and then to check up their signature.

21

Re: The list of loaded DLL units

Hello, ononim, you wrote: O> Well if these units absolutely standard and , I advise to receive stupidly ways to these files and then to check up their signature. Here thanks, it is necessary to try...

22

Re: The list of loaded DLL units

Hello, ononim, you wrote: O> Well if these units absolutely standard and , I advise to receive stupidly ways to these files and then to check up their signature. Does not roll, returns TRUST_E_NOSIGNATURE, for example, for SystemRoot\tquery.dll. But for ndis.sys works. But all the same thanks, will be useful on the future.

23

Re: The list of loaded DLL units

O>> Well if these units absolutely standard and , I advise to receive stupidly ways to these files and then to check up their signature. P> does not roll, returns TRUST_E_NOSIGNATURE, for example, for SystemRoot\tquery.dll. But for ndis.sys works. But all the same thanks, will be useful on the future. And VerifyCatalogSignature does not work?

24

Re: The list of loaded DLL units

Hello, ononim, you wrote: O> Well if these units absolutely standard and , I advise to receive stupidly ways to these files and then to check up their signature. How much I remember many Majkrosoftovsky dll are not signed absolutely not. I would try to combine signature check (catalog/embedded signing) where signer name should is in your list entrusted, and check using function SfcIsFileProtected. UPD: However in this case for "tquery.dll" signature all is available (catalog signing), checked on Windows8.1x86.

25

Re: The list of loaded DLL units

O>> Well if these units absolutely standard and , I advise to receive stupidly ways to these files and then to check up their signature. R> how much I remember many Majkrosoftovsky dll are not signed absolutely not. R> I would try to combine signature check (catalog/embedded signing) where signer name should is in your list entrusted, and check using function SfcIsFileProtected. R> UPD: However in this case for "tquery.dll" signature all is available (catalog signing), checked on Windows8.1x86. They are signed through the directory. Therefore I also specified the Author: ononim Date: 03.11 19:44