latest DeepGuard Update "kills" 16Bit Apps

sw2090

Hi there,

 

we encountered the following problem:

 

since that latest DeepGuard Update (in which the Scan Algorithm were optimized as stated by the support hotline) we cannot start any 16Bit App as long as Deepguard is  active!

Even defining an Exclusion from realtime Protection for the Binary and distributing it via the Policy Manager does not change this behavior nor does defining an Exclusion for Deepguard via sha1 hash.

The App will only start when DeepGuard is deactivated.

As far as out tests led this affects all 16Bit Apps we still have.

 

cheers

Sebastian

 

etomcat

Hello,

 

I don't think I understand the situation? As far as I know, Windows XP was the last Microsoft OS that could run 16-bit code (i.e. MS-DOS 6.22 programs). If you still need them in Win7 and up, there is a need to run a virtualized WinXP instance for that particular purpose, which is available in the Business/Enterprise/Ultimate editions.

 

On the other hand, F-Secure Client Security is no longer available for Windows XP since major version 12, so I can't see the two topics intermesh at all?

 

Best Regards: Tamas Feher, Hungary.

sw2090

That's not correct. You can still execute 16Bit Apps in Win7 32bit or even Win2008 Server 32bit.

Just the 64bit ones do not support that anymore.

And FSCS 11.61 is still available and runs on XP as it does on Win7 

sw2090

As I found out now the problem is that DeepGuard manipulates the Process by injecting some dll now. 

This is called "extended process monitoring". Once DeepGuard is active but extended process monitoring is deactivated all works fine.

So I gues either this manipulation oder the injected dll is not 16bit compatible anymore or those Apps don't like that at all.

etomcat

Hello,

 

> Once DeepGuard is active but extended process monitoring is deactivated all works fine.

 

Once the "advanced mode" of DeepGuard is turned off, the mini-DLL injection based surveillance becomes unavailable This means you lose all protection against newly emerging strains of ransomware (cryptor) infections! Since 95% of ransomware attacks happen with newly constructed minor versions of ransomware families, this is a huge security risk!

 

(We have seen ransomware epidemic happen in a factory just because they were running Deepguard in baseline mode, due to perceived performance excuses. It took them a weekend to restore from backups and data parts recovered by "deep undelete" software.)

 

Instead of taking such risk, I would recommend installing a dedicated virtual machine in the physical computer and run 16-bit programs there, so Deepgard Advanced Mode can remain active in the system.

 

Best Regards: Tamas Feher, Hungary.

sw2090

As far as this is concerned I agree with you. That is why I did that just on one host for testing and not in the whole Domain.

However running those app in a vm is not really an alternative. The most important App will be replaced by a newer one soon anyhow whti windows 10 coming up here (hence Win 10 does indeed not support 16bit anymore) but due to its complexity this is nothing that can be done from one day to annother. Plus we do not have the resources for running an extra vm for this everywhere. We'd need a vm for every one that uses the app then. The App is not installed on the client anyhow but started from a network share that is on a vm.

 

The Ability to define an exception vor the advanced monitoring in deepguard would be much more helpful. Marking the App as excption for DeepGuard itself via sha1 hash does not affect the extended monitoring obviously.

 

Jachym1

hi,

have you tried to exclude the affected application from REAL time scanning? If not try to add this application using FULL path name: "C:\Program Files\Affected_App_folder\Affected_App.exe". Do not use any wildcard. Do not use application name only "*\\Program Files\\Affected_App_folder\\Affected_App.exe" neither "Affected_App.exe".

 

etomcat

Hello,

 

> have you tried to exclude the affected application from REAL time scanning

 

To me, it seems a bit excessive to run a 16-bit app without any protection whatsoever. A Deepguard compatibility issue should not mean removing Aquarius, Hydra and Gemini protections from the problematic file. I think F-Secure virus lab should sort out and fix this case.

 

BR, Tamas Feher, Hungary.

sw2090

Accoarding to f-secure support it  is not possible to exclude a file from DeepGuard Advanced Process Monitoring.  So the only way would be to run the 16 Bit App in some emulator or vm (or deactivate advanced process monitoring in DeepGuard - which is not really an option).

F-Secure Lab is not going to analyze this further atm.

 

Just to clear this out: it's not f-secure/DeepGuard blocking 16Bit Apps, its compatibility issues with the advanced process monitoring which keep the app from functioning.

 

BTW: accoarding to f-secure support this didn't only affect us but also various other customers. So they know it but say it is too extensive modification on fscs to sort that out, so they will not do that.

 

Greets

Sebastian

MarekS

Solution:

 

While we are working to release a version of Deep guard that will resolve this issue, what you can do in the mean time is to exclude (C:\Windows\System32\ntvdm.exe ) from real-time scanning. The exclusion will apply to all 16-bit apps, and this is the only generic tip I can give at this point as we are still working towards a permanent fix that will be released with the next Deep guard update.

 

Have nice day