madConfigDrv.exe bug on Windows 10

c++ / delphi package - dll injection and api hooking

madConfigDrv.exe bug on Windows 10

Postby chaos072 » Mon Aug 24, 2015 8:40 am


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?
Posts: 20
Joined: Wed Mar 20, 2013 2:22 am

Re: madConfigDrv.exe bug on Windows 10

Postby madshi » Mon Aug 24, 2015 8:54 am

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?
Site Admin
Posts: 10024
Joined: Sun Mar 21, 2004 5:25 pm

Re: madConfigDrv.exe bug on Windows 10

Postby chaos072 » Tue Aug 25, 2015 1:59 am

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..
Posts: 20
Joined: Wed Mar 20, 2013 2:22 am

Return to madCodeHook

Who is online

Users browsing this forum: No registered users and 6 guests