-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Capstone/Keystone vs. Binutils #683
Comments
It would be nice to not require cross binutils for doing something common like |
@C0deH4cker: It does not require cross-binutils for native architecture, currently. See here. |
Unless you're using a Mac and don't have binutils installed by default ;)
|
Mac OS is not a supported configuration for pwntools. Anything that works
|
Interesting, I never realized that. Well I'm happy to say that pwntools works for me on macOS for everything I've tried so far (even cross binutils).
|
I would like to ask if there is a plan to use Capstone/Keystone to replace Binutils? It can be more convenient when using a Linux which can't install cross-binutils with apt, such as Archlinux. If so, I can try to contribute some code. |
No, because we still need binutils to actually build / link ELF files
…On Tue, Oct 17, 2017 at 8:27 AM Firmy Yang ***@***.***> wrote:
I would like to ask if there is a plan to use Capstone/Keystone to replace
Binutils? It can be more convenient when using a Linux which can't install
Binutils with apt, such as Archlinux. If so, I can try to contribute some
code.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#683 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAG0GGfyn8KljI7pMNQBLbTAnwUPzEc4ks5stKtWgaJpZM4JqZb7>
.
|
Using keystone as a backend assembler for |
I'd be glad to support the changes, but don't have time to implement them currently. Contributions would be greatly appreciated! |
FYI, pwntools-ruby uses Keystone/Capstone for asm/disasm |
Good to know! Unfortunately it looks like it’s missing the entire
shellcraft module — which is the bulk of the backward compatibility issue.
On Fri, Jun 22, 2018 at 1:46 AM david942j ***@***.***> wrote:
FYI, pwntools-ruby <https://github.com/peter50216/pwntools-ruby> uses
Keystone/Capstone for asm/disasm
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#683 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAG0GOW6tCXjeF7Mdw2EPUYBt2MpdMGAks5t_JLAgaJpZM4JqZb7>
.
--
*Zach Riggle*
|
👋 Hi, Homebrew-core maintainer here. FYI, binutils is fairly broken on macOS due to upstream. Also, is pwntools for macOS still not officially supported? Having binutils on the system path breaks compilation with GCC as of macOS 10.14 (Mojave) and/or XCode 10. Specifically GCC ends up trying to invoke During this process I attempted to upgrade pwntools from 3.12.0 to 3.12.1 because the build was failing and, after checking the release notes, I thought after a completely cursory inspection of the build logs that #1191 and #1198 might be to blame for the failure. After a version bump to 3.12.1 the pwntools formula is still failing, however, with undefined symbols at link time. If folks in your community enjoy having pwntools available through homebrew, a PR on Homebrew/homebrew-core with a version bump and resolution of the build failures would be much appreciated. For your reference, it seems that a number of people like installing pwntools this way: ==> install_on_request (30 days)
==> install_on_request (90 days)
==> install_on_request (365 days)
|
FYI, here is a link to the last 1MB worth of log for the build failure: https://jenkins.brew.sh/job/Homebrew%20Core%20Pull%20Requests/32547/version=mojave/testReport/brew-test-bot/mojave/install_pwntools/ |
Pretty sure we're gonna stick with binutils for the forseeable future. Modern Ubuntu distributions ship binutils for all Pwntools-supported architectures, without using a PPA. |
We should investigate using the Capstone disassembler and Keystone assembler, instead of shelling out to Binutils. This would streamline the installation process for foreign architectures and OSes.
This would probably be a major-version-bump type feature, since it likely breaks backward compatibility.
However, we will still have some dependencies on Binutils for generation of fully-functional ELF files -- unless we want to generate those ourselves. Since the ELFs that we emit are very minimal, this should not be particularly difficult.
The biggest thing that we lose is that there are no longer symbols to aid shellcode debugging when using
make_elf_from_assembly
. However, I expect that nobody knew that you could have debugging symbols except me, so that's probably moot point.The text was updated successfully, but these errors were encountered: