Reply to thread

Message

<blockquote data-quote="danb" data-source="post: 1123073" data-attributes="member: 62850"><p>There is a very good chance that it used to work like this.&nbsp; See, when a new process is detected, CyberLock evaluates the process with a massive set of rules, then it uploads the file to WLC / VoodooAi, and then it evaluates the process with our antimalware contextual engine, then it checks the rules to see if the item should be blocked or not, and if it is determined that the file should be blocked, then CyberLock presents the user prompt.&nbsp; The initial rules is where CyberLock checks to see if it is Disable / Install mode, and these rules have changes drastically throughout the years.&nbsp; Whenever you have this many rules, there are going to be some conflicts within the rules (there is no way around it), so when that happens, we reorder the rules to further refine the algorithms / decision tree.&nbsp; Over the years we have refined this part of the code time and time again to where there are very few conflicts at this point.&nbsp; But I distinctly remember moving the Disable / Install rule 3-4 times throughout the years.&nbsp; And depending on where that rule is, it might have worked correctly, or it might not have.&nbsp; And actually, that is how I am going to fix this issue... I am going to move that rule either further up or further down the chain... but hopefully when I do that, it will not create another conflict <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite110" alt=";)" title="Wink&nbsp; &nbsp; ;)" loading="lazy" data-shortname=";)" />.&nbsp; If it does, I can create a special rule that if CyberLock is in the Disable / Install mode and a valid CyberLock installer is detected... then we can prompt the user to ask them to exit CyberLock since it is in Disable / Install mode.</p></blockquote><p></p>

[QUOTE="danb, post: 1123073, member: 62850"] There is a very good chance that it used to work like this. See, when a new process is detected, CyberLock evaluates the process with a massive set of rules, then it uploads the file to WLC / VoodooAi, and then it evaluates the process with our antimalware contextual engine, then it checks the rules to see if the item should be blocked or not, and if it is determined that the file should be blocked, then CyberLock presents the user prompt. The initial rules is where CyberLock checks to see if it is Disable / Install mode, and these rules have changes drastically throughout the years. Whenever you have this many rules, there are going to be some conflicts within the rules (there is no way around it), so when that happens, we reorder the rules to further refine the algorithms / decision tree. Over the years we have refined this part of the code time and time again to where there are very few conflicts at this point. But I distinctly remember moving the Disable / Install rule 3-4 times throughout the years. And depending on where that rule is, it might have worked correctly, or it might not have. And actually, that is how I am going to fix this issue... I am going to move that rule either further up or further down the chain... but hopefully when I do that, it will not create another conflict ;). If it does, I can create a special rule that if CyberLock is in the Disable / Install mode and a valid CyberLock installer is detected... then we can prompt the user to ask them to exit CyberLock since it is in Disable / Install mode. [/QUOTE]

Verification