Closed Jon8RFC closed 9 months ago
Well we experienced this only with Debug, never with Release, or the Store version. Are you using the Store version or one of the Releases in 7z?
7z files on the releases page.
So I checked now and AdbProgressRedirection.exe in the latest release is indeed detected as a threat by Windows Defender. It's weird because nothing changed in it since the first public version. Anyway I replaced it with the exe from the previous release: ADB_Explorer_0.8.23120a_x64.zip
This one doesn't seem to trigger Windows Defender. If it works for you, I'll update it in the official release.
The old version works and does not trigger Windows Defender.
The file mentioned ( AdbProgressRedirection.exe ) is flagged by 11 security vendors as malicious at VirusTotal https://www.virustotal.com/gui/file/197b40ab56d5e5df357f5e5be6215fffb6ab35c09f6d966819621fe54f0c8f9f/detection
(Installed latest release - based on this report, I tried replacing the file with that from older version, however, there is no binary difference between the 2 .exe's and both are detected as malicious.)
Well it looks like it is the latest compilation, 17-Dec-2023, that is detected by 11 security vendors.
The first public compilation, from 27-Jun-2022, is only detected by 4 vendors, which is better.
Executable: AdbProgressRedirection.zip
VirusTotal analysis: https://www.virustotal.com/gui/file/3e5419dd6dc094b7a788dd6977aacfdcbbd29e34ca0559162be0cbef75502193/details
These compilations were both compiled with the same code, just different versions of MSVC and linker.
As stated before, the progress redirection is required to get progress updates from ADB in real time since ADB writes to console output on new updates instead of printing to stdout (which makes it more readable for a human, but a real hassle in C#).
Apparently, this behavior is considered suspicious, and there's not much that can be done about it, except testing different compilation scenarios for virus detection.
Option B is to let the user decide whether to deploy progress redirection, or instead execute push & pull operations with the CMD window visible for the user to see the progress themselves. This does prevent the app and the user from getting the push/pull summary after it's finished. It's ugly, but it will work...
Option C is to calculate the size of the items to transfer (in case it's a folder), and when paired with process disk usage, you get the transfer progress. This is probably the cleanest option, but recursive size calculation of folders can take a lot of time.
Of course, we can always combine B & C, to let the user decide.
I wish I could help, but can only offer opinion as user (and thankful user, because this is very useful software!) If AV file/system scans flag the redirect module, would you need to have the option at install vs at run? I like giving user the explanation & choice of using the 'malicious' module with the progress, or [some variant of option B] I don't like option C because of time - is there possibility of having option C show an updating transfer total of files and/or bytes for large transfers. That would eliminate need to know total transfer size but give user something..
Yes, showing total bytes transferred is easy. Then progress can be calculated if the size is known, otherwise you'll just see that it's doing something.
Is there any way to mitigate those? The dll and exe files throw up numerous flags at virustotal and Windows Defender no longer lets it run or download.