help! Do not injection (RESOLVED)

[hck2]

abc.dll is electronically signed.
"madConfigDrv.exe xxx.sys insight.if -unsafeStopAllowed abc.dll "
After running the above debug, abc.dll has an error in injection. abc2.dll fails to inject.
Is xxx.sys only MS cross-signed?
The -cert option in help says "madConfigDrv.exe renameme64.sys asdf -unsafeStopAllowed -cert=abc.dll"
"The driver file does not support storing trusted certificates."
Is there a solution?

[madshi]

First of all, does loading the driver succeed? That's the first step.

The "The driver file does not support storing trusted certificates" suggest that you might be using an outdated driver file? Please make sure you use the latest driver from the latest installer:

http://madshi.net/madCollection.exe

[kuaaan]

Hi, I'm a coworker of hck2. and we appreciate you kind reply.

> First of all, does loading the driver succeed? That's the first step.

Yes. we made sure that the driver is loaded successfully but does not work.

> The "The driver file does not support storing trusted certificates" suggest that you might be using an outdated driver file?

I don’t understand what “outdated driver file” means.

Currently, we are using madCodeHook version 4.2.1 with company license, which is not the latest version. (but just second version before the latest one.)
Unfortunately, we did not renew maintanance contract. so we cannot try the latest version that you sugested.
Are you suppose that the latest version can solve this problem? If so, we are willing to renew the contract.

--------------------------------------
Additionally, we have slight change with our driver signing. It might affected current status. please consider following change.

BEFORE (2023) : We configured our driver without “-cert” option of madConfigDrv.exe, and We signed our injection driver with (both) our own EV certificate and MS cross certificate. AND it works fine.

CURRENT (2024) : Our Ceritificate is replaced. and We sign our injection driver only with MS cross certificate. (so to say, our driver is not signed directly with our own certificate any more) and that’s why we try to configure with “-cert” option.

[madshi]

The driver wants to check if the DLL that it is asked to inject is "trustworthy" or not. Because if the driver didn't do that, malware could misuse the driver to inject malware dlls. We definitely don't want that! So because of that the driver has to have a way to verify if a DLL is trustworthy or not.

Originally, in older madCodeHook builds, you had to reconfigure the driver every time you recompiled your hook dlls. Reconfiguring the driver then basically just stored a CRC/hash of the recompiled hook dll into the driver file, so the driver knew this dll was trustworthy. However, having to reconfigure and resign the driver every time you recompile your hook dlls is very painful, so newer madCodeHook builds have an additional method to verify whether your hook dll is trustworthy:

Basically the madCodeHook driver now compares the certificate that the driver itself was signed with to the certificate your hook dlls are signed with. These certificates have to match. If they don't match, the driver will not consider your hook dlls to be trustworthy.

From what you're saying, it seems that your driver is no longer signed with your own certificate? But your hook dll is? In that case the certificate of the driver doesn't match the certificate of the hook dll, does it? That would explain why the driver rejects your hook dll. You can normally solve this by using the "-cert" option. However, is the dll signed at all? And do you call "madConfigDrv.exe" after your hook dll gets signed or before?

Alternatively, you can always use madCodeHook "the old way", by calling madConfigDrv.exe with the hook dlls as direct parameters, like this:

Code: Select all

madConfigDrv.exe your.sys yourDriverName hook32.dll hook64.dll

If you configure the driver like this, it should definitely be willing to inject your hook dlls - but this will only work as long as your hook dlls are not modified afterwards in any way. So any time you touch your hook dlls, you'd have to reconfigure and resign the driver. So this is not a very comfortable solution. However, maybe it would be worth trying this solution right now, just to double check that injection works fine like this? If it does, then we know for sure that the problem you're seeing at the moment is definitely caused by the driver vs hook dll certificate changes and by nothing else...

Hope that helps?

[kuaaan]

From what you're saying, it seems that your driver is no longer signed with your own certificate? But your hook dll is? In that case the certificate of the driver doesn't match the certificate of the hook dll, does it? That would explain why the driver rejects your hook dll. You can normally solve this by using the "-cert" option. However, is the dll signed at all? And do you call "madConfigDrv.exe" after your hook dll gets signed or before?

