SSM: folders, scripts-to-memory payloads

Discussion in 'other software & services' started by act8192, Apr 17, 2014.

Thread Status:
Not open for further replies.
  1. act8192

    act8192 Registered Member

    Joined:
    Nov 9, 2006
    Posts:
    1,272
    1) I haven't found a way to permit/block any .exe from a specific folder which I could use in one instance. Is there a way? I thought I was able to do that in the free version, but can't recall.
    I'm currently running a small AV - avast free, which sometimes loads .exe files for doing engine updates, but the filenames are unpredictable :( :( If I have SSM in, what I call, blue mode, which is disconnected UI, those things are blocked. If I do watch and SSM is in normal mode, then I have a chance to permit.
    In a recent thread you (Noone_particular, who else?) mentioned that you can prevent execute anything from a email folder - how do you do the folder rule?

    2) Related to discussion about the xp doomsday movie, specifically post#20,
    https://www.wilderssecurity.com/threads/has-the-xp-avalanche-of-doom-struck-yet.362718/#post-2362532
    what in SSM, if anything, would prevent a script, from a hacked website, writing directly to memory and causing trouble? What process would be involved? Or something else?

    Edited: defined "you"
     
    Last edited: Apr 17, 2014
  2. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    Interesting idea. I didn't think of folder rules when I was trying to do that with AntiVir. You didn't mention if you're using SSM free or pro but the procedure is similar for both. On both, folder rules can be created from the main interface. On the free version, use the "application rules" tab. On the pro version, use the "rules" tab, then the "applications" tab below that. On the free version, right click on an empty location and select add rule for folder, then applications from the sub menu. Navigate to the folder you want to make rules for. The rule will be created after you select the folder and click OK. Then navigate to that rule, edit your preferences for it and apply. On the pro version, right click on the specific rule group that you want the folder rule to be in, select "edit rules" then "add rule for folder". Select the folder, then "OK", then edit the rule to suit your need. On the pro version, the folder rule will inherit the rules of the group unless you select otherwise. Once the folder rule is created, select it and check the options tab below the rules. It will display an option to include subfolders for that rule.

    If AVast always uses the same folder for it's update executables, it should work. If it creates randomly named for those updates, you'd have to make folder rules for the parent folder. That could be dangerous if the parent folder is the system "temp" folder. If that's the case, you might be able to restrict the parent permissions for the folder rule using the advanced properties menu for the rule. On the pro version, you could make a separate rule group for the temp folder or for the AVs updater. I don't know how much testing was done on its enforcement of folder rules. You could drop a few harmless utilities in the folders and use a few different parent processes to execute them to verify the enforcement works properly.
    If you're referring to javascript, that''s executed within the browser itself. SSM does not control the activities that take place within a given process. In this instance, it's abilities are limited to the controls that it enforces on the browser itself. If the javascript instructs the browser to launch or access something else, there SSM has some control, either through the parent-child settings or the options listed under special permissions. Some of the special permissions can also interfere with the browsers ability to function and interact with the rest of the system, especially the options on the "protection", "code/DLL injection", and "system control" tabs. If you're looking for control over what javascript can and can't do, NoScript or Proxomitron are better suited for the job.

    If you were referring to scripts such as those executed by the Windows Scripting Host (CSCRIPT.EXE or WSCRIPT.EXE), SSM does not directly restrict what a script can or can't do. When a script requires a separate handler to be run, such as the WSH executables, SSM can allow or block that handler from running and to a degree, restrict what that handler can do. If that handler is already running, SSM is limited in its ability to control it. An example would be the Windows installer, MSIEXEC.EXE. Once it's running, SSM can't control the install scripts it executes. It can only restrict the installers ability to call another process or another instance of itself.

    Regarding scripts, access to memory, and their ability to influence or interfere with other processes.
    SSM Pro can allow or block the access to physical memory for the application that is running a given script. This option is under special permissions>system control. This is an "all or nothing" option that can interfere with some applications ability to function. It does not control the amount of memory or the specific memory locations that process can interact with. The options under special permissions>code/DLL injection can restrict specific types of access to memory for that application. These options will also interfere with some applications. Unlike newer Windows versions, these options have to be enabled per application. They're not as extensive as those in the newer versions of Windows. They are a big improvement for XP which has very little protection for the memory.
     
  3. act8192

    act8192 Registered Member

    Joined:
    Nov 9, 2006
    Posts:
    1,272
    I forgot to tell: XP-Pro-SP3, SSM-2.4.0.622-beta - the one Vitaly mailed key for.
    Folders
    You gave me fabulous instructions. Yes, that's how it's done. I just couldn't remember to reconstruct. THANK YOU very much.
    Test: I made a directory with harmless utilities, put it in Normal group, inherit all settings, plus set explorer as parent, all works fine.
    Avast: For Avast\...\setup directory into which they load the funnynamed.exe, it's all ready to go for the next engine update. I used a specific parent, that emergency update executable.
    Can't put any .exe files to test in that folder while Avast's self protection is on, but the test folder worked, this should as well.

    Memory question - I have to absorb the details what you wrote. I'll be back.
     
  4. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    So the names of the executables are random, but they're always in "Avast\...\setup" directory? If that's the case, a folder rule should work well. It may be possible to make another folder rule for the one that Avast is actually installed in, then use the parent-child options so that only Avast can execute the contents of the setup folder.That would prevent anything else from dropping an executable there and running it.

    Besides being accessible from the context menu, you probably noticed that the special permissions are also displayed below the ruleset. For several of the special permissions I mentioned earlier, you can see the specific APIs that SSM hooks when you hover the mouse over the specific option. Example, under the Code/DLL injection for the "Allow remote data modification" option, SSM intercepts any usage by that executable of the WriteProcessMemory and the ProtectVirtualMemory APIs. That prevents that executable from affecting other processes via those APIs. Under "Protection", the "protect from remote data modification" option, if you hover over that option, you'll see the same APIs. This options blocks the use of those specific APIs to that executable. Think of it in terms of separate inbound and outbound control over specific APIs for individual executables.

    Have you run Root Kit Unhooker since installing SSM? If you run it and have it generate a full report, it will give you a list of everything that SSM hooks. It's quite a list.
     
  5. act8192

    act8192 Registered Member

    Joined:
    Nov 9, 2006
    Posts:
    1,272
    Yes. And always run by AvastEmUpdate.exe.
    I almost understand but maybe not. Different .exe trigger different things. There's a bunch of them.
    Best I can do is watch SSM alerts and make rules exactly based on the very path and only the displayed parent that SSM shows. So probably if I or Avast or SSM allowed some scumware to turn off their self defence, I still might react to an unwanted .exe. I hope.
    I run SSM on and off for weeks, then stop when I get scared I'll set something wrong and have to reimage, which never failed but always scares me.
    Most of the time, other than careful parent-child settings, I use defaults. Exceptions are don't allow to kill my firewall, and some non-logging of some snagit activity.
    Yes I can see the hooks while mousing. I leave'm all as defaults. I think if something suddenly wanted to do some code injection and I haven't installed anything new, I won't allow it. It's a gamble for me.
    Nope. But I will. That might also show me what hooks are common to avast and SSM, because that part worries me a bit. I know what drivers they load and when, but the hooks display might be interesting. Thanks for the idea.
     
  6. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    If the folder name doesn't change and AvastEmUpdate.exe is always the parent process for the executables dropped in that folder, making a folder rule would be fairly simple. Disallow everything but that executable as the parent process for that folder. You could also set everything else to "ask" to test the rule. One problem you might run into is updates to AvastEmUpdate.exe itself. When I was testing AntiVir with SSM, the hash for Update.exe changed almost as much as the detection files. To make the autoupdate work, I had to set SSM to not check the hash for update.exe. Disabling the hash check for an executable makes it possible to run anything with that name that's dropped into that folder. That's very unlikely unless you're targeted by an attacker who knows that you're running Avast. I'm not familiar with the specifics regarding Avast. Is AvastEmUpdate.exe launched by the system scheduler?
    If you can boot to safe mode, you can undo major configuration mistakes from there. SSM allows you to export and import rulesets. You can either do that or you can delete its configuration file from safe mode. You might have noticed that 3 or 4 of the system rules for core executables are hard coded. On some of the earlier beta versions, they were editable. Those rules were hard coded to prevent people from locking up their systems when they tried to tighten those rules. It's still possible to lock up a system with bad rules but it's a lot less likely.

    Curious, under the main options>applications, are you blocking process creation or using the block everything mode? I'm pretty sure that when in "block process creation" mode, the activities under special permissions are all allowed unless you specify otherwise.
     
  7. act8192

    act8192 Registered Member

    Joined:
    Nov 9, 2006
    Posts:
    1,272
    I did exactly that. Definition updaters run from that folder but they have their own rules. So it should work, and I'll see it in the log if doesn't. Hmmm, is there a concept of rules sequence in SSM?
    That emergency .exe only gets new checksum when they run a major or minor update, not the little random emergency engine fixes. I update Avast when I feel like it, not automatic.
    When I don't use SSM, and enable my firewall's behavior checks, they alert about modified emergency checksum, and here too, the only time it happens is a real, not patches, update.
    Yes it is. It's not displayed under Scheduled tasks, is hidden. But it's visible in CCleaner and Autoruns. Svchost runs it from schedule. Avast service is a second parent for the rest of its activities.
    Oh, thanks. Didn't know that. And yes, I do preserve configurations that I may want to put back if I don't kill Windows first.
    Yup. csrss, lsass, smss. Good to know there's some protection from dummies.
    Yes, I block process creation. Don't know what to think here. Most special permissions currently have "?", very few overridden. So what's now Ask or a grey circle with a line in it will be allowed? Really? Maybe I have to log more stuff to see it?

    I think I'm OK with Avast now. But if you think not and need screenshots, let me know.
     
  8. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    No. The parent-child permissions for each also contains their relationship to other processes. If you have both a folder rule and an application rule for a specific executable in that folder, the application rule will apply. That was one of the biggest improvements with the 2.0X versions. On earlier versions, you had to manually edit rules for both the parent and child processes. Now when you specify an allowed child process for an executable, the change is also applied to the child processes rule.
    OK. When I last used Antivir, it had its own scheduler. If I recall, there's an option that makes all hidden tasks visible as long as you're logged in as administrator. I forgot that it was possible to hide scheduled tasks. I haven't used the Windows scheduler in ages. It's one of the first services that I disable. The entire concept of hiding schedules tasks is unacceptable to me. I'm not surprised at this from Windows but I have to wonder why an AV feels the need to hide the updater scheduler.

    In "block process creation" mode, the items listed in special permissions are allowed unless specifically blocked for that process. On the pro version of SSM, there's 3 layers of options. The first is the global option.
    1, allow everything
    2, block process creation
    3, block everything

    The first option is default-permit. Anything not specifically blocked is allowed. IMO, this setting is almost useless.
    The 2nd option only controls what can and can't run. It''s default-deny for the processes themselves but is default-permit in regards to allowed processes activities.
    The 3rd option blocks everything not specifically allowed in the rules. Default-deny for everything.

    After the global options, the settings for each rule group are applied. Individual rules in each group default to the group settings. For rule groups, the special permissions options show as red, blue or green, aka block, ask, allow respectively. Those settings are enforced for all rules in that group unless specified otherwise for an individual rule. This applies to both special permissions and parent-child settings.

    After the rule group options, the settings for individual rules are applied. The same color code applies with one addition. When the specific option for a rule is displayed grey, that rule is using the group setting (inherited permission).

    If you enable "block everything" you will see quite a few more prompts, especially for system components and probably AV components. How many more will depend on your group settings, what types of groups you defined, and what rules are in them. It may be more prompts than you're willing to deal with so save your old ruleset first.

    IMO, they made this more complicated than it needed to be. I don't care for the groups. It simplifies some of the organizing of rules but made it more complex and confusing by adding another layer of settings. The registry rules are especially bad, too many interfaces, too easy to make mistakes. The free version of SSM was much easier. The interface was more intuitive and the settings were more straight forward. Unfortunately it doesn't run on SP3. XP-SP2 and older.
     
  9. act8192

    act8192 Registered Member

    Joined:
    Nov 9, 2006
    Posts:
    1,272
    Thanks again. Neat explanations do help me. Still fuzzy on what you say about the 2 layers of option 2, but I'll think about it.
    Never heard of it. I gather there's version 3.8, but all googled links I tried are dead.
    Softpedia has version 3.7, zip, so I tried it. I made an image so can back out of this adventure.
    It's a installer and to run it, it wants to load a driver, start service and close csrss.exe handle (interprocess activity).
    csrss thing scared me so I didn't allow. It ran regardless, but is that ok? results valid?
     
    Last edited: Apr 23, 2014
  10. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    The version number of RKU isn't that critical for this purpose. They'll report the same hooked APIs. Those prompts are normal with RKU and other anti-rootkit tools. Never tried denying the prompts for csrss.exe. No idea how that affects the results. With block everything enabled, you'll see quite a few new prompts, including one process modifying the memory of another or taking control of another. Installers and utilities that modify your system trigger a lot of these.
     
  11. ichito

    ichito Registered Member

    Joined:
    Jan 14, 2011
    Posts:
    1,485
    Location:
    Poland - Cracow
  12. act8192

    act8192 Registered Member

    Joined:
    Nov 9, 2006
    Posts:
    1,272
    Interesting information.RKU reports mere 215 SSM hooks, 60 Avast hooks and few firewall hooks to all these NTxxxx functions. Also 666 shadow SSDT hooks - what;s that?

    RootkitHookAnalyzer - it didn't go too well because SSM got in the way :)
    and
    Actually they did ask to change booting stuff and reboot - that likely would have stopped SSM from booting. I didn't feel like doing all that. But I suppose that if I did, a report would have been made.
    Thanks ichito, from beautiful Krakow, anyway. It was interesting too see.
     
  13. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    Several pre-Vista Classic HIPS, including SSM used the same methods used by rootkits, including SSDT and shadow SSDT hooks. In the report you posted it said:
    "Note that these SSDT hooks are very notorious because they rely on undocumented techniques and are incredibly difficult to implement right for a programmer."
    IMO, since SSM uses a few hundred of these and stays reliable and stable, the programmer got it right. I don't know if an anti-rootkit tool could disable SSM or prevent it from loading if you allowed its activities. SSM does have built in self defense measures.

    Regarding the shadow SSDT, it's similar to the SSDT but the functions are more related to graphics, GUI, user inputs, etc. The RKU report itemizes both the SSDT and shadow SSDT hooks. Many of the hooks names will give you a better idea.

    There's definitely an interaction on yours between SSM and Avast. The RKU report for mine shows about the same number of hooks for SSM that yours has for SSM and Avast combined. I assume that Avast was installed first and was either running when SSM was installed or its driver was loaded. There could be some APIs that SSM couldn't hook because Avast already had. When more than one program wants to hook the same APIs, that's where instability problems start.
     
  14. act8192

    act8192 Registered Member

    Joined:
    Nov 9, 2006
    Posts:
    1,272
    Yes, Avast was first, and firewall before that. I'll follow up as this is interesting.
     
  15. act8192

    act8192 Registered Member

    Joined:
    Nov 9, 2006
    Posts:
    1,272
    Avast: good news - folder rule worked like a charm when emergency update named strangely came in. The end.

    Finally, back to Memory section from posts 1 and 2 (I wish I made a separete thread for this):
    OK. But, as you say
    I use NoScript and limit which precise address can permit js. Avast's WebShield also examines javascripts and denies if they smell a rat. I guess if it wanted to install some.exe SSM would alert, right?
    Special permissions for the browser or what browser invoked? Can you give me an example?
    Also Windows sets DEP on browsers when I start it, is that similar to not allowing code injection? And I drop rights for browsers in SRP section of gpedit. Is that related?
    Actually I wasn't. Just the web stuff.
    Yes I do use WSH, infrequently, mostly for get something out rather then execute (just output to some text file). I have a batch file which uses cscript which then calls a vbs which gets executed by wscript. SSM alerts to the initial cmd wants to run cscript, but not the harmless remaining wscript activity in the second file. No problem, I get it.
    OK. So if browser (Opera, SeaMonkey) plans to run a script but physical memory is blocked, the browser itself might not work? I guess I won't change any defaults here.
     
  16. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    Sorry about the delay.
    Basically true. SSM wouldn't alert to the executable being added to the file system. It would intercept attempts to run it.
    I don't have a browser specific example. An example that I do have regards kerio firewall, specifically its tray icon. With the protect from inter-process messaging option enabled, its tray menu doesn't function. Another somewhat confusing example that I haven't looked into is K-Meleon 1.7.0.a2. On my 98 unit running SSM free, I have to allow injection to\kplugins\rebarmenu.dll in order for its file menu to work. On the virtual XP unit, I saw no such prompt. I don't know if this is due to differences between the free and pro versions of SSM, differences in the way 98 and XP work, or if K-meleon works differently on XP. It might even be the older version of VPC that I'm using, which simulates older hardware. I haven't looked into it.
    Regarding DEP, this is separate from SSM memory protections. DEP prevents code from running in protected or non-executable memory. Code injection refers to one process injecting code into another running process. There is some overlap between these, but for the most part they complement each other. There's a lot more overlap between SSM options and some aspects of SRP. As before, each has abilities that the other doesn't. Both use different methods to achieve enforcement. For the most part, they complement each other. I haven't looked into software restriction policies on XP. On 98, group policy enforcement was pathetic to the point of being nearly useless. Hopefully they've closed some of the gaping holes in its enforcement.
    Regarding the special permission settings, as long as you're running with the SSM UI connected, you can set the permissions to "ask". If an app needs one of those functions, it'll prompt you. Most user apps will never need these permissions. The protection tab doesn't have the "ask" option available. If you use those, make sure that the app still functions and that you still have the access to it that you require. These options are best suited for protecting other security components like the firewall or filtering proxy.
     
  17. act8192

    act8192 Registered Member

    Joined:
    Nov 9, 2006
    Posts:
    1,272
    Injections, Special permissions subject
    Great. Thanks for explaining.
    I don't know much about SRP. But when I dropped rights to a folder or two and tried running something simple like TCPview from there it was doomed. But when something unwanted went to Program Files or system32, well, that would be allowed by SRP. So I guess it works.
    Got it. Explains why alerts for special permissions are nearly nonexistent. Thanks.

    RKU subject - Perhaps you can throw few thoughts to me. RKU is an eye opener.
    From your post#13
    Of the 280 items, Kerio hooks 5, Sunbelt (v4.7.4) hooks 15-17. Both were installed before SSM. No issues on either XP computer.
    Now, when Avast is installed first, you say then SSM can't hook. So all that makes me think:
    Does that suggest SSM ends up incomplete?
    Does that suggest an insecure conflict enough to warrant not using AV?
    Don't those routines pass control from one hooked to the next?

    - I think I read someplace here, long ago, that Windows can only tolerate so many hooks to a function. Exceed that and it's trouble.
    - Long ago, when in the Sunbelt firewall I had behavior on (just like parent-child in SSM), SSM alerted first, then the firewall alerted. That made me think they chained. Also, using just NTcreateProcess as an example, it looks chained to me, because firewalls and SSM and Avast see it and don't crash.
    - On the other hand: Sunbelt also has HIPS (sbhips.sys). Is ok to use with SSM, though I don't anymore. But first reboot of installation of Avast will BSOD and blame the Sunbelt sbhips driver which hooks NTLoadDriver and NTMapViewOfSection. So here we do have an example of a fatal conflict. So why here and not there?

    I hope you don't mind this flood of questions :)
     
  18. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    I should have been clearer. I doubt that Avast can prevent SSM's driver from setting its hooks. For all practical purposes, the hooks are chained. Think of each hook as a detour. The order of the hooks is a big variable here, especially if both want to be first. Example. If the first hook encountered is SSM, it diverts the instruction annd checks it against its rules. If the rules allow it, the instruction continues down the path to the next apps hook where it makes a similar decision based on its settings. There's 2 ways that this can cause problems.
    1, If SSM or one of the other apps determines that this instruction isn't allowed, the instruction stops there. The AV may respond differently. If an instruction is detected that it considers malicious, it can respond in other ways, like killing the process, severing threads, etc. If SSM isn't configured to allow the AV to perform functions that it hasn't seen it do before, it can start interfering with the AVs ability to kill or quarantine the file. The results can get unpredictable.
    2, The detours created by individual hooks introduces a small time delay. If that API is hooked several times, the time delay gets larger. This can result in all kinds of timing issues. Instructions can arrive late (or not at all). It's even possible for the delay to change the order that the commands are received. Delays that affect the loading of another driver or its functions can cause the app to crash. Why a HIPS will get along with the hooks or drivers of one AV but not another is impossible to say without knowing exactly what both are doing. I ran into this problem with SSM and Antivir when AntiVir introduced their anti-rootkit module. The first version got along fine with SSM. When they updated the module, every PC that I'd installed both on blue screened on reboot. Nothing I tried helped except for removing the anti-rootkit module, which proved to be quite a pain in itself.

    Regarding whether it's OK to run both a classic HIPS and an AV that hooks the same APIs, that doesn't have a simple answer. They may get along fine. They might conflict after an update, especially program updates. As long as you're aware of the possibility and have a system backup available, it's up to you. Myself, I have very little faith in AVs, and a growing distrust of them.

    I'm curious. Did your RKU report show hooks to NTCreateProcess for all 3 apps? On my virtual XP, the RKU report shows this API hooked by the firewall driver only. This might be an issue with the version of RKU that I used. It's possible that when it detects a hook on an API, it doesn't check if there's more.
     
  19. act8192

    act8192 Registered Member

    Joined:
    Nov 9, 2006
    Posts:
    1,272
    Wonderful, thank you for elaborating.
    For myself I had Excel compile a composite table, but just from the point of view of Sunbelt firewall drivers (with behavior on). It's more than you asked, but I think answers your query - see attached. FwDrivers.jpg

    That's my concern. Is OK so far, but any update might interfere. And would I know about it. Yikes.
     
    Last edited: Apr 30, 2014
  20. act8192

    act8192 Registered Member

    Joined:
    Nov 9, 2006
    Posts:
    1,272
    I just realized I didn't answer exactly what you asked. RKU reports only ONE hook, presumably the last set.
    I expected to see multiple drivers on a line on some of those functions.
     
  21. blacknight

    blacknight Registered Member

    Joined:
    Sep 25, 2007
    Posts:
    2,433
    Location:
    Europe
    For noone_particular:

    1 which is the last Windows version working with SSM ? ( Vista, I believe ).
    2 did you test SSM with recent tests or malware to verifiy it ?
     
  22. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    @blacknight
    SSM pro worked on Vista until service pack 1 broke it. Development ceased at that time. I doubt that many run Vista without service pack 1 so XP-SP3 should be considered the last compatible OS. On Vista, SSM pro was considered beta and had bugs on this OS. SSM free works on 98FE through XP-SP2. On SP3, the driver won't load.

    Regarding testing SSM, most of my testing was done during its development. I've done very little in the last few years as I've lost interest in capturing and using live malware. Occasionally I will open a document or POC that uses a newly discovered exploit if it's in a format that I use. This is primarily to test my own defenses as a whole, not just SSM. Currently, the only time I use SSM pro is on virtual XP and 2K systems. It doesn't run on my primary/host system.
     
  23. blacknight

    blacknight Registered Member

    Joined:
    Sep 25, 2007
    Posts:
    2,433
    Location:
    Europe
    Thank you ! I used SSM Pro on XP SP 3, and I stopped to use it six months after it was discontinued. Now I'm using Seven, so anyway I can't use it. Shame for the death of so a great program.:(
     
  24. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    The sad part is that it died for financial reasons, not technical reasons. I was hoping that he'd open source it instead of just letting it die. Then again, finding a developer/maintainer with the necessary expertise and willingness would be difficult as well.

    That's the biggest problem with products like SSM. They don't need constant updating which makes them a one-time sale. That combined with its targeting a very small user group, it's just not financially viable. The big names in PC security won't release such a product for the same reasons. In a capitalism controlled world, capability and performance take a back seat to profits.
     
  25. blacknight

    blacknight Registered Member

    Joined:
    Sep 25, 2007
    Posts:
    2,433
    Location:
    Europe
    I know that the main developer tried to sell the code, but I don't believe that he found a buyer. For the HIPS is an old, great problem that we talked about many times here in the Forum. HIPS and similar softwares have not a real business. For SSM and his develop, if it had continued, I would be happy to pay.
     
Loading...
Thread Status:
Not open for further replies.