Rufus changes UAC to "prompt for credentials on the secure desktop"

[tomasz1986]

Checklist

• [x] I looked at https://github.com/pbatard/rufus/wiki/FAQ to see if my question has already been answered.
• [x] I performed a search in the issue tracker for similar issues using keywords relevant to my problem, such as the error message I got from the log.
• [x] I clicked the 'Log' button or pressed Ctrl-L in Rufus, and copy/pasted the log into the line that says <FULL LOG> below.
• [x] The log I am copying is the FULL log, starting with the line Rufus version: x.y.z - I have NOT removed any part of it.

Additionally (if applicable):

• [ ] I ran a bad blocks check, by clicking Show advanced format options then Check device for bad blocks, and confirmed that my USB is not defective.
• [ ] I also tried one or more of the following:
  • [ ] Using a different USB drive.
  • [ ] Plugging the USB into a different port.
  • [ ] Running Rufus on a different computer.
• [ ] If using an image, I clicked on the (✓) button to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.

Issue description

This is a weird issue, but I encounter this behaviour every single time when I launch Rufus, hence I think that something must be related.

Basically, these are my normal UAC settings:

However, as soon Rufus has been launched, the settings are changed to:

Because of this, every time after using Rufus, I need to go and change the settings manually back.

Do you have any idea what may be causing such a behaviour? I have found https://github.com/pbatard/rufus/issues/753, which could be related. I know you mentioned a possible bug in Windows there, but I have never experienced this problem when running any other software so far.

For the record, "prompt for credentials on the secure desktop" means that you have to enter a password in the UAC prompt instead of just being able to click "yes".

Log

Rufus x86 v3.17.1846 (Portable)
Windows version: Windows 10 Enterprise S, 64-bit (Build 17763.2237)
Syslinux versions: 4.07/2013-07-25, 6.04/pre1
Grub versions: 0.4.6a, 2.06
System locale ID: 0x0409 (en-US)
Will use default UI locale 0x0409
SetLGP: Successfully set NoDriveTypeAutorun policy to 0x0000009E
Localization set to 'en-US'
Found USB 3.0 device 'Corsair Survivor 3.0 USB Device' (1B1C:1A0A)
Could not get device number for device \\.\R:: [0x00000001] Incorrect function.
Could not get device number for device \\.\R:: [0x00000001] Incorrect function.
Found USB 3.0 device 'WD Game Drive USB Device' (1058:262F)
Could not get device number for device \\.\R:: [0x00000001] Incorrect function.
Could not get device number for device \\.\R:: [0x00000001] Incorrect function.
Device eliminated because it was detected as a Hard Drive (score 23 > 0)
If this device is not a Hard Drive, please e-mail the author of this application
NOTE: You can enable the listing of Hard Drives under 'advanced drive properties'
Found UAS (USB 3.0) device 'Samsung Portable SSD T1 SCSI Disk Device' (04E8:8001)
Could not get device number for device \\.\R:: [0x00000001] Incorrect function.
Could not get device number for device \\.\R:: [0x00000001] Incorrect function.
Device eliminated because it was detected as a Hard Drive (score 33 > 0)
If this device is not a Hard Drive, please e-mail the author of this application
NOTE: You can enable the listing of Hard Drives under 'advanced drive properties'
1 device found
No volume information for drive 0x83
Disk type: Removable, Disk size: 64 GB, Sector size: 512 bytes
Cylinders: 7783, Tracks per cylinder: 255, Sectors per track: 63
Partition type: SFD (Super Floppy Disk) or unpartitioned

[pbatard]

Hmm, that's a weird one indeed.

The first thing I am noticing is that you are using Windows 10 Enterprise S, which I suspect has a different default security behaviour than consumer Windows 10 versions.

Especially on a vanilla installation of Windows aimed at global users (e.g. Windows 10 Pro), the default policy is Prompt for consent for non Windows binaries and this is not being altered.

I have however been able to replicate your issue after I changed the policy to Prompt for consent on the secure desktop after which I was asked for the Admin password when running Rufus, instead of simply answering Yes or No on a "Do you want to run...?" question.

On subsequent runs however, I found that Prompt for consent on the secure desktop appeared to stick and I also wasn't being asked for the Admin password, though I suspect that a previous choice is being kept for the duration of a session, and I have yet to see what happens after rebooting...

