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
Framework Native/Universal build for Apple Silicon (x86_64 & arm64) #17628
Comments
It doesn't look like your platform even fully supports Ruby yet. Take a look at the |
In the same issue as above it says it was fixed in Ruby 3.1.3 and anyways metasploit-framework is run on Ruby 3.0.5 as suggested by the .ruby-version file which works fine on Apple Silicon.
So I did bundle install with Ruby 3.0.5 and everything installed without any warnings or errors. I don't know if thats what you mean by that statement.
I agree with Linux but I try to use my mac as an All in One kind of a solution. Anyways, so I took a close look at the link provided and its contents. I don't think we can come to the conclusion that Apple is scanning files and sending data back to its servers just by a call to an API. mediaanalysisd is probably downloading classifier or other AI models or something else but it doesn't suggest that its scanning files and sending data back in any way. I could be wrong but the author of that article also doesn't back it up with wireshark data which might suggest that its true. If you look in the comments, a lot of people who have done a little more digging also don't think thats true. |
Any timeline for this yet? |
Does that mean you were using the Ruby interepreter native to your architecture with native extensions built, or that you used the x86_64 |
Yes, its native. I installed Ruby 3.0.5 from rbenv, bundle install worked fine. Tried it with Homebrew Ruby (ruby@3.0) as well, no warnings or errors. Rosetta2 is not being used since both Ruby installations were compiled for arm64 arch which is native for Apple Silicon. |
If that works, then at least for the time being, you should be able to run Metasploit from source on native binaries executing the Ruby scripts. Rather surprised that everything compiled as intended both due to the architecture and platform quirks - thats quite a win. |
Thats what I have been doing since a year but wanted to see a pkg installer file for easy maintenance. Are there any issues adding an M1 build in your macOS automation for building pkg files?
That is true and here is the log for environment, build and run: Environment
Build
msfdb and msfconsole initial run
|
Thanks for the detailed log outputs - nice of |
Please review the above PRs |
Since now all PRs have been merged, native compilation and build part has been finished. @jmartin-r7 @sempervictus Can the new packages with arm64 support be officially released? Also be updated on osx.metasploit.com? |
@Ishaanahuja7 - thank you for the kindness in over-scoping my role, but i'm merely a community contributor 😄 |
Official installers will take at least a few weeks or more. Testing worked out the requirements, however work still needs to be done to get the build process codified into our infrastructure and maintained before we can added to our publishing process. |
Any updates? @jmartin-r7 |
@Ishaanahuja7 I appreciate the ping, Official installers are still on the todo list. Earliest is still likely to be end of August. |
Is the progress still ongoing for the official installers? Just wanted to get an idea about the release cadence for this. |
@Ishaanahuja7 - rapid7 had a layoff round this month, might result in all sorts of timetables being pushed out |
@sempervictus Thats said to hear... Looks like not before another couple months they will get this checked off. Hopefully sooner |
You never know... however, framework is FOSS so if you can wire up the pull request to build releases for the arch it would get the ball rolling leaving their team with "only" the QA/integration effort (I may be smitten for my word choice there, and if I am, its well deserved after the PRs they recently landed). |
For visibility - this isn't something that's actively being worked on right now; I'm not sure where this was left off unfortunately |
Hey any news here? |
Unfortunately reworking automation to support these in nightly builds is not high priority. I will research to determine if the requirements for this build can be met using the recently released github actions M1 runners as I believe the If github actions can support this the project may be able to add signing and distribution more easily than jumping thought the hoops required to build for M1 in the current pipelines. |
How about cross compiling? |
Per the omnibus-toolchain/README.md:
While it may be possible to convince the env to report values that would enable clang to cross compile it would likely require significant divergence from existing omnibus tooling. |
So any update if github actions runner can be used here? @adfoster-r7 |
@Ishaanahuja7 There's still no updates for official nightly OSX ARM installers; However everything should work in a Kali ARM VM running on your OSX host, or there's now added support for amd64 and arm64 builds for Docker too - https://hub.docker.com/r/metasploitframework/metasploit-framework/tags |
Any updates on this yet? |
No updates to report; Only the docker image is available as pre-built arm64 environment - there's been no cycles spent looking at arm64 omnibus builds. Some cycles were spent on using Github actions to build omnibus on windows/unix environments thouugh, just not with the m1 builders |
Summary
Support Universal build for macOS (x86_64 and arm64). If Universal cannot be done, then provide arm64 installer pkg file in addition to x86_64.
I did a complete dev environment setup of metasploit-framework described here on my M1 Max and it was successful. I don't know if there is a script for running tests to check everything but seems to be working with initial testing of like msfvenom, msfconsole session from macOS -> Windows 10, and msfdb.
Motivation
Running over Rosetta is really slow even on an M1 Max. Providing Universal or arm64 binaries would definitely speed up the framework.
The text was updated successfully, but these errors were encountered: