1

Topic: From application 32-bit to learn that process uses more 4GB storages

All greetings! It is possible to learn somehow from application 32-bit, how many storages are used by other process provided that it uses more 4GB storages? GetProcessMemoryInfo returns value of type SIZE_T. For 32 bits is to 4 GB.

2

Re: From application 32-bit to learn that process uses more 4GB storages

Hello, maks __, you wrote: __> GetProcessMemoryInfo returns value of type SIZE_T. For 32 bits is to 4 GB. If absolutely  does not help, SIZE_T under x64 it is 64-bit type. It is possible to load directly appropriate function from System32 and to feed to it the structure with 64-bit variables.

3

Re: From application 32-bit to learn that process uses more 4GB storages

Hello, CEMb, you wrote: CEM> If absolutely  does not help, SIZE_T under x64 it is 64-bit type. It is possible to load directly appropriate function from System32 and to feed to it the structure with 64-bit variables. It is offered reach to invisibly present 64-bit ntdll.dll in Wow64-process, and to cause therefrom  NtQueryInformationProcess, corresponding GetProcessMemoryInfo? In the theory the perversion is possible, probably, but that still...

4

Re: From application 32-bit to learn that process uses more 4GB storages

CEM>> If absolutely  does not help, SIZE_T under x64 it is 64-bit type. It is possible to load directly appropriate function from System32 and to feed to it the structure with 64-bit variables. AG> It is offered reach to invisibly present 64-bit ntdll.dll in Wow64-process, and to cause therefrom  NtQueryInformationProcess, corresponding GetProcessMemoryInfo? AG> In the theory the perversion is possible, probably, but that still... Probably but . I even the 64  loaded in wow64 process and pulled it methods. Here : http://blog.rewolf.pl/blog/?p=102 but it is not so actual. In the modern Windows here something exchanged with stack switching.

5

Re: From application 32-bit to learn that process uses more 4GB storages

CEM>>> If absolutely  does not help, SIZE_T under x64 it is 64-bit type. It is possible to load directly appropriate function from System32 and to feed to it the structure with 64-bit variables. AG>> It is offered reach to invisibly present 64-bit ntdll.dll in Wow64-process, and to cause therefrom  NtQueryInformationProcess, corresponding GetProcessMemoryInfo? AG>> In the theory the perversion is possible, probably, but that still... O> it is possible but . I even the 64  loaded in wow64 process and pulled it methods. O> here : http://blog.rewolf.pl/blog/?p=102 but it is not so actual. In the modern Windows here something exchanged with stack switching. I can launch from process 32-bit child 64-bit process, in it to make all necessary operation and to hand over the information reversely through memorymap. But I thought, suddenly it is possible somehow through WinApi32 it to make.

6

Re: From application 32-bit to learn that process uses more 4GB storages

Hello, maks __, you wrote: __> All greetings! __> it is possible to learn somehow from application 32-bit, how many storages are used by other process provided that it uses more 4GB storages? __> GetProcessMemoryInfo returns value of type SIZE_T. For 32 bits is to 4 GB. WMI?

7

Re: From application 32-bit to learn that process uses more 4GB storages

CEM>> If absolutely  does not help, SIZE_T under x64 it is 64-bit type. It is possible to load directly appropriate function from System32 and to feed to it the structure with 64-bit variables. AG> It is offered reach to invisibly present 64-bit ntdll.dll in Wow64-process, and to cause therefrom  NtQueryInformationProcess, corresponding GetProcessMemoryInfo? AG> In the theory the perversion is possible, probably, but that still... NtWow64QueryInformationProcess64 by the way here

8

Re: From application 32-bit to learn that process uses more 4GB storages

Hello, bnk, you wrote: bnk> WMI? It can be stopped (it for cases when the program is used in large quantities and it is not known where)

9

Re: From application 32-bit to learn that process uses more 4GB storages

Hello, maks __, you wrote: __> I can launch from process 32-bit child 64-bit process Well here I and I do, but if only for the sake of to count the size of storage - would be separate  to collect, launch, adjust laziness communication, to stop...

10

Re: From application 32-bit to learn that process uses more 4GB storages

Hello, CEMb, you wrote: __>> I can launch from process 32-bit child 64-bit process CEM> Well here I and I do, but if only for the sake of to count the size of storage - would be separate  to collect, launch, adjust laziness communication, to stop... powershell.exe not ?

11

Re: From application 32-bit to learn that process uses more 4GB storages

Hello, maks __, you wrote: __> All greetings! __> it is possible to learn somehow from application 32-bit, how many storages are used by other process provided that it uses more 4GB storages? __> GetProcessMemoryInfo returns value of type SIZE_T. For 32 bits is to 4 GB. With performance counters did not experiment?

12

Re: From application 32-bit to learn that process uses more 4GB storages

CEM>>> If absolutely  does not help, SIZE_T under x64 it is 64-bit type. It is possible to load directly appropriate function from System32 and to feed to it the structure with 64-bit variables. AG>> It is offered reach to invisibly present 64-bit ntdll.dll in Wow64-process, and to cause therefrom  NtQueryInformationProcess, corresponding GetProcessMemoryInfo? AG>> In the theory the perversion is possible, probably, but that still... O> NtWow64QueryInformationProcess64 by the way here Idea good, but it produces only ProcessBasicInformation. It can be used only for obtaining of command line of process.

13

Re: From application 32-bit to learn that process uses more 4GB storages

O>> NtWow64QueryInformationProcess64 by the way here __> Idea good, but it produces only ProcessBasicInformation. __> It can be used only for obtaining of command line of process. I do not think that it is restricted only ProcessBasicInformation.  simply gate in , and one on everything so I think that ProcessVmCounters it too produces a kernel. Simply it needs to feed correct VM_COUNTERS, with 64 fields.

