Skip to content
Browse files

[misc] disable DLL sideloading mitigation

* To avoid odd bug on Vista that causes visual styles on common controls to be disabled
  (if you've got malicious DLL on your system, you've already lost anyway).
  • Loading branch information...
UCyborg committed Dec 27, 2018
1 parent 6f90e94 commit 90d1ec80a5b0e2dfe12a309d007975d55812e7c0
Showing with 5 additions and 5 deletions.
  1. +5 −5 src/rufus.c
@@ -2757,7 +2757,7 @@ int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine
const char* rufus_loc = "rufus.loc";
wchar_t kernel32_path[MAX_PATH];
//wchar_t kernel32_path[MAX_PATH];
int i, opt, option_index = 0, argc = 0, si = 0, lcid = GetUserDefaultUILanguage();
int wait_for_mutex = 0;
FILE* fd;
@@ -2769,7 +2769,7 @@ int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine
char *tmp, *locale_name = NULL, **argv = NULL;
wchar_t **wenv, **wargv;
PF_TYPE_DECL(CDECL, int, __wgetmainargs, (int*, wchar_t***, wchar_t***, int, int*));
PF_TYPE_DECL(WINAPI, BOOL, SetDefaultDllDirectories, (DWORD));
//PF_TYPE_DECL(WINAPI, BOOL, SetDefaultDllDirectories, (DWORD));
HANDLE mutex = NULL, hogmutex = NULL, hFile = NULL;
@@ -2790,7 +2790,7 @@ int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine
// indicates that "If the parameter is an empty string (""), the call removes the current
// directory from the default DLL search order"? Yeah, that doesn't work. At all.
// Still, we invoke it, for platforms where the following call might not work...

// Also, even if you use SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32), you're
// still going to be brought down if you link to wininet.lib or dwmapi.lib, as these two
@@ -2800,7 +2800,7 @@ int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine
// generic URLs around and deliberately refusing to practice *responsible disclosure*...
// Finally, we need to perform the whole gymkhana below, where we can't call on
// SetDefaultDllDirectories() directly, because Windows 7 doesn't have the API exposed.
GetSystemDirectoryW(kernel32_path, ARRAYSIZE(kernel32_path));
/*GetSystemDirectoryW(kernel32_path, ARRAYSIZE(kernel32_path));
wcsncat(kernel32_path, L"\\kernel32.dll", ARRAYSIZE(kernel32_path) - wcslen(kernel32_path) - 1);
// NB: Because kernel32 should already be loaded, what we do above to ensure that we
// (re)pick the system one is mostly unnecessary. But since for a hammer everything is a
@@ -2809,7 +2809,7 @@ int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine
pfSetDefaultDllDirectories = (SetDefaultDllDirectories_t)
GetProcAddress(LoadLibraryW(kernel32_path), "SetDefaultDllDirectories");
if (pfSetDefaultDllDirectories != NULL)

uprintf("*** " APPLICATION_NAME " init ***\n");

2 comments on commit 90d1ec8


This comment has been minimized.

Copy link

replied Jan 9, 2019

if you've got malicious DLL on your system, you've already lost anyway

Yeah, tell that to the people who are also deliberately using this to make Rufus look like malicious software.

The process is as follows:

  1. Download a trojan-infected DLL and place it in one of the directories that Rufus may try to load DLLs from (after also adding an exception in your Antivirus so that it doesn't scan your malicious DLL file)
  2. Download the official, digitally signed version of Rufus and run it
  3. Tell your Antivirus to scan the processes running in memory. Success! Because of the DLL that was loaded, it now declares that Rufus is infected...
  4. Since modern Antivirus software (e.g. Windows Defender) now automatically report user-detected threats "to the cloud", repeat the process on a large enough number of machines and, voilà, you have managed to flag a perfectly clean official binary as malicious, because the Antivirus will add the SHA of the application to the list of the ones that are flagged for that specific trojan.

Unfortunately, this is not an hypothetical scenario, but one that I have had to repeatedly fight, since it appears that Windows Defender, and its "Cloud Reporting", can easily be fooled this way. And of course, as soon as Defender declares that your software contains a trojan, you're screwed.

Granted, considering the nature of your fork, this shouldn't apply to you. But I just wanted to point out that, unfortunately, there's a bit more to the reasons we've had to apply DLL side-loading mitigation in Rufus than trying to be nice with people who are already running an infected system...

Oh, and good luck with your Vista-compatible project. Not to sure why you don't simply fork or use the 2.18 version, that was still Vista compatible, but I suppose you have your reasons. 😄


This comment has been minimized.

Copy link
Owner Author

replied Jan 9, 2019

I was actually going to stop at the first commit, seeing how trivial it was to lift the limitation of it only running on Windows 7+, despite not actually requiring any API calls that aren't available on Vista.

I don't really buy into the modern FUD that is spread about the older OSes and anti-virus companies don't get a single cent from me neither. Haven't used an anti-virus program in years, I found them redundant and also working against the user when they quarantine software that user actually wants to run. I see this happening all the time. And people still run them.

Your reasons are valid given the circumstances. This commit was really done just to workaround that odd bug on Vista and the whole fork is really meant for those few folks that happen to run Vista for one reason or the other. Though TBH, I have no idea if those users would find anything missing or not with the older version that was officially still compatible.

It's true that the bug with mitigation applied is merely cosmetic. From what I remember, it's the SetDefaultDllDirectories call that triggers it.

I don't have any big plans for this or any other project for that matter, given the lack of enthusiasm for programming.

Please sign in to comment.
You can’t perform that action at this time.