madConfigDrv.exe bug on Windows 10

c++ / delphi package - dll injection and api hooking
Post Reply
chaos072
Posts: 21
Joined: Wed Mar 20, 2013 2:22 am

madConfigDrv.exe bug on Windows 10

Post by chaos072 »

Hi,

I've found some weird bug in madConfigDrv.exe.

To reproduct the bug:

* Development environment: Windows 10, x64 machine, Visual Studio 2015(SP5)

1) Set up a Win32 empty project on Windows 10 and Visual Studio 2015(SP5).
2) In Post Build Event, set madConfigDrv.exe script(e.g. madConfigDrv.exe Xxx.sys DrvName Xxx1.dll Xxx2.dll -stopDisallowed)
3) Set Configuration Properties -> General -> Platform Toolset to "Visual Studio 2013 - Windows XP (v120_xp)"
4) Build the project, and you get the generated sys file.
5) Now this .sys file cannot be loaded Windows 7(x64) machine. But this .sys file is loaded successfully on Windows 8.1/10.

If you set Platform Toolset to "Visual Studio 2013", this bug doesn't occur.
On Windows 8.1 this bug does not occur.
Also if you run madConfigDrv.exe outside Visual Studio, everything's fine.

Why is that?
madshi
Site Admin
Posts: 10754
Joined: Sun Mar 21, 2004 5:25 pm

Re: madConfigDrv.exe bug on Windows 10

Post by madshi »

That sounds quite weird. Are you sure that you're using the same certificate for signing in both cases? I think Windows 8.1 and 10 support SHA256 certificates, but Windows 7 does not (without installing a patch for that). So maybe your Post Build Event somehow uses an SHA256 certificate, but in all other cases you're using an SHA1 certificate? That would be the best explanation that comes to my mind.

If that's not the problem, then I've no clue what it could be right now. Have you checked the size and contents of the driver file after configuration and *before* signing, either when using the Post Build Event, or when running madConfigDrv manually? Anything different?
chaos072
Posts: 21
Joined: Wed Mar 20, 2013 2:22 am

Re: madConfigDrv.exe bug on Windows 10

Post by chaos072 »

Thank you madshi.

I've found the cause and resolved the problem.

madConfigDrv.exe was not the cause. Wrong signtool.exe was called.

Thank you..
Post Reply