You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Much of the platform and architecture detection code within Framework and accompanying libraries has grown naturally as needed over the past 20 years.
Many patches and enhancements were implemented as needed, usually in a manner similar to the following:
x64 is new, let's add support! If the arch detection fails then it must x64
x86 is old school - we're all about x64 now. Let's check a version string for 64, and if it's not x64 then it must be x86
ARM is becoming popular. If the x86 / x64 detection fails then it must be ARM. Let's check for ARM first (32-bit of course), then fall back to x86 / x64 detection
x64 means x86_64, but there are other 64 bit architectures. Even ARM is 64 bit now.
...
If it doesn't match <large collection of string comparison conditional statements>, then assume it's x86
This evolution is not unique to Metasploit and has played out many times across many projects.
The resulting code patterns are often brittle. In particular, in instances where:
anything containing 64 is expected to be x86_64, ignoring 64-bit ARM and RISC-V (and MIPS64 and LoongArch64 and SPARC64 and ...).
anything that isn't _________ is presumed to be __________. (ie; anything that isn't <expected architectures> is presumed to be x86)
This will become more of an issue due to the increasing popularity of ARM (OSX on Apple M1 and official support for running Windows on ARM) and RISC-V.
Issues will also arise with a lot of the Windows Meterpreter code if we ever add ARM native Meterpreter (#15025).
We have Msf::Post::Architecture now, which is a good start for local execution on Windows platforms.
Creating a thread to track instances where this should be addressed in Framework and supporting libraries.
Feel free to edit this post, post in this thread, or creating a new issue referencing this issue.
Much of the platform and architecture detection code within Framework and accompanying libraries has grown naturally as needed over the past 20 years.
x64
64
, and if it's notx64
then it must bex86
x86
/x64
detection fails then it must be ARM. Let's check for ARM first (32-bit of course), then fall back tox86
/x64
detectionx64
meansx86_64
, but there are other 64 bit architectures. Even ARM is 64 bit now.<large collection of string comparison conditional statements>
, then assume it's x86This evolution is not unique to Metasploit and has played out many times across many projects.
The resulting code patterns are often brittle. In particular, in instances where:
64
is expected to be x86_64, ignoring 64-bit ARM and RISC-V (and MIPS64 and LoongArch64 and SPARC64 and ...).<expected architectures>
is presumed to be x86)This will become more of an issue due to the increasing popularity of ARM (OSX on Apple M1 and official support for running Windows on ARM) and RISC-V.
Issues will also arise with a lot of the Windows Meterpreter code if we ever add ARM native Meterpreter (#15025).
We have
Msf::Post::Architecture
now, which is a good start for local execution on Windows platforms.Creating a thread to track instances where this should be addressed in Framework and supporting libraries.
Feel free to edit this post, post in this thread, or creating a new issue referencing this issue.
Modules
metasploit-framework/modules/exploits/windows/local/payload_inject.rb
Lines 61 to 63 in f20dcb2
metasploit-framework/modules/exploits/windows/local/applocker_bypass.rb
Lines 51 to 53 in f20dcb2
metasploit-framework/modules/exploits/multi/http/jboss_maindeployer.rb
Lines 347 to 358 in f20dcb2
Libraries
MySQL (arm is supported; RISC-V is not officially supported yet)
metasploit-framework/lib/rex/proto/mysql/client.rb
Lines 56 to 82 in f20dcb2
MSSQL:
metasploit-framework/lib/rex/proto/mssql/client.rb
Lines 92 to 110 in f20dcb2
PostgreSQL for comparison:
metasploit-framework/lib/postgres/postgres-pr/connection.rb
Lines 177 to 208 in f20dcb2
metasploit-framework/lib/msf/core/exploit/remote/mysql.rb
Lines 190 to 211 in f20dcb2
metasploit-framework/lib/msf/core/exploit/remote/http_server.rb
Lines 337 to 352 in f20dcb2
metasploit-framework/lib/msf/core/exploit/remote/http/jboss/base.rb
Lines 125 to 140 in f20dcb2
The text was updated successfully, but these errors were encountered: