Open blshkv opened 6 years ago
ok, it is complicated. The issue is with .so shared library which is provided within each binary and it is different for each platform. I would be happy to compile frida-core or whatever required package but it is fails with latest capstone (and may be other libs). I'm basically hitting the old bug https://github.com/frida/frida/issues/130 or https://github.com/aquynh/capstone/issues/757
We do this to work around PIP's lack of support for prebuilt binaries. The .egg
format supports this, so our setup.py
downloads the .egg
and extracts the prebuilt binding pretending it just built it. It's a pretty nasty hack.
I would however not recommend building Frida without Frida's forks of the upstream dependencies, especially GLib which we've patched to support dynamic unloading, fork()
-handling, and more. We have also patched libffi
with custom API to be able to keep track of the pages it allocates, so we can hide them from Process.enumerateRanges()
and similar APIs. This is important for Frida-based memory dumping tools, that don't want to deal with "noise" from Frida's own allocations.
By the way, there's a fallback where we look in the home-directory for the prebuilt .egg
if the download fails. It's not great, but perhaps we could come up with a better workaround until somebody volunteers to do proper packaging.
ok noted on the customisation part. That make sense, will not try to use system tools anymore.
Regarding prebuilt binaries, I can suggest to create frida-bindings package which would only distribute python code and call a system .so library installed by a relevant package (frida-core?). For example, radare2-bindings
or nfqueue-bindings
are designed in this way and it worked well for everybody.
The fallback is exactly the way how I patched it now. But I had to remove network part so that it won't try to connect and not to raise a warning since there is no offline
option
I see you decided in #38 not to use wheels because PyPI didn't support Linux wheels at the time. That restriction has now been lifted (https://github.com/pypa/manylinux/), so you might want to revisit the idea.
We have discovered that the tool downloads its dependencies during installation. This is a typical behavior of malicious software and is getting blocked in a sandbox environment such as Gentoo portage. So we have to remove the tool (https://github.com/pentoo/pentoo-overlay/commit/f40dd2afeb952e02897371a6f1384e4212f37050).
Please add requirements.txt file with all dependencies and verify them before installing it on your own.