Closed Bix3 closed 5 months ago
It means injecting shellcode into an existing code cave and then running it.
Dll injection over DMA (without first touching target system file system) is much more complex. I'm not going to say never, but it's not something I'm working on at the moment.
ok. thank you for your answer. Pcileech is a great project : )
Thanks, just a question, would dll injection still be interesting if the .dll file could touch disk on the target system? possibly it could be dropped in normally applocker restricted dir such as system32 and then loaded by your targeted process?
Yes, it would still be interesting. it doesnt need to be fully remote : )
Dropping the file to the file system may be done remotely fairly easy (inject in admin user-mode process and let that one write .dll file). Then inject a small shellcode which just do LoadLibrary inside your targeted process - it avoids me having to code a loader for completely diskless :)
I may look into this later this fall.
sadly LoadLibary is actually traced/traced by some processes, ManualMapping would be interesting! I will maybe make some code for that.
Agree that fileless with your own custom loader would make much more sense, but it's also a much bigger undertaking code-wise and time-wise.
Isnt it just allocating a buffer writing the DLL and make a pid based hook Shellcode?
No. You will have to account for things like relocations, import/export tables, dependencies (that may have to be loaded) and so on. It's a quite complex process unfortunately.
Well yeah, you could manual import, but that's not really a solution... Resolving Imports should be "pretty" easy tho. Import Table is stored in PE?
Ulf Frisk notifications@github.com schrieb am So., 28. Juli 2019, 17:34:
No. You will have to account for things like relocations, import/export tables, dependencies (that may have to be loaded) and so on. It's a quite complex process unfortunately.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ufrisk/pcileech/issues/98?email_source=notifications&email_token=AGM4KXGEG655QPJK7GC3KCDQBW4AJA5CNFSM4IHJ3QP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD27BADQ#issuecomment-515772430, or mute the thread https://github.com/notifications/unsubscribe-auth/AGM4KXCVSOMJCYGKBTY2YCDQBW4AJANCNFSM4IHJ3QPQ .
Would you accept a PR for full mapping with decent support (import resolution, deps, section reloc)? Happy to contribute.
Yes, I would, it would be super nice :) but depending on implementation.
I currently have the analysis functionality / parsing in the MemProcFS project - it's just mostly a matter of importing the .dll and then coding the injects against this - and you'll get full virtual memory support and a lot of other nice things that will make life a lot easier when writing the actual injects. Having a user-mode inject for cmd and file system access makes so much sense :)
The downside of the MemProcFS integration approach is that it will be Windows only (on the attacker side). The upside is that it will be very little code in PCILeech for it.
I'm wary of adding a lot of additional functionality into core PCILeech with regards to virtual memory support and PE parsing since that would mean massive amounts of code that would have to be maintained. But at the same time it would be beneficial if it would work on the Linux version as well.
I'm curious what you had in mind, if you already have something somewhat ready? Can you please drop me an email so we could talk more?
Yes, I already have the core functionality spread over quite a few projects throughout the years, but all in cpp so it'd be a matter of unifying it while porting to C. I haven't been keeping up to date on your project since before you split everything up and released 4.0 I believe, so I'll have to read through everything.
I will shoot you an email hopefully sometime this weekend, we can figure it out there.
@ufrisk
This is possible!
The end of .TEXT section in most PE files (exe/dll/sys/etc) always has slack space due to page alignment. Hence you have often 1000 bytes to play with, so do your little shellcode trickery in there, and swibble a pointer somewhere.
You could Alloc from there or overwrite a rwx module.
@arannothc yes, user mode injects will be quite easy to implement when integrating with the memory analysis capabilities of the MemProcFS library. It's mostly a matter of coding. Unfortunately it will be a Windows-only feature (on PCILeech side as well, since MemProcFS is Windows only).
Easiest would most probably be to use the code cave you mention to insert a small piece of shellcode that will allocate r-x and rw- pages (no rwx needed) in-process virtual memory. Then use DMA to write code into the payload proper into the r-x pages and use the rw- pages as a control channel back to PCILeech.
I'm working on some enhancements of MemProcFS right now, but when I'm done adding proper integration to PCILeech to achieve this will be a good idea.
@arannothc yes, user mode injects will be quite easy to implement when integrating with the memory analysis capabilities of the MemProcFS library. It's mostly a matter of coding. Unfortunately it will be a Windows-only feature (on PCILeech side as well, since MemProcFS is Windows only).
Easiest would most probably be to use the code cave you mention to insert a small piece of shellcode that will allocate r-x and rw- pages (no rwx needed) in-process virtual memory. Then use DMA to write code into the payload proper into the r-x pages and use the rw- pages as a control channel back to PCILeech.
I'm working on some enhancements of MemProcFS right now, but when I'm done adding proper integration to PCILeech to achieve this will be a good idea.
Hey, so I was looking into user mode injections and was wondering if this feature was ever implemented in PCILeech?
I never got around implementing it fully. I couldn't find a generic way of always gain code injection in all kinds of processes this way. Customizations always had to be made and I got busy with other things to do. This is an open source project and I've been providing a lot of things for free for a very long time. Things like this is quite a lot of work to implement...
In theory it's relatively simple though, (1) inject shellcode in a code cave. (2) patch function and redirect to shellcode (to hijack a thread and gain code execution). (3) do your stuff (ex: spawn new thread) and then clean up.
I'm closing this issue due to old age.
Hello, in the release notes is written that experimental feature user mode injects are added. Does that mean dll-injection?