Implementing HttpDNS on Windows via API Hook for WinInet

Background: The Xueersi online classroom installer uses the Windows WinInet library for network requests and seeks to reduce package size and avoid third‑party network libraries. To improve connection success and prevent DNS hijacking, an HttpDNS approach is adopted for domain resolution.

Why use HttpDNS: Compared with traditional DNS, HttpDNS offers domain‑hijack protection, more accurate scheduling by resolving to the client’s IP, and real‑time effectiveness through pre‑resolution, caching, and lazy updates, achieving millisecond‑level latency.

HttpDNS implementation schemes: Two common methods are discussed. Scheme 1 replaces the domain with the resolved IP before the request, but this fails with virtual‑host (Host header) and HTTPS SNI/certificate verification issues because WinInet cannot modify the Host header. Scheme 2 leverages a third‑party library’s DNS callback; the article instead uses Windows API Hook to intercept GetAddrInfoEx, providing custom DNS resolution with a fallback to the default resolver.

Windows Hook principle and implementation: Hooking can be done at user‑mode (Ring 3) or kernel‑mode (Ring 0); the project uses an inline hook implemented with Microsoft Detours. The inline hook overwrites the first five bytes of the target function with a JMP to custom code, preserving the original bytes for later restoration.

// Hook function prototype BOOL hookByCode(LPCWSTR szDllName, LPCSTR szFuncName, PROC pfnNew, PBYTE pOrgBytes) { FARPROC pfnOrg = {0}; DWORD dwOldProtect = {0}; DWORD dwAddress = {0}; BYTE pBuf[5] = {0xE9,0}; // ... (code omitted for brevity) ... return TRUE; }

Detours is used to attach and detach the hook for GetAddrInfoEx, allowing custom DNS logic to be injected while preserving the ability to restore the original function.

// Detours hook example bool StartHook() { DetourTransactionBegin(); DetourUpdateThread(GetCurrentThread()); DetourAttach(&(PVOID&)Old_GetAddrInfoEx, New_GetAddrInfoEx); return DetourTransactionCommit() == NO_ERROR; } bool StopHook() { DetourTransactionBegin(); DetourUpdateThread(GetCurrentThread()); DetourDetach(&(PVOID&)Old_GetAddrInfoEx, New_GetAddrInfoEx); return DetourTransactionCommit() == NO_ERROR; }

Custom GetAddrInfoEx implementation: The new function checks for localhost or IPv4 addresses, retrieves IP lists from an HttpDNS service, allocates ADDRINFOEX structures on the private heap, and builds a linked list of results. If resolution fails, it falls back to the original GetAddrInfoEx.

// Simplified custom GetAddrInfoEx INT WSAAPI New_GetAddrInfoEx(PCWSTR pName, PCWSTR pServiceName, DWORD dwNameSpace, LPGUID lpNspId, const ADDRINFOEX* hints, PADDRINFOEXW* ppResult, struct timeval* timeout, LPOVERLAPPED lpOverlapped, LPLOOKUPSERVICE_COMPLETION_ROUTINE lpCompletionRoutine, LPHANDLE lpHandle) { // ... (logic omitted) ... return Old_GetAddrInfoEx(pName, pServiceName, dwNameSpace, lpNspId, hints, ppResult, timeout, lpOverlapped, lpCompletionRoutine, lpHandle); }

Hook process summary: The WinInet request flow normally calls GetAddrInfoEx for DNS resolution; after hooking, the custom resolver is invoked, and on failure the original resolver is used as a fallback.

Conclusion: Using API Hook with WinInet provides a transparent HttpDNS solution without modifying business‑layer code, though it adds extra localhost resolution overhead. References to related documentation and articles are listed.