Implement KeRegisterBugCheckCallback to use a different color for typical BSOD screen.

Hi, i'm trying for a long time to solve PagedPoolSession challenge, but i can't find a way to heap spraying this vulnerability, also actually there's no solution in source-code exploit path. Please, someone can help me with some hint or explanation about how we can perform this exploit? very thanks and loved all of those other challenges <3

Hello,

I was trying to something that's why I was going to see DriverEntry function.
I used "x HEVD!DriverEntry" command on WinDBG. I got some error about memory access.

I am not sure it's kind of error or my mistake.

When attempting to compile HEVD using the .SLN file (Visual Studio Project Solution file), the following error is returned:

Invalid argument <HEVD.crt> for property <TestCertificate>. HackSysExtremeVulnerableDriver C:\Program Files (x86)\Windows Kits\10\build\WindowsDriver.common.targets 1422

This is due to the .SLN file still using the HEVD.crt file rather than the HEVD.pfx file which is included.

After testing it appears this doesn't affect the .BAT files as they have already been altered to use the HEVD.pfx file, so only the .SLN file is affected. Discussions about this matter revealed that the issue can likely be fixed by altering the .SLN file to use the HEVD.pfx file and then supplying a valid password in the .SLN file so that HEVD.pfx can be opened and utilized by Visual Studio to sign the driver.

The Write-What-Where vulnerability only allows you to write a DWORD, even in 64-bit.

Would be nice to have both options in 64-bit:

1. DWORD -> Partial Arbitrary Overwrite (this is already there)
2. QWORD -> Full Arbitrary Overwrite

Implement WRMSR Vulnerability in HackSys Extreme Vulnerable Driver.

Implement Insecure Kernel Resource Access vulnerability in HackSys Extreme Vulnerable Driver.

Hello,

I don't think this is very important but just a very little detail.

In the secure version of Driver/Stackoverflow.c wouldn't it be more logical to replace:

RtlCopyMemory((PVOID)KernelBuffer, UserBuffer, sizeof(KernelBuffer));

with:

RtlCopyMemory((PVOID)KernelBuffer, UserBuffer, min(sizeof(KernelBuffer), Size));

In the case that DeviceIoControl provides a buffer with Size smaller than sizeof(KernelBuffer), the driver will copy garbage to its stack, or maybe trigger an exception if that memory is not mapped in user land. I don't think this is exploitable (so it does not make it UNSECURE), but it just seems not very logical.

Regards

Hello, I have a question. I am on a Windows 10 (22H2) machine and I am trying to perform the Uaf exploit on the NonPagedPool. After following some tutorials unsuccessfully, I checked and learned that Windows only supports NonPagedPoolExecute(NonPagedPool) for backwards compatibility so that old drivers still work. I suspect that Windows has adapted all internal functions such as CreatePipe to use the NonPagedPoolNx, because every time I've tried to apply some "heap feng shui" I've been unable to find the "spray" objects on the NonPagedPool, which would make sense with DEP. Is it still possible to allocate objects at the NonPagedPool using functions similar to CreatePipe? Or do I need to load ExAllocatePoolWithTag from ntdll.dll and try it with that? Thank you in advance:)

Hi everyone, a while ago i did a blogpost about [HEVD - WriteNULL x86] challenge and how to exploit it utilizing [NtQuerySystemInformation winapi call] . May i ask if isn't possible that the project can link this blogpost, since particularly no solve was implemented nowadays, in order to facilitate people who want to finish too (i'm a very fan of the project and really enjoying to learn, very thanks!).

how to solve:
https://wafzsucks.medium.com/hacksys-extreme-vulnerable-driver-arbitrary-write-null-new-solution-7d45bfe6d116

exploit:
https://github.com/w4fz5uck5/3XPL01t5/tree/master/OSEE_Training/HEVD_exploits/windowsx86/%5BHEVD%5D-WriteNULL

OBS: Sorry but my finally code was made with python lang, can't adapt to C++ (i'm noob), but the explanation in medium should be very useful.

Really not a problem If isn't possible to link, really love to learn everyday on those challs. =D

Refactor ULONG to ULONG_PTR in HackSys Extreme Vulnerable Driver, so that it supports x64 data types.

It would be great to have self signed version of the HackSys Extreme Vulnerable Driver

Implement Kernel Handle Use After Free Vulnerability in HackSys Extreme Vulnerable Driver.

