Shellcode executing warning

[MrHaber]

I compiled all sources in VS 2022 x64 release mode. Windows 10 22H2 Build(19045.4170)

cmd: kdu -map dummy.sys

[#] Kernel Driver Utility v1.4.1 (build 2312) started, (c)2020 - 2023 KDU Project
[#] Built at Sun Jan 7 08:04:15 2024, header checksum 0x631C3
[#] Supported x64 OS : Windows 7 and above
[] CPU vendor string: AuthenticAMD
[] Windows version: 10.0 build 19045
[] SecureBoot is disabled on this machine
[+] MSFT Driver block list is enabled
[] Driver mapping using shellcode version: 1
[+] Input driver file "dummy.sys" loaded at 0x00007FF608E50000
[+] The "" hypervisor present
[+] Drivers database "drv64.dll" loaded at 0x00007FFEECCD0000
[+] Firmware type (FirmwareTypeUefi)
[+] Provider: "CVE-2015-2291", Name "NalDrv"
[+] Extracting vulnerable driver as "C:\Users\User\NalDrv.sys"
[+] Vulnerable driver "NalDrv" loaded
[+] Driver device "NalDrv" has been opened successfully
[+] Executing post-open callback for given provider
[+] Driver device security descriptor set successfully
[+] Processing victim "Process Explorer v17" driver
[+] Mapped victim image at 0000024DE9180000 with size 0xC000 bytes
[+] Extracting victim driver "PROCEXP152" as "C:\Windows\system32\drivers\PROCEXP152.sys"
[+] Successfully loaded victim driver
[+] Query victim image information
[+] Query victim loaded driver layout
[+] Victim target address 0xFFFFF80B77421D60
[+] Loaded ntoskrnl base 0xFFFFF80750600000
[+] Ntoskrnl.exe mapped at 0x7FF7A94F0000
[+] Resolving kernel import for input driver
[+] Resolving payload import
[] ZwClose 0xFFFFF807509F9F20
[] PsCreateSystemThread 0xFFFFF80750CA97F0
[+] Resolving base shellcode import
[] MmSectionObjectType 0xFFFFF807512FC520
[] ExAllocatePoolWithTag 0xFFFFF80750FB7010
[] IofCompleteRequest 0xFFFFF8075085CFF0
[] ZwMapViewOfSection 0xFFFFF807509FA240
[] ZwUnmapViewOfSection 0xFFFFF807509FA280
[] ObReferenceObjectByHandle 0xFFFFF80750C46740
[] ObfDereferenceObject 0xFFFFF80750845B20
[] KeSetEvent 0xFFFFF8075083DBF0
[+] Bootstrap code size = 0x2D5
[~] Shellcode overlaps page boundary, switching target memory address to 0xFFFFF80B77421000
>> Setting jump[E9][FFFFF29B] at address 0xFFFFF80B77421D60
[+] Writing shellcode at 0xFFFFF80B77421000 address with size 0x800
[+] Executing shellcode
[~] Shellcode result: NTSTATUS (0x0)
[+] Victim released
[+] Vulnerable driver "NalDrv" unloaded
[+] Vulnerable driver file removed
[+] Return value: 1. Bye-bye!

What mean is Shellcode overlaps page boundary, switching target memory address to 0xFFFFF80B77421000 ??? After complete, in dbgview64 no output(tried helloworld driver and dummy's drivers) with setting Capture kernel and Enable verbose kernel output.

[hfiref0x]

Your log is ok. The Mark Russinovich tool is bugged. Select everything except "Log Boot" and try again with restarting DbgView. If it doesn't work use DummyDrv2 example driver - during work it creates a named device \Device\TDLD, it can be verified with something like WinObjEx64.

[MrHaber]

Your log is ok. The Mark Russinovich tool is bugged. Select everything except "Log Boot" and try again with restarting DbgView. If it doesn't work use DummyDrv2 example driver - during work it creates a named device \Device\TDLD, it can be verified with something like WinObjEx64.

Now looks it created new device, named TDLD.

dbgviewer worked before and output driver debug logs, strange because dbgviewer crash if I select all modes, with "Capture Events", it looks broken. KDU looks very userful for working with any custom drivers without test-sign mode. Apparently everything works, but I need ways to debug this. Can you recommend anything that will help me debug my drivers, so that first I can at least see the result of initializing my driver? Thanks in advance.

[hfiref0x]

DbgView often crashes when you enable logging and run something from inside of Visual Studio (debug or release, doesn't matter).

If you want DbgView style and don't want to use WinDbg you can follow the above method and use named objects, for example named events. Also AFAIR there are similar to DbgView tools available, some ARK's maybe. Not sure if they use DbgSetDebugPrintCallback like DbgView does but you can try.

[MrHaber]

DbgView often crashes when you enable logging and run something from inside of Visual Studio (debug or release, doesn't matter).

If you want DbgView style and don't want to use WinDbg you can follow the above method and use named objects, for example named events. Also AFAIR there are similar to DbgView tools available, some ARK's maybe. Not sure if they use DbgSetDebugPrintCallback like DbgView does but you can try.

Thanks for advice. =)