Yes, our driver file is not signed with our own certificate any more, and it's obvious that this change caused this problem. We understand that. and we tried to solve this situation with "-cert" option.
What we want to know is... "Why '-cert' option doesn't work?"

Code: Select all

madConfigDrv.exe renameme64.sys asdf -unsafeStopAllowed -cert=abc.dll

At the moment that above command is invoked, xxx.sys is not signed and abc.dll is already signed. (so to say, we call madConfigDrv.exe AFTER abc.dll gets signed)

Unfortunately, "the old way" you suggested is not a solution. We want to rebuild our hooking dll whenever our any source code is changed. But hooking driver file need to be cross-signed by MS and it takes quite long time. That's why we cannot rebuild whenever our package is built.

Here, we attach our hook dll and sys file and madDrvConfig.exe binary as it is. (password : masShi)
Could you check it?

pmon.7z

(193.18 KiB) Not downloaded yet

Driver.7z

(65.55 KiB) Not downloaded yet

[madshi]

I've copied all the files into one folder, then ran this command line:

"madConfigDrv.exe renameme64.sys funnyName -unsafeStopAllowed -cert=pmon.dll"

However, I've overwritten the madConfigDrv.exe with the latest version, because I didn't want to execute some EXE I downloaded from the internet on my PC. Anyway, the command line above executed without warnings. So I did not get the "The driver file does not support storing trusted certificates" complaint. On your PC, do you still get that complaint?

[kuaaan]

Thanks for your tests.

On your PC, do you still get that complaint?

YES, I do. (refer to the attached screenshot, plz)

ONE MORE QUESTION :
Does your madConfigDrv.exe has something changed in comparison to ours?
(Our madConfigDrv.exe is built on ‎2023‎-11-07 with version 1.0.3.0 according to resource information.
it's identical to the one installed at the first time, and actually we don't have any Delphi build env at all.)

If so, according to your test, it means that upgrading madCodeHook (including madConfigDrv.exe) may solve our problem (whatever it is caused by).
But, if it doesn't... ??

[iconic]

I've personally never encountered this problem with any version of madConfigDrv tool, however I use the "old" and proven way without the -cert parameter. Like Madshi said previously, it's much less flexible in case of changes to a binary, however (as Madshi noted)

Lastly, does this only happen on a single machine or environment? Seems like something else is amiss here.

--Iconic

[kuaaan]

@iconic, thank you for your attention!!

It's first time that I tried "-cert" option, so I've never seen madConfigDrv message like this before, either.
(No "-cert" option, no such problem.)

Currently, we need "-cert" option because we need to rebuild hook dll but don't want to rebuild driver whenever we build agent package. We build agent package more than 10 times a day and it takes about 20 minutes each. if kernel driver is recompiled whenever package is made, it means that kernel driver need to be cross-signed by MS everytime and it will takes additional 30~60 minutes.

Lastly, does this only happen on a single machine or environment?

I checked two devices and result was identical.

[iconic]

Hello,

Ran a quick test myself with your exact binaries and the latest madConfigDrv tool worked fine here, no warnings/errors (hash of the driver changed accordingly, too) - Your "older" binary version of madConfigDrv.exe failed with the same error you are experiencing on my end. It all comes down to key length/size differences in the code internally which was updated in newer builds of the tool.

--Iconic

[madshi]

Thanks iconic!

@kuaaan, if you send me an email, I can make the newer madConfigDrv.exe available to you separately.

[iconic]

Code: Select all

            if drvCfg.Magic2[1] = $12345678 then
              maxKeySize := 260
            else
              if drvCfg.Magic2[1] = $12345679 then // unavail on OLD builds
                maxKeySize := 516;
 

That's what caused the issue in my tests during x-comparison (older to latest)


--Iconic

[madshi]

It's strange, though, that kuaaan has a driver which is prepared for the longer key size, but not a matching madConfigDrv.exe. Not sure how that happened. I'm pretty sure I updated both the driver and the madConfigDrv.exe at the same time, to support longer key sizes...

[kuaaan]

We really appreciate your help.
Request mail will be sent soon.

Sincerely.

[iconic]

@kuaaan,

Please let us know if your issue is resolved so we can close this thread, thanks!

--Iconic