Bug by: James Forshaw
Reference: https://bugs.chromium.org/p/project-zero/issues/detail?id=274

I'm trying to load the driver with OSM on my win10 Build19041 VM in testsigning mode. This is the first driver I encounter where this Error-Message is being presented.
I used the 2.0 Release.
Think is when I use the newest 3.0 Release or the older one. The driver will be "loaded" but I can neither interact to it nor do I see any Messages in DbgView...

I already tried to compile the driver myself. I changed some things like TargetVersion, and the signing certificate (to TestSign, and removed the preset value) nothing helps.

Any tips appreciated

Hi,
The .pfx included in release 3.0 is password protected and therefore unable to be installed, please provide the password.

Push the exploit for Uninitialized Heap Variable Vulnerability.

ProbeForRead and ProbeForWrite can be bypassed when the Length argument is zero.

There might be an exploitable condition after the probe if the length is fetched from somewhere else on a subsequent read / write operation on the probed buffer.

Some examples:

• MS08-025
• MS08-066

I've also seen it in some AV's drivers.

Cheers, and thanks for the driver & sources! o/

P.S: do you accept pull requests if I want to implement this 'feature'?

Implement Semi-Controlled Stack Based Buffer Overflow which can be exploited using partial RIP/EIP overwrite in HackSys Extreme Vulnerable Driver.

Implement Dos Device Misuse Vulnerability in HackSys Extreme Vulnerable Driver.

Bug by: James Forshaw
Reference: http://googleprojectzero.blogspot.in/2015/10/windows-drivers-are-truely-tricky.html
https://bugs.chromium.org/p/project-zero/issues/detail?id=538&redir=1

I see that the 3.00 version of the release does not contain compiled Exploit, so I wanted to compile them myself.
I am running on Windows 10 x64, with Visual Studio Code 2022.

I ran the .bat file in C:\Users\user\Documents\HackSysExtremeVulnerableDriver-master\Builder\Build_HEVD_Exploit.bat.

However, when then running
C:\Users\user\Documents\HackSysExtremeVulnerableDriver-master\compile\exploit\HackSysEVDExploit.exe, I get the following output (option was -a -c cmd)

[+] Starting Arbitrary Memory Overwrite Exploitation
        [+] Creating The Exploit Thread
                [+] Exploit Thread Handle: 0x190
        [+] Getting Device Driver Handle
                [+] Device Name: \\.\HackSysExtremeVulnerableDriver
                [+] Device Handle: 0x194
        [+] Setting Up Vulnerability Stage
                [+] Allocating Memory For WRITE_WHAT_WHERE Structure
                        [+] Memory Allocated: 0x013E55A8
                        [+] Allocation Size: 0x8
                [+] Gathering Information About Kernel
                        [+] Loaded Kernel: ntoskrnl.exe
                        [+] Kernel Base Address: 0x7CA00000
                        [-] Failed To Load Kernel: 0x7E

Looking the documentation, I see that 0x7E means ERROR_MOD_NOT_FOUND. However, I can see the file C:\Windows\System32\ntoskrnl.exe.

Edit:
I feel like this is because the application is compiled in 32 bits, but try to load ntoskrnl.exe that is 64-bit. If I actually Load ntoskrnl.exe with LoadLibraryEx("C:\\Windows\\System32\\ntoskrnl.exe", NULL, LOAD_LIBRARY_AS_DATAFILE);, it loads successfully, but fails to find HalDispatchTable proc address afterwards.

However, I could not find a way to compile the exploit in 64 bits for now. Espececially Payloads.c, because it looks like inline assembly is not supported in 64 bits by Visual Studio ?

error C4235: nonstandard extension used: '__asm' keyword not supported on this architecture

What I am missing to get the exploits running ? (I am in a VirtualBox VM)

Thank you very much,
Atticus

Implement Use Of Uninitialized Variable Vulnerability in HackSys Extreme Vulnerable Driver.

Implement Paged Pool Session Buffer Overflow Vulnerability in HackSys Extreme Vulnerable Driver.

There seems to me a problem with the implementation of the Write NULL vulnerability.

Currently, it is not writing NULL to the address pointed to by the user buffer, but to the user buffer itself.

To correct this, I think there should be a second dereference operator on multiple lines:

DbgPrint("[+] *(UserBuffer): 0x%p\n", (PVOID *)UserBuffer);

should become:

DbgPrint("[+] *(UserBuffer): 0x%p\n", *(PVOID *)UserBuffer);

And

*(PVOID *)UserBuffer = NULL;

should become:

**(PVOID *)UserBuffer = NULL;

Or am I missing something?

I would like to know if all the implemented vulnerabilities apply to remote code execution (RCE)?

Please let us know when can we have an ARM64 version for Windows on ARM OS. As WOA is becoming a new attack surface on ARM64 Architecture.

It would be cool to have an arbitrary read vulnerability as well.

Implement Write NULL Where Vulnerability in HackSys Extreme Vulnerable Driver.

Hi,

I was interested in playing the Integer Overflow challenge running on a Windows 10 (x64). Unfortunately, the binary generated by the original source code uses a 64-bit register when performing the sum Size + TerminatorSize and the integer overflow cannot be achieved.

I have modified the code to allow the integer overflow to occur on 64-bit by using an ULONG (4 bytes) variable to store the sum result.

I'm opening this as an issue instead of submitting a pull request because the modified code is not as "elegant" as the original one.

ULONG TmpSize = 0;

[...]

        TmpSize = (ULONG) (Size + TerminatorSize);
        if (TmpSize > sizeof(KernelBuffer))
        {
            DbgPrint("[-] Invalid UserBuffer Size: 0x%X\n", Size);

            Status = STATUS_INVALID_BUFFER_SIZE;
            return Status;
        }

[...]

@masthoon and I found the below issue in the HEVD secure mode:

(base) c:\work\codes\wtf\targets\hevd>..\..\src\build\wtf.exe run --name hevd --state state --backend=bochscpu --input crashes\crash-0xfffff764b91c0000-0x0-0xffffbf84fb10e780-0x2-0x0 --limit 10000000
Initializing the debugger instance.. (this takes a bit of time)
Setting debug register status to zero.
Setting debug register status to zero.
Running crashes\crash-0xfffff764b91c0000-0x0-0xffffbf84fb10e780-0x2-0x0
Hevd: DbgPrintEx: ****** HEVD_IOCTL_DOUBLE_FETCH ******
Hevd: DbgPrintEx: [+] UserDoubleFetch: 0x%p
Hevd: DbgPrintEx: [+] KernelBuffer: 0x%p
Hevd: DbgPrintEx: [+] KernelBuffer Size: 0x%X
Hevd: DbgPrintEx: [+] UserDoubleFetch->Buffer: 0x%p
Hevd: DbgPrintEx: [+] UserDoubleFetch->Size: 0x%X
Hevd: KeBugCheck2: crash-0xfffff764b91c0000-0x0-0xffffbf84fb10e780-0x2-0x0
--------------------------------------------------
Run stats:
Instructions executed: 2107 (1777 unique)
          Dirty pages: 61440 bytes (0 MB)
      Memory accesses: 10743 bytes (0 MB)
#1 cov: 1777 exec/s: 0.5 lastcov: 0.0s crash: 1 timeout: 0 cr3: 0 uptime: 2.0s

The issue is in:

#ifdef SECURE
        UserBuffer = UserDoubleFetch->Buffer;
        UserBufferSize = UserDoubleFetch->Size;

        DbgPrint("[+] UserDoubleFetch->Buffer: 0x%p\n", UserBuffer);
        DbgPrint("[+] UserDoubleFetch->Size: 0x%X\n", UserBufferSize);

        if (UserBufferSize > sizeof(KernelBuffer))
        {
            DbgPrint("[-] Invalid Buffer Size: 0x%X\n", UserBufferSize);

            Status = STATUS_INVALID_PARAMETER;
            return Status;
        }

        //
        // Secure Note: This is secure because the developer is fetching
        // 'UserDoubleFetch->Buffer' and 'UserDoubleFetch->Size' from user
        // mode just once and storing it in a temporary variable. Later, this
        // stored values are passed to RtlCopyMemory()/memcpy(). Hence, there
        // will be no race condition
        //

        RtlCopyMemory((PVOID)KernelBuffer, UserBuffer, UserBufferSize);
#else

UserDoubleFetch->Buffer isn't probed.

Cheers

Push the exploit for Uninitialized Stack Variable Vulnerability.

Implement Use Of Uninitialized Heap Variable Vulnerability in HackSys Extreme Vulnerable Driver.