One thing that Rufus is doing is temporarily set a Local Group Policy (that's the SetLGP: Successfully set NoDriveTypeAutorun policy to 0x0000009E message you see in the log) so that you don't get prompted to reformat a drive while using Rufus, so I am wondering if the fact that we are applying a Local Group policy may result in other security settings being modified.

Considering that we're definitely not modifying that's even related UAC in the Rufus code, I think it's fair to assume that what we're seeing is the consequence of a default Windows behaviour when accessing a specific API that is not directly related to UAC (such as calling the APIs that modify the Local Group Policies).

Since I can replicate it, I'm going to keep this issue opened, but, considering that I'm fairly certain that it's not something that we can pinpoint to a formal bug in the code (such as Rufus modifying the settings of a Group Policy when it should be modifying the settings of another) and therefore something that might both require a lot of time to investigate, without even the certainty that we'll be able to work around it if it turns out to be a Windows default behaviour, I'm going to keep this as deferred/low priority.

But thanks for the report, coz that certainly a very puzzling behaviour...

[tomasz1986]

The first thing I am noticing is that you are using Windows 10 Enterprise S, which I suspect has a different default security behaviour than consumer Windows 10 versions.

Especially on a vanilla installation of Windows aimed at global users (e.g. Windows 10 Pro), the default policy is Prompt for consent for non Windows binaries and this is not being altered.

Actually, the version in reported wrongly. This is Windows 10 Enterprise LTSC 2019. The default policy is the same as in other versions, but I always bump it up to prompt for consent for all binaries. One possible clue that I'd like to add is that I myself, maybe 1 year ago, tested bumping it higher to "prompt for credentials" and ran like that for a month or so. Then, after finding it too bothersome, I changed the policy back to the currently used "prompt for consent".

On subsequent runs however, I found that Prompt for consent on the secure desktop appeared to stick and I also wasn't being asked for the Admin password, though I suspect that a previous choice is being kept for the duration of a session, and I have yet to see what happens after rebooting...

In my case, it always switches to "prompt for credentials" on each Rufus launch, making me extremely hesitant to even use the program, to be honest 😕. And, I do want to use it because it works extremely well when it comes to creating bootable media for uncommon devices (e.g. ones with 32-bit UEFI). Especially in the recent days, I've been doing a lot of Linux installation testing, and this is why I've come here to finally report the issue (which I already experienced at least a few months ago).

One thing that Rufus is doing is temporarily set a Local Group Policy (that's the SetLGP: Successfully set NoDriveTypeAutorun policy to 0x0000009E message you see in the log) so that you don't get prompted to reformat a drive while using Rufus, so I am wondering if the fact that we are applying a Local Group policy may result in other security settings being modified.

I have a feeling that this is the culprit. There is no way to disable the temporary policy application, right? I would't mind having another prompt when reformatting the drive, to be honest. In other words, is there anything that I can do to work around this problem other than modify the source code and compile the program myself?

[pbatard]

is there anything that I can do to work around this problem other than modify the source code and compile the program myself?

I'm afraid not. And I'd be more than happy to have someone else investigate the issue by compiling their own modified version of the application (that's why it's Open Source after all) and figure out what is the cause.

[tomasz1986]

I've compared what actually happens, and it appears that the only thing that changes is the value data of ConsentPromptBehaviorAdmin in [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System], which is modified from 2 to 1.

For now, I will likely simply start Rufus using a script that will immediately reset the value to its previous data.

Edit: I've tested my idea in practice, and it's a two-step process. Firstly, the value needs to be changed back right after starting Rufus. Secondly, it also needs to be changed back after closing the program, because the same change takes place yet again when exiting Rufus. I've written a small batch script for my personal use that applies the registry fix on Rufus start, and then stays in background waiting for the process to exit, so that it can apply the fix again.

[inikishev]

its spyware try running rufus at any.run

[pbatard]

• https://www.virustotal.com/gui/file/6d362897059df29d9674112a43e68dbc549ba4c25e7036dd9fae7c92bfafda02/detection
• https://github.com/pbatard/rufus/wiki/FAQ#Antivirus_X_reports_that_Rufus_contains_malware
• https://github.com/pbatard/rufus/wiki/Security#Tamperproof_signed_executable

[inikishev]

why does it disable windows defender spyware protection via registry edit?

[inikishev]

to be precise, it deletes this key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects\{05CE21DA-E5EC-4E5F-8642-4BDEB76168F4}Machine\Software\Policies\Microsoft\Windows Defender\Real-time Protection and this key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects\{05CE21DA-E5EC-4E5F-8642-4BDEB76168F4}Machine\Software\Policies\Microsoft\Windows Defender

and then it goes to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects\{05CE21DA-E5EC-4E5F-8642-4BDEB76168F4}Machine\Software\Policies\Microsoft Windows Defender and sets DisableAntiSpyware to 1

[inikishev]

also goes here HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects\{05CE21DA-E5EC-4E5F-8642-4BDEB76168F4}Machine\Software\Policies\Microsoft\Windows Defender\Real-time Protection and sets DisableRealtimeMonitoring to 1

also changes system certificate settings

[pbatard]

And where in the code are you alleging we are doing that?

It should be exceedingly obvious to point to Rufus doing anything like this considering that, through the way we build the current executables, the 3.17 runtime can only have been built from https://github.com/pbatard/rufus/tree/d5dc8ee5e753e0bd4bea6afa745aeac1acb1d0e8, with no possibility of code added or removed from what you can see in the link I gave you (which can also be cloned using git).

If you perform a search, you will see that Rufus does not do anything even remotely related to manipulating Windows Defender registry keys. And, again, you can validate yourself that the executable we publish can only have been produced from the public code I linked to. Please perform a search for DisableAntiSpyware in our source if you don't believe what I am stating as a fact. Unless you can point to anything from our code that would manipulate a DisableAntiSpyware or Real-time Protection key, you have to consider that you might need a little more proof than what an automated tool is reporting.

Even if we obfuscated registry edits in the code, or somehow downloaded and executed remote code to evade detection, it should be relatively obvious to spot that (since there are only so many ways one can access the registry or can launch remote code).

Now, the one thing we do (and this too is something you can easily validate in the code) is ask Windows to use Local Group Policies to disable NoDriveTypeAutorun (so that users don't get prompted to format a drive they just plugged) and you will notice that all the keys you mention are children of Group Policy Objects. Note that manipulating Local Group Policies rather than editing the registry directly is the method Microsoft recommends to change this setting.

So, the most likely explanation, if such a detection is true (which I am a bit doubtful since I would assume other AV would pick on something like this) is that, on the system executable was tested by any.run, Windows itself temporarily alters the key when it modifies the local group policies. Or that the analysis from any.run is misreading a localised alteration (Group Policy Objects\{05CE21DA-E5EC-4E5F-8642-4BDEB76168F4}Machine doesn't strike me as a global setting, but I might be wrong) as a global system-wide thing.

At any rate, the burden of proof is on you, as there is simply no possibility that the changes any.run alleges Rufus performs could come from anything else but the public code. So, if you can't actually locate anything in our public code that even remotely looks like an attempt to disable Real-Time protection or anti spyware, then there is something missing in your analysis, because it genuinely shouldn't be that difficult to point to the Rufus code performing something that malicious, if you are going to allege that we intentionally added malware to our application.

[pbatard]

also changes system certificate settings

Which could also be triggered by the OS performing such thing as changing one local group policies, validating that the digital signature is valid, connecting to the update server through SSL, at the request of the application, but without the application explicitly altering, as you allege, the system certificates. Again, there is simply no way we can do any of that without leaving breadcrumbs about it in our code. So, either we're running exceedingly lucky that noone ever picked on malware elements in our code, that should be there in plain sight, or it's just that there's never been any malware at all, and that the analysis of an automated security tool, that has to perform some heuristics evaluation and that runs on a system of which we have no insight about its configuration, might be flawed...

[inikishev]

And where in the code are you alleging we are doing that?

It should be exceedingly obvious to point to Rufus doing anything like this considering that, through the way we build the current executables, the 3.17 runtime can only have been built from https://github.com/pbatard/rufus/tree/d5dc8ee5e753e0bd4bea6afa745aeac1acb1d0e8, with no possibility of code added or removed from what you can see in the link I gave you (which can also be cloned using git).

If you perform a search, you will see that Rufus does not do anything even remotely related to manipulating Windows Defender registry keys. And, again, you can validate yourself that the executable we publish can only have been produced from the public code I linked to. Please perform a search for DisableAntiSpyware in our source if you don't believe what I am stating as a fact. Unless you can point to anything from our code that would manipulate a DisableAntiSpyware or Real-time Protection key, you have to consider that you might need a little more proof than what an automated tool is reporting.

Even if we obfuscated registry edits in the code, or somehow downloaded and executed remote code to evade detection, it should be relatively obvious to spot that (since there are only so many ways one can access the registry or can launch remote code).

Now, the one thing we do (and this too is something you can easily validate in the code) is ask Windows to use Local Group Policies to disable NoDriveTypeAutorun (so that users don't get prompted to format a drive they just plugged) and you will notice that all the keys you mention are children of Group Policy Objects. Note that manipulating Local Group Policies rather than editing the registry directly is the method Microsoft recommends to change this setting.

So, the most likely explanation, if such a detection is true (which I am a bit doubtful since I would assume other AV would pick on something like this) is that, on the system executable was tested by any.run, Windows itself temporarily alters the key when it modifies the local group policies. Or that the analysis from any.run is misreading a localised alteration (Group Policy Objects\{05CE21DA-E5EC-4E5F-8642-4BDEB76168F4}Machine doesn't strike me as a global setting, but I might be wrong) as a global system-wide thing.

At any rate, the burden of proof is on you, as there is simply no possibility that the changes any.run alleges Rufus performs could come from anything else but the public code. So, if you can't actually locate anything in our public code that even remotely looks like an attempt to disable Real-Time protection or anti spyware, then there is something missing in your analysis, because it genuinely shouldn't be that difficult to point to the Rufus code performing something that malicious, if you are going to allege that we intentionally added malware to our application.

run the latest github version on https://app.any.run/ and it will tell you what registry keys it modifies. As most users I am not a programmer and have no opportunity to browse the source code especially since the malicious code is probably well hidden, but that doesn't mean I can blindly trust the developers if a tool shows exact registry keys rufus disables.

[pbatard]

but that doesn't mean I can blindly trust the developers if a tool shows exact registry keys rufus disables.

Yet you trust an automated tool that makes an extraordinary claim about an application that has existed for 10 years and that has yet to see a credible report of doing anything that can even remotely be malicious.

Of course, you are free to believe who you want, but there is such thing as innocent until proven guilty, and I'm afraid that a vulnerability report (from what I can tell is a relatively new source) that can't be translated into actual evidence does not constitute proof. Plus, don't you think very strange that the only thing remotely close to cries of "Rufus disabled my anti virus!!!" that this public issue tracker should be full of, is an report of UAC alteration that, if you look at it objectively, can hardly even be considered as something malicious having happened (since this is not a report of UAC having been disabled, but one of a small change in the manner in which UAC prompts are reported to the user). I mean, shouldn't this issue tracker be full of such reports (or, if you believe that we can somehow disappear reports like this, which we can't, shouldn't other places be, besides a single automated report on any.run?)

But hey, feel free to consider the developer of Rufus as a matermind of obfuscation (coz keeping malicious code hidden for so long, when we've only been making harder and harder on ourselves to do so would be quite a stroke of genius), with explicit intent to cause harm to users of its application, because developers can't be blindly trusted but somehow, creators of security applications whose business model is well known to generate false positive after false positive somehow can...

[inikishev]

I understand that if rufus does nothing like that it would be very frustrating from a developers point of view because the developer knows what rufus does. Most users however DON'T know what goes under the hood, so either the developer is telling the truth or any runs is telling the truth and the developer is trying to hide the malware, and there is no way we can tell those apart. A tool can be developed to be biased, a human on the other hand can easily straight up lie, so I have no reason to trust anyone in particular, but it is safer to trust the tool as it implies avoiding a potential risk. For an average user it is probably more rational to avoid using rufus until the issue is resolved since there are many alternatives.

shouldn't this issue tracker be full of such reports?

Not if it is well hidden

[pbatard]

and there is no way we can tell those apart.

There is. The idea that "Well, there is no way to tell those apart, because I don't want to look (or don't know how to look and therefore assume that others won't either)" is completely ludicrous. You can't accuse someone of doing something and then, when pressed for evidence, state "Well, I just know that person is guilty because I heard somebody else state so, and I trust the person who stated it more than the person I am accusing of wrongdoing".

Sorry to break it to you, but that's not how you go claiming that someone is guilty of wrongdoing, because the one thing that is still missing, even if you are of the opinion that a single third party report is more trustworthy than all the elements I have presented to disprove it, is conclusive evidence that the verifiable facts I have presented are invalid. That you do not want, or want to assert that you personally do not have the technical know how (which isn't actually that hard to obtain, since it's just a matter of figuring out code operations that would manipulate registry keys related to AV protection), to validate my claims does not make them any less valid. Because, I hope you can appreciate that, if that was the case, then any trial where a defendant presents evidence to disprove what they are being accused of could be dismissed by the prosecution with an "I / most people don't know to look at it, therefore this evidence can not be received"? Do you not see the problem there? What kind of justice system is that, where the person who accuses someone of doing something can just cherry pick what they like and remove what they don't like from what the accused puts forward.

There's a huge difference between "Most users don't know what goes under the hood" and "NOBODY apart from the developer knows (or can know) what goes under the hood". If you want to press this further, you can get in touch with the any.run folks and ask them to disprove any of my counter claims. They are expert, they are the ones who have a vested interest in confirming that their analysis is correct, and, if they want to allege that a very popular application is somehow disabling security solutions, they will have a lot to gain in terms of publicity, if they can demonstrate that there is indeed malware hidden within Rufus, especially if it's been so well hidden that nobody before them has been able to spot it.

A tool can be developed to be biased

A point I made above. Both any.run analysis and Rufus could be developed to be biased. The any.run analyser is automated software that has been developed by folks who have a vested interest in flagging actual innocuous behaviour as potential malware behaviour. So you can't just cherry pick one set of developers to potentially be biased and not the other. If you do assert that the any.run developers are more trustworthy than the Rufus developers, then you yourself are obviously biased too, which makes your claim a lot less receivable, since it lacks objectivity and lacks the consideration that the any.run report is a false positive, even if false positives are much more common occurrence than an Open Source utility somehow hiding malware in plain sight.

Again, you are making 3 extraordinary claims here:

1. That Rufus contains malware based on a single report generated by an automated utility, that dozens and dozens of other well established AV tools have somehow failed to pick upon. In other words, you are stating that every single AV vendor out there is incompetent at detecting obvious actions such as disabling real time protection, outside of any.run. That's quite the extraordinary claim here (even if you want to turn it into an "any.run is just the first one, just wait and see", which I'll be more than happy to do if the absence of other security solutions agreeing with any.run's analysis is what it'll take to try to prove to you and others than this analysis is either flawed or being misinterpreted by non experts).
2. That, the malware is so well hidden, in completely public code, that even experienced users/developers/security researchers are unable to spot it (or that experienced users/developers/security researchers NEVER look at existing public Open Source code).
3. That somehow, even as Rufus is allegedly supposed to disable real-time protection, not a single real-life user of Rufus (as opposed to a single automated tool) has ever picked on this behaviour (since, again, this UAC issue, which you had to piggy back on because there just wasn't any report that goes towards the "disables real-time protection" claim, has nothing to do with disabling real-time protection). I hope you can agree that your "Not if it is well hidden" is in complete contradiction of obvious DisableAntiSpyware keys being altered. And I can guarantee that there are some paranoid users out there who do run applications like Rufus with tools that allow them to detect any minute alteration of the registry (which isn't that difficult to do), yet not a single one has reported the any.run behaviour. Oh, and of course, you can expect respectable AV vendors, who test a potentially malicious executable in a sandbox, for the purpose of monitoring registry and other OS changes, to perform this kind of detection too. Yet, not a single one of them, before any.run, has somehow managed to detect and flag that behaviour? Or are you gonna tell me that, not only am I somehow alleged to have managed to conceal obvious registry manipulation in very public source, but I have also added detection of AV analysis tools to evade their detection while I was at it? Because that's stuxnet level of development you're talking about here...

So, please come back when you have contacted the any.run folks and asked them to point to how exactly Rufus is accomplishing the behaviour you (and their report) alleges, since there is no possibility that this can have come from anything but the code that is public and since security experts should have little trouble pointing to it (as opposed to "mere" users like yourself who aren't experts or developers).

As long as you are unwilling to do something like that, I'm afraid that all you are doing here is pointing the finger at somebody, without much "evidence" to back your claim, while at the same time indicating that just don't want to look into any of the verifiable counter claims, because it appears that, to you, a single accusatory report from a third party (that I will assert you have never directly liaised with) should be more than good enough to pass a verdict...

[XdekHckr]

I understand that if rufus does nothing like that it would be very frustrating from a developers point of view because the developer knows what rufus does. Most users however DON'T know what goes under the hood, so either the developer is telling the truth or any runs is telling the truth and the developer is trying to hide the malware, and there is no way we can tell those apart. A tool can be developed to be biased, a human on the other hand can easily straight up lie, so I have no reason to trust anyone in particular, but it is safer to trust the tool as it implies avoiding a potential risk. For an average user it is probably more rational to avoid using rufus until the issue is resolved since there are many alternatives.

shouldn't this issue tracker be full of such reports?

Not if it is well hidden

Hello Mr. 🤡. Compile rufus on your own and do research how to spot malware in plain text/open source apps. If you can't do heuristic or reverse engineering then don't waste our time, because there is no proof that it's malware (any.run obviously isn't proof). Try to execute rufus also on https://www.hybrid-analysis.com and compare results.

[pbatard]

Try to execute rufus also on https://www.hybrid-analysis.com/ and compare results.

Also please learn how to interpret results, because it's easy to wrongly assume that Rufus is doing something dodgy, like this person did here because it happens to download legitimate files from the IP addresses associated with the GitHub servers and of course, as a major host of content, GitHub also happens to be used by malware authors to download malicious payloads.

But it's pretty much the same as telling someone "I trust you, but you're asking me to download a file from your Google Drive/Microsoft OneDrive account? Don't you know that bad people also use Google Drive/Microsoft OneDrive to share malware! Therefore, the file that you are asking me to download must be malware", which is fallacious reasoning.

Or to put it more succinctly, it's not because criminals also use the motorway that everybody you encounter on a motorway is a criminal, just like it's not because Rufus happens to download files from GitHub and malware authors also use GitHub that the files being downloaded by Rufus from GitHub are malware (which is what, if you don't know how to be critical of what an automated report tells you, is what hybrid-analysis.com will seem to be hinting at).

In short, as @XdekHaker said, you must be willing to do your own research on how to actually spot malware, and not rely exclusively on what an automated analyser appears to tell you. Now, that's not to say that automated analysers don't have their place, but, when an application starts to perform fairly advanced low level stuff, like Rufus needs to be doing, it will often trigger a stream of "scary" false positives, which subsequently need to be properly interpreted, by a human person, for what they are.

[inikishev]

it's pretty much the same as telling someone "I trust you, but you're asking me to download a file from your Google Drive/Microsoft OneDrive account? Don't you know that bad people also use Google Drive/Microsoft OneDrive to share malware! Therefore, the file that you are asking me to download must be malware", which is fallacious reasoning.

I never said must, I said it's more likely to contain malware which invalidates your arguments. If criminals use a certain motorway, and there is a different road that is as easy to use, I will simply out of caution use the different road.

” you must be willing to do your own research" yeah I need to get a PhD in computer security just to see if rufus is malware or not. It's like saying "here is a new vaccine, a biochemical simulation or whatever says it might lead to some terminal illness but you need to do your own research, but since you don't have a PhD and can't do research, just use it without any caution and ignore that there are other vaccines that at least don't give any signs of leading to any illnesses

[pbatard]

I said it's more likely to contain malware which invalidates your arguments

And I say you're more likely to be a complete idiot, according to the "evidence" you've provided us above, which invalidate yours.

See how that works?

If you want to go that way then anybody can call anybody on anything, and I can use the "hints" of your previous posts to back up that "claim", since you've provided us with ample reasons (just like the automated detection tools have provided you with hints) that we should strongly doubt your reasoning on account that you continue to indicate that you are willing to blindly trust automated reports over what actual humans tell you.

Have you contacted the any.run folks (or any other security experts for that matter) to ask them if, in their expert position, they actually believe Rufus to be malware and what they make of nobody else reporting the huge malicious behaviour their automated analysis appear to be flagging as well as what they make of the complete absence, still, of user reports here or on other user forums complaining about Rufus allegedly disabling security solution (or doing something potentially nefarious), which there should be plenty of if the any.run report can be trusted?

Or are you simply continue to ignore the actual evidence (that wasn't generated by an automated tool), which can logically be used to demonstrate that, unless you are stubborn or want to buy into a conspiracy theory of silence, your misginving about Rufus, based on a single automated report, may potentially be misplaced. Note that this does not require you acquiring a PhD or becoming a security expert, but simply using logic.

If you want another analogy, you're still telling us there's smoke on the motorway, because you heard a robot tell you there was, and therefore, telling everyone that there probably is fire. But we ARE standing right at the place where the fire should be, with tens of thousands of people who CAN AND WILL report the fire if there actually is one, and yet nobody appears to be reporting anything, besides your robot...

So, I have to ask again, what is your explanation for that?

I mean if I was silencing issues from actual people reporting that they've effectively seen Rufus perform potentially malicious behaviour here, there would be some hints (because for one thing even if GitHub lets one lock issues and ban participants, it does not allow the ability to delete issues, only report them). And even if I somehow could manage to do it, there would be places (like reddit, superuser and malware forums like the one I linked to) that should be full of reports that Rufus does perform some questionable actions. But there aren't, which can only mean two things (and, again, you don't need a PhD to come to that conclusion):

• Either that potentially malicious behaviour is fairly new and hasn't been detected yet.
• Either I am so incredibly good at hiding the malicious behaviour, that not only have I been able to hide it in plain sight, in public code (all the while making it harder and harder on myself to do so), that actual people with PhD in computer security can look at, but I've also hidden any hints of malicious communication with remote servers (since malware that doesn't communicate these days is of very limited interest) and found ways, even as I am allegedly disabling security solutions per the any.run report, not to trip the large number of security solutions that are designed, usually by very smart people, that should pick on that.

With regards to point 1, it's been many months since the any.run reports, and we're still seeing nothing from anybody else. Doesn't that strike you at strange, and shouldn't that make you actually be suspicious of the one thing we have actual hints of being suspicious of, which is that among something like 50 public detection tools., any.run is the only one that thinks Rufus is disabling AV? With regards to point 2, which I've tried to deconstruct for you as I went along, then I guess I'll just be waiting for my call from the NSA or some other government security agency any minute now, because if I actually managed to pull that off, that's unheard of level of malware concealment, which, if confirmed, will have folks with actual PhDs in computer security, making a living of publishing papers on how I somehow managed to fool everybody, including every single expert out there, planting malware in 100% PUBLIC code that does not offer any hint about it.

Once more, you don't need a PhD, just logical reasoning, to come to the conclusion above, which I still haven't seen you either acknowledge or attempt to deconstruct. And sorry, your "I'm personally not able to tell from looking at the source if there's malware or not in it" won't quite cut it on point 2, because it's akin to pretending that nobody looks at the source of a popular project with millions of downloads each month and that currently also has had more than a hundred contribution from third parties (most of which actually had to look at the code for contributing).

Therefore, one can only conclude that, when you are not willing to look into these points, even as I have repeatedly raised them, then you are effectively willing to blindly trust programmed machines to tell you how you should lead your life, instead of applying critical thinking, which is really all the people in this thread are asking you to do.

Ergo, since you have provided us with evidence that you want to be led by machines without applying critical thinking of what these machines are telling you, this gives us the right to naturally call it as complete idiocy, and start a post calling you out on that, on account that you have also given everybody the green light here to use limited and disputable "evidence" (even if you are unwilling to look into its disputability) to happily declare what someone or something is more likely to be.

[inikishev]

I said it's more likely to contain malware which invalidates your arguments

And I say you're more likely to be a complete idiot, according to the "evidence" you've provided us above, which invalidate yours.

See how that works?

I have the actual argument right after that sentence you quoted. There is a huge difference between must and might.

Here is a one for you

Ergo, since you have provided us with evidence that you want to be lead by machines without applying critical thinking of what these machines are telling you, this gives us the right to naturally call it as complete idiocy, and start a post calling you out on that, on account that you have also given everybody the green light here to use limited and disputable "evidence" (even if you are unwilling to look into its disputability) to happily declare what someone or something is more likely to be.

You provided me with evidence that you completely disregard reports of an automated tool and instead are willing to blindly believe developers of the app that their app is "perfectly safe", which gives me the right to call or a complete idiocy.

Or are you simply continue to ignore the actual evidence (that wasn't generated by an automated tool), which can logically be used to demonstrate that, unless you are stubborn or want to buy into a conspiracy theory of silence, your misginving about Rufus, based on a single automated report, may potentially be misplaced. Note that this does not require you acquiring a PhD or becoming a security expert, but simply using logic.

You are using logic as a gateway, again I can do the same and say that my position can be understood by simply using logic and yours is ignoring the actual evidence of an automated too and calling it a conspiracy instead. I don't see any I should provide any evidence that wasn't generated by an automated tool. You are putting it as a given but there is no reason for it to be a given.

What evidence do I have of Rufus being safe? Developers saying so (not actually evidence) and the fact that no one found the malware yet. This would also not be a good piece of evidence of the malware is hidden so that it is hard to find by browsing the source code. A picture where any.runs uncovered a hidden action that rufus performs is therefore consistent picture. I am not staying it must be true, but there is some probability that it is true, and any person with critical thinking won't be taking a risk of using something that is probably safe when there are alternatives for which no evidence of malicious actions exists.

If you want another analogy, you're still telling us there's smoke on the motorway, because you heard a robot tell you there was, and therefore, telling everyone that there probably is fire. But we ARE standing right at the place where the fire should be, with tens of thousands of people who CAN AND WILL report the fire if there actually is one, and yet nobody appears to be reporting anything, besides your robot...

Not a good analogy since most malware in open source projects must be hidden otherwise people will find it. A better analogy - a new robot is detecting a slightly toxic has that has no smell and is hard to detect. People have used this motorway for ages before and no one has suspected anything. Well, it can be close to impossible to pinpoint the cause of a medical condition, and pretty much impossible to associate something like reduced life span with such a local and hard to detect phenomenon. Even if the robot has 10% chance of being right, if there is a different road any person with critical thinking will avoid taking the risk by essentially paying nothing and simply using an alternative road.

[pbatard]

What evidence do I have of Rufus being safe? Developers saying so

No, it's developer trying to demonstrate to you how difficult it would actually be to conceal the malware (instead of your pipe dream that, because you can't/won't analyse source code, then it must be easy), because public code not something that sits under a rock, not to be looked at, and because, unlike what you want to assert, malware that does what the any.run report alleges Rufus does (such as disabling AV by altering the registry) does get detected.

You can reject that all you want, and pretend nobody but any.run is analysing registry changes when Rufus is running. But that doesn't make what I state above, about how actually difficult it would be to conceal the alleged malicious behaviour from Rufus, any less true.

And please feel free to ask other security experts, if you want to pretend that "it's just the developer saying so", because, even if I am the one to state it, detecting malicious registry changes at application runtime is actually not that difficult.

But we both know you're not going to bother trying to validate the allegation that forms the foundation of your whole tirade with actual security researchers, even as I have repeatedly prompted you to do so, because it would deprive you of your beloved "Developer says so".

the fact that no one found the malware yet.

Yup, that's the one.

You can't accuse someone of being a murderer unless someone found a dead body or there is a missing person, period. And we still haven't seen any human report of a dead body having been found or missing person. Instead we've only heard from some robot shouting "Danger, Danger, Will Robinson!" a few months ago, with yet no verifiable sign of danger around (but hey, the danger is probably just very good at concealing itself).

This would also not be a good piece of evidence of the malware is hidden so that it is hard to find by browsing the source code.

You keep coming back to this allegation as your only proof that Rufus may contain malware. That is not receivable evidence by a long shot. It's just allegation. And a bad one at that, as I've repeatedly tried to point out (see more on this right below).

This would also not be a good piece of evidence of the malware is hidden so that it is hard to find by browsing the source code.

Ah yes, good old "See officer, isn't the fact that we haven't seen a body or gotten a report of a missing person evidence in itself that this person might be a master criminal?".

Do you have many other such fallacies you want to impart on us?

A picture where any.runs uncovered a hidden action that rufus performs is therefore consistent picture.

You forgot the "allegedly". You are cherry picking your "truths", by dropping any possibility that there might be doubt, and instead holding an automated report as factual and "evidence", when people have repeatedly trying to tell you that false positives are a thing. Difference between "must" and "might", right?

I am not staying it must be true

Too bad you don't apply the same logic to the any.run report.

but there is some probability that it is true, and any person with critical thinking won't be taking a risk of using something that is probably safe when there are alternatives for which no evidence of malicious actions exists.

Yet you choose to completely disregard the possibility that the any.run can be a false positive (or that you are misinterpreting what the report actually says), in light of them being the only analysis tool that is reporting the AV disabling.

Sorry pal, but your logic makes no sense. Either you apply the same critical thinking on both sides, or you acknowledge that your reasoning that you should be entitled to distrust Rufus while at the same time not distrusting the any.run report is flawed. You can't have your cake and eat it there.

And that's what we've been trying to call you on (rather than your imaginary and convenient idea that we're somehow saying that Rufus is 100% absolutely safe because... "just trust the developer"), and what you are still completely trying to ignore.

Well, it can be close to impossible to pinpoint the cause of a medical condition, and pretty much impossible to associate something like reduced life span with such a local and hard to detect phenomenon.

LOL

And we're back to the "I think that person's a murderer. But they are so incredibly good at it that they make it look like people die of natural causes. And all I have for evidence is some automated report, that I am NOT going to question in any way, and that I am definitely not ask the people who generated it, or any other folks who might have expertise to apply on that matter, about. You'll just have to trust that automated report, and please ignore all the counterpoints that that person I am accusing of may put forward, about how difficult what I am claiming would be to accomplish, and that people who are familiar with such matters would no doubt validate in light of the absence of any other evidence...".

Even if the robot has 10% chance of being right

"Even if there's 10% chance of that guy being a murderer, because we have no evidence other than potentially unreliable hear and say, that guy should be put in jail, right?"

I don't think I want to live in the world you want to live in, because it's not a world ruled by logic or sanity, but by folks vaguely pointing accusatory fingers, and, through the form of very uneducated guesses (instead of asking for some more expert advice — and no, in case this needs to be spelt out, I'm not talking about myself here), throwing wild accusations around with very flimsy logic, if it can even be called that.

You're free not to use Rufus. But you're seriously making a fool of yourself with your dubious logic of why it should be considered untrustworthy, especially in the absence of anything that would remotely appear to validate any.run's claim (or rather, and this might be important, what you are interpreting the any.run report to say), even as months have passed.

So please go ahead and take the "alternative" road. It'll save us having to repeat why your logic is flawed and point again and again how, if you are so sure that Rufus might conceal malware, you are demonstrating that you are completely unwilling to help other users, by still refusing to contact experts on the matter, so that they can try to validate your claim and oust out the malware that you allege might be present in the application.

[pbatard]

Setting aside the irrelevant lengthy discussion above about false positives, I am coming back to this issue and would like to ask OP (@tomasz1986) if they are still seeing this behaviour?

For what is worth, whereas I was originally able to replicate the original issue with Windows 11 Pro for Workstations, when testing with the current latest build (Build 22621.2361), I can see that the problem no longer occurs and the UAC policy is no longer altered after Rufus launches.

Hopefully, OP can confirm this as well on a fully up to date version of Windows 10, as (and this is part of the reason I tagged this issue as deferred), all signs appear to point that this was a really a Windows bug, that Microsoft needed to fix, and that they have apparently finally sorted in a recent update, rather than something that Rufus should try to address...

[pbatard]

Since there has been no update, and I am no longer able to replicate the issue, I will close it.

[github-actions[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.