-1

I tried loading the DLL file "bcryptprimitives.dll" (which in my case, originally sits under "C:\Windows\syswow64\bcryptprimitives.dll") from another location, with this snippet of code:

LoadLibraryW(L"<altered path>\\bcryptprimitives.dll");

However, right after executing this line of code I get the following error:

enter image description here

C:\Program Files (x86)\Notepad++\bcryptprimitives.dll is either not designed to run on Windows or it contains an error. Try installing the program again using the original installation media or contact your system administrator or the software vendor for support. Error status 0xc0000428.

I searched the 0xc0000428 NTSTATUS in the following dictionary: https://msdn.microsoft.com/en-us/library/cc704588.aspx and apparently this status means STATUS_INVALID_IMAGE_HASH.

The error at first makes sense, because I changed the "LoaderFlags" field in the image PE header from 0x00000000 to 0x00000001 (which doesn't need to affect anything because this field is deprecated), but even though I changed the field, I fixed the PE checksum.

enter image description here

As you can see: enter image description here

However, LoadLibrary still refuses to load the DLL. Diving deep into ntdll reveals that the error is returned from kernel:

enter image description here

It makes me think that the DLL is somehow signed and the kernel checks whether the DLL was altered. So to my point, how can I load this DLL from another location anyway and remove the sign check?

Aviv
  • 516
  • 1
  • 3
  • 21
  • 1
    Why do you feel compelled to do this? Wouldn't it be easier to fit in with the system rather than trying to subvert it? – David Heffernan Jul 14 '16 at 07:44
  • @DavidHeffernan, that's all the fun about it. I'm working at a company that develops unique security solutions that can be implemented only by subverting the system. – Aviv Jul 14 '16 at 08:08
  • Smells like malware – David Heffernan Jul 14 '16 at 08:13
  • @DavidHeffernan, apparently everything smells to you like a malware. If you find comfort in thinking that I'm developing malwares I won't ruin the party for you. – Aviv Jul 14 '16 at 08:19
  • 1
    Removing certificates from Windows system DLLs is not permitted by the license, how can this not be malware? I guess we have a different definition of malware. – David Heffernan Jul 14 '16 at 08:20
  • *Malware, short for malicious software, is any software used to disrupt computer operations, gather sensitive information, gain access to private computer systems, or display unwanted advertising.* I dont think I do that. – Aviv Jul 14 '16 at 08:21
  • That's not my definition of malware. – David Heffernan Jul 14 '16 at 08:22
  • 2
    This question is so full of wrong assumptions, it hurts to think that you are working in the security field. Directly from the [NTSTATUS values](https://msdn.microsoft.com/en-us/library/cc704588.aspx) link you posted: *"The hash for image %hs **cannot be found in the system catalogs**. The image is likely corrupt or the victim of tampering."* No clue, why you believe that fixing up the CRC would have any effect on the entries in the system catalog. – IInspectable Jul 14 '16 at 09:32
  • 1
    @IInspectable it had nothing to do with system catalog files. Clearly noted in my question that the DLL is altered and is being loaded from another location - therefore I can remove the DLL's "Force integrity check" flag in the OptionalHeader and the hash will not be searched in the system catalog. You use arrogance in order to write nonsense pretending that you know everything. So let me recommend you, read the docs. – Aviv Jul 14 '16 at 23:15
  • 1
    @IInspectable, It hurts to think that you are commenting on windows internal posts without having the proper knowledge to write an answer. Signatures are checked only on DLLs that have this DllCharacteristic flag. BTW I bet all the down-voters know nothing about this post's subject. – Aviv Jul 14 '16 at 23:22

2 Answers2

5

If a DLL is signed, then by changing a single byte in the file will invalidate the signature. It appears you are doing exactly that by modifying PE header.

This blog post might be of interest to for deeper insight how this technology works:

Code Integrity is a feature that improves the security of the operating system by validating the integrity of a driver or system file each time it is loaded into memory. Code Integrity detects whether an unsigned driver or system file is being loaded into the kernel, or whether a system file has been modified by malicious software that is being run by a user account with administrative permissions. On x64-based versions of the operating system, kernel-mode drivers must be digitally signed.

Brandon
  • 416
  • 2
  • 5
1

Found a quick solution:

DWORD dwIndex = 0;

hFile = CreateFileW(L"C:\\Program Files (x86)\\Notepad++\\bcryptprimitives.dll", FILE_READ_DATA | FILE_WRITE_DATA, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

while (ImageRemoveCertificate(hFile, dwIndex))
{
    ++dwIndex;
}

LoadLibraryW(L"C:\\Program Files (x86)\\Notepad++\\bcryptprimitives.dll");

It is working like a charm :)

This is how the API works:

    1. Calculate the offset of the end of the last section.
    1. Remove all the data following that section.
    1. Remove the security data directory.
    1. Shrink the image.
    1. Calculate an updated checksum of the PE.
Aviv
  • 516
  • 1
  • 3
  • 21
  • 1
    What is the purpose of this code? You claim to be doing security research, but you appear to be doing it from the other side of the airtight hatchway. If you have the privileges to do this, then you have already pwned the system. Why mess around with removing certificates when you can just execute arbitrary binary code directly? – Cody Gray - on strike Jul 14 '16 at 17:29
  • @CodyGray, because I'm not developing a malware like people here think. – Aviv Jul 14 '16 at 21:48