wbenny / injdrv Goto Github PK
View Code? Open in Web Editor NEWproof-of-concept Windows Driver for injecting DLL into user-mode processes using APC
License: MIT License
proof-of-concept Windows Driver for injecting DLL into user-mode processes using APC
License: MIT License
Running InjDrv successfully hooks all process once its' loaded.
But after injection on MicrosoftEdgeCP.exe the Edge browser stalls, and errors thrown at EventLogs. [After loading the driver, close all edge browser windows and open a new edge browser window ]
My Scenario:
I want to know all the processes that are opened and want to elegate/delegate some process specifically. InjDrv satisifies the need and it works perfect, except it stalls MicrosoftEdge browser. I have tried by modifying forceUserAPC but still its not working.
Kindly show the way to overcome it.
Hi,
I was wonder if it's optional to using APC to inject into already running processes that doesn't necessarily have alertable threads.
According to APC doc :
When a user-mode APC is queued, the thread to which it is queued is not directed to call the APC function unless it is in an alertable state.
(I assume kernel-mode APC work the same way)
Is there a way to change thread state so it will accept APC calls, or any other alternative ?
thanks
Unprotected processes may set the ProcessDynamicCodePolicy
flag on, which prevents the driver from allocate new executable memory on their virtual memory space and fail injDrv.
I guess that the intention was that no user-space program may alter this settings, but there must be a way from driver to avoid this bit, since it has more privileges.
I know that there are methods to detect mitigation policy flags such as NtQueryInformationProcess
and set them using SetProcessMitigationPolicy()
, but they all uses undocumented structures. I wonder if there's an alternative way to do so from driver...
Is there any way to avert this bit from driver once process has started, or allocate the memory for injected code before this policy is being enforced ?
thanks
I complied the driver and created 2 x64/x86 dlls that just call to OutputDebugString on process attach.
I get injection successful message in DebugView but nothing is printed in the DebugView that indicates that the dll was loaded to the process. I also used procexp and I don't see the injdllx64 in the dll list. This behavior is on all the processes!
This is the message I'm getting for example from DebugView:
[injlib]: Injecting (PID: 15608, Wow64: FALSE, Name: 'ftp.exe')
[injlib]: InjpQueueApc successfull
[injlib]: Mark process: 15608 is injected
What could be the reason that it does not load the dll?
Thanks,
Rony.
Hi & Tnx for your code
After a few hours running in system, We've got a BSOD. Can you guide me to how to fix it plz ?!
this is the result of !analyze -v
BUGCODE_NDIS_DRIVER (7c)
The operating system detected an error in a networking driver.
The BUGCODE_NDIS_DRIVER bugcheck identifies problems in network drivers.
Often, the defect is caused by a NDIS miniport driver. You can get a complete
list of NDIS miniport drivers using !ndiskd.netadapter. You can get a
big-picture overview of the network stack with !ndiskd.netreport.
Arguments:
Arg1: 0000000000000025, NDIS_BUGCHECK_WATCHDOG
An attempt to manage the network stack has taken too
long. When NDIS calls out into other drivers, NDIS
starts a watchdog timer to ensure the call completes
promptly. If the call takes too long, NDIS injects a
bugcheck.
This can be caused by a simple deadlock -- look with
"!stacks 2 ndis!" or similar to see if any threads
look suspicious. Pay special attention to the
PrimaryThread from the NDIS_WATCHDOG_TRIAGE_BLOCK.
This can be caused by lost NBLs, in which case
!ndiskd.pendingnbls may help. Check for OIDs that are
stuck using !ndiskd.oid.
Arg2: 0000000000000011, NDIS_BUGCHECK_WATCHDOG_FILTER_PAUSE
There was a timeout while pausing a filter driver.
Arg3: ffffd78e90fb4fa8, Cast to ndis!_NDIS_WATCHDOG_TRIAGE_BLOCK. Interesting fields:
* StartTime shows what time the operation started,
in 100ns units, as returned by KeQueryInterruptTime.
* TimeoutMilliseconds shows how long NDIS waited, at a
minimum, before triggering this bugcheck.
Measured in milliseconds.
* TargetObject is a handle to the protocol, filter,
or miniport that NDIS is waiting on. Use with
!ndiskd.protocol, !ndiskd.filter, or !ndiskd.miniport.
* PrimaryThread is the thread on which NDIS initiated
the operation. Usually this is the first place to
look, although the thread may have gone elsewhere
if the operation is being handled asynchronously.
Arg4: 0000000000000000
KEY_VALUES_STRING: 1
PROCESSES_ANALYSIS: 1
SERVICE_ANALYSIS: 1
STACKHASH_ANALYSIS: 1
TIMELINE_ANALYSIS: 1
DUMP_CLASS: 1
DUMP_QUALIFIER: 0
BUILD_VERSION_STRING: 18362.1.amd64fre.19h1_release.190318-1202
DUMP_TYPE: 0
BUGCHECK_P1: 25
BUGCHECK_P2: 11
BUGCHECK_P3: ffffd78e90fb4fa8
BUGCHECK_P4: 0
MODULE_NAME: wfplwfs
FAULTING_IP:
wfplwfs!LwfLowerPause+0
fffff805`081a61f0 48895c2408 mov qword ptr [rsp+8],rbx
CPU_COUNT: 4
CPU_MHZ: a22
CPU_VENDOR: GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 3e
CPU_STEPPING: 4
CPU_MICROCODE: 6,3e,4,0 (F,M,S,R) SIG: 427'00000000 (cache) 427'00000000 (init)
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
BUGCHECK_STR: 0x7C
PROCESS_NAME: System
CURRENT_IRQL: 0
ANALYSIS_SESSION_TIME: 12-14-2020 12:28:48.0744
ANALYSIS_VERSION: 10.0.18362.1 amd64fre
STACK_TEXT:
ffff9f88ad213c38 fffff805
05aba942 : 0000000000000025 00000000
00000003 ffff9f88ad213da0 fffff805
058709f0 : nt!DbgBreakPointWithStatus
ffff9f88ad213c40 fffff805
05aba032 : 0000000000000003 ffff9f88
ad213da0 fffff805059e7a60 00000000
0000007c : nt!KiBugCheckDebugBreak+0x12
ffff9f88ad213ca0 fffff805
059d3487 : 0000000000000000 00000000
00000007 ffffd78e8a80c1a0 fffff805
05b3af6b : nt!KeBugCheck2+0x952
ffff9f88ad2143a0 fffff805
07c4e27e : 000000000000007c 00000000
00000025 0000000000000011 ffffd78e
90fb4fa8 : nt!KeBugCheckEx+0x107
ffff9f88ad2143e0 fffff805
07cf4121 : 0000000000000000 fffff805
0618b3f0 ffffd78e90fb4ee0 00000000
000000a8 : ndis!ndisBugCheckEx+0x1e
ffff9f88ad214420 fffff805
07cf3ff1 : 0000000003bfefbf ffffd78e
90fb4ee0 fffff80507cb6918 00000000
00000000 : ndis!ndisReportTimeoutWaitingForExternalDriver+0xd5
ffff9f88ad214460 fffff805
07cf43e9 : 0000000000040b28 ffffd78e
90fb4fa8 0000000000000011 ffff9f88
ad214558 : ndis!ndisFindSomeoneToBlame+0x125
ffff9f88ad2144d0 fffff805
07cf3e6e : ffffd78e90fb4ee0 ffff9f88
ad2145d9 ffffd78e8b6b2d30 00000000
00010286 : ndis!ndisWaitForExternalDriver+0x75
ffff9f88ad214500 fffff805
07cf4342 : ffffd78e90fb4ee0 fffff805
07cf4314 0000000000000010 00000000
00010246 : ndis!NdisWatchdogState::WaitSynchronously+0x6e
ffff9f88ad214540 fffff805
07d06a23 : ffffd78e90fb4ee0 ffff9f88
ad2145d9 ffffd78e8b6b2d30 ffffd78e
8b6b2ca0 : ndis!ndisWaitForEventThenDisarmWatchdog+0x2e
ffff9f88ad214580 fffff805
07cdb830 : ffffe78746c4efa0 ffffe787
46c4efa0 ffffd78e8a80d5a8 ffffd78e
8b6b2ca0 : ndis!ndisPauseFilterInner+0x573b
ffff9f88ad214640 fffff805
07cd166a : 0000000000000000 ffff9f88
ad214790 ffffd78e8a80d590 00000000
00000000 : ndis!ndisPauseFilter+0xb4
ffff9f88ad214690 fffff805
07cd13c0 : ffffd78e8a80c1a0 ffffd78e
8a80c1a0 ffffd78e8a80d608 ffffd78e
8a80d590 : ndis!Ndis::BindEngine::Iterate+0x202
ffff9f88ad214810 fffff805
07ccc409 : ffffd78e8a80d590 00000000
00000000 0000000000000000 00000000
00000000 : ndis!Ndis::BindEngine::UpdateBindings+0x98
ffff9f88ad214860 fffff805
07ccc2c8 : ffffd78e8a80d590 00000000
00000000 ffffd78e8a80d590 fffff805
07ccc8e6 : ndis!Ndis::BindEngine::DispatchPendingWork+0x75
ffff9f88ad214890 fffff805
07c24728 : ffffd78e8a80c1a0 00000000
00000002 0000000000000020 00000000
00000000 : ndis!Ndis::BindEngine::ApplyBindChanges+0x54
ffff9f88ad2148e0 fffff805
07be280d : ffffd78e8a80c1a0 00000000
00000000 ffffd78e8a80cd48 ffffd78e
8a80c1a0 : ndis!ndisPrepForLowPowerCommon+0x41eec
ffff9f88ad2149d0 fffff805
07be3246 : ffffd78e8a80c1a0 00000000
00000000 ffffd78e970f4e10 fffff805
07bd6755 : ndis!ndisPrepForLowPower+0x1d
ffff9f88ad214a20 fffff805
07be3931 : 0000000000000000 ffffd78e
00000004 ffffd78e970f4e10 ffffd78e
8a80c1a0 : ndis!ndisSetSystemPower+0x19e
ffff9f88ad214aa0 fffff805
07be9e84 : ffffd78e970f4e10 ffffd78e
8690ed30 ffffd78e970f4f28 ffffd78e
8a80c1a0 : ndis!ndisSetPower+0x109
ffff9f88ad214b00 fffff805
0598b02f : ffffd78e8a80c050 ffff9f88
ad214be0 0000000000000000 ffffd78e
970f4e10 : ndis!ndisPowerDispatch+0x114
ffff9f88ad214b60 fffff805
0587cce5 : 0000000000000000 ffffd78e
86939080 fffff8050598ae50 00000000
00000000 : nt!PopIrpWorker+0x1df
ffff9f88ad214c10 fffff805
059da9ca : ffffa38117580180 ffffd78e
86939080 fffff8050587cc90 00000000
00000000 : nt!PspSystemThreadStartup+0x55
ffff9f88ad214c60 00000000
00000000 : ffff9f88ad215000 ffff9f88
ad20f000 0000000000000000 00000000
00000000 : nt!KiStartSystemThread+0x2a
THREAD_SHA1_HASH_MOD_FUNC: fb82d6835acc43782ce2d8cc87312c71a062da7a
THREAD_SHA1_HASH_MOD_FUNC_OFFSET: e9f541403998cd88a52fb202de8d71d9d54c78c0
THREAD_SHA1_HASH_MOD: ee7c730e4531afb6d09bc1abcea8a663b1fba34b
FOLLOWUP_IP:
wfplwfs!LwfLowerPause+0
fffff805`081a61f0 48895c2408 mov qword ptr [rsp+8],rbx
FAULT_INSTR_CODE: 245c8948
SYMBOL_NAME: wfplwfs!LwfLowerPause+0
FOLLOWUP_NAME: MachineOwner
IMAGE_NAME: wfplwfs.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 60902cbb
STACK_COMMAND: .thread ; .cxr ; kb
BUCKET_ID_FUNC_OFFSET: 0
FAILURE_BUCKET_ID: 0x7C_VRF_FILT_Pause_wfplwfs!LwfLowerPause
BUCKET_ID: 0x7C_VRF_FILT_Pause_wfplwfs!LwfLowerPause
PRIMARY_PROBLEM_CLASS: 0x7C_VRF_FILT_Pause_wfplwfs!LwfLowerPause
TARGET_TIME: 2020-12-14T08:55:59.000Z
OSBUILD: 18362
OSSERVICEPACK: 0
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
SUITE_MASK: 272
PRODUCT_TYPE: 1
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
OSEDITION: Windows 10 WinNt TerminalServer SingleUserTS
OS_LOCALE:
USER_LCID: 0
OSBUILD_TIMESTAMP: unknown_date
BUILDDATESTAMP_STR: 190318-1202
BUILDLAB_STR: 19h1_release
BUILDOSVER_STR: 10.0.18362.1.amd64fre.19h1_release.190318-1202
ANALYSIS_SESSION_ELAPSED_TIME: d54
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:0x7c_vrf_filt_pause_wfplwfs!lwflowerpause
FAILURE_ID_HASH: {fef43b4d-fb67-4c46-c742-ecef5a38ee06}
On Windows11 ARM64 , amd64 process can run. But cann't be injected.
I compile the project in visual studio 2019 and get the following:
Error C1083 Cannot open the inclusion file: phnt / phnt_windows.h: No such file or directory, injdll C: \ Users \ Alexander \ Desktop \ injdrv-master \ include \ ntdll.h 19
Error LNK1104 cannot open the file "LIBCMT.lib" injldr C: \ Users \ Alexander \ Desktop \ injdrv-master \ src \ injldr \ LINK 1
Bugcheck Analysis
KERNEL_SECURITY_CHECK_FAILURE (139)
A kernel component has corrupted a critical data structure. The corruption
could potentially allow a malicious user to gain control of this machine.
Arguments:
Arg1: 0000000000000003, A LIST_ENTRY has been corrupted (i.e. double remove).
Arg2: fffff208510c9970, Address of the trap frame for the exception that caused the BugCheck
Arg3: fffff208510c98c8, Address of the exception record for the exception that caused the BugCheck
Arg4: 0000000000000000, Reserved
"C:\Windows\System32\KERNELBASE.dll" was not found in the image list.
Debugger will attempt to load "C:\Windows\System32\KERNELBASE.dll" at given base 00000000`00000000.
Please provide the full image name, including the extension (i.e. kernel32.dll)
for more reliable results.Base address and size overrides can be given as
.reload <image.ext>=<base>,<size>.
Unable to add module at 00000000`00000000
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 2171
Key : Analysis.DebugAnalysisManager
Value: Create
Key : Analysis.Elapsed.mSec
Value: 693889
Key : Analysis.IO.Other.Mb
Value: 15
Key : Analysis.IO.Read.Mb
Value: 4
Key : Analysis.IO.Write.Mb
Value: 27
Key : Analysis.Init.CPU.mSec
Value: 1734
Key : Analysis.Init.Elapsed.mSec
Value: 11687220
Key : Analysis.Memory.CommitPeak.Mb
Value: 97
Key : Bugcheck.Code.DumpHeader
Value: 0x139
Key : Bugcheck.Code.KiBugCheckData
Value: 0x139
Key : Bugcheck.Code.Register
Value: 0x3
Key : FailFast.Name
Value: CORRUPT_LIST_ENTRY
Key : FailFast.Type
Value: 3
Key : WER.OS.Branch
Value: 19h1_release
Key : WER.OS.Timestamp
Value: 2019-03-18T12:02:00Z
Key : WER.OS.Version
Value: 10.0.18362.1
BUGCHECK_CODE: 139
BUGCHECK_P1: 3
BUGCHECK_P2: fffff208510c9970
BUGCHECK_P3: fffff208510c98c8
BUGCHECK_P4: 0
TRAP_FRAME: fffff208510c9970 -- (.trap 0xfffff208510c9970)
NOTE: The trap frame does not contain all registers.
EXCEPTION_RECORD: fffff208510c98c8 -- (.exr 0xfffff208510c98c8)
ExceptionAddress: fffff804756b1772 (injdrv+0x0000000000001772)
ExceptionCode: c0000409 (Security check failure or stack buffer overrun)
ExceptionFlags: 00000001
NumberParameters: 1
Parameter[0]: 0000000000000003
Subcode: 0x3 FAST_FAIL_CORRUPT_LIST_ENTRY
PROCESS_NAME: ngentask.exe
ERROR_CODE: (NTSTATUS) 0xc0000409 - <Unable to get error code text>
EXCEPTION_CODE_STR: c0000409
EXCEPTION_PARAMETER1: 0000000000000003
EXCEPTION_STR: 0xc0000409
STACK_TEXT:
fffff208510c8ea8 fffff804
720a9522 : 0000000000000003 00000000
00000003 fffff208510c9010 fffff804
71f1db90 : nt!DbgBreakPointWithStatus
fffff208510c8eb0 fffff804
720a8c12 : 0000000000000003 fffff208
510c9010 fffff80471fd5b60 00000000
00000139 : nt!KiBugCheckDebugBreak+0x12
fffff208510c8f10 fffff804
71fc15e7 : ffffda084a8f6ae0 fffff804
71e40b8a fffff208510c9c60 00000000
ffff7fff : nt!KeBugCheck2+0x952
fffff208510c9610 fffff804
71fd32e9 : 0000000000000139 00000000
00000003 fffff208510c9970 fffff208
510c98c8 : nt!KeBugCheckEx+0x107
fffff208510c9650 fffff804
71fd3710 : 0000000000000000 00000000
00000000 ffffb28a8afb1730 fffff208
510c9840 : nt!KiBugCheckDispatch+0x69
fffff208510c9790 fffff804
71fd1aa5 : ffffda083f267300 fffff804
72460351 0000000000000000 00000000
00000000 : nt!KiFastFailDispatch+0xd0
fffff208510c9970 fffff804
756b1772 : fffff804756b182d 00000000
00000000 0000000000000000 00000000
000000c8 : nt!KiRaiseSecurityCheckFailure+0x325
fffff208510c9b08 fffff804
756b182d : 0000000000000000 00000000
00000000 00000000000000c8 fffff804
71f9fb13 : injdrv+0x1772
fffff208510c9b10 fffff804
756b2a61 : fffff804756b6370 fffff804
756b6370 0000000000000000 fffff804
7216f06d : injdrv+0x182d
fffff208510c9b40 fffff804
756b28d8 : fffff804756b6370 00000000
00000030 ffffda0800000000 fffff804
74dea5a0 : injdrv+0x2a61
fffff208510c9b70 fffff804
756b19b7 : fffff804756b6370 ffffda08
4ac90b90 ffffda0843c089a0 ffffda08
00000000 : injdrv+0x28d8
fffff208510c9bb0 fffff804
756b19e7 : 0000000000000000 00000000
00000380 ffffda0843c08970 ffffda08
4a0d72c0 : injdrv+0x19b7
fffff208510c9bf0 fffff804
723cd996 : ffffda084a0d72c0 00000000
00000380 fffff208510c9c60 00000000
00000000 : injdrv+0x19e7
fffff208510c9c20 fffff804
7245da9c : ffffffff00000000 fffff208
510caa10 fffff208510ca301 ffffda08
4b41d120 : nt!PspCallProcessNotifyRoutines+0x212
fffff208510c9cf0 fffff804
7242fba4 : ffffda084aec60c0 ffffda08
4a0d72c0 fffff208510ca4b0 fffff208
510ca370 : nt!PspInsertThread+0x5e8
fffff208510c9de0 fffff804
71fd2d18 : 00000000004ffda0 00000000
00774000 0000000000000000 00000000
00000000 : nt!NtCreateUserProcess+0x964
fffff208510caa90 00007ffd
54ddd934 : 00007ffd52fa04f8 00007ffd
00580058 0000000000a901dc 00000000
004fe050 : nt!KiSystemServiceCopyEnd+0x28
00000000004fdd28 00007ffd
52fa04f8 : 00007ffd00580058 00000000
00a901dc 00000000004fe050 00000000
00a901c0 : ntdll!NtCreateUserProcess+0x14
00000000004fdd30 00007ffd
52f9fce0 : 00000000004fe050 00000000
004fdef8 0000000002000000 00000000
02000000 : wow64!Wow64NtCreateUserProcess+0xe4
00000000004fde10 00007ffd
52f97123 : 00000000005fea01 00000000
00774000 00007ffd52f9f790 00000000
00000000 : wow64!whNtCreateUserProcess+0x550
00000000004fe0f0 00000000
777f1783 : 0000002377871e7c 00007ffd
54d90023 0000000000000000 00000000
005fdf4c : wow64!Wow64SystemServiceEx+0x153
00000000004fe9b0 00000000
777f1199 : 00000000005ff61c 00007ffd
52f9c864 00000000004fea80 00007ffd
52f9bf58 : wow64cpu!ServiceNoTurbo+0xb
00000000004fea60 00007ffd
52f9c77a : 0000000000773000 00000000
00450080 0000000000000000 00000000
004ff2e0 : wow64cpu!BTCpuSimulate+0x9
00000000004feaa0 00007ffd
52f9c637 : 0000000000000000 00000000
00912178 0000000000000000 00000000
00000000 : wow64!RunCpuSimulation+0xa
00000000004fead0 00007ffd
54e13fb3 : 0000000000772000 00000000
00772000 00007ffd54e6d4c0 00000000
00000010 : wow64!Wow64LdrpInitialize+0x127
00000000004fed80 00007ffd
54e01db5 : 0000000000000001 00000000
00000000 0000000000000000 00000000
00000001 : ntdll!LdrpInitializeProcess+0x186b
00000000004ff1c0 00007ffd
54db1853 : 0000000000000000 00007ffd
54d40000 0000000000000000 00000000
00774000 : ntdll!_LdrpInitialize+0x50549
00000000004ff260 00007ffd
54db17fe : 00000000004ff2e0 00000000
00000000 0000000000000000 00000000
00000000 : ntdll!LdrpInitialize+0x3b
00000000004ff290 00000000
00000000 : 0000000000000000 00000000
00000000 0000000000000000 00000000
00000000 : ntdll!LdrInitializeThunk+0xe
SYMBOL_NAME: injdrv+1772
MODULE_NAME: injdrv
IMAGE_NAME: injdrv.sys
STACK_COMMAND: .cxr; .ecxr ; kb
BUCKET_ID_FUNC_OFFSET: 1772
FAILURE_BUCKET_ID: 0x139_3_CORRUPT_LIST_ENTRY_injdrv!unknown_function
OS_VERSION: 10.0.18362.1
BUILDLAB_STR: 19h1_release
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {b45b9d7e-89f1-dfe2-8192-89894ee49511}
7: kd> .trap 0xfffff208510c9970
NOTE: The trap frame does not contain all registers.
k
*** Stack trace for last set context - .thread/.cxr resets it
00 fffff208510c9b08 fffff804
756b182d injdrv+0x1772
01 fffff208510c9b10 fffff804
756b2a61 injdrv+0x182d
02 fffff208510c9b40 fffff804
756b28d8 injdrv+0x2a61
03 fffff208510c9b70 fffff804
756b19b7 injdrv+0x28d8
04 fffff208510c9bb0 fffff804756b19e7 injdrv+0x19b7
05 fffff208510c9bf0 fffff804723cd996 injdrv+0x19e7
06 fffff208510c9c20 fffff8047245da9c nt!PspCallProcessNotifyRoutines+0x212
07 fffff208510c9cf0 fffff8047242fba4 nt!PspInsertThread+0x5e8
08 fffff208510c9de0 fffff80471fd2d18 nt!NtCreateUserProcess+0x964
09 fffff208510caa90 00007ffd54ddd934 nt!KiSystemServiceCopyEnd+0x28
0a 00000000004fdd28 00007ffd52fa04f8 ntdll!NtCreateUserProcess+0x14
0b 00000000004fdd30 00007ffd52f9fce0 wow64!Wow64NtCreateUserProcess+0xe4
0c 00000000004fde10 00007ffd52f97123 wow64!whNtCreateUserProcess+0x550
0d 00000000004fe0f0 00000000777f1783 wow64!Wow64SystemServiceEx+0x153
0e 00000000004fe9b0 00000000777f1199 wow64cpu!ServiceNoTurbo+0xb
0f 00000000004fea60 00007ffd52f9c77a wow64cpu!BTCpuSimulate+0x9
10 00000000004feaa0 00007ffd52f9c637 wow64!RunCpuSimulation+0xa
11 00000000004fead0 00007ffd54e13fb3 wow64!Wow64LdrpInitialize+0x127
12 00000000004fed80 00007ffd54e01db5 ntdll!LdrpInitializeProcess+0x186b
13 00000000004ff1c0 00007ffd54db1853 ntdll!_LdrpInitialize+0x50549
14 00000000004ff260 00007ffd54db17fe ntdll!LdrpInitialize+0x3b
15 00000000004ff290 0000000000000000 ntdll!LdrInitializeThunk+0xe
The command I have used to build was:
msbuild injldr.vcxproj /p:Configuration=Release /p:Platform=x64
Error
Build FAILED.
"C:\Users\Username\injdrv\src\injldr\injldr.vcxproj" (default target) (1) ->
(MakeDirsForCl target) ->
C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppBuild.targets(1016,5): error MSB3191: Unable to create director
y "C:\Users\Username\injdrv\src\injldr\bin\obj\x64\Release\injldr\C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.36.32532\modules". The g
iven path's format is not supported. [C:\Users\Username\injdrv\src\injldr\injldr.vcxproj]
What did I do as a solution
I have changed
<ObjectFileName>$(IntDir)%(RelativeDir)%(Filename)%(Extension).obj</ObjectFileName>
in line 70 to
<ObjectFileName>$(IntDir)%(Directory)%(Filename)%(Extension).obj</ObjectFileName>
Hi,
I got BSOD on Windows 10.
SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff802bc932524, Address of the instruction which caused the bugcheck
Arg3: ffffe08f1ba66ae0, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.
FAULTING_IP:
injdrv+2524
fffff802`bc932524 48394110 cmp qword ptr [rcx+10h],rax
MODULE_NAME: injdrv
IMAGE_NAME: injdrv.sys
This is the callstack:
0: kd> kp
Child-SP RetAddr Call Site
00 ffffe08f1ba66208 fffff802bd45b669 nt!KeBugCheckEx
01 ffffe08f1ba66210 fffff802bd45abbc nt!KiBugCheckDispatch+0x69
02 ffffe08f1ba66350 fffff802bd4533ad nt!KiSystemServiceHandler+0x7c
03 ffffe08f1ba66390 fffff802bd35b126 nt!RtlpExecuteHandlerForException+0xd
04 ffffe08f1ba663c0 fffff802bd35cc23 nt!RtlDispatchException+0x416
05 ffffe08f1ba66ab0 fffff802bd45b742 nt!KiDispatchException+0x1f3
06 ffffe08f1ba67160 fffff802bd4582c5 nt!KiExceptionDispatch+0xc2
07 ffffe08f1ba67340 fffff802bc932524 nt!KiPageFault+0x405
*** WARNING: Unable to verify timestamp for injdrv.sys
08 ffffe08f1ba674d0 fffff802bc9327f3 injdrv!InjFindInjectionInfo(void * ProcessId = 0x00000000000020ac)+0x34 [c:\working\injdrv\injlib.c @ 1093] 09 ffffe08f1ba674f0 fffff802bd7f2efe injdrv!InjLoadImageNotifyRoutine(struct _UNICODE_STRING * FullImageName = 0xffff91889adea688 "\Windows\System32\msvcrt.dll", void * ProcessId = 0x00000000000020ac, struct _IMAGE_INFO * ImageInfo = 0xffffe08f1ba676c0)+0x23 [c:\working\injdrv\injlib.c @ 1340]
0a ffffe08f1ba675b0 fffff802bd7f19f4 nt!PsCallImageNotifyRoutines+0x12e
0b ffffe08f1ba67610 fffff802bd7a1721 nt!MiMapViewOfImageSection+0x734
0c ffffe08f1ba67790 fffff802bd7a0e7b nt!MiMapViewOfSection+0x3c1
0d ffffe08f1ba678e0 fffff802bd45b143 nt!NtMapViewOfSection+0x12b
0e ffffe08f1ba67a10 00007ff9f867aea4 nt!KiSystemServiceCopyEnd+0x13
0f 00000070e8c7e6e8 0000000000000000 0x00007ff9`f867aea4
Checking the source code I found that it is in:
PINJ_INJECTION_INFO
NTAPI
InjFindInjectionInfo(
In HANDLE ProcessId
)
{
PLIST_ENTRY NextEntry = InjInfoListHead.Flink;
while (NextEntry != &InjInfoListHead)
{
PINJ_INJECTION_INFO InjectionInfo = CONTAINING_RECORD(NextEntry,
INJ_INJECTION_INFO,
ListEntry);
if (InjectionInfo->ProcessId == ProcessId)
{
return InjectionInfo;
}
NextEntry = NextEntry->Flink;
}
return NULL;
}
It only happened once.
What could be the cause of the problem?
Maybe the page fault while in the function for memory that should not be paged?
Hello,
The InjMethodThunk method is failing on Win7 x64 (both updated 6.1.7601.24387 ntdll.dll and non updated 6.1.7601.17514) when loading a wow64 process. All native x64 processes are loaded and injected fine.
This leads to an access violation error.
Some debug output:
The original shellcode looks broken for me. I've updated it with the following one (but still failing):
0x83, 0xec, 0x0c, // sub esp,0xc
0x0f, 0xb7, 0x44, 0x24, 0x18, // movzx eax,[esp + 0x18]
0x66, 0x89, 0x04, 0x24, // mov [esp],ax
0x66, 0x89, 0x44, 0x24, 0x02, // mov [esp + 0x2],ax
0x8b, 0x44, 0x24, 0x14, // mov eax,[esp + 0x14]
0x89, 0x44, 0x24, 0x04, // mov [esp + 0x4],eax
0x8d, 0x44, 0x24, 0x08, // lea eax,[esp + 0x8]
0x50, // push eax
0x8d, 0x44, 0x24, 0x04, // lea eax,[esp + 0x04]
0x50, // push eax
0x6a, 0x00, // push 0x0
0x6a, 0x00, // push 0x0
0xff, 0x54, 0x24, 0x20, // call [esp + 0x20]
0x83, 0xc4, 0x0c, // add esp,0xc
0xc2, 0x0c, 0x00, // ret 0xc
0:000> g
ModLoad: 0000000077a10000 0000000077b2f000 WOW64_IMAGE_SECTION
ModLoad: 0000000076190000 00000000762a0000 WOW64_IMAGE_SECTION
ModLoad: 0000000077a10000 0000000077b2f000 NOT_AN_IMAGE
ModLoad: 0000000077910000 0000000077a0a000 NOT_AN_IMAGE
(b6c.eb4): WOW64 breakpoint - code 4000001f (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
00010000 cc int 3
0:000:x86> u
00010000 cc int 3
00010001 83ec0c sub esp,0Ch
00010004 0fb7442418 movzx eax,word ptr [esp+18h]
00010009 66890424 mov word ptr [esp],ax
0001000d 6689442402 mov word ptr [esp+2],ax
00010012 8b442414 mov eax,dword ptr [esp+14h]
00010016 89442404 mov dword ptr [esp+4],eax
0001001a 8d442408 lea eax,[esp+8]
0:000:x86> dd esp L8
0018fd08 77d0007d 77d2eaea 00010032 00000062
0018fd18 00010003 00000000 00000000 00000000
0:000:x86> ln poi(esp)
(77d00058) ntdll32!KiUserApcDispatcher+0x25 | (77d000a0) ntdll32!KiUserCallbackExceptionHandler
0:000:x86> du poi(esp+8)
00010032 "C:\Users\tant\Desktop\bin\x64\De"
00010072 "bug\injdllx86.dll"
Before calling LdrLoadDll, the stack seems having the correct arguments:
00010028 ff542420 call dword ptr [esp+20h] ss:002b:0018fd0c={ntdll32!LdrLoadDll (77d2eaea)}
0:000:x86> dd esp LC
0018fcec 00000000 00000000 0018fcfc 0018fd04
0018fcfc 00620062 00010032 00000000 77d0007d
0018fd0c 77d2eaea 00010032 00000062 00010003
Where:
PVOID BaseAddress == 0x0018fd04;
DllName.Length = (USHORT)SystemArgument2 = 0x0062;
DllName.MaximumLength = (USHORT)SystemArgument2 = 0x0062;
DllName.Buffer = (PWSTR) SystemArgument1 = 0x0018fcfc;
Then an access violation occurs in RtlEqualUnicodeString
0:000:x86> g
(b6c.eb4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll32!RtlEqualUnicodeString+0x10:
77d1e8cb 0fb732 movzx esi,word ptr [edx] ds:002b:00000024=????
With the following call stack:
0:000:x86> kp
ChildEBP RetAddr
0018fa14 77d2bc57 ntdll32!RtlEqualUnicodeString+0x10
0018fa34 77d2e737 ntdll32!LdrpFindLoadedDllByName+0x9d
0018fb1c 77d2e946 ntdll32!LdrpFindOrMapDll+0x1e5
0018fca8 77d6d3df ntdll32!LdrpLoadDll+0x2d6
0018fce4 0001002c ntdll32!LdrLoadDll+0xc7
WARNING: Frame IP not in any known module. Following frames may be wrong.
00000000 00000000 0x1002c
It seems that RtlEqualUnicodeString is getting invalid arguments:
0:000:x86> dd ebp L8
0018fa14 0018fa34 77d2bc57 0018fb70 00000024
0018fa24 00000001 00000000 00000002 00000000
0:000:x86> dd poi(ebp+8) L2
0018fb70 00620062 00010032 <== this is our DllName struct
0:000:x86> dd poi(ebp+c) L2
00000024 ???????? ???????? <== this is a broken UNICODE_STRING, coming from somewhere.
I've encounter in image validation error while trying to inject dll from slightly different version of injdrv where the injection timing is on creation of new thread (so that processes that existed before the driver is loaded could be injected as well - assuming new alertable threads will be created on them).
Anyhow, it seems that although the dll is signed, it fails on signing issue (perhaps mismatch between processes executable file and dll signatures)
here's the stack trace from the context of the injected processes after initial injected code tried to call ldrloaddll
[0x0] CI!CipReportAndReprieveUMCIFailure + 0x563
[0x1] CI!CiValidateImageHeader + 0xbdb
[0x2] nt!SeValidateImageHeader + 0xd6
[0x3] nt!MiValidateSectionCreate + 0x436
[0x4] nt!MiValidateSectionSigningPolicy + 0xa6
[0x5] nt!MiValidateExistingImage + 0x12e
[0x6] nt!MiShareExistingControlArea + 0xc2
[0x7] nt!MiCreateImageOrDataSection + 0x1a3
[0x8] nt!MiCreateSection + 0xf4
[0x9] nt!MiCreateSectionCommon + 0x1ff
[0xa] nt!NtCreateSection + 0x60
[0xb] nt!KiSystemServiceCopyEnd + 0x25
[0xc] ntdll!NtCreateSection + 0x14
[0xd] ntdll!LdrpMapDllNtFileName + 0x136
[0xe] ntdll!LdrpMapDllFullPath + 0xe0
[0xf] ntdll!LdrpProcessWork + 0x74
[0x10] ntdll!LdrpLoadDllInternal + 0x13e
[0x11] ntdll!LdrpLoadDll + 0xa8
[0x12] ntdll!LdrLoadDll + 0xe4
the process is image is spawned from dllhost.exe and it's not revealed as protected as one might thing ...
Any idea what can lead to this error ?
thanks
Hi,
I've got a question regarding the usage of the undocumented method PsWrapApcWow64Thread
that is used to support regular 32bits normalRoutines to wow64 processes.
Basically i've used your project with replacing the section memory allocation with ZwProtectVirtualMemory
for user-space memory allocation on the context of the process I wish to inject to. I'm using VM of windows 10 RS5.
reading the memory from winDbg, the candidate NormalRoutine function looked pretty much like a normal function in assembly code :
0: kd> u 0x00000000`00880000
00000000`00880000 55 push rbp
00000000`00880001 8bec mov ebp,esp
00000000`00880003 83ec1c sub esp,1Ch
However, after calling the method PsWrapApcWow64Thread
with this function I got the following wrapping :
0: kd> u 0x00000000`00880000
00000000`00880000 ac lods byte ptr [rsi]
00000000`00880001 d24df0 ror byte ptr [rbp-10h],cl
00000000`00880004 4d8ce3 mov r11,fs
00000000`00880007 e8fc000000 call 00000000`00880108
00000000`0088000c 00c7 add bh,al
00000000`0088000e 45ec in al,dx
00000000`00880010 0000 add byte ptr [rax],al
First, i thought that the original function was relocated to address 00880108
, but when i read this section in memory i got all zeros
0: kd> dd 00000000`00880108
00000000`00880108 00000000 00000000 00000000 00000000
00000000`00880118 00000000 00000000 00000000 00000000
00000000`00880128 00000000 00000000 00000000 00000000
00000000`00880138 00000000 00000000 00000000 00000000
...
So it seems that the wrapping cause the code to jump to "zeroes" code.
Any idea what went wrong ?
Is it possible to inject any dll? I try to inject my dll and gives an error: "the entry point to the interlockedincrement procedure was not found"
how to use IoAllocateMdl in injdllx64.dll?thank you again.
how to inject iphlpapi.dll?
So I would like to know if there is a way (as a driver) to see and detect when another process creates a thread in my process. This is for a notification to my process to update itβs internal thread counter that I put in place for the fun of it (or to tell the process to exit upon the call to CreateRemoteThread to my process).
I also would like to figure out to have my program init, and unit my driver upon closing and to feed data to/from it. If anyone here knows how that is done and how some well know online game anti-hacks do it with a dll and a device driver to detect suspicious programs running, debuggers, etc.
I use InjMethodThunk to cause the wow64 process to fail to start, but when I use InjMethodThunkless, I can inject 64-bit DLL into the wow64 process, but loading 32-bit DLL in this 64-bit DLL will fail.
Currently, the mini-filter is registered by injldr.exe. Move this registration to injdrv.
Hi wbenny,
Thanks for your work. I test injdrv in Win7, it works perfectly. However, in win10, it will cause some wow64 process crash. For example, the "cl.exe" comes from visual studio 2013. It will crash at launch, the dll didn't load into the process space.
ModLoad: 74ce0000 74d05000 C:\WINDOWS\SysWOW64\IMM32.DLL
(4c4.3608): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00010000 ebx=00a89000 ecx=00010000 edx=77312790 esi=00000001 edi=0105f8dc
eip=00010000 esp=0105f8c8 ebp=0105fc04 iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
00010000 0000 add byte ptr [eax],al ds:002b:00010000=00
It seems it crashes in the first line of the shellcode. Any ideas? Thanks.
Line 24 in a8dadf4
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.