To flag or not to flag, that is the question; (PRGrep.exe - "Winstart")

Hi Guys,

A day or two ago I decided to test PRGrep Utility (context search in files) and I got an Alert

File was submitted as per known rules. I haven’t got email back yet but since BOClean was updated, I decided to check. First I dropped the file in question unto BOC window. It was quiet. Good – FP was fixed –was the conclusion.
I started the program and checked few things.
This evening I started PRGrep… and it was flagged again… hmm (???) – there were no updates for BOC.
To make the story short: If BOC interface is active – there is no Alert.

I have a feeling that I was reading something like that long ago. I would prefer to be wrong though, because I’m not sure it is correct behaviour. File should be explicitly placed into Excluder’s exception list in order to stop Alerts… and then Drag & Drop should fire up the Alert anyway. I understand that the latter is different to execution but still memory scans in both cases should not differ.
Am I missing something?

Thanks in advance

My regards

Thanks for reporting. The FP has been fixed in the latest update.


Hi Baskar,

Thanks for reply. It was fixed indeed. I had no doubts … but I checked :wink:

At the same time the submission was made silently first time. The purpose of my post above was mostly dedicated to different issue - “not flagging potential threat when GUI is active”

It would be highly appreciated to get some responses from developers regarding that particular matter

Thank you in advance
Best wishes

Greetings, and apologies for the wait. Dragging anything to the BOClean popup menu will cause BOClean to examine the file for a FILE match only, but it won’t detect things unless it matches our original FIRST submission file sample. Since the file in question isn’t actually running, there can’t be a memory test since it won’t be running in memory as a result of being dragged and dropped. In other words, “drag and drop” won’t spot variants and it seems that’s what your particular FP detection was based on “memory detect” rather than as a file. Not uncommon at all there. Malware is routinely obfuscated and can only be detected properly in memory by BOClean, which is what apparently happened as the detection still remained until it was fixed.

That “drag and drop” feature was never intended for use by the public, but rather exists for our own people to check submitted samples to see if we were about to handle a duplicate submission. Nothing else than that. So if something isn’t detected on a “file drop” it doesn’t necessarily get detected unless it matches that original file by doing that move. Somehow “legend” has replaced the reality as we’ve explained this before as to “leaving it in there” for our loyal submitters. We accidentally released a 4.06 version with that feature unintentionally left in the “commercial build” of BOClean (we used to distribute a special “test build” to our lab folks and spotters) years ago and were kinda forced to leave it there in subsequent releases. BOClean is NOT a file scanner, and so about all that’s useful for is spotting things we’ve seen before to our spotters. Only mentioning this to prevent future confusion as to how things work. When the “5” version of BOClean finally gets back on the front burner (CAVS is the priority right now) we’re probably going to remove that feature as we haven’t fed it in a long while now since we now have automated handling of submissions thanks to Robert A. here, and humans don’t have to wade through duplicates anymore. :slight_smile:

Hope this helps to explain for you … that “feature” isn’t what many have come to think it’s there for. It’s only still there for the sanity of those about to submit a nasty we already know, and BOClean’s “file sig” portion only recognizes the very first of a set of nasties we’ve seen. Variants won’t likely be detected by the old “drag and drop” and that tells our spotters, “send it in!” Bottom line, don’t count on the drag and drop for detection, that was never its purpose …

Hi Kevin,

Thank you for explanation.

Well, I do agree that since “dag & drop” has kinda internal purpose an actually can give different result(s) - it should be disabled for “public use” and remain deeply internal
Viva version 5! (we don’t need confusions :smiley: )

Probably that should’ve been done a while ago… there were lot of discussions about it here.
… but that is fine - at least we know a bit more about it.

The only question left:

That was not “drag & drop” by itself stressed as major concern in my description
As I mentioned the said detection was not flagged irrespectively to “drag & drop”
There was no flagging when BOClean’s GUI was active and that is what shouldn’ve happened
I apologize if that wasn’t put clear enough… I thought it was.
As it’s shown on second image - there was no “drag & drop” prior to starting of suspected Application and it was not flagged. Flagging occurred only when there were no BOC window.

My regards

Sorry once again for the delay - my connectivity here in upstate New York is often non-existent after an ice storm last month and since I was able to get here last night for the first time in a while, wanted to get you an answer while I still could. :frowning:

As best as I can comprehend your question, I think what you’re down to is why didn’t BOClean pop up on you with the menu item opened … if that’s the question, then this too is part of the original design in that we did NOT expect folks to leave the menu item up and while it’s up, BOClean IS suspended since things can get messed up internally while that’s open. This is why when you close it, you’ll notice that BOClean throws away all of the data it remembered and then does a thorough re-scan of everything. Solution, don’t leave that open unless you’re doing a manual update or require details or a configuration change.

Because BOClean in its current form MUST be compatible with all versions of windows back to WFW3.11, there is only one thread running in the GUI at any given time. If the menu is open, it will miss that notification until it does a rescan after it has been closed. Things can slip by …

This is why when the 5 version gets built, it will be for XP and later only … those still using older versions of Windows will be stuck with a “final 4.xx” build which will continue to be updated for those folks “stuck in the past” for as many years into the future as is practical. However, once freed from the old Win9X code, then this won’t be a problem … assuming I finally understand what you meant there …

Hi Kevin,

“Sorry once again for the delay” ??? What delay? When?

I wish every developer was as responsive as you are giving detailed info and sharing thoughts.

…and yes - that’s what I meant and I am glad that v5 will have correct behaviour regarding the issue.

My best wishes :■■■■