14

Re: From application 32-bit to learn that process uses more 4GB storages

O>>> NtWow64QueryInformationProcess64 by the way here __>> Idea good, but it produces only ProcessBasicInformation. __>> It can be used only for obtaining of command line of process. O> I do not think that it is restricted only ProcessBasicInformation.  simply gate in , and one on everything so I think that ProcessVmCounters it too produces a kernel. Simply it needs to feed correct VM_COUNTERS, with 64 fields. At me it did not turn out. I launched it on Windows 7 with all possible values PROCESSINFOCLASS and lengths of the buffer (the simple loop launched). Also tried zero length of the buffer that it returned the necessary length of the buffer. It always returned STATUS_NOT_IMPLEMENTED except ProcessBasicInformation.

15

Re: From application 32-bit to learn that process uses more 4GB storages

__> At me it did not turn out. __> I launched it on Windows 7 with all possible values PROCESSINFOCLASS and lengths of the buffer (the simple loop launched). Also tried zero length of the buffer that it returned the necessary length of the buffer. It always returned STATUS_NOT_IMPLEMENTED except ProcessBasicInformation. , I here was confused (panting in a mask). . #include <windows.h>//based on http://blog.rewolf.pl/blog/?p=102 #define EM (a) __ asm __ emit (a) #define X64_Start_with_CS (_cs) \EM (0x6A) EM (_cs)/* push _cs */\EM (0xE8) EM (0) EM (0) EM (0) EM (0)/* call $ +5 */\EM (0x83) EM (4) EM (0x24) EM (5)/* add dword [esp], 5 */\EM (0xCB)/* retf */#define X64_End_with_CS (_cs) \EM (0xE8) EM (0) EM (0) EM (0) EM (0)/* call $ +5 */\EM (0xC7) EM (0x44) EM (0x24) EM (4)/* */\EM (_cs) EM (0) EM (0) EM (0)/* mov dword [rsp + 4], _cs */\EM (0x83) EM (4) EM (0x24) EM (0xD)/* add dword [rsp], 0xD */\EM (0xCB)/* retf */#define X64_Prolog () \__ asm push ebp \__ asm lea ebp, [esp + 4] \__ asm sub esp, 32 \__ asm and esp,-8 \ ULONG_PTR arg2 = 0, ULONG_PTR arg3 = 0, ULONG_PTR arg4 = 0, ULONG_PTR arg5 = 0, ULONG_PTR arg6 = 0, ULONG_PTR arg7 = 0, ULONG_PTR arg8 = 0, ULONG_PTR arg9 = 0, ULONG_PTR arg10 = 0) {__ asm {X64_Prolog () mov ecx, [ebp + 8]; mov ecx, [rbp + 8] mov edx, [ebp + 12]; mov ecx, [rbp + 12] EM (0x44) EM (0x8b) EM (0x45) EM (0x10); mov r8d, [rbp + 16] EM (0x44) EM (0x8b) EM (0x4d) EM (0x14); mov r9d, [rbp + 20] mov eax, [ebp + 44]; arg10 push eax mov eax, [ebp + 40]; arg9 push eax mov eax, [ebp + 36]; arg8 push eax mov eax, [ebp + 32]; arg7 push eax mov eax, [ebp + 28]; arg6 push eax mov eax, [ebp + 24]; arg5 push eax sub esp, 32 + 8; expected mov eax, [ebp + 4]; mov eax, [rbp + 4] EM (0x49) EM (0x89) EM (0xca); : GetProcAddress (:: GetModuleHandle (L "ntdll.dll"), name); if (! p) return-1; if (*p! = 0xb8)//not mov eax...? Likely function modified by hook. Such case can be overcomed by loading separate ntdll copy. return-2; return * (PLONG) (p+1);} typedef struct _VM_COUNTERS64 {//Information Class 3 ULONGLONG PeakVirtualSize; ULONGLONG VirtualSize;//<<VM use ULONGLONG PageFaultCount; ULONGLONG PeakWorkingSetSize; ULONGLONG WorkingSetSize; ULONGLONG QuotaPeakPagedPoolUsage; ULONGLONG QuotaPagedPoolUsage; ULONGLONG QuotaPeakNonPagedPoolUsage; ULONGLONG QuotaNonPagedPoolUsage; ULONGLONG PagefileUsage; ULONGLONG PeakPagefileUsage;} VM_COUNTERS64, *PVM_COUNTERS64; int _tmain (int argc, _TCHAR* argv []) {if (argc <2) {return 1;} HANDLE prc =:: OpenProcess (MAXIMUM_ALLOWED, FALSE, _ttoi (argv [1])); if (! prc) {fprintf (stderr, "Process open error: %u\n":: GetLastError ()); return-1;} ULONG64 *rl = new ULONG64 (); VM_COUNTERS64 *info = new VM_COUNTERS64 ();//ensure alignment LONG index = SyscallIndexByName ("NtQueryInformationProcess"); if (index <0) {fprintf (stderr, "Failed to get syscall index: %d\n", index); return index;} ULONG rv = Syscall64_Intel (index, (ULONG_PTR) prc, (ULONG_PTR) 3, (ULONG_PTR) info, (ULONG_PTR) sizeof (*info), (ULONG_PTR) rl); printf ("index=0x%x rv = % x rl = % I64u ws=0x%I64x\n", index, rv, *rl, info-> WorkingSetSize); delete info; delete rl;:: CloseHandle (prc); return 0;}