Look for the writes to the qword_18009FBD0 to see where it's initialized.
Apparently it's a part of an array called __encodedKERNEL32Functions where various pointers to kernel32 functions are stored after being XORed with __security_cookie. You can rename the pointer to the kernel32 function's name to better see what is happening:
There are many steps to patch an executable, but here is I think the easiest one. The highlighted one is the EntryPoint, you can patch the highlighted one and redirect it to your control, in my sample, I added a new executable section but remember, you have to return the control to the original program, or else it will not run properly.
As Commented Windbg Just Reads A Structure and Formats it
you can simply use the #FIELD_OFFSET macro (wdm.h)
kd> ?? #FIELD_OFFSET( ntkrpamp!_DRIVER_OBJECT , MajorFunction)
kd> ?? #FIELD_OFFSET( ntkrpamp!_DRIVER_OBJECT , MajorFunction[0xe]) <<<<<
0xe == IRP_MJ_DEVICE_CONTROL
kd> dd 0x85ded260+0n112 l1
Searching for RVA as bytes works for x86 code since RVA is encoded directly in the instruction. However, as you noticed, it does not work on x64 where you instead have a RIP-relative offset which obviously changes depending on the address of the instruction.
I don't see any tricks you could use here but I think that unless your binary is multi-gigabyte, a ...
int 1 is not a part of the SEH setup, that's done by the third instruction. However, int is intercepted by Windows and is translated into an exception which is then dispatched to the handler that has been set up by the previous instructions. So basically here it serves as a sort of "invoke handler" macro.
In practice, any privileged instruction (e.g. hlt ...