-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Full in-memory loading (Feature request) #10
Comments
Hi! Thanks for reaching out, I really like your work and I'm following for a while.
Having said that, your project could be a nice feature to add, along with an OPSEC warning maybe, so that users can choose which way to walk (inject pyds with MM, drop or load from UNC). Cheers, |
Quick update to this, I just released a new POC that I'm working on called pythonmemimporter, which I've found a way to load python modules with raw python using just a function pointer to a python pyd's init function (loaded with pythonmemorymodule). I have some local code where I've gotten this working with several package's pyd, aside from one which is my pyclrhost module. So because this uses your pythonmemorymodule, it should be able to do whatever memory protections you're providing with that. Let me know your thoughts on that. |
I should also say, it's not currently integrated into my od_import package officially, but I have tested imports with it for things like lazagne (using pycrypto) |
Hey, this looks great! |
Let me know if/when you need help on something. I do have another repo that I should be releasing soon that will replicate my pyclrhost functionality with raw python as well. So CLR hosting without the need of any compiled code. In this instance it wraps a custom clr-loader netfx binary so that you can interact with pythonnet through COM. |
Which version of python are you using? |
Sorry, also which pyds have you tried, that way I can test locally |
I am debugging using 3.11.3 embedded, but got same behaviour with 3.10.9 embedded. I am trying to import the pyds used by LaZagne: r"/Cryptodome/Cipher/_raw_cbc.pyd", however, the issue appears from the starting item in the list r"/Cryptodome/Cipher/_raw_ecb.pyd". |
Okay, so that's actually normal. The way they handle those pyds in Crypto and Cryptodome is different. They don't use the normal import mechanism because they're pyds in name only. So for those I do have some other stuff I do in od_import to make them work. Namely function stomping some of the cffi functions. If you check out my dev branch for od_import I handle them in the hooks.py |
If you wanted to give me some requirements I could add some features to make od_import suite your use case instead of having to reinvent the wheel. I know you have some stuff that you do with encryption/XOR , if I remember correctly at least. If you want to try out od_import with the pythonmemimporter support that's in the dev branch and I'd be more than happy to add an obfuscation engine to it, it's been on my roadmap for a bit anyway. |
the base case we can work on is on getting LaZagne pyds to just load so that after the loading process we can access their functions. In the script below that I used for testing I was downloading the pyds from a simple http.server and tried to import with pythonmemimporter. Once we can make a base case like this work, the main goundwork for getting it into Pyramid should be done. Could you help in getting this base case working? Thanks!
|
I saw that in od_import you are using different transports for delivery. While I think this is cool, in Pyramid I am keeping the transports separated in cradle and in modules. The cradle should be as simple as possible and for this reason I am not importing anything into it. This brings of course limitations, but that's a way to try and keep things loosely coupled. I think the only other delivery methods that are worth implementing beyond HTTP/S is DNS and ICMP and that would require different cradles and modules in order to keep things separated and don't bake constraints into the Pyramid process. |
Whew, that was a bit to digest, hopefully I can address all the points: I also did a refresher of the pyramid code and what od_import could potentially do is be a drop-in for your import hook you define in your modules (at it's heart that's what od_import is). There would be some changes I'd have to make on the od_import side to add functionality for handling your XORing/chacha. On the point of using window's libraries, I actually have the beginnings of a wrapper for the winhttp library that I've had mostly finished (great minds think alike, I suppose) for several months and done some testing with, but just hadn't made public yet; which I could implement as another option that could be used in the http handler. Finally, on this issue of pythonmemimporter and pycrypto/pycryptodom, pycrypto(dome) doesn't use the normal python import mechanism, which is why I have a custom patch that is implemented in od_import. They use cffi to do the import of that. That is actually why pythonmemimporter has a dlopen function is for use by the functions I stomp over the cffi functions which do the dlopen calls. I look forward to hearing your thoughts on all of those, regards. |
As an update to the third item I touched on, over the weekend I went ahead and finished my winhttp wrapper and implemented it into od_import, so all requests with that import hook can use winhttp now. |
--Shameless plug warning--
I have recently released a memory importing tool that can import both normal python (.py) and python c extension (.pyd) files fully from memory.
--End shameless plug--
With this new functionality, if it isn't too difficult to implement it into this projects structure, you could potentially drop the zip requirement from this project. Feel free to close if that would be needlessly complex or the interest isn't there. If you are interested, the project is https://github.com/rkbennett/od_import.
The text was updated successfully, but these errors were encountered: