Launch Chrome from ZAP results in x86_64 translated chrome which is very slow on Mac M1/ARM64

segevfiner commented 1 week ago

Describe the bug

When launching Chrome from ZAP, it launches chrome in x86_64 translated mode, instead of the native ARM64. This is despite ZAP being installed as ARM64 and it using an ARM64 chromedriver.

Steps to reproduce the behavior

Open ZAP ARM64 on M1/ARM64 Mac
Launch Chrome

Expected behavior

For it to launch Chrome as ARM64, it is slow to the point of being unusable otherwise.

Software versions

ZAP Version: 2.15.0

Installed Add-ons: [[id=alertFilters, version=21.0.0], [id=ascanrules, version=66.0.0], [id=authhelper, version=0.13.0], [id=automation, version=0.40.1], [id=bruteforce, version=16.0.0], [id=callhome, version=0.12.0], [id=commonlib, version=1.26.0], [id=custompayloads, version=0.13.0], [id=database, version=0.4.0], [id=diff, version=15.0.0], [id=directorylistv1, version=8.0.0], [id=domxss, version=19.0.0], [id=encoder, version=1.5.0], [id=exim, version=0.9.0], [id=formhandler, version=6.6.0], [id=fuzz, version=13.13.0], [id=gettingStarted, version=17.0.0], [id=graaljs, version=0.7.0], [id=graphql, version=0.24.0], [id=help, version=18.0.0], [id=hud, version=0.19.0], [id=invoke, version=15.0.0], [id=network, version=0.16.0], [id=oast, version=0.18.0], [id=onlineMenu, version=13.0.0], [id=openapi, version=41.0.0], [id=postman, version=0.4.0], [id=pscanrules, version=58.0.0], [id=quickstart, version=47.0.0], [id=replacer, version=18.0.0], [id=reports, version=0.32.0], [id=requester, version=7.6.0], [id=retest, version=0.9.0], [id=retire, version=0.36.0], [id=reveal, version=8.0.0], [id=scripts, version=45.4.0], [id=selenium, version=15.25.0], [id=soap, version=23.0.0], [id=spider, version=0.11.0], [id=spiderAjax, version=23.19.0], [id=tips, version=13.0.0], [id=webdrivermacos, version=91.0.0], [id=websocket, version=31.0.0], [id=zest, version=45.0.0]]

Operating System: Mac OS X Architecture: aarch64 CPU Cores: 10 Max Memory: 4 GB Java Version: Eclipse Adoptium 11.0.23 System's Locale: en_IL Display Locale: en_GB Format Locale: en_IL Default Charset: UTF-8 ZAP Home Directory: /Users/segevfiner/Library/Application Support/ZAP/ ZAP Installation Directory: /Applications/ZAP.app/Contents/Java/./ Look and Feel: FlatLaf Light (com.formdev.flatlaf.FlatLightLaf)

Screenshots

Errors from the zap.log file

No response

Additional context

This is the normal install of ZAP, using the bundled Java, I'm not sure where it could possibly be picking up anything x86_64...

Chrome is a universal binary.

Would you like to help fix this issue?

[ ] Yes

psiinon commented 1 week ago

ZAP will just pick up chrome from the default path, its not under our control. But you can set the correct path in the Selenium options: https://www.zaproxy.org/docs/desktop/addons/selenium/options/

segevfiner commented 1 week ago

It's the correct path. Chrome is a universal binary so has both x86_64 and ARM64 in the same binary. But something is causing it to launch Chrome in x86_64 mode. Like using the arch -x86_64 command to launch chrome. And it's unusably slow like that. Something along the way of launching chrome might be x86_64 which causes it to do so, or there is something else weird going on... But I can't figure out what...

segevfiner commented 1 week ago

I think this cause is this mess due to the app executable being a shell script: https://apple.stackexchange.com/questions/466284/why-is-a-macos-app-whose-executable-is-a-shell-script-launching-as-x86-64-on-an https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary

thc202 commented 1 week ago

Download the mac-arm64 from https://googlechromelabs.github.io/chrome-for-testing/#stable not ideal but it would work as expected (you need to update the Selenium options to use the binary from that one).

segevfiner commented 1 week ago

I worked around this by editing ZAP.app/Contents/MacOS/ZAP.sh to:

#!/usr/bin/env bash

# cd into the Java directory of the .app file
cd "$( dirname "${BASH_SOURCE[0]}" )"
cd ../Java

# execute zap.sh, passing through the command line arguments
exec arch -arm64 ./zap.sh "$@"

(Adding the arch -arm64 bit).

Basically it seems that if the main executable in an app bundle is a shell script, it gets launched under Rosetta, which later on leads to universal executables launched by ZAP to prefer the Intel architecture. The LSArchitecturePriority or LSRequiresNativeExecution don't seem to work to get it to launch the shell script under ARM64. Which smells like a bug in mac as the documentation suggests otherwise https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary#Specify-the-Launch-Behavior-of-Your-App.

thc202 commented 1 week ago

Good that works but ZAP is/was running with correct arch. In any case, I guess we could apply that workaround when building the arm64 dist…

zaproxy / zaproxy