In testing and landing #21744, I realized that we are inconsistent in supporting the socket registry conventions on our staged payloads. Our x86 and x86_64 second stages assume the socket value will be left in EDI or RDI by the stager.
That's a tall ask on AARCH64, yet in the osx stager, we declare it is sockedi complaint, and there's no way we're saving the socket in edi on an aarch64 host.
See
|
'Convention' => 'sockedi' |
Instead, we're probably storing the socket in
x0, and we could start using that convention, but the underlying check has a regex that assumes 3 alpha chars: :
|
def encode_stage_preserved_registers |
I don't think our Linux stagers have this check, and I think the best thing would be to remove the compatibility check from the AARCH64 stagers since it does not actually do anything?
In testing and landing #21744, I realized that we are inconsistent in supporting the socket registry conventions on our staged payloads. Our x86 and x86_64 second stages assume the socket value will be left in
EDIorRDIby the stager.That's a tall ask on AARCH64, yet in the osx stager, we declare it is
sockedicomplaint, and there's no way we're saving the socket inedion anaarch64host.See
metasploit-framework/modules/payloads/stagers/osx/aarch64/reverse_tcp.rb
Line 31 in e5d3b91
Instead, we're probably storing the socket in
x0, and we could start using that convention, but the underlying check has a regex that assumes 3 alpha chars: :metasploit-framework/lib/msf/core/payload/stager.rb
Line 261 in 35a405b
I don't think our Linux stagers have this check, and I think the best thing would be to remove the compatibility check from the AARCH64 stagers since it does not actually do anything?