VoodooShield/Cyberlock

Well, what doesn't work now, will lead us to what "does" work in the future. Often times this is how life itself works.
How long that path is ?, who knows.
I understand your drive and views on this, and respect your openness.
Having to reboot in the event of a compromised system sure beats the hell out of loosing my data or having
a busted system that now requires a complete OS reinstall.
I do agree that there should be a closed or Alpha testers group Dan, and only "semi stable" open beta versions
should appear on any public access forums.
There are a few of us Long time users that would be more than happy to Alpha builds for you.
I would be in that line gladly, and I test in a real world environment because I use dual drives
that I clone so a crash is of no concern to me, seeing I can swap a drive and boot in under a min 30.
If you decide to go that route keep me in mind.
PeAcE

 

so you are saying that you ignore the possibility that a users mistakenly allowing a malware? what about social engineering? so the feedback in this case isn't valid to evaluate your feature? really?
If you test a security feature, you test it against all vectors attacks and user mistakes is a vector attack, this is basic of security.

good, better late than never.

What are you talking about? i said that @mWave told you about ObRegisterCallbacks since the beginning ( here ), you ignored it (Here), saying it is not the best option (because it allows continual tries from the attacker: here and here). So from this, i said "if you can't find a way to do a decent self-protection; drop it and just focus on the strong point" (which is blocking a process to even try to disable the service). Don't distort the meaning of my words...

of course, what you think is the job of a tester or the Quality & Control/Assurance team ? to know every stuff the devs do? no at all.
Those testing teams are separated from the dev team, so they don't know what the devs are doing , they take the build, test it to the core, and report.
And the Dev team don't know the testing procedure of the test team. it is how it works.

I don't care of all the procedure/works you do, what interest me (and every users here) is the behavior of the build we have, report and give feedbacks and opinion about mechanism and features.
We just help you with objective and constructive opinions. Objective means things you won't like, this is part of the deal to make a product greater and popular.
And i think i did quite a lot to help you, even if sometimes it annoys you.

who said the opposite? no need to quote every people , i know how is your product, i dont need people telling me .

Now if you find my opinions not valuable, just tell me and i will withdraw like the others, because i don't like waste my time for nothing.

 

@stapp Closed beta testers get closed builds ; then they keep using it , until next closed beta builds, and this goes on and on...then public testers get the "public beta" which is a fixed builds made from the closed tester feedbacks.

Alpha (internal build) > closed beta (1st external but private build) > public beta (2nd external but not private build) > stable release

Mostly closed betas tester test the core functionality and security, while public ones test compatibility with various environment.
Closed-beta testers must be more rigorous, knowledgeable and reliable than others testers, because they influence the core of the product and the fix that are required.

Look at me , i currently closed-beta testing several softs (so i have them permanently on my machines) : Appguard, ReHIPS, HMPA. You can't be a closed beta if you don't use it daily.
The case you mentioned are public beta testers, for people that just want to try the latest builds/features before the stable.

 

Saved me the trouble guest

 

+1

One thing I forgot to mention last night was--to me at least--very painfully obvious, that any security solution is going to be targeted because the malware has no place to hide. It's NOT because it's a profit-making opportunity, it's because it interrupts blackhat business. I'm put in mind of a military sentry: always among the first to die (hopefully quietly) in any attack. There's nothing special about VS, it just happens to be In. The. Way. So it has to be killed. That's why all useful AVs have self-defense: because they do their jobs well.

-------

I must also say that the last few pages have been disturbingly unedifying. I've seen more useful discussion in a kindergarten. But then kindergartens have so few precious egos.

 

Agreed.

 

Again, I oppose the fragmentation of testers into groups...The suggestion that it should by a few here reeks of egotism.

 

Understood your point

technically you are right, it wouldn't add much more, but from an outsider perspective, seeing that kind of discussion publicly, will not give a good picture of VS efficiency.
for example; from this discussion, some members told me that they decided to uninstall VS for the moment because they don't feel it securing enough...why? because:
1- the macro video published
2- no self-protection and that surprised them.

Problem is not that those issues are PoC and very limited and specific but that impact the image of VS; however if Dan doesn't care much of the image, indeed it is not necessary.

Most big names have a "closed beta testers" area , to discuss discovered vulnerabilities/mechanism bugs, missing/may-be added features, etc... and those discussion help the developers while being private so malcoders don't get more infos that they should about the product.


And indeed it is Dan decision

 

Cool, thank you, I appreciate that!

 

Hi Peter2150,

If a piece of malware has made itself permanently resident on the system, then why would they need to terminate VS ? Wouldn't that act of disabling VS tip off the user ?

 

When discussing UAC, how many times have you said “If the user clicks allow, it is not a bypass!”?

Correct… the ObRegisterCallbacks routine provides the user with unlimited attempts at being defeated, and my method hopefully fixes that.

You referenced the watch dog method I do not like… where is the confusion?

 

Pete, do you have any specific examples, so we do not have to be discussing hypotheticals?

 

Very true.

 

Too funny

 

“Remember the two benefits of failure. First, if you do fail, you learn what doesn't work; and second, the failure gives you the opportunity to try a new approach.”

― Roger Von Oech



Continue Dan, I think more users support your efforts than the few who use this as a platform to spout their so called expertise.

 

As soon as an attempt to kill VS is detected, the service kicks in and locks down the system. How is that funny .

How is your valid bypass coming along mWave? You have three days, and time is ticking.

 

I completely agree that all bets are off when malware is able to successfully execute... which is why I am a huge fan of application whitelisting. The only question is, how does malware edit the registry without VS blocking it first?

 

we don't talk bypass, we talk self-protection...i dont care of bypass...self protection is assuming you are bypassed already..so stop mentioning bypasses.

Instead of implementing a fast and simple solution that is proved efficient and works for "everybody" , you try do something fancy that is doesn't even work properly yet....if it was efficient, this topic won't last 15 useless pages...
Why not just implementing the one working and then experimenting your method later... because at the moment , the only things you achieved is making people get rid of VS...well done...

 

Overuse of "smileys" is this a teenage chatroom?.....Grow up!