Windows afd socket buffer size driver#
Now that we have a valid socket handle, we can communicate with the AFD driver using NtDeviceIoControlFile. Memcpy((void*)pSocketData, (void*)&SocketData, sizeof(SocketData)) Memset((void*)&SocketData, 0, sizeof(SocketData)) ObjectAttributes.ObjectName = &ObjectFilePath ĭwStatus = NtCreateFile(&hSocket, 0xC0140000, &ObjectAttributes, &IoStatusBlock, NULL, 0, FILE_SHARE_READ | FILE_SHARE_WRITE, 1, 0, bExtendedAttributes, sizeof(bExtendedAttributes)) ObjectAttributes.Length = sizeof(ObjectAttributes) Memset((void*)&ObjectAttributes, 0, sizeof(ObjectAttributes)) ObjectFilePath.MaximumLength = ObjectFilePath.Length ObjectFilePath.Length = wcslen(ObjectFilePath.Buffer) * sizeof(wchar_t) ObjectFilePath.Buffer = L"\\Device\\Afd\\Endpoint" Memset((void*)&ObjectFilePath, 0, sizeof(ObjectFilePath)) The socket attributes (address family, protocol type, etc) are specified using an undocumented structure that is passed to NtCreateFile as "extended attributes". To create a socket, we call NtCreateFile to open the \Device\Afd\Endpoint object. I would expect that further information about the AFD structures can be found elsewhere.
I have only reverse-engineered the internal AFD data structures as much as is necessary for this proof-of-concept. To demonstrate this concept, I have created a tool that downloads a file via HTTP. These functions could also be called using direct syscall instructions for added stealth against user-mode hooks, although it is still easy to detect network traffic at the kernel level. The Winsock library uses these functions to communicate with the AFD driver, but we will bypass Winsock and call them directly. The functions that we will be using are NtCreateFile and NtDeviceIoControlFile.
Windows afd socket buffer size how to#
This post demonstrates how to create TCP sockets and transmit/receive data using only ntdll exports.