If its using sigs., they should be stored in one of its directories. Should be easy enough to verify. Also, those sigs. have to be updated so RansomFree has to be periodically dialing out.
I'm pleased with its performance (given cruelsisters appraisal) and look forward to its continuing development.
Don't worry, I won't, any more than I would depend on seatbelts to save me if I drive my truck over a cliff. But neither would I remove my seatbelts.
A new version has been released: 2.2.2.0 No changelog. Code: Cybereason RansomFree 2.2.2.0 (timestamp: 2017-01-15) https://ransomfree.cybereason.com/download/ or: https://ransomfreedownload.cybereason.com/CybereasonRansomFree.msi
Introducing RansomFree Free ransomware protection software Protecting against 99% of ransomware types
That would be cool, because this means it will probably block most known ransomware. Good point. I can't deny that I also take this stuff into consideration, you can't just blindly trust security companies, sadly enough. Just look at what AV companies are doing, with all that system monitoring, which I call spying. But anyway, to me it would be more reassuring if the developer would make a comeback. It probably still fails to protect multiple partitions? And what type of ransomware did you test?
Weird, this means that both their signatures and pro-active detection are not good enough. I really would love to hear what the developer has to say about this, I mean didn't he test RF against ransomware that's currently in the wild? And again, I do appreciate his efforts to build this tool, and 100% security isn't possible, but detection should really be better.
It doesn't seem to interfere with the installation files that it did before. As for its effectiveness, I think we need to wait for real life situations and personal experiences. Maybe I'm naïve, but I'm not convinced that the testers are more competent than the developers are, or that the developers are trying to perpetrate some scam in providing the product for free as has been suggested.
So you're still claiming that the only thing it has is honey pots, despite what the developers say and experiences from people like me that would indicate otherwise? Your initial testing indicated what you wanted to prove, and you're done?
Actually I've stopped testing. I don't know if they have added anything more. When you say your experiences do you mean you've tested it against real malware? The other thing is it doesn't take much competence. Just get the malware(it's available) and run it in a safe environment. The safe environment can be the tricky part.
"The other thing is it doesn't take much competence. Just get the malware(it's available) and run it in a safe environment. The safe environment can be the tricky part." Shadow Defender?
No, I'm talking about my experience with it interfering with certain legitimate installations as I've discussed above in this thread. Yes, but in some ways a "safe environment" will tend to be a test tube type environment. While I find self tests entertaining and somewhat useful, I get a little concerned when a company and its product seems to get dismissed from the start as if they don't have a clue what they're doing while everyone else does. But I'm not blaming you, if I was convinced it was a failure, I wouldn't waste time on it either.
Curiously, a competing company didn't find it as completely ineffective: (https://techtalk.pcpitstop.com/2016/12/20/ransomfree-vs-pc-matic/) And that was from over a month ago. It goes on to say that the "major issues" are that the user may override the alert, and some of the same concerns about the honey pots, it appears they may be under the same impression that honey pots are the only method of detection. So, of course, in conclusion, they believe that even though in their tests it was 100% effective, their product is better. (Surprise! )
Peter- your comment about testing: "The other thing is it doesn't take much competence. Just get the malware (it's available) and run it in a safe environment. The safe environment can be the tricky part." Really? I always thought a valid test would be in using the product to be tested and analyzing it enough to understand what the protection methodology is, then with the intimate knowledge of malware and their mechanisms (build up over years of experience) to choose those samples that will breach the protection afforded by the product to prove a point- and a point that may be in direct contradiction to the self-serving claims of the Developer. Was I wrong? I can honestly say that this last page of comments was the first time I've been depressed in quite a while...
A valid test is one which accomplishes the objective. We have different objectives. Let me give you a real live analogy. Years ago I applied for a job with Ford Motor Co. They were hiring for the test group. The had two groups of testers. The first took cars that were wired up like lab rats. They monitor temperature points, various pressures, totally measuring the heart beat of the engine,transmission, drive axles, just about everything. The 2nd group just drove the car. On the track, out on the highway, and what they were monitoring was the experience of the driver and passengers. How it was in a short to the store visit, and how it was for a 5 day trip. Different tests. Same is true here. I don't use any special samples, just as they are released. Although I know generally how the software I use works, I don't need to know. Also I don't need to know how the malware works either. All I need to know for ME, is does the software detect and stop the malware as claimed. It's that simple. Once detected one can chose the method of remedying the problem. This tells me if the claims made by a developer are valid for the malware most likely to be encountered. Frankly, it bothers me that you are tailoring the tests to the product. I feel it puts a cloud over the impartiality of the tests, and opens the door to claims that you are testing for self serving claims you make. I am not at all saying you do that, but you do open the door for that. Hope that makes sense. Pete