Ver. 10 - Driver Hash Error

[itman 1,659]

I just found what I believe is another issue in this area.

Per the Microsoft article link I posted previously:

 

Launching a child process as protected

 

The new security model also allows the anti-malware protected services to launch child processes as protected. These child processes will run at the same protection level as the parent service and their binaries must be signed with the same certificate that has been registered via ELAM resource section.

 

As shown in the below screen shots, neither of ekrn.exe's spawned child processes, Eset GUI or Online Payment and Protection, are running in protected mode. Ekrn.exe is running in protected mode:

 

 

 

 

 

 

 

 

Edited November 4, 2016 by itman

[Marcos 5,074]

I don't think this is an issue. Ekrn.exe is the only ESET's service and the most crucial component which subsequently runs other processes.

[itman 1,659]

I don't think this is an issue. Ekrn.exe is the only ESET's service and the most crucial component which subsequently runs other processes.

I partially agree; equi.exe not that critical. However, malware can disable Eset's self-defense through it. This could be done silently and upon next reboot, Eset is vulnerable. Note that self-defense setting is not CAPTCHA protected.

 

However, I believe OPP should be running in protected mode.

[mandiato 19]

I only want to confirm that this "bug" still exists in ESS...

Baza sygnatur wirusów: 14666 (20161226)
Moduł szybkiego reagowania: 9238 (20161225)
Aktualizacja: 1009 (20161205)
Skaner antywirusowy i antyspyware: 1507 (20161209)
Zaawansowana heurystyka: 1175 (20161110)
Obsługa archiwów: 1258 (20161117)
Leczenie: 1128 (20161025)
Technologia Anti-Stealth: 1106 (20161017)
Zapora osobista: 1328.1 (20161206)
Moduł programu ESET SysInspector: 1264 (20161108)
Moduł obsługi tłumaczeń: 1565 (20161219)
Moduł obsługi systemu HIPS: 1259 (20161213)
Moduł ochrony internetowej: 1289 (20161202)
Moduł filtrowania zawartości WWW: 1052 (20160620)
Zaawansowany moduł ochrony przed spamem: 4832 (20161226)
Moduł bazy danych: 1087 (20161107)
Moduł konfiguracji (33): 1368.7 (20161214)
Moduł komunikacji LiveGrid: 1022 (20160401)
Specjalistyczny moduł czyszczący: 1012 (20160405)
Moduł ochrony operacji bankowych i płatności: 1092 (20161130)
Moduł wykrywania programów typu rootkit oraz leczenia: 1006 (20160715)
Moduł ochrony sieci: 1335 (20161223)
Moduł skanera luk w zabezpieczeniach routera: 1024 (20161201)
Moduł skanera skryptów: 1010 (20161205)

[Samoréen 8]

On 04/11/2016 at 6:38 PM, Marcos said:

 

It is. As I wrote, we have figured out what is causing the issue and will prepare a workaround for this.

Currently, with version .386, the problem is still there, I'm afraid.

[Marcos 5,074]

2 hours ago, Samoréen said:

Currently, with version .386, the problem is still there, I'm afraid.

I don't understand. It's not an issue those records in the log as it seems to be how ELAM works according to our investigation. Don't see problems where there aren't any What I wrote is that we would look into it deeper and try to find a way how to minimize the number of records that are logged. Since this is not any real issue and the feature correctly works as it's supposed to, the task isn't treated with priority and we continue working on high priority tasks.

[itman 1,659]

Yes, the issue still persists in ver.386:

Keywords:      Audit Failure
User:          N/A
Computer:      Don-PC
Description:
Code integrity determined that the image hash of a file is not valid.  The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error.

File Name: \Device\HarddiskVolume3\Program Files\ESET\ESET Smart Security\Drivers\eelam\eelam.sys 

