While working on VS 5.50, I explored the possibility of adding SRP to VS. It turns out, we can add full SRP to VS in around 4-5 hours, and will be happy to do so if ANYONE can figure out a compelling reason to do so.
- November 30, 2019 at 1:49 am
So far, I have yet to find a good reason to do so, although some people insist SRP is the way to go.
What Umbra does not understand is that the dll is not going to spawn itself and the driver is not going to install itself. And VS will block the executable or command line (eg rundll32) long before this happens. As far as memory protection goes… who needs memory protection when the file is blocked from running in the first place?
There are however, a few disadvantages to implementing SRP into VS. SRP is not nearly as flexible or granular as the mechanism VS currently uses. That, and I do not believe there is a way to parse the command line with SRP, so that makes it even less flexible and granular.
But if anyone can find a reason for me to add SRP to VS, I will be happy to do so over the weekend. Thank you!00
- December 2, 2019 at 7:08 pm
Geri123: Disclaimer: Novice+ user here so all I did could have been totally wrong but I had always a backup so I wouldn’t rage if all went south.
I used appguard before it became a subscription model. Since I have a rather static system and after adding some programs appguard worked good for me. As long as my stuff runs and works as expected I don’t care if I get popups for memory blocks or so. Systems runs normal > don’t care about “memory blocks”.
If the wouldn’t get greedy for company money and had decent end user prices I would still think about it.
I used Hard Configurator from Andy Full. Besides having activated 173 sponsors on the blocklist and nearly maxed all the “designated file types” I didn’t see any block in my “blocked events” log.
The file types I see in the list I have never encountered as a home user and doubt I ever will. I can update stuff like adguard (desktop app from the adblocker) without problems.
From memory: VS on the other hand gives tones of popups when adguard uses.tmp or tmp.exe for updating from a dumb filepath. [Getting as “suspicious” warning in VS without any real VT results to back it up doesn’t help much]
I know it’s the fault of adguards devs for using stupid file pathes but you either trust them and disable VS and hope for Windows Defender/your AV or click accept 10++ times in VS
Tldr: As long as SRP seems to let me block 173 sponsors and dozens of strange file types without any problems why not give me an option to do it in VS?
Actually, VS automatically blocks pretty much all of the Windows files as sponsors, along with all of the ones listed in the Anti-Exploit /Vulnerable Protected Applications box in Advanced settings. And you can add more if you like. We actually pioneered that mechanism here…
At the time, most people thought I was crazy and thought it was a silly new feature that would never work correctly, but I knew it was going to be an important mechanism moving forward, so I kept working at it. We actually could list all of the blocked sponsors, but it would be thousands of items that the user would have to decide whether to block or not. Most people do not even know that mechanism is active because they do not receive any unnecessary prompts, so it would be foolish in my opinion to make these items user-definable, simply because malware does not discriminate. I hear all of the time “yeah, home users do not need to worry about this malware or that exploit”, or “that would only happen on a corporate network.” I mean, when someone says something as ridiculous as this, they do not realize that A LOT of corporate laptops join home networks each and every night. They also forget about the collateral damage that WannaCry and other malware create on endpoints they did not intend to infect. Remember Stuxnet? The creators of Stuxnet with the GREAT lengths to ensure their malware was only delivered to the intended target, only for it to blow up world wide.
So as long as our automatic mechanism does not impact usability, and as long as users do not experience unwanted user prompts, it would be absolutely foolish to make these items user-definable. As I was saying, malware does not discriminate… and often times there is collateral damage.
Speaking of silly things people say… a lot of times people will try to differentiate between home users and corporate users, and imply that corporate users are able to handle more advanced security software more effectively. This is simply not the case… home users go to work to use the computer, then they come home to use the computer. There is absolutely no correlation between corporate and home user skill level.
That is interesting on the adguard block… do you have an old version of adguard that will update itself and demonstrate the block? I would have to see either the block or the logs to know really what is going on, but it kind of sounds like this item should be blocked… although it should not be more than one block.00
- December 2, 2019 at 7:28 pm
Dan: Yeah, there might actually be a good use for SRP in VS…
Anyway, I am still looking for a good reason to implement SRP,
Of course, if M$ is moving away from SRP… Is there something we should know? Like perhaps it doesn’t work too good?
I think SRP would be great for ATM, POS and similar machines that are completely static, and I think it is great that there are several effective SRP solutions on the market. But after playing around with SRP for many hours to figure out how it all works, I have come to the conclusion that it is simply not going to work with the user-friendly computer lock we all know as VS ;). It is too bad because there might have been some pretty cool things we could have done with it… but even if there were, these are all things we can implement in the driver.
As far as directly monitoring dll’s, this is the actual warning when you attempt to apply SRP policies to directly monitor dll’s…
“Applying software restriction policies to libraries (dll’s) requires you to set rules for all the libraries used by a program in order to use the program.” Which is EXACTLY why dll monitoring is always disabled… well, that and there is a performance hit.
Either way, it is great that we all have a choice on what software best fits our needs. As I was saying, I actually use a similar product to VS on two of our static machines, simply because it fits the use case better. I could use VS and tweak it so that it never toggles to OFF, but this specific product works better for this specific use case, so that is what I use for these two static boxes ;).
So SRP certainly has its role, but please keep in mind, if your car was locked all of the time, you would not be able to drive it. And as hard as I tried, it just simply did not make sense for VS.10
Besides, Umbra recommends anti-exe for most people…
- December 2, 2019 at 7:46 pm
Oops, I guess he changed his mind…
Umbra, final warning, leave VS alone and focus on the products you promote.10
simmerskoolParticipantDan, glad you decided (for now) not to implement SRP in VS. If it adds nothing why add unnecessary code? I used AppGuard 4.nnn.something, and earlier versions too IIRC. I even used it with VS for awhile, but yes with the subscription I uninstalled it, I think I uninstalled it even before that as I minimalized and better coordinated layers of protection.
- December 2, 2019 at 10:16 pm
I like VS, I like WLC…
…and I rarely get VS popups, I must be doing something wrong (or right?)?20
Yeah, it is definitely best for VS to not implement SRP, especially when we can just do anything extra we want in the kernel mode driver.
- December 2, 2019 at 10:43 pm
The thing is, it was a very, very close call and I took a very serious look at it… I basically played around with SRP all weekend. I always wondered why the SRP products that I have used in the past did not offer the ability to allow / whitelist new items “on the fly”. I mean, you can install new software by disabling SRP, but when you do, it does not learn / whitelist the item, so if you want to whitelist something, you have to manually do so, and then log off and log back on the computer.
That was the real deal breaker as far as implementing SRP into VS goes. I mean, we would not be able to offer a user prompt with an Allow button. Well, we actually could have an allow button that would create the rule immediately to whitelist that item, but that rule would not take effect until the user logged off and logged back on the machine. Which obviously would never work for VS users.
Learn something new everyday ;).10
- You must be logged in to reply to this topic.