Conrad Sallian's community posts

Hi David,

Recently, Microsoft denied the inclusion of Remote Utilities in the MS Store, even though the previous version was accepted without any problems (both Viewer and Host). In their message, they referred to VirusTotal results as the basis for their decision. Apparently, if there is even a 1/70 detection ratio, they reject the submission—regardless of whether it’s a false positive or a warning like "potentially unwanted."

Even after ESET, whose PUP detection it was, directly confirmed via email that it wasn’t a malware detection, Microsoft didn’t revise their decision.

While we can't confirm this with absolute certainty, there are indications that Microsoft Defender and SmartScreen may rely on third-party detection data—such as VirusTotal results or sandbox analysis—to form their verdicts. This is concerning because VirusTotal was never intended for such purposes. It's an experimental platform, and its engines often operate in their most aggressive detection modes.

We always encourage users to immediately file a complaint with Microsoft whenever there’s even a single file detection or SmartScreen blocks a file download in Edge (as is currently the case with Agent). Edge provides a dedicated menu option for submitting such complaints. Without these complaints any antivirus detection system tends to retain false positive classifications unless explicitly brought to their attention.

Currently, our software adheres to every single CSA guideline—any analyst can easily verify this by examining the software. In our upcoming release, we will introduce features that could further address this situation. However, it seems that many antivirus engines disregard performing any thorough analysis.

It might be considered unethical to point this out, but I feel it’s important to mention. After the production systems(!) of one of our competitors—well-known remote access software—were breached a year ago and their digital signature was compromised, it took nearly a week for some antivirus software to start blocking files signed with that signature. During that time, it was unclear how many malware builds might have been signed with it and distributed.

Now compare this to every version of Remote Utilities being blocked by some well-known a/v programs immediately after release, despite being signed with a digital signature that has never been compromised, only for the detections to be removed later with apologies.  🤦

Hello Aurel,

Thank you for your message.

Could you please elaborate on what you specifically mean by macro commands with regards to Remote Utilities?

Hi Martin,

We completely understand your frustration. The current state of the "security" industry is indeed dismal. Security software providers often remain unaccountable for the damages they cause. Take this recent incident as an example.

Hello Martin,

We are sorry to hear that that happened.

Yes, I could have excluded RU from any AV access, but I naively assumed RU had been around long enough to not have this happen. Apparently, I'm wrong.

For modern antivirus software, longevity alone is no longer sufficient. They may blacklist a file that has been used by tens of thousands of paid customers and corporations—one whose digital signature hasn’t changed for years—based on a single incident or even a complaint from a victim who fell prey to a technical support scam where the software was used (pure social engineering).

The closest analogy would be confiscating kitchen knives from every household in the country simply because a single crime was committed using such a knife.

Oliver,

Update on this issue: In the next update, we will remove the Remote Utilities logo from the disclaimer window and reduce the window size. We understand that for customized Agents, our logo may not be appropriate.

Hi Oliver,

Thank you for your message.

The window you are referring to with the Remote Utilities logo is simply a disclaimer that is shown only once. It will not appear again when the Agent is run next time on the same computer. The user should select the checkbox and click 'Continue'.

This disclaimer was added to prevent antivirus software from flagging Remote Utilities as an 'unwanted' program or even a threat. Unfortunately, there is little we can do in today’s overly cautious antivirus landscape, where almost everything is treated as a potential threat.

Hope that helps.

Hi Scot,

Thank you for your message.

In version 7.6.2.0, the time window was already increased by 30 seconds in both directions (before and after). However, time synchronization is often the root cause of issues with 2FA not working.

I hope this helps.

Hi Graham,

Thank you for your message.

Here is how to use the macOS agent (and linux agent for that matter):

- Download the .dmg file
- Double click the downloaded file and drag the agent icon to the applications folder:




- Navigate to the Applications, find 'Remote Utilities Agent.app' and double click/run it.

This will open the Agent window with Internet-ID and password automatically generated, ready to accept connections.

Hope that helps.

Hello Brad,

This issue might arise because of how RDP interacts with the display driver on Windows XP (and older systems in general) within a virtual machine. When you initiate an RDP session, the operating system switches from the standard VGA driver (used by Proxmox) to the RDP-specific display driver. Even after disconnecting the RDP session, the operating system may not switch back to the original display driver.

Possible solutions:

1. Avoid using RDP for that machine altogether (if possible).

2. Limit RDP interference by launching RDP with the /admin or /console key:

mstsc /admin

to connect to the console session instead of creating a new RDP session.

3. Force XP to use the original VGA driver (a hack):

Locate the registry entry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Find (or create) the DWORD value:

DisableHardwareAcceleration

and set it to 1. Then restart the virtual machine.

4. Instead of restarting the virtual machine, you can create a bat file to manually make WinXP to switch back to the local console session:

tscon 0 /dest:console

Which you will need to run after the RDP session is over.

Still all the suggestions above aim to help with the same - switching back from using the rdp driver to the standard driver, which is the possibly the root cause of the issue.

Hope that helps.

Hi Brad,

Just to clarify, do you mean that it's the Full Control and/or View mode works until you rdp into the computer?