Skip to content
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

Refactor bindings to use an external bindings library #15

Open
twizmwazin opened this issue Mar 29, 2023 · 0 comments
Open

Refactor bindings to use an external bindings library #15

twizmwazin opened this issue Mar 29, 2023 · 0 comments

Comments

@twizmwazin
Copy link
Member

twizmwazin commented Mar 29, 2023

Description

Currently pysoot's architecture involves the Python (3) library communicating with a Python (2) program running in Jython, in a JVM along with soot. This is less than ideal, especially considering python 2 has been sunset for a while now. To address this, pysoot needs to be refactored away from this architecture.

I've taken a very brief look at what the state of java to python bindings are, and unfortunately it doesn't seem great. However, the library Py4J does seem promising! An implementation based around Py4J would still depend on an external JVM, but it would allow us to ditch our own communication code and replace it with a small java program. I might be too optimistic, but the python side should also be mostly just be adapting the exposed Java types into something ergonomic from Python.

Alternatives

Someone with more experience using java libraries in Python might know how to do this better. If that's you, please get in touch!

Another option is to consider replacing Soot with SootUp, a new library intended to succeed Soot.

Lastly, pypcode also nominally supports lifting JVM bytecode! I'm not aware if anyone has tested this support, but it might also be a suitable replacement for pysoot for some use cases. If anyone gives this a test, feedback would be super cool.

Additional context

Right now improving and modernizing pysoot is not a high priority for the angr team. We're looking for community members who would be interested in undertaking this effort.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant