Windows paravirtualized

KVM/QEMU Windows guest drivers (virtio-win)

This repository contains KVM/QEMU Windows guest drivers, for both paravirtual and emulated hardware. The code builds and ships as part of the virtio-win RPM on Fedora and Red Hat Enterprise Linux, and the binaries are also available in the form of distribution-neutral ISO and VFD images. If all you want is use virtio-win in your Windows virtual machines, go to the Fedora virtIO-win documentation for information on obtaining the binaries.

If you'd like to build virtio-win from sources, clone this repo and follow the instructions in Building the Drivers. Note that the drivers you build will be either unsigned or test-signed with Tools/VirtIOTestCert.cer, which means that Windows will not load them by default. See Microsoft's driver signing page for more information on test-signing.

If you want to build cross-signed binaries (like the ones that ship in the Fedora RPM), you'll need your own code-signing certificate. Cross-signed drivers can be used on all versions of Windows except for the latest Windows 10 with secure boot enabled. However, systems with cross-signed drivers will not receive Microsoft support.

If you want to produce Microsoft-signed binaries (fully supported, like the ones that ship in the Red Hat Enterprise Linux RPM), you'll need to submit the drivers to Microsoft along with a set of test results (so called WHQL process). If you decide to WHQL the drivers, make sure to base them on commit eb2996de or newer, since the GPL license used prior to this commit is not compatible with WHQL. Additionally, we ask that you make a change to the Hardware IDs so that your drivers will not match devices exposed by the upstream versions of KVM/QEMU. This is especially important if you plan to distribute the drivers with Windows Update, see the Microsoft publishing restrictions for more details.