Also, I don't agree throwing a driver hash error is known and accepted behavior. If it is for the Eset/Microsoft ELAM driver, please post Microsoft's confirmation. Then instruct Microsoft to fix the OS to ignore a hash validation for this driver.
 

 

Edited January 16, 2017 by itman

[Samoréen 8]

5 hours ago, Marcos said:

I don't understand. It's not an issue those records in the log as it seems to be how ELAM works according to our investigation. Don't see problems where there aren't any

Marcos,

You should understand this : I'm facing a problem that shows up with every release since 9.0.402 and that forces me to manually install some ESET drivers in safe mode in order to get the product working normally (see other thread about that). I'm slowly getting tired of this. I never got any explanation about this issue and no indication about what I should check in my system (beside your suggestion about WMI). I didn't write the installation program and I'm looking for a possible cause of the installation failure for these drivers. Now I discover this strange behavior of the eelam driver. I'm trying to understand what's going on and I'm wondering whether this could be related to the installation problem.

[cyberhash 188]

On 16/01/2017 at 5:01 PM, itman said:

Yes, the issue still persists in ver.386:

Keywords:      Audit Failure
User:          N/A
Computer:      Don-PC
Description:
Code integrity determined that the image hash of a file is not valid.  The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error.

File Name: \Device\HarddiskVolume3\Program Files\ESET\ESET Smart Security\Drivers\eelam\eelam.sys 

Also, I don't agree throwing a driver hash error is known and accepted behavior. If it is for the Eset/Microsoft ELAM driver, please post Microsoft's confirmation. Then instruct Microsoft to fix the OS to ignore a hash validation for this driver.
 

 

This was also an issue for me up until i upgraded to 386 and now the error has gone. Strange if you are still getting it.

[itman 1,659]

13 hours ago, cyberhash said:

This was also an issue for me up until i upgraded to 386 and now the error has gone. Strange if you are still getting it.

Check and see if the eelam.sys driver was updated on your PC. It was not updated on mine for the .386 upgrade. Whether that driver should have been updated is presently a point of contention.

[cyberhash 188]

6 minutes ago, itman said:

Check and see if the eelam.sys driver was updated on your PC. It was not updated on mine for the .386 upgrade. Whether that driver should have been updated is presently a point of contention.

I'm the same as yourself, the eelam.sys driver was NOT updated along with the 386 upgrade, but all the other sys files were. File version just shows 10.0.0.0

[itman 1,659]

14 minutes ago, cyberhash said:

I'm the same as yourself, the eelam.sys driver was NOT updated along with the 386 upgrade, but all the other sys files were. File version just shows 10.0.0.0

Are you using Win 10? My OS is Win 10 Home x64 ver. 1607.

[cyberhash 188]

3 minutes ago, itman said:

Are you using Win 10? My OS is Win 10 Home x64 ver. 1607.

Exactly the same, win 10 home x64 1607. As you can see from this screenshot, it was a persistent issue until i upgraded to 386 on the 14th Jan.

[Samoréen 8]

55 minutes ago, cyberhash said:

I'm the same as yourself, the eelam.sys driver was NOT updated along with the 386 upgrade, but all the other sys files were. File version just shows 10.0.0.0

Same here with Windows 10 Ultimate x64 1511.

[itman 1,659]

1 hour ago, cyberhash said:

Exactly the same, win 10 home x64 1607. As you can see from this screenshot, it was a persistent issue until i upgraded to 386 on the 14th Jan.

I am starting to believe this also could be HDD device related? It very well could be that the Eset ver. of the Win 10 ELAM driver just doesn't "play" well with older HDD hardware. My HDD where Win 10 is installed is a SATA II over 5 years old.

The question now is if the driver is actually loading properly. That is if the driver is functioning as intended. It appears that it is based on prior postings since the Eset kernel is running as a Level 0 process.

[cyberhash 188]

1 hour ago, itman said:

I am starting to believe this also could be HDD device related? It very well could be that the Eset ver. of the Win 10 ELAM driver just doesn't "play" well with older HDD hardware. My HDD where Win 10 is installed is a SATA II over 5 years old.

The question now is if the driver is actually loading properly. That is if the driver is functioning as intended. It appears that it is based on prior postings since the Eset kernel is running as a Level 0 process.

Nah i don't think its anything hardware related, as i'm running a SSD that's only a few months old. Driverview does not show that this driver is loaded on my system, but i am unsure if this driver is only used when needed(on demand) or if it should be a permanently running driver. Something that ESET themselves would need to elaborate on.

[itman 1,659]

Eset's ELAM driver is loading early as it should as shown by the below ntbtlog extract. So hash error is not affecting it, I believe. Note that this driver is used to verify other subsequent drivers as they load.

Maybe I will try Process Monitor to see if it has any details if there are issues with Eset's ELAM driver.

After all drivers load at boot time, the ELAM driver uninstalls itself.

Microsoft (R) Windows (R) Version 10.0 (Build 14393)
 1 18 2017 16:05:39.494
BOOTLOG_LOADED \SystemRoot\system32\ntoskrnl.exe
BOOTLOG_LOADED \SystemRoot\system32\hal.dll
BOOTLOG_LOADED \SystemRoot\system32\kd.dll
BOOTLOG_LOADED \SystemRoot\system32\mcupdate_AuthenticAMD.dll
BOOTLOG_LOADED \SystemRoot\System32\drivers\werkernel.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\CLFS.SYS
BOOTLOG_LOADED \SystemRoot\System32\drivers\tm.sys
BOOTLOG_LOADED \SystemRoot\system32\PSHED.dll
BOOTLOG_LOADED \SystemRoot\system32\BOOTVID.dll
BOOTLOG_LOADED \SystemRoot\System32\drivers\FLTMGR.SYS
BOOTLOG_LOADED \SystemRoot\System32\drivers\msrpc.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\ksecdd.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\clipsp.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\cmimcext.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\ntosext.sys
BOOTLOG_LOADED \SystemRoot\system32\CI.dll
BOOTLOG_LOADED \SystemRoot\System32\drivers\cng.sys
BOOTLOG_LOADED \SystemRoot\system32\drivers\Wdf01000.sys
BOOTLOG_LOADED \SystemRoot\system32\drivers\WDFLDR.SYS
BOOTLOG_LOADED \SystemRoot\System32\Drivers\acpiex.sys
BOOTLOG_LOADED \SystemRoot\System32\Drivers\WppRecorder.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\ACPI.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\WMILIB.SYS
BOOTLOG_LOADED \SystemRoot\system32\DRIVERS\eelam.sys

[itman 1,659]

I am also questioning is Eset's ELAM driver is working properly. For reference: https://msdn.microsoft.com/en-us/windows/hardware/drivers/install/elam-driver-requirements . Of particular note is the following section:

Malware Signatures

The malware signature data is determined by the AM ISV, but should include, at a minimum, an approved list of driver hashes. The signature data is stored in the registry in a new “Early Launch Drivers” hive under HKLM that is loaded by Winload. Each AM driver has a unique key in which to store their signature binary large object (BLOB). The registry path and key has the format:
HKLM\ELAM\\<VendorName>\

Within the key, the vendor is free to define and use any of the values. There are three defined binary blob values that are measured by Measured Boot, and the vendor may use each:

•Measured
•Policy
•Config

The ELAM hive is unloaded after its use by Early Launch Antimalware for performance. If a user mode service wants to update the signature data, it should mount the hive file from the file location \Windows\System32\config\ELAM. The storage and retrieval format of these data BLOBs is left up to the ISV, but the signature data must be signed so that the AM driver can verify the integrity of the data.

This file, \Windows\System32\config\ELAM, has not been updated on my Win 10 home x64 system since I upgraded to ver. 1607 in early Oct., 2016. This indicates to me that Eset has not updated it with driver hashes to verify against?

-EDIT-

Also worth noting is:

Defined Policy

When the status of the drivers is returned (good, bad, unknown), system will decide whether load particular driver or not, based on the policy stored in:

HKLM\SYSTEM\CurrentControlSet\Policies\EarlyLaunch\DriverLoadPolicy

If the policy is not configured or disabled the boot drivers determined to be Good, Unknown, or Bad but Critical are initialized and the drivers determined to be Bad are skipped.

I checked that registry key and Eset has established no load policy. This means that all drivers except bad are being allowed to load. I realize that the HIPS also monitors driver loading but based on my observations, it allows all drivers to load.

Edited January 19, 2017 by itman

[itman 1,659]

Problem resolved ........ at least in regards to the Eset ELAM driver hash errors!!!

After posting the previous reply, it caused me enough concern to get motivated. I uninstalled the previous .386 ver. that I had recently updated by means noted in this reply:  https://forum.eset.com/topic/10722-ver-10-upgrade/#comment-54652 . I then downloaded and installed the full off-line installer ver. 386. Subsequent boots no longer show eelam.sys hash errors in the event log.

All drivers in the off-line installer ver. showed update dates of 12/9/2016. However, file details of the eelam.sys driver still showed ver. 10.0.0.0, the same as what was previously installed, which is indeed a bit puzzling.  Perhaps Eset forgot to update the revision number? I will check out the other concerns I posted in my previous reply when I get a chance.

[cyberhash 188]

16 hours ago, itman said:

Problem resolved ........ at least in regards to the Eset ELAM driver hash errors!!!

After posting the previous reply, it caused me enough concern to get motivated. I uninstalled the previous .386 ver. that I had recently updated by means noted in this reply:  https://forum.eset.com/topic/10722-ver-10-upgrade/#comment-54652 . I then downloaded and installed the full off-line installer ver. 386. Subsequent boots no longer show eelam.sys hash errors in the event log.

All drivers in the off-line installer ver. showed update dates of 12/9/2016. However, file details of the eelam.sys driver still showed ver. 10.0.0.0, the same as what was previously installed, which is indeed a bit puzzling.  Perhaps Eset forgot to update the revision number? I will check out the other concerns I posted in my previous reply when I get a chance.

There is also the possibility that there was no update to the eelam.sys driver since it was originally coded and therefore why it still shows ver 10.0.0.0.

[itman 1,659]

OK. Finally got this straightened out.

Secure Boot feature of Win 8/10 only applies if your motherboard has UEFI and not a BIOS. My old MB is BIOS based. Secure boot uses ELAM driver to validate driver hashes and the like.

The primary use of ELAM excluding the above on WIN 8/10 is noted in this PC Mag ref.: http://www.pcmag.com/article2/0,2817,2411464,00.asp .

Regardless of whether you are using Windows Defender or a different anti-malware product, Windows 8 has tweaked its load process so that security software runs first. Early Launch Anti-Malware (ELAM) insures that the first software driver loaded into Windows 8 is a driver from the user's anti-malware software.

Eset uses its ELAM driver to early load its kernel as Level 0 protected process.
 

[electricdream75 0]

Hi to all , I read the messages and so I wanted to check the problem by installing the demo version of internet security 10.0.390.0 on Windows 10 home 64 bit updated to today.
At the end of installation and the first launch of that also it appeared to me the error in the event log.
The next reboot the error did not appear anymore.
The version of eelam.sys files in my system after installation is the 10.0.0.0. but it is the 17/01/2017 (January 2017).
And 'why do you think that the error did not appear anymore? So the problem seems to have been solved by Eset?

Thank you all.

Edited March 19, 2017 by electricdream75

[itman 1,659]

5 hours ago, electricdream75 said:

So the problem seems to have been solved by Eset?

Yes. The issue disappeared for me with the ver. .390 update.