[Bug/Security] Norton 360 Data Protector blocked a suspicious action by <exe> for C:\Windows\INF\input.inf
cyraid opened this issue · 8 comments
Summary
Suspicious process attempted to lock a file protected by Data Protector
As the title says, for some reason an executable run with Silk.Net pops up a warning by Norton. Sometimes the file is C:\Windows\INF\keyboard.inf and sometimes input.pnf if I remember?
Steps to reproduce
- Platform: Desktop (Windows 11)
- Framework Version: .NET Core 8
- API: OpenGL
- API Version: OpenGLES 3.0
- Use Norton 360.
- Use Silk.NET and open a Window
- Use
window.CreateInput() - Iterate
input.Keyboardswith aforeach.
var input = window.CreateInput();
foreach (var kb in input.Keyboards)
kb.KeyDown += OnKeyDown;Comments
I'm not sure exactly if it does come from the CreateInput(), as I can't seem to time when it pops up, but I'm guessing it comes from it. I've tried with various Windowing attempts (SDL, GLFW) and both seem to trigger it?
Does Silk.NET iterate over devices at any point?
I've gone ahead and removed that comment, it's a common scam going around atm. Please remove the link from your comment as well.
I'm not sure I have enough to go off with this issue.
@Perksey Hi Perksey. Been a long while. Does Input do any scanning with OtherDevices? I didn't check too much into it yet. Like any winapi that would lock the file? Other Norton users would have this same popup with others that use Silk.NET, so I'm thinking it may be dotnet doing it.
It's possible that this is occurring as a result of the Win32 APIs that GLFW and SDL use, but these are standard. Those files contain the data required to enumerate input devices. It is completely normal to access input.inf and hidserv.pnf. I have checked GLFW and SDL and they make no direct reference to these files, so this is a Win32 thing (i.e. built-in OS API/functionality). A good antivirus would not block this.
The weird thing is, it still works but pops up a security warning. I'm guessing it's blocking the "locking" of the file and granting read only access.. But why would the win API need to lock the file at all? I suppose if an API is locking it, it would be so the file doesn't change while reading but, you'd think a good Antivirus would allow this but prevent modification? But alas, people use Norton.
A file is locked by default when reading it. The file afaik doesn't have write permissions except when used when running as administrator/the OS itself.
Having looked at the code (obviously can't disclose too much), Windows uses this to get a friendly name for the HID device using GetPrivateProfileStringW which in turn uses NtOpenFile. Interestingly, while this operation opens a file handle (that would usually lock the file from other accesses), this does use FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE which effectively makes it unlocked. I think your antivirus is just objecting to this file being accessed at all.
Your antivirus should not be blocking standard DirectInput functionality.
As far as I've been able to test, a file is determined if it's shared from it's shared access settings for the flags set when opening a file which determines if other processes can access the file. Eg. FILE_SHARE_READ.
There's also LockFile, etc.
But that aside, I have read online with others having similar problems with Norton and games. That's really unfortunate. I'll close this bug request and see if I can raise the issue with Norton and help some others in the process.