i use mch 4.2.1
I tried to perform an injection with the procedure below, but I get error code 31.
1. Build the Hook DLL and sign it with SHA256.
2. add the Hook DLL to the driver using madConfigDrv.
I used the command line below.
madConfigDrv iMonFTS-HookX64.sys iMonFTS-Hook -unsafeStopAllowed -cert=".\x64-release\iMonFTS-HookX64.dll"
3. SHA256 signed the driver and submitted it to MS for EV signing. We did not EV sign the Hook DLL.
Afterward, loadInjectionDriver succeeds, but InjectLibraryW returns an error 31 times.
[question] error code 31..
Re: [question] error code 31..
That might mean that the DLL is not recognized by the driver. Can you confirm that the driver is actually running?
Did you sign the hook DLL at all, or not? If so, did you sign the hook DLL before or after calling madConfigDrv?
Did you sign the hook DLL at all, or not? If so, did you sign the hook DLL before or after calling madConfigDrv?
Re: [question] error code 31..
hmm. i got it.
The cause was the use of "/" as a path separator in the pathname of the DLL file when calling InjectLibraryW. We realized that using / as a path separator caused the GetFileHash function inside AddDLL to call ZwCreateFile, which caused ZwCreateFile to fail.
The cause was the use of "/" as a path separator in the pathname of the DLL file when calling InjectLibraryW. We realized that using / as a path separator caused the GetFileHash function inside AddDLL to call ZwCreateFile, which caused ZwCreateFile to fail.
Re: [question] error code 31..
@jgh0721
Thanks for letting us know what your resolution was, it helps others on the forum too. As far as Windows OS is concerned... some Win32 API will normalize separators such as a / instead of a \ but other APIs may not (especially some native API). Sanitization and normalization is expected to occur at the higher up Win32 layer before it's handed down to the lower native layer so this only makes sense.
--Iconic
Thanks for letting us know what your resolution was, it helps others on the forum too. As far as Windows OS is concerned... some Win32 API will normalize separators such as a / instead of a \ but other APIs may not (especially some native API). Sanitization and normalization is expected to occur at the higher up Win32 layer before it's handed down to the lower native layer so this only makes sense.
--Iconic