Closed EONRaider closed 2 years ago
Perfect! Thanks! 🎊
Glad it worked. Is the project open to contributions to the code base itself?
I think there may be a thing or two I can help with.
In fact, this tool could do more than just mapping the scheme but also proceed to exploitation.
It's a privilege for me to receive your contributions and suggestions. Let's discuss your ideas! We can do it in a new issue, in Twitter (@_nikitastupin
) / Telegram (@nikitastupin
) DMs or even right here!
I personally favor "do one thing and do it well" approach in programming. In this way a program becomes a building block for users. Users can then use a combination of programs that fits their needs the best, without a need to implement the same thing. There are other pros as well as cons to this approach.
It was an approach I've chosen for clairvoyance (at least "do one thing" part). One can use clairvoyance for the case when Introspection is disabled, obtain a schema and then use this schema with any other tool you want.
So I see at least three options here:
Anyways I suggest to discuss your ideas and then make a decision 😃
That's nice. I think this one is a good approach:
* To split clairvoyance to importable module and CLI. Thus any other project can import clairvoyance as a module and benefit from not implementing the same thing from scratch. Specifically, you may start a project that combines your ideas and clairvoyance.
It would be necessary to somehow structure the application to allow it to be pushed to PyPI as a library. With that all one would need to do is to pip install clairvoyance
and use it.
This presents a challenge in architecture, though. From what I could get from the code I noticed that it doesn't have an entry point yet and it couples quite heavily the use case of the CLI to the code itself. I'll find a way around this. It's been some time since I wrote a library but I can manage it.
I'll read the code thoroughly and do a first PR just fixing formatting and maybe adding more specific function and class signatures. It's not a refactoring as it won't be intended to modify any functionality. This way I can understand each line before trying to modify anything.
In the long run, after having this tool zeroed in, we can maybe start another project that expands into exploitation too.
Great! Let's try it 😄
If you'll have any questions regarding the code you can ask me and I'll do my best to provide an answer. There is also https://github.com/nikitastupin/clairvoyance/wiki/Development page that describes the project a little bit (mostly theoretical though).
I suppose there is also a quick-and-dirty way to decouple CLI and the code: we can wrap (with some modifications) this https://github.com/nikitastupin/clairvoyance/blob/main/clairvoyance/__main__.py#L77-L113 code to a function and this function together with oracle.py
and clairvoyance.py
will become a library. However, I'm not sure that it'll work. Moreover, it'll be really great to give my spaghetti code a better shape because it is a major obstacle to improvements (e.g. #15 was really hard to do and not yet finished).
Add instructions for usage with Docker image