switch-remote-play-host deleted by windows defender - fix documentation

[lapp0]

The current docs don't work because switch-remote-play-host is automatically deleted when extracted, both from 7zip and zip. There is no option in windows defender to allow this program before or after it's run.

To resolve this you must

• copy the folder over
• do not view properties, open, or do anything with switch-remote-play-host
• Open windows defender
• Virus & threat protection
• quick scan
• select the switch-remote-play-host folder
• there will be a virus detected message: Trojan:Win32/Wacatac.D6!ml,
• • Verify that switch-remote-play doesn't include malware. I have no idea whether it does! Please check for yourself, it is a good security practice. Note, a quick review appears that this often is the result of unsigned binaries. Perhaps a separate issue should be created to sign your releases?
• • you must select "allow on system"
• if the file was deleted, you must extract once more
• all set!

[lapp0]

Related to #15 #10

[Moehammered]

Thank you for detailing how you managed to get Windows Defender to stop deleting it.

I've found that Windows Defender also has been updated now and can delete files within a 7zip archive. But regardless of this users can always check the Windows Defender history and go through the threats and choose to allow them.

Or users can whitelist a folder but I chose not to show users how to do in the interest of not causing security issues for users.

As for signing, I attempted that in one of the previous releases but it did not stop it from triggering the virus detection. Like I have stated in the documentation, it is due to 2 features of the program:

• It keeps a broadcast port open for listening
• It executes ffmpeg via CreateProcess

I don't know a way around this issue yet. Only thing I've seen is to contact the virus scanners and request a whitelist of the program but because I am still working on it and updating it I'd rather not.
That said, this is also why people should only ever download this program from this repository. If some malicious person replaced the ffmpeg.exe file with a virus then it'd be dangerous. Thankfully however the proper ffmpeg program doesn't get detected as a virus. So if it ever does, users can and should go and download the ffmpeg program themselves.

Thank you for providing a breakdown on how you solved the issue. I will update the documentation to include a link to your comment as well as provide a way to safely ensure ffmpeg is safe for users who'd like to take extra precautions.

I will close this issue once the documentation is updated.

Kind Regards.

[lapp0]

Virus scan for release executable https://www.virustotal.com/gui/file/e4fd31a1e92454e7c7964180cbd4051a14d5a8036097fa0141fb193f6a72d122/detection

https://www.virustotal.com/gui/file/6994d74755c1c1a4debaac9ef1b7c97b1d3255e6d07f0d7b35a934cdc3da3530/detection

• checks-network-adapters
• • this seems like necessary functionality? I couldn't find anyone resolving or having this false positive
• invalid-rich-pe-linker-version
• • I found an example of this being fixed here: die_win32_portable_3.00.zip is reported as trojan horsicq/DIE-engine#17 https://github.com/horsicq/DIE-engine/compare/851176f03b82bacd7954bb2b21b4183dee397f36..2bf491dfd62f4282693b17066cc0a8e6b00043a5
• peexe
• runtime-modules

[Moehammered]

I'm aware of the virustotal results of the executable. The debug version also produces different results.

• Network adapter functionality
  • It is necessary. Scans broadcast for network discovery of switch. Prints out diagnostic info of network configuration. Accepts connection from the switch in order to stream data.
• Rich pe linker version
  • I'm unsure of what the exact 'fix' was in that link. Reading through it, the dev made a submission to Microsoft to whitelist the application. Is that what you were referring to?
  • In the case of submitting a whitelist request, I don't plan to do one anytime soon because there are many modifications I'm still in the process of making. I don't want to have to create a whitelist submission for every release. Once the program is in a stable state I will consider it.

The rest are most likely triggering from CreateProcess. You can google other users using the CreateProcess function and having similar issues. I don't have a way around that yet.

[lapp0]

My understanding is the fix involved removing link.exe in the build https://github.com/horsicq/DIE-engine/compare/851176f03b82bacd7954bb2b21b4183dee397f36..2bf491dfd62f4282693b17066cc0a8e6b00043a5#diff-0d42097698da2d7b3c23030021047bd316d946e9f69fc854d2013d7bf8dd0c81L58

The XOR key used for encryption of the Rich Header is a unique four-byte value generated for every executable built by a Microsoft compiler (linker). The value is a checksum of the DOS header, the DOS stub and plaintext Rich Header data. The checksum calculation algorithm can be found in the IMAGE::CbBuildProdidBlock function in Visual Studio’s link.exe binary. A code snippet is shown in Figure 5.

You don't use link.exe in your build (at least not explicitly in this repo), but maybe that link above has a hint. Sorry I can't be of more help, windows builds aren't my wheelhouse.

[Moehammered]

Thanks for digging that up for me. Much appreciated!

Yeah I noticed that the build files in that linked repo started using qmake.exe to perform the builds.
I'll look into link.exe and see if I can remove it from the build process if it's present. I'm just hoping it isn't the actual linker program because then removing it would not be possible.

You've been very helpful. Please no apologies necessary :)

[ElBori82]

Up voted this on virstotal and left a brief description. I also marked it as safe on Hitman Pro. Hope this helps somehow.