Windows 10: Is this hash a valid...

Please help me verify if this hash 68fa9209563cd30dc7a96419822084761a3726645ee150716887c4a0b9b135af is an authentic kernel32.dll. the file size is only 149kb. the system32 folder has a kernel32legacy.dll and the forwarder folder inside the system32 contains this kernel32.dll. This is part of a nano server which hash a forwarder folder in the system32 and the kernel32.dll is located in the forwarders folder. The kernel32.dll is 149kb, is this authentic?

:)

 

efswrt.dll page hashes of an image file are not valid

I started getting this message on Event Viewer 12/9/15 and get it every 2 to 5 days:

Code Integrity determined that the page hashes of an image file are not valid. The file could be improperly signed without page hashes or corrupt due to unauthorized modification. The invalid hashes could indicate a potential disk device error.

File Name: \Device\HarddiskVolume2\Windows\System32\efswrt.dll

Event ID: 6281

I ran DISM.exe /Online /Cleanup-image /Scanhealth and it said everything was OK.

I saw a suggestion to run sfc /scannow, but I am concerned about doing that on my own.

 

Files hash info

I suggest you verify whether the files really are identical. Generate different hashes- as f14tomcat suggests below..

What convinces you the hash value computed is embedded in the file?

 

Signtool.exe hashing process

Hi,

We are not able to generate SHA256 hash of a .exe file, similar to hash generated by Signtool sign's command. We need to learn Signtool's hashing process.

We have a requirement for Reproducible Build, origin verification, and Automated Hash validation, as a part of our CodeSigning software.

For that we are using client-side hashing, and some extra metadata while sending a /signing request to our server, it generates reproducible build and checks its hash with incoming hash. We have implemented our Key Storage Provider for that.

KSP calls this method..

SECURITY_STATUS

WINAPI

KSPSignHash(

__in NCRYPT_PROV_HANDLE hProvider,

__in NCRYPT_KEY_HANDLE hKey,

__in_opt VOID *pPaddingInfo,

__in_bcount(cbHashValue) PBYTE pbHashValue,

__in DWORD cbHashValue,

__out_bcount_part_opt(cbSignature, *pcbResult) PBYTE pbSignature,

__in DWORD cbSignature,

__out DWORD * pcbResult,

__in DWORD dwFlags) {

// pbHashValue is PBYTE, converts to Hex e.g. "60afbb393d1501929096ffd28c56ba586a30726491ce976d24df9479d27d6bdc"

signature = SendPost ({

"server_url": "https://codesigningserver.com/api/signing/sign"

"key_name": "signingKey1",

"hash_to_sign": "60afbb393d1501929096ffd28c56ba586a30726491ce976d24df9479d27d6bdc"

"signing_project_id": 1,

"build_job_id": 8

})

}

But the fileDigest hash calculated by signtool, maybe like AuthentiCode is "10494480e5deefe3d6060fffc33f1d893380a2c3788659a4afef5fbf9c6da7b1"

At our CodeSigning server, we are generating reproducible build with the help of extra parameters passed in the request, so we get an reproducible-build .exe file generated at our server, we are to validate its hash (or file digest maybe) with the incoming hash_to_sign .

But we are not able to generate this incoming hash_to_sign at our server, and we are not able to deliver Automated-hash validation feature for our code signing software.

Please provide assistance.

Thanks,

Shivam Sharma