Comments
  • Need AArch64 / ARM64 versions

    Need AArch64 / ARM64 versions

    Microsoft is now building Windows 10 and Windows Server for ARM64 machines. To successfully run these in qemu, virtio drivers are needed for the ARM64 platform.

  • VirtFS / 9p support for Windows

    VirtFS / 9p support for Windows

    https://github.com/virtio-win/kvm-guest-drivers-windows/issues/60 notes that "Gal is working on it". I didn't find his repo. So let's track progress here! @hammerg , @YanVugenfirer invited ;)

  • [BUG] Windows 10 ARM64 guest went wrong

    [BUG] Windows 10 ARM64 guest went wrong

    The Windows 10 ARM 64 went wrong like this : Screenshot_2020-04-05-10-14-46-363_com realvnc viewer android After the reboot , it went wrong like this : Screenshot_2020-04-05-10-24-09-387_com realvnc viewer android

    I think this error is caused by the VirtIO drivers . I installed the VM using this method : 1.Make an iso image using uupdump 2.Make an empty image using command qemu-img create -f vpc Windows.vhd 80G 3.Boot and install the system qemu-system-aarch64 -M virt-2.11 -cpu host \ -smp cores=4,threads=1,sockets=1 \ -m 2G -device nec-usb-xhci \ -device usb-kbd -device usb-tablet \ -net user -net nic,model=virtio \ -pflash QEMU_EFI.img -pflash QEMU_VARS.img \ -device virtio-blk,drive=disk \ -drive if=none,id=disk,file=Windows.vhd \ -device usb-storage,drive=install \ -drive if=none,media=cdrom,id=install,file=Windows.iso \ -device usb-storage,id=drivers -drive if=none,id=drivers,file=fat:drivers \ -serial stdio -vnc :0 -device ramfb -enable-kvm the driver folder contains the virtio drivers like netkvm.inf vioster.inf,etc. the UEFI firmware are compiled from edk2-edk2-stable-202002 source code . 4. Install the drivers to let the PE recognize the disk . 5. Finish the installation and then reboot . 6. ERROR Host information Host : Raspberry Pi 4B 4G with Ubuntu 20.04 VirtIO drivers version : 0.17.3 Guest version : Windows 10 ARM64 Build 19041&18362

  • Server 2008 R2 BSOD when installing viostor.sys

    Server 2008 R2 BSOD when installing viostor.sys

    Got the following iso: virtio-win-0.1-52.iso

    and it bsods on install. The BSOD is flying by too quickly as the VM reboots. I can see that it is viostor.sys, though.

    The block device is set up as qemu-img create -f qcow2 test.img 128M

    kvm -m 1024 -cdrom virtio-win-0.1-52.iso -drive file=win2008.img,if=ide -boot c -drive file=test.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -nographic -vnc :5

    (the win2008.img was filled by an install from iso using ide drivers)

    It is interesting that http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/ only links a pre whql driver suite.

  • virtio-fs service on a win10 QEMU guest fails before restart and user cannot modify created files

    virtio-fs service on a win10 QEMU guest fails before restart and user cannot modify created files

    As probably well known virtio-fs on a Win10(20H2) Windows guest (and maybe other versions too) is unusable for some users.

    The way this problem manifests at first is that a user is able to create/delete files or directories on a drive mapped through virtio-fs, but then he cannot modify them in any way (where in the case of a directory this means to add any file to it or remove it).

    On a first look this problem appears of the same nature of few others that have been affecting some WinFsp filesystems, but on a further analysis it actually seems to be specific to the virtio-fs driver which, before restart, returns VirtFs->LocalUid == VirtFs->LocalGid == 0 (or better most probably does so).

    Once the virtio FS service is restarted (after logging in into the VM at least) the returned uid/gid are correct and the file permissions correctly mapped to those of the underlying linux host filesystem.

    A more complete description of this problem is found in virtio-fs with a win10 QEMU guest and WinFsp

    I'm available to perform some testing or answer other questions if needed.

    Thank you.

    Edit: I wonder if the virtio-fs service should be started after some other windows service that I'm not aware of...

  • BSOD Balloon driver crashing Windows 7 64bit SP1 (fully updated).

    BSOD Balloon driver crashing Windows 7 64bit SP1 (fully updated).

    I have tried to install 4 different versions: 0.1.102, 0.1.112, 0.1.113, 0.1.117

    They all crash during install of the driver. I have to reboot in Safe Mode to uninstall the driver.

    Also I noticed something odd about the virtio-win-0.1*.iso most are about 54Mbyte but version 0.1.102 is about 100Mbytes larger (153Mbyte).

    When I mount the 54Mbyte isos on linux and use "du -sh /media/cdrom" it return 217Mbytes for the contents, but "df -h /media/cdrom" returns 55Mbytes. I don't understand how there could be 217Mbytes on the iso. They don't seem to be compressed.

    I can still copy all the files off and get about the same amount of data. I am not sure if the iso have been truncated or if some of the files are damaged.

  • Signed build of IVSHMEM

    Signed build of IVSHMEM

    I know I have raised this before, and to work around the problem I obtained a personal driver signing certificate so I could continue working on this project, but I am nearing release and I would like the Red Hat signed build to be available before I open my code up to the public.

    The project that uses this is "Looking Glass", it has garnered an enormous amount of publicity and hundreds of users are extremely excited to use it, but without the ivshmem driver it will not work. This project bridges the last hurdle in consumer space VM integration with full 3D Acceleration.

    https://forum.level1techs.com/t/a-little-teaser-of-what-is-to-come https://www.youtube.com/watch?v=tHv9qh2F3NU

    Once all our ducks are all lined up I will be publishing the source under GPL 2.0 on GitHub, I don't want people to grab this and be disappointed that it doesn't function yet.

  • NetKVM Connectivity Loss

    NetKVM Connectivity Loss

    Hello,

    I've been experiencing connectivity loss issues with what seems to be every version of the Windows Virtio NetKVM driver on Windows 10. This is my current configuration:

    Host OS: Ubuntu 18.04 Guest OS: Windows 10 1903 Kernel: Linux 4.15.0-36-generic x86_64 QEMU-KVM Version: 2.11+dfsg-1ubuntu7.6 NetKVM Versions: 0.1.141, 0.1.160, 0.1.171, 0.1.172

    After a period of time from several minutes to several hours, the NetKVM network interface will lose connectivity with the network, as shown here: image

    Rebooting or disabling and enabling the interface temporarily resolves the problem, until a few minutes or hours pass where the issue recurs. Investigating the Windows event log and host's syslog, there seem to be no events that are correlated with the connectivity loss. I have tried increasing the logging level of the NetKVM driver, but haven't been able to successfully retrieve those logs. Is there a preferred way to capture the log output of the driver?

    Here also are some of the details of the VM's configuration (currently using libvirt):

    <domain type='kvm' id='87'>
      <os>
        <type arch='x86_64' machine='pc-i440fx-bionic'>hvm</type>
        <loader readonly='yes' type='pflash'>/firmware/OVMF_CODE.fd</loader>
        <nvram>/firmware/OVMF_VARS.fd</nvram>
      </os>
      <features>
        <acpi/>
        <apic/>
        <hyperv>
          <relaxed state='on'/>
          <vapic state='on'/>
          <spinlocks state='on' retries='8191'/>
          <synic state='on'/>
        </hyperv>
        <vmport state='off'/>
      </features>
      <cpu mode='custom' match='exact' check='full'>
        <model fallback='forbid'>Skylake-Server-IBRS</model>
        <vendor>Intel</vendor>
        <topology sockets='2' cores='5' threads='1'/>
        <feature policy='require' name='ss'/>
        <feature policy='disable' name='vmx'/>
        <feature policy='require' name='hypervisor'/>
        <feature policy='require' name='tsc_adjust'/>
        <feature policy='require' name='clflushopt'/>
        <feature policy='require' name='pku'/>
        <feature policy='require' name='ssbd'/>
        <feature policy='require' name='xsaves'/>
      </cpu>
      <clock offset='utc'>
        <timer name='rtc' tickpolicy='catchup'/>
        <timer name='pit' tickpolicy='delay'/>
        <timer name='hpet' present='no'/>
        <timer name='hypervclock' present='yes'/>
      </clock>
    ...
      <devices>
        <emulator>/usr/bin/kvm-spice</emulator>
        <interface type='direct'>
          <source dev='enp59s0' mode='bridge'/>
          <target dev='macvtap4'/>
          <model type='virtio'/>
          <boot order='1'/>
          <alias name='net0'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
        </interface>
    ...
      </devices>
    </domain>
    
  • NetKVM driver failure on Windows Server 2019

    NetKVM driver failure on Windows Server 2019

    I'm still in the research phase, but we're currently having issues with the NetKVM drivers.

    Some details: Using Bhyve for virtualization Windows Server 2019 NetKVM 141 Stable drivers obtained from here: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.141-1/ It doesn't specify 2019 or have a folder for that so we used the Windows Server 2016 drivers, but from what I've read here in other issues that were resolved those should work as they are the same. And running a file hash seems to show that they were the same as well.

    The issue is that we had the network stop working 2 nights in a row. The first night we were using the latest 164 drivers, so we decided to roll back to the 141 Stable version as we had issues on Windows 2016 servers with the newer drivers. The second night the same thing, network just stopped.

    When I went to the driver in Device Manager it noted this for the status. No drivers are installed for this device. yet the driver files were still there, it also showed as Disabled here in the and in the network panel. One other thing it showed is that it was in the D3 power state rather than D0, though I wasn't sure if this was just due to it being disabled or not. I didn't see any configuration for making this device not sleep so I figured it wasn't due to that, but this I'm not certain about.

    Other than the errors related to a network being disabled I couldn't find any data in Event Viewer indicating why the network drivers were disabled.

    I also tried TraceView tool using the PDB in the iso that we downloaded for the drivers above as per your readme. But when I tried to create a new session with that PDB it says PDB file does not contain provider information. so I am unable to run this. https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/NetKVM/Documentation/Tracing.md

    Do you have any recommendations for how we can go about figuring out the issue with this driver? I'm not as familiar with getting data for driver issues, so perhaps I'm missing some key information in Event Viewer by either not looking in the right spot or I don't have an appropriate log enabled. Or perhaps there is a log file with more data that I am unaware of for device drivers.

    Please let me know what information you might need to help you or me investigate this issue.

  • Citrix Workspaces not compatible with QXL DOD

    Citrix Workspaces not compatible with QXL DOD

    There is an incompatibility between the "Citrix Indirect Display Adapter" installed by Citrix Workspaces for Windows version 1812 (originally Citrix Receiver) and the QXL DOD adapter driver for Windows 10.

    To reproduce:

    • Run VM with Windows 10 build 1803
    • Relevant VM config: Video QXL, Display Spice, USB Tablet device
    • Install Spice Guest Tools (stable or latest)
    • Install Citrix Workspaces 1812 (https://www.citrix.de/downloads/workspace-app/windows/workspace-app-for-windows-latest.html)
    • Reboot VM

    ==> After reboot, host mouse and automatic resolution adjustment no longer work. Reinstalling Spice tools has no effect.

    Solution:

    Open device manager, delete "Citrix Indirect Display Adapter", reboot VM.

  • Disk conflicts

    Disk conflicts

    I have a standard Windows Server 2016 boot disk and also a block storage disk. Restarting the server, I get these events logged. seems like an issue with the drivers, and the info in that KB was not useful. Reformatting the disks and such aren't helping.

    diskerr1 diskerr2

  • NetKVM: Allocate Rx buffers appropriately with RSC support in the driver

    NetKVM: Allocate Rx buffers appropriately with RSC support in the driver

    Is your feature request related to a problem? Please describe. The current NetKVM driver allocates Rx buffers based on whether the driver supports RSC, instead of whether the RSC is enabled on the VirtIO network adapter or tso is enabled on the host side. For example, for NetKVM driver with NDIS 6.3 and above, buffers with roughly total size 64K are allocated for Rx side. However, if the tso is disabled from host side(guest_tso4/6=off w/o VIRTIO_NET_F_GUEST_TSO4/6) or the RSC is disabled on the VirtIO network adapter in the Windows guest, the host sends MTU size packets to the guest. In this case, allocating the 64K size buffer is a waste.

    Describe the solution you'd like ParaNdis_InitializeContext initializes the nMaxDataSizeHwRx as roughly 64K as following,

    ....
    #if PARANDIS_SUPPORT_RSC
    pContext->MaxPacketSize.nMaxDataSizeHwRx = MAX_HW_RX_PACKET_SIZE;
    pContext->MaxPacketSize.nMaxFullSizeOsRx = MAX_OS_RX_PACKET_SIZE;
    #else
    ...
    

    In CreateRxDescriptorOnInit funcition, Rx buffers are allocated based on the size of nMaxDataSizeHwRx initialized as above,

    ...
        ULONG ulNumPages = m_Context->MaxPacketSize.nMaxDataSizeHwRx / PAGE_SIZE + 2;
    ...
    while (ulNumPages > 0)
    {
    ..
    allocate buffers
    ...
    }
    ...
    

    In InitializeRSCState function, the tso and RSC value are being negotiated and then VIRTIO_NET_F_GUEST_TSO4 feature will be Acked accordingly. So I suggest to set the value of pContext->MaxPacketSize.nMaxDataSizeHwRx in InitializeRSCState after the negotiation of tso and RSC has been done, i.e. set nMaxDataSizeHwRx as MTU size if VIRTIO_NET_F_GUEST_TSO4 is not Acked. For example, if VIRTIO_NET_F_GUEST_TSO4 is not Acked, add following,

    pContext->MaxPacketSize.nMaxDataSizeHwRx = pContext->MaxPacketSize.nMaxFullSizeOS + ETH_PRIORITY_HEADER_SIZE; 
    pContext->MaxPacketSize.nMaxFullSizeOsRx = pContext->MaxPacketSize.nMaxFullSizeOS;
    

    Additional context This change can help reducing the total memory especially with multiple queue or cpus.

  • Can't create file in folder with group write access

    Can't create file in folder with group write access

    Describe the bug

    I have folder where my user has write access as member of debian-transmission group:

    drwxrwxr-x debian-transmission debian-transmission 4.0 KB Sat Nov 12 21:17:59 2022 downloads
    

    I can create files there from my user on Debian host.

    But from Windows VM I get "Catastrophic failure" when I try to create file there.

    To Reproduce

    • Create folder which is owned by different user and their group
    • Add current user to that group
    • Try to create file there from mounted virtiofs share on Windows VM

    If I change permissions to either of these, it works:

    dr-xrwxr-x ruslan              debian-transmission 4.0 KB Sat Nov 12 21:27:04 2022 downloads
    or
    drwxrwxr-x debian-transmission ruslan              4.0 KB Sat Nov 12 21:33:41 2022 downloads
    

    Also I can create file there when it mounted as Samba share.

    So it seems that group membership is not checked properly.

    Expected behavior Files can be created in all these cases.

    Screenshots error

    Host:

    • Disto: Debian
    • Kernel version: 5.18.0-2-amd64
    • QEMU version: 7.1.0 (Debian 1:7.1+dfsg-2+b2)
    • QEMU command line
    • libvirt version: 8.5.0-1+b2
    • libvirt XML file

    VM:

    • Windows version: Windows 10 22H2 19045.2006
    • Which driver has a problem: virtiofs
    • Driver version or commit hash that was used to build the driver: 0.1.225 (stable)
  • NETKVM: fix packet loss in special case

    NETKVM: fix packet loss in special case

    If a poor designed TCP server application doesn't receive data from windows socket function driver afd.sys as quickly as possible, then afd.sys will hold recv buffers temporaryly, and don't call NdisReturnNetBufferLists until afd return-buffer timer expired(at most 1 second).At this time, if there are many packets send in by tcp clients, there may not be enough receive buffer descriptors in the vring to receive packets, and finally packet loss.

    Notes:

    1. If someone found this patch could help you to avoid packet loss, the most probably root cause is the application is not well-designed;
    2. An another way which can avoid packet loss under the situation described above is set DoNotHoldNICBuffers to 1(REG_DWORD) under registry path HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\AFD\Parameters. But microsoft had never mentioned this registry (even hadn't document the behavior of HoldNICBuffers), so the registry param maybe not working in the future version of windows.
    3. According to my analysis, the pusrpose of HoldNICBuffers behavior in afd.sys is mainly to decrease memory copy times when deliver incomming tcp packets to the buffer of recv/wsarecv systemcall. But sometimes it may lead packet loss.

    Signed-off-by: junjiehua [email protected] Reviewed-by: yongduan [email protected]

  • Windows Balloon is not report the mem

    Windows Balloon is not report the mem

    after my proxmoxve was crash and reboot,i find the balloon was not report the mem,only one vm was report.

    it is the vm when use qm monitor ==> info balloon

    qm> info balloon balloon: actual=16384 max_mem=16384 last_update=1666319200

    i try to uninstall and reinstall it。but it also not works

    how can i fix it?

  • Driver build does not work on master branch.

    Driver build does not work on master branch.

    Describe the bug I'm trying to build the drivers from scratch using the current master branch and I am unable to do so. My current main goal is to build the Win10 drivers, but i will need to build for win 8 and win 8.1 in the future.

    Logs are attached (2, 3) to the issue for both win8 and win10, however the first pass appears to be 2 major issues with win10 building:

    • Signing fails because SignTool cant find a certificate which matches all given criteria
    • VioSock can't find viosocklib.dll or viosocklib.pdb but files exist.

    To Reproduce I'm running on a windows server 2019 KVM, freshly installed. No windows updates. Following the build instructions to build the drivers using ewdk 1903 and 2004 from the wiki (1) I setup the EWDK 2004 environment with the dvl files from EWDK 1903, and installed the required components (WinFsp, CPDK WIndows 10, .NET framework 4.8, VS 2013 redistribution x86)

    • downloaded the .zip from the master.branch
    • extracted the contents to the desktop
    • ran LaunchBuildEnv.bat from the edwk2004 directory
    • in the environment set VIRIO_WIN_NO_ARM=True
    • change dir to the extracted contents
    • .\buildAll.bat AMD64
    • save `buildfre_win8_amd64.log
    • edit the .\BuilAll.bat file to remove Win8 and Win8.1 such as call tool\build.bat virtio-win.sln "Win10" %*
    • .\BuildAll.bat AMD64
    • save buildfree_win10_amd64.log
    1. https://github.com/virtio-win/kvm-guest-drivers-windows/wiki/Building-the-drivers-using-EWDK-1903-2004
    2. buildfre_win8_amd64.log
    3. buildfre_win10_amd64.log

    Expected behavior Drivers build resulting in proper test signed (or unsigned) VirtIO drivers and .sdv files in the <driver>\install\Win<version>\amd64\ directory in a sate where they can be signed and tested for WHQL certification.

    Screenshots N/A

    Host:

    • Disto: Ubuntu 22.04
    • Kernel version: 5.15.0-50.56
    • QEMU version: 1:5.2+dfsg-2ubuntu6.2
    • QEMU command line: N/A (can provide if needed)
    • libvirt version: 8.0.0-1ubuntu7.1
    • libvirt XML file: N/A (can provide if needed)

    VM:

    • Windows version: Windows Server 2019 Datacenter 1809, os build 17763.107
    • Which driver has a problem: None
    • Driver version or commit hash that was used to build the driver: Drivers on system are from the mm220 commit, drivers being built are from the master branch.
  • Virtio-gpu-gl through already existing Windows Mesa Driver

    Virtio-gpu-gl through already existing Windows Mesa Driver

    Hi

    From what I get a virtio-gpu windows guest driver already exist but there is no support for 3D acceleration with VirGL (on host) as renderer

    On Linux a 3D acceleration on a virtio-gpu-gl is supported through Mesa Drivers

    For windows there is support for Mesa Driver, I would like to investigate the possibility of using this drivers to interact with the virtio-gpu of this repo so to enable 3D acceleration on windows

    The basic idea is:

    1. Virtio-gpu-gl driver exposing a vGPU
    2. Mesa driver using such vGPU
    3. WindowsOS using Mesa Driver

    (I know about VFIO, GPUPassthrough, Nvidia Grid ecc, but this would be a more Flexible, Hardware Agnostic and Open Source option)

    Is this achievable? Or am I missing something?

    Thanks, Luca

Windows Calculator: A simple yet powerful calculator that ships with Windows
Windows Calculator: A simple yet powerful calculator that ships with Windows

The Windows Calculator app is a modern Windows app written in C++ that ships pre-installed with Windows. The app provides standard, scientific, and programmer calculator functionality, as well as a set of converters between various units of measurement and currencies.

Nov 26, 2022
The new Windows Terminal and the original Windows console host, all in the same place!

The new Windows Terminal and the original Windows console host, all in the same place!

Nov 28, 2022
Windows 2000 styled installer for Panther based distributions of Microsoft Windows (WIM files).

An advanced installer for Microsoft Windows that mimics the looks of the Windows XP and older installers. Takes any modern (Vista and newer) Windows ISO or WIM file and creates a old styled Windows Setup experience on the go.

Nov 18, 2022
Windows kernel information leakage POCs on Windows 10 RS1+
Windows kernel information leakage POCs on Windows 10 RS1+

This repository covers various techniques and methods I write while conducting research into infoleaks, these are for leaking various Windows kernel a

Nov 13, 2022
Some extensions for windows explorer, tested on windows 10+

WindowsExplorerExtension Extensions for windows explorer, tested on windows 10 & windows 11. New Folder Extension What's This A Gnome nautilus inspire

Jan 13, 2022
Defender-control - An open-source windows defender manager. Now you can disable windows defender permanently.
Defender-control - An open-source windows defender manager. Now you can disable windows defender permanently.

Defender Control Open source windows defender disabler. Now you can disable windows defender permanently! Tested from Windows 10 20H2. Also working on

Nov 27, 2022
A small self-contained alternative to readline and libedit that supports UTF-8 and Windows and is BSD licensed.

Linenoise Next Generation A small, portable GNU readline replacement for Linux, Windows and MacOS which is capable of handling UTF-8 characters. Unlik

Nov 15, 2022
A readline and libedit replacement that supports UTF-8, syntax highlighting, hints and Windows and is BSD licensed.
A readline and libedit replacement that supports UTF-8, syntax highlighting, hints and Windows and is BSD licensed.

Read Evaluate Print Loop ++ A small, portable GNU readline replacement for Linux, Windows and MacOS which is capable of handling UTF-8 characters. Unl

Nov 29, 2022
The Hoard Memory Allocator: A Fast, Scalable, and Memory-efficient Malloc for Linux, Windows, and Mac.

The Hoard Memory Allocator Copyright (C) 1998-2020 by Emery Berger The Hoard memory allocator is a fast, scalable, and memory-efficient memory allocat

Nov 20, 2022
Drogon: A C++14/17 based HTTP web application framework running on Linux/macOS/Unix/Windows
Drogon: A C++14/17 based HTTP web application framework running on Linux/macOS/Unix/Windows

English | 简体中文 | 繁體中文 Overview Drogon is a C++14/17-based HTTP application framework. Drogon can be used to easily build various types of web applicat

Dec 1, 2022
C++ Library Manager for Windows, Linux, and MacOS

Vcpkg: Overview 中文总览 Español 한국어 Français Vcpkg helps you manage C and C++ libraries on Windows, Linux and MacOS. This tool and ecosystem are constant

Nov 30, 2022
the checkra1n set of tools targeting bare metal, Linux and Windows

Universal toolchain Low-effort cross-compiling for the masses. What's Universal toolchain? It's a collection of sysroots and shell scripts in such a w

Nov 21, 2022
Double weave on high latency add-on for Final Fantasy XIV for Windows PC.
Double weave on high latency add-on for Final Fantasy XIV for  Windows PC.

XivAlexander Connection Image Korea to NA DC VPN only Korea to NA DC XivAlexander enabled Korea to Korean DC Direct connection Use XivMitmLatencyMitig

Nov 25, 2022
UnhookMe is an universal Windows API resolver & unhooker addressing problem of invoking unmonitored system calls from within of your Red Teams malware

UnhookMe - Dynamically unhooking imports resolver In the era of intrusive AVs and EDRs that introduce hot-patches to the running processes for their e

Nov 20, 2022
Play Doh Windows ACL Tools

PDAcl 是一个支持Windows活动目录扩展权限设置、Windows活动目录常规权限设置、Windows服务权限设置的命令工具。

Oct 30, 2022
This project aims to facilitate debugging a kernel driver in windows by adding support for a code change on the fly without reboot/unload, and more!
This project aims to facilitate debugging a kernel driver in windows by adding support for a code change on the fly without reboot/unload, and more!

BSOD Survivor Tired of always telling yourself when you got a BSOD that what if I could just return to the caller function which caused the BSOD, and

Nov 12, 2022
Exploit for the RpcEptMapper registry key permissions vulnerability (Windows 7 / 2088R2 / 8 / 2012)
Exploit for the RpcEptMapper registry key permissions vulnerability (Windows 7 / 2088R2 / 8 / 2012)

Perfusion On Windows 7, Windows Server 2008R2, Windows 8, and Windows Server 2012, the registry key of the RpcEptMapper and DnsCache (7/2008R2 only) s

Nov 18, 2022
OC EFI Generator for Windows, Coded in C#
OC EFI Generator for Windows, Coded in C#

Opencore EFI Generator for Windows THIS APP IS NOT READY YET, NO FUNCTIONS OR ANYTHING IS ADDED A Utility to create EFI Folder for Opencore bootloader

Nov 2, 2022