From this page, KBDLLHOOKSTRUCT is defined as:
typedef struct tagKBDLLHOOKSTRUCT {
DWORD vkCode;
DWORD scanCode;
DWORD flags;
DWORD time;
ULONG_PTR dwExtraInfo;
} KBDLLHOOKSTRUCT, *LPKBDLLHOOKSTRUCT, *PKBDLLHOOKSTRUCT;
Field vkCode has type DWORD. According to this page DWORD is defined as A 32-bit unsigned integer.
However, the field docs say: The code must be a value in the range 1 to 254.
Is there an undocumented purpose for the additional 3 bytes of data in this field? Or is this either (a) byte alignment concerns or (b) future expansion of virtual key codes?
I am trying to use the RegGetValueA() from the Windows API , but so far I've been unable to get any results from it. At best, I get a "file not found" error, and at worst it crashes hard without any error messages at all.
Below is the current code I have; I'm not sure what is and isn't relevant, and what might be causing the problem or not. I've only got a smidge of C knowledge, so please try to keep it simple.
ffi.cdef([[
typedef void * HKEY;
typedef HKEY * PHKEY;
typedef unsigned long DWORD;
int RegGetValueA(HKEY handle, const char* path, const char* value, int filter_flags, void* unused, char *result, DWORD* size);
]])
local size = ffi.new('DWORD[1]')
size = 1024
local data = ffi.new('char['..size..']')
local dptr = ffi.cast('char*', data)
local lenptr = ffi.cast('DWORD*', size)
test = reg.RegGetValueA(ffi.cast("HKEY", ffi.cast("uintptr_t",0x80000002)), "SOFTWARE\\Microsoft\\Speech\\Voices\\Tokens\\CereVoice Heather 5.0.1", "CLSID", 0x0000ffff, nil, dptr, lenptr)
When you use ffi.new, what you get is a pointer variable, and you assign the pointer to 1024, and then use ffi.cast to convert to DWORD *, which causes an access address conflict when calling RegGetValueA, so the program crashes.
You only need to modify the code as follows:
local ffi = require("ffi")
ffi.cdef([[
typedef void * HKEY;
typedef HKEY * PHKEY;
typedef unsigned long DWORD;
int RegGetValueA(HKEY handle, const char* path, const char* value, int
filter_flags, void* unused, char *result, DWORD* size);
]])
local size = 1024
local data = ffi.new('char['..size..']')
local dptr = ffi.cast('char*', data)
local lenptr = ffi.new('DWORD[1]', size)
local test = ffi.C.RegGetValueA(ffi.cast("HKEY", ffi.cast("uintptr_t",0x80000002)), "SOFTWARE\\Microsoft\\Speech\\Voices\\Tokens\\CereVoice Heather 5.0.1", "CLSID", 0x0000ffff, nil, dptr, lenptr)
print(test)
print(ffi.string(dptr))
I get a "file not found" error
This means "registry key not found".
There are two different registries in 64-bit Windows, you should try reading from both of them:
local ffi = require'ffi'
ffi.cdef"int RegGetValueA(uintptr_t, const char*, const char*, uint32_t, void*, char*, uint32_t*);"
local size = 1024
local pcbData = ffi.new'uint32_t[1]'
local pvData = ffi.new('char[?]', size)
local RRF_SUBKEY_WOW6464KEY = 0x00010000
local RRF_SUBKEY_WOW6432KEY = 0x00020000
for _, WOW64_flag in ipairs{RRF_SUBKEY_WOW6464KEY, RRF_SUBKEY_WOW6432KEY} do
pcbData[0] = size
local errcode = ffi.C.RegGetValueA(
0x80000002, -- HKLM
"SOFTWARE\\Microsoft\\Speech\\Voices\\Tokens\\MS-Anna-1033-20-DSK",
"CLSID",
0x0000ffff + WOW64_flag,
nil,
pvData,
pcbData
)
if errcode == 0 then
break
end
end
print(ffi.string(pvData))
My question is about cryptoAPI interface.
Look, CertEnumSystemStoreLocation() is a function to enumerate all certificate store locations available in system. It returns (using callback) enumerated location as wide string (LPCWSTR).
CertEnumSystemStore() enumerates stores by the given location. It takes integer constant for location (DWORD) as argument.
I tried to enumerate locations and the result was a list of strings, that semantically is equal to the list of DWORD location constants from CryptoAPI import module.
And my question is: what should i do to translate wide string representation of store location to DWORD constant? Is there a cryptoAPI function (or, at least, commonly used method) for it?
It looks like the dwFlags passed to your CertEnumSystemStoreLocationCallback callback function actually gives you the store location constant, although this is incredibly badly documented.
The example shown here for Listing System and Physical Stores handles the dwFlags value in its callback like this:
dwFlags &= CERT_SYSTEM_STORE_MASK;
dwFlags |= pEnumArg->dwFlags & ~CERT_SYSTEM_STORE_LOCATION_MASK;
CertEnumSystemStore(dwFlags, ...);
So I think if you do that masking you'll be left with the location constant in dwFlags equivalent to the string passed in the pvszStoreLocation parameter.
The dwFlags argument passed to the CertEnumSystemStoreLocationCallback callback function contains the store location encoded in the bits CERT_SYSTEM_STORE_LOCATION_MASK. Shifting those to the right by CERT_SYSTEM_STORE_LOCATION_SHIFT turns it into the numeric store ID.
The following code retrieves the list of store locations alongside the numeric store IDs:
Structure for communication:
#include <SDKDDKVer.h>
#include <windows.h>
#include <wincrypt.h>
#pragma comment(lib, "Crypt32.lib")
#include <vector>
#include <string>
#include <iostream>
struct Location {
DWORD StoreId;
std::wstring Name;
};
typedef std::vector<Location> StoreLocationsContainer;
Callback:
BOOL WINAPI CertEnumSystemStoreLocationCallback( LPCWSTR pvszStoreLocations,
DWORD dwFlags,
void* pvReserved,
void* pvArg
) {
StoreLocationsContainer& locations = *reinterpret_cast<StoreLocationsContainer*>( pvArg );
DWORD StoreId = ( dwFlags & CERT_SYSTEM_STORE_LOCATION_MASK )
>> CERT_SYSTEM_STORE_LOCATION_SHIFT;
Location location = { StoreId, std::wstring( pvszStoreLocations ) };
locations.push_back( location );
return TRUE;
}
Implementation:
StoreLocationsContainer GetStoreLocations() {
StoreLocationsContainer locations;
if ( !::CertEnumSystemStoreLocation( 0x0,
&locations,
CertEnumSystemStoreLocationCallback ) ) {
throw std::runtime_error( "CertEnumSystemStoreLocation" );
}
return locations;
}
For completeness, here is the remaining code to dump all stores across all locations:
BOOL WINAPI CertEnumSystemStoreCallback( const void* pvSystemStore,
DWORD dwFlags,
PCERT_SYSTEM_STORE_INFO pStoreInfo,
void* pvReserved,
void* pvArg ) {
std::wcout << L" " << static_cast<const wchar_t*>( pvSystemStore ) << std::endl;
return TRUE;
}
void PrintStores( const StoreLocationsContainer& locations ) {
for ( const Location& loc : locations ) {
std::wcout << loc.Name << std::endl;
DWORD dwFlags = ( loc.StoreId << CERT_SYSTEM_STORE_LOCATION_SHIFT )
& CERT_SYSTEM_STORE_LOCATION_MASK;
::CertEnumSystemStore( dwFlags, nullptr, nullptr, CertEnumSystemStoreCallback );
}
}
int main() {
StoreLocationsContainer locations = GetStoreLocations();
PrintStores( locations );
return 0;
}
typedef struct _FILE_BOTH_DIR_INFORMATION {
ULONG NextEntryOffset;
ULONG FileIndex;
LARGE_INTEGER CreationTime;
LARGE_INTEGER LastAccessTime;
LARGE_INTEGER LastWriteTime;
LARGE_INTEGER ChangeTime;
LARGE_INTEGER EndOfFile;
LARGE_INTEGER AllocationSize;
ULONG FileAttributes;
ULONG FileNameLength;
ULONG EaSize;
CCHAR ShortNameLength;
WCHAR ShortName[12];
WCHAR FileName[1];
} FILE_BOTH_DIR_INFORMATION, *PFILE_BOTH_DIR_INFORMATION;
FileNameLength is declared ULONG. I guessed this is byte-count because all(or most) string lengths are byte-count in the kernel.
Yesterday, I wrote wrong code, because I misunderstood that it means count of char when I see CCHAR ShortNameLength. Now, I know ShortNameLength requires bytes-count.
Then, what does C mean in CCHAR?
C means count in Hungarian Notation. A variable named cch would be a "count of chars" and you would expect it to contain a string length. So CCHAR is the type that can contain a count of chars.
It's a horrible abuse of Hungarian notation typical of the Windows team.
For 32-bit Windows, following declaration of _SYSTEM_PROCESSES structure ( System Information Class 5 ) with ZwQuerySystemInformation works fine for my purpose to construct process tree.
typedef struct _SYSTEM_PROCESSES
{ // System Information Class 5
ULONG NextEntryDelta;
ULONG ThreadCount;
ULONG Reserved1[6];
LARGE_INTEGER CreateTime;
LARGE_INTEGER UserTime;
LARGE_INTEGER KernelTime;
UNICODE_STRING ProcessName;
ULONG BasePriority;
ULONG ProcessId;
ULONG InheritedFromProcessId;
ULONG HandleCount;
ULONG Reserved2[2];
} SYSTEM_PROCESSES, * PSYSTEM_PROCESSES;
On the other hand, it doesn't function well in 64-bit Windows. If I declare the ProcessId as ULONG64, then the data for ProcessId comes right. Is the datatype defined for above structure is right for Windows-64?
For some weird reason, process and thread id's are 64bit in the kernel and 32bit in the documented windows api on x64
If you look at SYSTEM_PROCESS_INFORMATION # ntinternals you see that they have declared the PID's as HANDLE (pointer sized)