How to inject dll from kernel mode driver ?
Share the source code.
Thank You.
Tsubasa Ryuu
you can use APC
Why? What is you are trying, or wanting, to do? What DLL? What driver?
Gary Little
H 952 2231349
C 952 4544629
xxxxx@comcast.net
On Jul 26, 2011, at 5:34 AM, xxxxx@hotmail.com wrote:
How to inject dll from kernel mode driver ?
Share the source code.Thank You.
Tsubasa Ryuu
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
i am writing another process monitor tool. i need to execute my code in context of another process. the best way to do this is to write a driver as main module and dll module with inject code. another part is user interface module which communicate with driver. dll injection is legal way if i do not change the
execution of another process. i think thats ok.
thank you.
tsubasa
Short answer: DON’T DO THAT.
Long answer: tell us why you think you need that, and we help you to find a proper solution instead of DLL injection.
but how to execute my code in context of another process?
D-Pin Purr working with dll injection.
What do you intend to do in the DLL? It may be possible to do the work
in the kernel proper. Give us an idea of what you are looking for,
injecting a DLL is a bad idea.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@hotmail.com” wrote in message
news:xxxxx@ntdev:
> but how to execute my code in context of another process?
Do not use such a mechanism. This is completely unsupported and may stop working without notice. (Why would you think that fields within internal kernel data structures would be at fixed offsets for all time, or that prototypes for internal undocumented kernel APIs would never change over time?)
- S (Msft)
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, July 26, 2011 4:32 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Dll injection from driver
you can use APC
http://binhong.wordpress.com/2007/09/24/hack-for-user-apcs/
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
D-Pin Purr injects dll using apc’s.
tsubasa
And has been pointed out totally undocumented and subject to change.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@hotmail.com” wrote in message
news:xxxxx@ntdev:
> D-Pin Purr injects dll using apc’s.
>
> tsubasa
They are not likely to change, because then the kernel team might have to change some other stuff which happens to think they are at fixed offsets.
Skywing wrote:
Do not use such a mechanism. This is completely unsupported and may stop working without notice. (Why would you think that fields within internal kernel data structures would be at fixed offsets for all time, or that prototypes for internal undocumented kernel APIs would never change over time?)
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
xxxxx@hotmail.com wrote:
i am writing another process monitor tool. i need to execute my code in context of another process. the best way to do this is to write a driver as main module and dll module with inject code. another part is user interface module which communicate with driver. dll injection is legal way if i do not change the
execution of another process.
Why do you need to do this from a kernel driver? If you are running a
process to do the process monitoring, just have that process do the
injection. It’s easy for one process to inject a thread into another
(assuming you have permission). That’s what window hooks are all about.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
So far, this thread is winning the “Dumb Thread Of The Week” award.
I’m not sure what that means, but if it means “fixed offsets into very common structures are not likely to change”… it is VERY wrong.
NOBODY in the core team that I know or have ever met, appreciates ANYBODY (internal or external to MSFT) fooling with their private structures… and that’s even when those people doing the messing are using symbolic offsets. And, in my experience, they appreciate it even LESS when people depend on fixed offsets into structures.
And I can tell you from experience that fixed offsets into structures do indeed change. Structures get reorganized, fields get added, fields get removed. You need to look no further than the EPROCESS for a good example of this.
OP… if you’re trying to do something legitimate, do it in a reasonable, supportable, and legitimate way. If you’re trying to write malware, go to another list somewhere.
Peter
OSR
This is incorrect. When we build the OS, internal code references easily updateable header definitions (as any other C code would). Internal data structures can and do change over time. You cannot rely on poking at fixed offsets into internal data structures like this as the OS definitions may change without notice (nor is there every any guarantee that internal API prototypes will remain fixed for all time).
- S (Msft)
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
Sent: Tuesday, July 26, 2011 9:29 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Dll injection from driver
They are not likely to change, because then the kernel team might have to change some other stuff which happens to think they are at fixed offsets.
Skywing wrote:
Do not use such a mechanism. This is completely unsupported and may
stop working without notice. (Why would you think that fields within
internal kernel data structures would be at fixed offsets for all
time, or that prototypes for internal undocumented kernel APIs would
never change over time?)
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com) http://www.alfasp.com File system audit, security and encryption kits.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Err … why on earth would the kernel team care about buggy unsupported
“other stuff” which used such a ridiculous technique?
Dejan Maksimovic wrote:
They are not likely to change, because then the kernel team might have to change some other stuff which happens to think they are at fixed offsets.
Skywing wrote:
> Do not use such a mechanism. This is completely unsupported and may stop working without notice. (Why would you think that fields within internal kernel data structures would be at fixed offsets for all time, or that prototypes for internal undocumented kernel APIs would never change over time?)
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
On 07/26/2011 08:44 PM, Skywing wrote:
Internal data structures can and do change over time. You cannot
rely on poking at fixed offsets into internal data structures like
this as the OS definitions may change without notice (nor is there
every any guarantee that internal API prototypes will remain fixed
for all time).
There are reasons why MS might even deliberately change “internal” data
structures:
(a) for security reasons, to prevent malicious software (ab)using fixed
references to internal structures
(b) for QA, to make sure nobody in-house inadvertently used fixed
references to internal structures.
FWIW, in x64 build, KeQueryTickCount is implemented via using a hardcoded offset in USER_SHARED_DATA area. This means _KUSER_SHARED_DATA will never shange.
Just so we’re clear, I’m not advocating Dll Injection, as it doesn’t present a way that is hard to circumvent. On the other hand, neither does an
antivirus. If I install a specific filter, I can remove the AV engine completely from the stack and do whatever I want.
AVs have and still use Dll Injection and some even worse stuff to do what they do. I’ve had a similar opinion as most on this list: “There’s always a
better (documented) solution/workaround”. But I came to figure that there will always be those who don’t do it that way, and there are cases where you can do
it the undocumented way or tell the customer to hire someone else - which they will gladly do, and make sure everyone else hires someone other than you 
IOW, unless someone asks “how to detect a file copy” BS question again, I’ll either help or not bother trying to steer them in the right direction. One it
wastes my time, and two it won’t deter them from asking the same on another list and doing it “their” way.
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
It doesn’t mean all of SHARED_USER_DATA will never change.
- S (Msft)
From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] on behalf of xxxxx@broadcom.com [xxxxx@broadcom.com]
Sent: Wednesday, July 27, 2011 1:25 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Dll injection from driver
FWIW, in x64 build, KeQueryTickCount is implemented via using a hardcoded offset in USER_SHARED_DATA area. This means _KUSER_SHARED_DATA will never shange.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer