Prevx Edge not detecting anything.

Joe,
Prevx detects both the notepad tests here. I also participated in the same tests with OA in the link sded gave, Prevx worked there as well.

Am running Prevx, DefenseWall and Shadow Defender at present on Windows XP Home SP3 and System Restore is off.
Anything else you want me to try I'll have a go

 

Try doing an over-the-top reinstall of your current OA version. This kills Prevx detection on my system.

 

I have it disabled.

 

FWIW, I very much wanted to test Prevx with something else before uninstalling/reinstalling, so I ran eicar.com (from here) with all of my avast! shields terminated, and Prevx did nothing. With avast! shields running, avast! detected immediately. This is what made me believe that Prevx was broken.

 

An update on the diagnosis: Phantasm has "lent" me his computer for the last few hours and we're very close to having a full solution in place. We still have not reproduced this in-house but it is flawlessly reproduced on his PC and can definitely be fixed.

I will update here as soon as I have something final.

 

same here with mamutu or avira but prevx alone will do better than layer i experience this this week

 

Getting anxious to hear some good news on this, Joe.

 

he will, joe takes this stuff personally. Me? I think a little of 3.5 got released a tad to soon in 3.0.

 

So far I can't say it is perfectly fixed as we only have data from one user and absolutely no one else can reproduce it today However, we have identified the cause for the issue and do have a fix ready to deploy on-demand as soon as someone else can reproduce it. If not, the v3.5 release coming in the next week or so will have these changes in which will prevent this issue from happening in the future and will retroactively correct existing users who have had the issue as well.

 

Is this a case whereby if we knew the cause perhaps one of us could reproduce it?

 

We don't have a specific cause but the order of installation is relevant and the issue is time-dependent, depending on how quickly each of the drivers are loaded and the attachments made which is why it is very difficult to produce on demand.

 

An update to all:

We have finally tracked down the underlying issue at hand here with detecting files and have fixed it 100% thanks to some very patient beta testers! Our scheduled update is slotted for early next week and I am extremely confident in this fix and the fact that it will prevent it from happening in the future.

Thank you all for your patience - this has been a tricky one indeed but a fantastic issue to find!

 

Nice!!

 

Great news

 

Joe, as you know, I've had big problems getting Prevx working consistently in my VM (protection flipping between on/off) Does this have anything to do with it?

 

For unqualified peace of mind, I have had to test Prevx on my computers each day to make sure that it is detecting either notpad.exe or the eicar file. So far so good, but since this vulnerability came to light, (or I should say, since I witnessed it on both of my machines 4 days ago), I honestly have not fully trusted Prevx. I wish that wasn't the case, but it is.

In an earlier post on this thread, you said,

I keep going back over that statement in my head... "Our protection constantly tests itself"... and I'm thinking perhaps part of the forthcoming fix you speak of will include a test that a user can perform, maybe an auto version of what I have been doing to satisfy myself that Prevx is actually on the job. It really is disturbing to see that otherwise reassuring green light in the Prevx systray icon, indicating "System Status: Secure", while knowing that on the contrary that might not be the case at all.

 

Indeed there is a hole in the self testing which seemed illogical to occur: the communication between the protection engine and the scan engine does work fine, and files are scanned but not when they should be.

We are implementing a new level of self testing which will prevent any issue like this: whenever we see a new process start or new file open in memory, we are cross referencing it with the list of processes/files which have opened and that we have scanned. If the interception was somehow evaded because of an incompatibility between another AV, we will immediately latch onto this and warn the user.

 

Are you saying that this issue has to do with an incompatibility with another AV?

 

Yes, not necessarily an AV but other security - one of the main compatibility issues is MalwareBytes in realtime + Prevx however note that it is not a global issue: it will only happen in extremely rare circumstances and can be prevented with a minor registry change that lets Prevx play nicer with other security programs. We're holding off deploying this fix until the release of v3.5 which is scheduled for next week but if you do come across the issue again, let me know and I can send you the details.

 

It would be interesting to know which of my security programs interacted with Prevx to create the problem I experienced. As you've stated, if the situation is encountered again, I will surely be in touch.

 

okay, well first off i have not read past this post, so i do not know if a cure has been found. secondly, yes my system seems to be suffering from the broke Prevx syndrome.

i did the notpad test which downloaded without prompt from Prevx (or Comodo anti-virus for that matter). i ran the executible without prompt from Prev, i scanned from right click menu as well as a full system scan, Prevx is telling me all is well, green for go.

real time securoty apps Defensewall, Comodo CIS with anti-virus real-time profile enabled, and Prevx 3.0, on a Win XP SP3 machine.

i will find some really bad infections and see if Prevx awakens or not, as further testing. news at 11.

EDIT: seems as if the one place i know of to collect malware samples is experiencing database issues ( i wonder if the inmates are now running the asylum) and i have long since purged my "Live" folder of older samples.

i did attempt to run DFK Threat Simulator, which Prevx has long ago flagged as malicous. extracting ipod.exe was interesting, i received the disassociated file icon after the extraction (btw in the past P3 immediatly blocked this file with a prompt) and could not execute the file. i cliked on the P3 taskbar icon to see if P3 had blocked this file without prompting, and discovered P3 was scanning and had been for 42 seconds. after the scan my system was given a green system status, no prompts, and no indicatin ipod.exe was quaranteed. colour me stumped!

Mike

 

Mike, are you certain that none of your other security apps are blocking notpad.exe? With GeSWall on my system, and browser isolated, the download is automatically untrusted, or isolated... so I had to trust it.

I also test Prevx with eicar, and I had to terminate all avast! shields in order for Prevx to alert on it... although for some reason today Prevx is not objecting to the eicar test.

 

prett sure....the only other real-time app i have that may have blocked notpad is Comodi AV and it prompts, as far as i know there is no way to disable prompting.

and yes, notpad is untrusted. the whole purpose of my system being set-up the way it is with respect to security apps is Defensewall contains, Comodo FW & HIPS blocks, and P3 kills. if i download something that DW contains and is malicous, i fully expect P3 to block/remove it, and in all fairness it always has in the past. if something has changed and P3 can no longer look into DW containment, then it's useless to me. but i doubt this is the case, likely just an anomally, though a disturbing one.


Mike

 

I just ran notpad.exe on my system while it was untrusted by GeSWall, and to my surprise, Prevx did alert on it. So I was wrong to say that trusting notpad.exe was necessary on my machine to get Prevx to block it. Sorry for any confusion. This doesn't help you in any way with what you are dealing with, but I needed top clear up that error of mine.

 

Indeed I think this is the same anomaly which will be fixed very shortly. We're just finishing some final changes and will have test versions available very soon.

The change which will let v3.0 work properly is as follows (note: it requires registry modifications so play carefully/with backups):

- Uninstall Prevx 3.0
- Reinstall Prevx 3.0
- Change HKLM\System\CurrentControlSet\Services\pxsec\Instances\PrevxSEC Instance\ value name "Altitude" to 321200
- Change HKLM\System\CurrentControlSet\Services\pxsec - value named Type, to 2 (type DWORD)

and then reboot your PC. This will correct the incompatibility but the pending Prevx 3.5 upgrade will do the same and prevent it from happening in the future (and is scheduled for release this week).