You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to be able to have an option to force the NetMQ.Core.Utils.Clock's s_rdtscSupported to false, and therefore always fall back to using Stopwatch.GetTimestamp. As an idea add this Boolean:
publicclassSocketOptions{/// <summary>/// If set, the time stamp counter is not read directly through opcode injection, rather/// <see cref="System.Diagnostics.Stopwatch.GetTimestamp"/> is used./// </summary>publicstaticboolDoNotUseRDTSC;
The method of injecting opcode into memory and invoking it to read the time stamp counter is being detected as dynamic shellcode by some anti-malware such as Sophos. When detected, the process executing the code is terminated. The detection as malware occurs when the Opcode.Open method is called and the s_codeBuffer is allocated with EXECUTE_READWRITE.
Steps to reproduce the behavior
Bind a publish socket to a tcp URL when running on a system protected by Sophos. Unfortunately, my companies corporate IT has deployed this feature everywhere and I can't argue it is able to detect actual malware scenarios. But I have a large engineering community where ZeroMQ is going to become more prevalent.
The text was updated successfully, but these errors were encountered:
Environment
Expected behavior
I would like to be able to have an option to force the NetMQ.Core.Utils.Clock's s_rdtscSupported to false, and therefore always fall back to using Stopwatch.GetTimestamp. As an idea add this Boolean:
Then in Opcode.Open
Actual behavior
The method of injecting opcode into memory and invoking it to read the time stamp counter is being detected as dynamic shellcode by some anti-malware such as Sophos. When detected, the process executing the code is terminated. The detection as malware occurs when the Opcode.Open method is called and the s_codeBuffer is allocated with EXECUTE_READWRITE.
Steps to reproduce the behavior
Bind a publish socket to a tcp URL when running on a system protected by Sophos. Unfortunately, my companies corporate IT has deployed this feature everywhere and I can't argue it is able to detect actual malware scenarios. But I have a large engineering community where ZeroMQ is going to become more prevalent.
The text was updated successfully, but these errors were encountered: