Hello everyone (sorry my English). There was a time, and decided to write something unusual on VB6, namely to try to write a driver. I must say before that I never wrote a driver and have no programming experience in kernel mode. The driver, according to my idea, will have to read the memory is not available in user mode, namely in the range 0x80000000 - 0xffffffff (in default mode, without IMAGE_FILE_LARGE_ADDRESS_AWARE). Immediately give the driver source code which is obtained:
So, the driver must have an entry point DriverEntry, which causes the controller I/O driver is loaded. In the parameters of a pointer to an object-driver and a pointer to a string containing the name of the registry key corresponding to the loadable driver. In the Init procedure, we create two lines, one with the name of the device, the other with reference to the device name. Because we can not use the runtime kernel mode, it is necessary to create a string in the form of a static array, wrapped in a user-defined type, thereby VB6 allocates memory for the array on the stack. If you use a string that will inevitably be caused by one of the functions for runtime and copy assignment line, and we can not allow that. Then we can call IoCreateDevice, which creates a device object. Device object is the recipient of I/O requests and to him we will access when calling CreateFile function from user mode.
Last edited by The trick; Jul 30th, 2016 at 08:13 AM.
Reason: New version/translation to English
The first parameter is a pointer to an object-driver; the second parameter is 0, then since we do not have the structure of the expansion device, and we do not need to allocate memory; the third parameter we pass the name of the device, it is we need to implement access to the device; fourth parameter passed to the device type (see below). in the fifth, we pass 0 as we have "non-standard device"; in the sixth pass False, because We do not need single-user mode; the last parameter - the output. As the name of the device we have to use a string like \Device\DeviceName (where DeviceName - TrickMemReader), is the name we need to ensure that we can create a link to it, which in turn need to access the device from user mode.
Device type - FILE_DEVICE_MEMREADER. All non-standard devices must be of type or FILE_DEVICE_UNKNOWN, or the number of 0x8000 - 0xffff. I created FILE_DEVICE_MEMREADER constant with a value of 0x8000, which corresponds to the first free number. On success, the device is created and filled structure DEVICE_OBJECT. After the need to create a connection between the device name of the kernel mode and user mode. As the name we use \DosDevices\TrickMemReader, from user mode, we will refer to it via the link '\\.\TrickMemReader". The link is created through IoCreateSymbolicLink. Next we define callback-procedure that will be called when certain events occur:
DriverUnload - deinitialize driver;
DriverCreateClose - when opening and closing device;
DriverDeviceControl - when calling DeviceIoControl.
And So. Now we return STATUS_SUCCESS, which corresponds to the successful implementation.* Now consider the procedure DriverUnload. It's simple - we remove the connection and set up the device. In the processing functions of opening and closing device DriverCreateClose, the status of the request, we return a success, and return the IRP packet I/O manager. Exchange of data between an application and device via the IRP-packets. IRP-package consists of 2 parts: a header and a stack of variable length. Part of the structure represented by the type of IRP. So now we add functionality to our driver function DriverDeviceControl. In this function I/O Manager will send IRP-data packet transmitted from the client application, which we will generate a call to DeviceIoControl. The parameters we pass 2 Long numbers: 1st address, where produce reading, 2nd number of bytes to read. Also one of the parameters passed to IRP-bag, when calling DeviceIoControl, a control code input / output (IOCTL), which represents the structure of the device type, function number, the type of data and the type of access. You can define several such codes for different operations and use them. I defined the code so IOCTL_READ_MEMORY = 0x80002000, 8000 - corresponds to the type of our device (FILE_DEVICE_MEMREADER); function number = 0x800, values below are reserved for user-defined functions allowed values 0x800 - 0xFFF; the type of data transmission - 0x0 (METHOD_BUFFERED), it means that we will receive / transmit data through the buffer that is specified SystemBuffer IRP-package); access type - FILE_ANY_ACCESS. visually:
So, as a function of DriverDeviceControl we get a pointer to the I/O stack IRP-query using the IoGetCurrentIrpStackLocation, which returns the parameter of lpCurStackLocation. When Successes (if non-zero pointer) is copied to the local structure IO_STACK_LOCATION parameters are referenced by the pointer. Now we check the IOCTL-code field AssociatedIrp, which is a union (in VB6 no associations) which stores a pointer to SystemBuffer. Because we have the type of data corresponds METHOD_BUFFERED, in parameter SystemBuffer contains a pointer to the buffer with the parameters (address and size) DeviceIoControl, in this buffer, we can also recover data that is written to the output buffer DeviceIoControl. Now, if we have data contains the correct values (IOCTL and SystemBuffer), then we copy into local variables (lpPointer, DataSize). Next, check the size of the buffer. Size of the system I/O buffer is contained in the parameter DeviceIoControl.OutputBufferLength. If the requested number of bytes is not larger than the size of the system buffer, then everything is fine. Now we need to calculate the number of memory pages occupied by the data that we want to copy. To do this, we define the virtual address of the beginning of the page corresponding to pass a pointer, and because page size is a multiple of 4 KB (0x1000) we simply vanish 12-bit pointer. Next, we check in the cycle will not be whether an exception is thrown Page fault using the MmIsAddressValid. If the page is not in memory, the function returns False. Thus we check the number of pages that you want us to take a piece of memory and the number of pages that we can read. Then we calculate the actual size of the data that we will be able to read and, if necessary, adjust the size. Next to the title of IRP-package we copy the data size that we can read and a successful status. IoStatus.Information field matches the value returned by DeviceIoControl parameter lpBytesReturned. Next copy in SystemBuffer right amount of bytes using RtlMoveMemory and return IRP-package I/O manager. Return the status of a successful operation. In all other cases, return error STATUS_INVALID_PARAMETER and zero data size. All the driver code is ready.
Last edited by The trick; Jul 30th, 2016 at 11:39 AM.
Reason: New version/translation to English
PS. InterlockedExchange - I left because first driver had a bit of a different structure, subsequently left the ad in the TLB. In the driver, it does not fall into imports.
To the driver worked to do three things:
In the field Subsystem, structure IMAGE_OPTIONAL_HEADER PE-driver file should be the value that corresponds to IMAGE_SUBSYSTEM_NATIVE kernel-mode driver.
Specify as the entry point of our procedure DriverEntry
Add a relocation section, in order that the driver can be loaded at any address.
Exclude MSVBVM60 of imports.
For the first 3 points are added to the compilation keys vbp-file with the following contents:
Compile the project with all the default optimization. To exclude the runtime of the import, I use a utility Patch, I used here. I'm a little modify it, as initially could not start the driver and long puzzled because of what it does, and the reason was the checksum. After exclusion of the import library checksum has changed, and I do not update it. And EXE, DLL, etc. this field is not checked, and the driver checks. To check the watch imports in any viewer PE:
As you can see there is no runtime. What we required.
Last edited by The trick; Jul 30th, 2016 at 11:31 AM.
Reason: New version/translation to English
To debug a driver you want to use the kernel-mode debugger. Debug going on a virtual system (VMware) - Windows XP. As a debugger take Syser, choose our driver and click Load. The system stops and we go to the debugger:
We are in the beginning of the function DriverEntry. The first "CALL" corresponds to a function call Init. If we follow step by step (F8) what's inside, we see how to complete the structure and called RtlInitUnicodeString for the device name and a symbolic link. The second "CALL" corresponds to the function "NT_SUCCESS", look it returns TRUE (in the register EAX) and code jumps after checking (TEST EAX, EAX) zero (False) on:
As can be seen code pushes the stack parameters for the IoCreateDevice from last to first using the instructions "PUSH". We start checking parameters. Check the name of the device (the third parameter - PUSH 0f8a2c010), for example, type "d 0f8a2c010" (which means to view a memory dump at f8a2c010, addresses are valid only for the current debugging) and see the contents:
the first 8 bytes - this is our variable DeviceName. The first two words - respectively the length of the line and the maximum length of the string in bytes. Next double word - a pointer to a string, look (d f8a2c0d8 consider the byte order little-endian):
there Unicode string with the name of the device. If you look at parameter Device (last output parameter - PUSH 0f8a2c020), we can see that it is different from the name on the 0x10 byte. Now look at the declaration of variables, the variable "Device" is declared after the DeviceName and DeviceLink, a total length of 8 + 8 = 0x10 bytes. Ie the order of the variables in the memory corresponds to the order in the ad code. Check the first non-const parameter ESI, in the beginning it is copied to the value at ESP + 0xC. Register ESP - points to the top of the stack. If you walk to the top function DriverEntry, you can see the preservation of the stack of two registers ESI and EDI (by agreement StdCall these registers are saved in the list, ie, the procedure should not change them after the call). DriverObject transmitted in the first variable, i.e. closest to the top of the stack, and after all the settings saved return address - ie DriverObject parameter before executing the first instruction in the DriverEntry function is located at ESP + 4 (the stack grows downward addresses), after two instructions "PUSH" he accordingly shifted by 8 bytes, as a result DriverObject located at ESP + 0C, all right . Correct settings, you can call the function. Hit F10 to not go inside and look IoCreateDevice value of the EAX register after the call, there must be a non-negative integer that indicates that the function worked without error. I have it returned 0 (STATUS_SUCCESS), everything is fine. Next comes the familiar procedure at 0xF8A2B750 - NT_SUCCESS:
If successful, go jump on 0xf8a2b7bf, where there is the pushing of the stack parameters for the function IoCreateSymbolicLink. Parameter DeviceName we have checked, check DeviceLink:
What you need. Hit F10, test EAX, if successful go further if it fails, remove the device and exit with an error. Procedure at 0xf8a2bbb0 - it GetAddr, which simply returns its this value:
Next there is copying of addresses at offsets DriverObject, if you look at the declaration you can see that at offset 0x34 is written address DriverUnload, at offset 0x38 - MajorFunction (0), etc. Recorded values correspond to the address of the function in our driver. Then there is zero EAX (the returned value) and exit from the procedure DriverEntry. Everything works without error, go ahead. So, to track the performance of the driver we will put a breakpoint on the function DriverDeviceControl. Address it is possible to take on the newly written offsets in the structure of DRIVER_OBJECT or find easy viewing and by analyzing the code. In my test, the address is 0xf8a2b870, go to him (. 0xf8a2b870) and press F9, set breakpoints. On the contrary instructions to set a marker:
Now, when this function is called the debugger will stop code execution and enables us to step through the code. Function "DriverCreateClose" and "DriverUnload" I will not describe, because everything is simple. Hit F5, thereby continuing to perform normally. We were immediately transferred back to Windows. Now we run our test application, enter any address (eg 81234567) and click on the button Read. Our challenge intercepts debugger and we can continue to test the function code DriverDeviceControl. Details inside I will not describe the code will focus on the copy:
Immediately look at the stack (register ESP), we see that the correct parameters are passed. In any case, do a dump, then compare:
Press F5 - and return to Windows. We look at the dump is already in our program:
As you can see everything is fine copy. Let's try to copy the data to a page boundary, so that one page was missing. Experimental method was found such a page that's what we get:
As we can see that the data is copied correctly, which did not work there, we displayed a question mark. The output parameter DeviceIoControl we actually returns the number of bytes read, we use it to display a question mark. _________________________________________________________________
As you can see on VB6, you can write a simple driver, and if you use inline assembly can be more serious and write something. Thank you for your attention. Good Luck!
Last edited by The trick; Jul 30th, 2016 at 11:30 AM.
Reason: New version/translation to English
The driver must be in the same folder as the program. Code is commented, so I will not describe his work.
Hi The trick,
Thank you for the post. I run the project on Windows 7 32bit, the system seemed to hang a bit (But only on the first run), then gave the message: "Unable to start service". I think the problem is in Driver, because with the same "TestDriver" project, I have successfully started another Kernel Driver written in C ++.
The driver must be in the same folder as the program. Code is commented, so I will not describe his work.
Hi The trick,
Thank you for the post. I run the project on Windows 7 32bit, the system seemed to hang a bit (But only on the first run), then gave the message: "Unable to start service". I think the problem is in Driver, because with the same "TestDriver" project, I have successfully started another Kernel Driver written in C ++.
I'm sorry to have to bother you again, but the fact is that I searched a lot on the Internet and found that almost no one deeply understands the system Kernel in VB6 like you.
I have a problem with Kernel mode driver, want to ask for your help.
In the project that I attached, everything works fine: Driver OK (Tested), Start Service OK, Connect to driver OK. However, when sending a request with the DeviceIoControl function, I do not receive a response from the Driver.
I send you both the source code of the program written in C ++, by Naveen (link: https://www.codeproject.com/Articles...ing-Used-Files), it is working fine. My project is rewritten in VB6, which is based on that source code. As for Driver, I still keep the original file written in Naveen's C ++, and if you can help me convert it to VB6 it is great.
Note: The operating system I am using is Windows 7 32bit
Best regards,
ferrmask
Last edited by ferrmask; Apr 23rd, 2019 at 03:10 AM.
260 is the number of the elements in the array. On the contrary, you have the following declaration in the VB code:
Code:
Private Type HANDLE_INFO
tcDeviceName(260) As Integer
tcFileName(260) As Integer
uType As Long
End Type
260 is the top bound of the arrays. If you don't have the Option Base 1 statement (and you don't have one) it means 261 elements (ie. from 0 to 260 inclusive). The proper declaration is:
Code:
Private Type HANDLE_INFO
tcDeviceName(259) As Integer
tcFileName(259) As Integer
uType As Long
End Type
Then it'll work.
and if you can help me convert it to VB6 it is great.
It's possible but if you want to use only the pure VB you couldn't implement try/catch behavior (with rough approximation you can use MmIsAddressValid function).
Last edited by The trick; Apr 23rd, 2019 at 02:24 AM.
A couple questions as I set out trying to write a file filter driver:
Is there a particular reason for defining structures in the module when you have to declare APIs in a TLB?
It's weird using void* for typed parameters lol... and it would save a lot of time with fewer conversion changes to types to have them in TLB.
Second: Since I can't use the runtime, I can't use VarPtr, correct? (Unless it can possibly be called as a regular DLL import?) How could I get the address of a structure without it, for the purpose of assigning a pointer to a FAST_IO_DISPATCH type to DRIVER_OBJECT.FastIoDispatch?
Is there a particular reason for defining structures in the module when you have to declare APIs in a TLB?
No. You can declare structures (UDTs) in a module as well.
Originally Posted by fafalone
Since I can't use the runtime, I can't use VarPtr, correct? (Unless it can possibly be called as a regular DLL import?) How could I get the address of a structure without it, for the purpose of assigning a pointer to a FAST_IO_DISPATCH type to DRIVER_OBJECT.FastIoDispatch?
You can't use any user-mode libraries in the kernel. You can get the address using several ways. For example use InterlockedExchange with void* parameter.
I'm a bit confused by where to import it from; Windows driver documentation suggests "OneCoreUAP.lib", if I imported from kernel32.dll where it's also listed, would that count as user mode or kernel mode as it's described as running in both, or could it be imported from ntoskrnl.exe, as other things suggest? I loaded ntoskrnl.exe in an export viewer and it's not coming up as exported in either Windows 10 or Windows 7, which contradicts other documentation (although Geoff Chappell's export list flags it as 'x86', perhaps meaning *only* 32bit Windows), so that just made me even more confused.
Another question...
How is the 64bit issue being dealt with here? I thought drivers needed to be 64bit on 64bit Windows. But some pointers in your declarations I know to be 64bits internally are declared as 32bits (e.g. as I had to deal with in my ETW project, FILE_OBJECT pointers have to be declared as 64bit). Is there some undocumented support for 32bit and it is able to successfully run 32bit drivers... or is something else going on here? Because I get 64bit IRP pointers too, but clearly your project here is working with 32bit ones. If it does recognize 32bit drivers, will this extend to API calls... e.g. if I call ZwCreateFile(PHANDLE FileHandle, ...), although as I understand it Windows will always use handles that fit in 32bits, it would still mean it's expected 8 bytes on the stack for each 64bit type like HANDLE.
Sorry, very new to drivers but trying to learn, doesn't help that in C all I'd need is an include statement.
Last edited by fafalone; Apr 12th, 2022 at 12:14 AM.
Ah I see. I saw Windows 10 in the video and forgot there even was a 32bit edition, since it was so uncommon and MS said they weren't doing 32bit anymore after Win10 2004, although it appears they've backtracked on that. (and the VM I was testing this project in was 32bit).
Putting the APIs in a typelib-- is this because the runtime is needed for the late binding, or because they're late bound at all, rather than in the import table?
Putting the APIs in a typelib-- is this because the runtime is needed for the late binding, or because they're late bound at all, rather than in the import table?
APIs in a typelib fall to import table. So i used a typelib to avoid of runtime usage (DllFunctionCall)
How did you get anything to work from VB6 in a driver? The first thing that any VB6 EXE program does is to run something called ThunRTMain, which is a function in the VB6 runtime DLL. How did you make that not happen? From my understanding, a driver (SYS file) is just an EXE file designed to run in kernel mode, instead of user mode. And VB6 doesn't have a special driver building mode to directly create a SYS file with no dependencies on the runtime. All kinds of auto-generated code within a function in VB6, contain various references to the VB6 runtime.
Also how do you run a driver like this? It's certainly unsigned.
Also how do you even install it? Drivers need to be associated with a specific piece of hardware, so when you plug it in Windows detects the hardware. When you plug in a device for which Windows doesn't have a builtin driver results in it asking you to manually locate the driver files. In fact, plugging in a device is really the only time Windows asks you to select a driver to install.
So how did you make and install a driver that has no association with any external hardware?
Did you even read the post? The trick made it pretty easy to follow, all the code is there, and a link to the tool to remove msvbvm60.
The vbp makes use of an undocumented option to provide instructions to the linker. This is used to override the default entry point (making it DriverEntry instead of ThunRTMain), and specify native subsystem instead of GUI.
The trick created a tool that then removes the msvbvm60.dll dependency (obviously, this means tons of stuff isn't useable for instance I had to use the InterlockedExchange API to replace VarPtr).
Hardware isn't the only thing that has drivers. Windows comes with numerous drivers unrelated to hardware. I'm working on file system filter drivers now... antivirus tools like Windows Defender use these, among others.
The project comes with code that loads it. It's in post #4. You use the Service API; CreateService with SERVICE_KERNEL_DRIVER.
There's ways to load unsigned drivers; obviously developers can't send every single test build off to Microsoft for signing. There's an advanced boot option to allow them; or attaching a kernel debugger. Earlier Windows versions allow you to enable installing unsigned drivers.
This is still the coolest VB6 project I've ever seen, and I've run the project myself and am working on my own--- I've got Wayne interested and it looks like we'll get this functionality easier in twinBasic, so that should mean being able to compile them for x64 Windows too (you need 32bit Windows for VB6 projects like this).
Last edited by fafalone; Jul 24th, 2022 at 08:32 AM.
Did you even read the post? The trick made it pretty easy to follow, all the code is there, and a link to the tool to remove msvbvm60.
The vbp makes use of an undocumented option to provide instructions to the linker. This is used to override the default entry point (making it DriverEntry instead of ThunRTMain), and specify native subsystem instead of GUI.
The trick created a tool that then removes the msvbvm60.dll dependency (obviously, this means tons of stuff isn't useable for instance I had to use the InterlockedExchange API to replace VarPtr).
Hardware isn't the only thing that has drivers. Windows comes with numerous drivers unrelated to hardware. I'm working on file system filter drivers now... antivirus tools like Windows Defender use these, among others.
The project comes with code that loads it. It's in post #4. You use the Service API; CreateService with SERVICE_KERNEL_DRIVER.
There's ways to load unsigned drivers; obviously developers can't send every single test build off to Microsoft for signing. There's an advanced boot option to allow them; or attaching a kernel debugger. Earlier Windows versions allow you to enable installing unsigned drivers.
This is still the coolest VB6 project I've ever seen, and I've run the project myself and am working on my own--- I've got Wayne interested and it looks like we'll get this functionality easier in twinBasic, so that should mean being able to compile them for x64 Windows too (you need 32bit Windows for VB6 projects like this).
So does the CreateService API function require a signed driver (or alternatively enabling test-signing mode) to function? It also clearly runs runs it as a service, which usually means adding it to the registry. Right? So how do you uninstall (remove the registry entries) for the driver when you don't want to use it anymore? And regarding test-signing mode, does enabling test-signing mode disable the signing requirement altogether, or does it now mean you need to generate your own self signed certificate, and then sign the driver manually? If so, how do you do that (easiest way to generate cert, and sign your own driver)?
Driver signing is enforced at a lower level; I don't think the service manager itself cares. You could presumably use a .inf to put it into the startup to load it that way too.
The demo here removes it when you stop it; you just use the DeleteService API like removing any other service.
The signing requirement is disabled all together if you boot into test mode; otherwise from the link I posted,
Enforcing Kernel-Mode Signature Verification in Kernel Debugging Mode
However, there are situations in which a developer might need to have a kernel debugger attached, yet also need to maintain load-time signature enforcement. For example, when a driver stack has an unsigned driver (such as a filter driver) that fails to load it may invalidate the entire stack. Because attaching a debugger allows the unsigned driver to load, the problem appears to vanish as soon as the debugger is attached. Debugging this type of issue may be difficult.
In order to facilitate debugging such issues, the kernel-mode code signing policy supports the following registry value:
C++
Copy
HKLM\SYSTEM\CurrentControlSet\Control\CI\DebugFlags
This registry value is of type REG_DWORD, and can be assigned a value based on a bitwise OR of one or more of the following flags:
0x00000001
This flag value configures the kernel to break into the debugger if a driver is unsigned. The developer or tester can then choose to load the unsigned driver by entering g at the debugger prompt.
0x00000010
This flag value configures the kernel to ignore the presence of the debugger and to always block an unsigned driver from loading.
There's endless contradictory information about self-signing out there. Boot vs not boot, x64 vs x86, SecureBoot... I honestly have no idea under what conditions self-signing will work for kernel mode.
There might be an undocumented, unlicensed method.
Driver signing is enforced at a lower level; I don't think the service manager itself cares. You could presumably use a .inf to put it into the startup to load it that way too.
The demo here removes it when you stop it; you just use the DeleteService API like removing any other service.
The signing requirement is disabled all together if you boot into test mode; otherwise from the link I posted,
There's endless contradictory information about self-signing out there. Boot vs not boot, x64 vs x86, SecureBoot... I honestly have no idea under what conditions self-signing will work for kernel mode.
There might be an undocumented, unlicensed method.
I looked at that, and it looked WAY too complicated for testing this one VB6 driver.
Some questions about declarations... (not suggesting they're wrong as I'm just learning about kernel mode, but want to understand why they are as they are so I can apply it in new scenarios)
Why is the Exclusive argument in IoCreateDevice declared as 'int'?
[in] BOOLEAN Exclusive,
and typedef UCHAR BOOLEAN; // winnt
?
In KDPC, DpcListEntry As LIST_ENTRY, but it's a SINGLE_LIST_ENTRY, which is
[*]Why is the Exclusive argument in IoCreateDevice declared as 'int'?
There is no difference if you pass UCHAR (a byte) or int (four bytes) in STDCALL convention because the both cases uses 4 bytes in the stack. The proper variant is a byte of course. I don't remember why i used that probably i forgot to change the type. You could use a byte of course.
Originally Posted by fafalone
[*]In KDPC, DpcListEntry As LIST_ENTRY, but it's a SINGLE_LIST_ENTRY
Definition from WDM.h (Windows Driver Kit version 7.1.0):
I couldn't figure out why a similar driver I made based on this method was bluescreening; and I eventually worked all the way back to trying to compile the sample simply with a name change. That worked. But in a new VBP (again, only your code besides name change) it does not; blue screen. I compared the VBPs;
I'm not sure which one(s) are mandatory, but at least one is, and it's not mentioned. When I enabled them all like your project, the bluescreening was resolved and my own code (to do something different) now works.
This project has been quite the inspiration. The_trick figured out how to hack VB to do this and posted this brilliant project... I was endlessly fascinated with the possibilities, I got Wayne interested, he added the ability to target the native subsystem in tB... and now it's possible for VB programmers to make drivers for the dominant 64-bit Windows versions
There's a lot fewer limitations in tB... the lack of runtime means things like VarPtr can be used directly, and it looks like soon it'll have a way to use String literals instead of the manually-defined arrays here.
Forgive me as I'm very bad at this kind of logic: For 64bit addresses, would lpStart be extended to &HFFFFFFFFFFFFF000, or the same? I'd assume pgOfst &HFFF and the &H1000 count would stay the same as that's just for the 4KB page size (which is the same on x64).
I'm making a utility driver with a number of functions and wanted to include the memory reading command from this.
The trick's typelib for this project already answers the question anyway.
Note that if you're doing code verification/bug checking between VB for 32bit and tB for 64bit, InterlockedExchange is not exported on x64, but you can use VarPtr in tB as it doesn't rely on an outside runtime.
Forgive me as I'm very bad at this kind of logic: For 64bit addresses, would lpStart be extended to &HFFFFFFFFFFFFF000, or the same? I'd assume pgOfst &HFFF and the &H1000 count would stay the same as that's just for the 4KB page size (which is the same on x64).
I'm making a utility driver with a number of functions and wanted to include the memory reading command from this.
Yes. The kernel address space is negative numbers.