Implement Time-Of-Check-To-Time-Of-Use Vulnerability (TOCTOU/Race Condition) in HackSys Extreme Vulnerable Driver.

Make HackSys Extreme Vulnerable Driver a Linux Kernel Module as well.

• Buffer Overflow Stack
• Buffer Overflow Stack GS
• Arbitrary Write
• Buffer Overflow Kernel Heap
• Use after Free
• Type Confusion
• Integer Overflow
• NULL Pointer Dereference
• Uninitialized Memory Stack
• Uninitialized Memory Kernel Heap
• Double Fetch
• Memory Disclosure Kernel Heap
• Write NULL

Hello, could you help me, I need a universal mathematical driver for the System and applications, capable of changing the characteristics of the System and applications based on mathematical formulas and adjusting the mathematical values of values including constants, the System Windows and applications. Regards.

Hello, I'm sorry, I'm not good at English. Please forgive me my grammer mistakes.

Thanks for your outstanding work. However, I think some mistakes...

https://github.com/hacksysteam/HackSysExtremeVulnerableDriver/blob/master/Driver/UseAfterFree.c#L179

I think the code:
g_UseAfterFreeOject = NULL
may not secure. because I could do this.
00000000: 00401000(shellcode address)

It is exploited. I'm so sorry, I'm so terrrible in English....

Hello,

When I tried to load HEVD.sys(v3.00) on OSRLOADER, it doesn't work. But I also tried HEVD v1.2 and v2.0 then it works.

Do you have a any idea why?

"Note: I am working on Windows7x86"

Hi hacksysteam,
After 3 months long, finally i could finish my [HEVD - TypeConfusion] exploit in the latest windows 11 build (22621).
We covered alot of important things such as:

• ROPchain
• Kernel ASLR Bypass
• Supervisor Mode Execution Prevention (SMEP)
• Stack Manipulation

It's that any possibility to add my blogpost into the project references?

https://wafzsucks.medium.com/how-a-simple-k-typeconfusion-took-me-3-months-long-to-create-a-exploit-f643c94d445f

big thanks for the amazing project,
best regards!

Hello! I am trying to do some debugging with WinDBG, and I need to trigger BufferOverflowStackIoctlHandler, but I can't get a handle to the device for some reason? I am using the latest HEVD and I have Windows 7 updated as far as I can get it (two security updates that VMWare forums recommended, although I am using a virtualbox machine)

IDK if I have a broken driver, or not. OSRLoader said everything was successful, and I can view the functions in memory in WinDBG (but I can't if I try to look at it in Cheat Engine, but apparently that is because the drive is paged to disk. This would be a cool view if someone knew how to breakpoint one of the vulnerable functions with Cheat Engine, as I really like the view of the memory in that program).

    HANDLE hevd = CreateFileA(
            "\\\\.\\HackSysExtremeVulnerableDriver",
            0xC0000000,
            0,
            0,
            0x3,
            0,
            0);

    printf("Driver: %p, Last Error: %d", hevd, GetLastError());

hevd = kernel32.CreateFileA(
        "\\\\.\\HackSysExtremeVulnerableDriver", 
        0xC0000000, 
        0, 
        None, 
        0x3, 
        0, 
        None)
 
 if (not hevd) or (hevd == -1):
    print("[!] Failed to retrieve handle to device-driver with error-code: " + str(GetLastError()))
    sys.exit(1)
else:
    print("[*] Successfully retrieved handle to device-driver: " + str(hevd))

the terminal is the c program and sublime text is running the python program. The python script outputs error code 3, but the C version seems to return an invalid handle, but no issue with GetLastError. Any ideas?

Cheat Engine issue if you are curious and have any input!
cheat-engine/cheat-engine#2417

Implement Arbitrary Increment vulnerability in HackSys Extreme Vulnerable Driver.

Hi,
is that possible to exploit this IOCTL ArbitraryReadWriteHelperNonPagedPoolNx with somehow technique? i'm actually trying to exploit it but there so many filters that i can't. I guess it only works for ArbitraryWrite challenge or i'm missing something?

Thanks!

Push the exploit for Time-Of-Check-To-Time-Of-Use (TOCTOU/Race Condition) Vulnerability.

Implement Memory Disclosure Vulnerability in HackSys Extreme Vulnerable Driver.