Re: inline meterpreter payload

[Sherif El-Deeb <archeldeeb () gmail com>]

I will explain my own understanding of what happens behind the scenes,
which might be very wrong.

It is only one .dll with all the connection flavors built into it.

Please allow me to explain the missing piece of how the .dll knows where to
connect back when it arrives at the destination, since all the first stage
does is "make room for the .dll in memory, jump to it"... when exactly did
the .dll know where to go and what connection type to use? "let me take the
reverse_http as an example"

The .dll will get patched "on the fly" in memory at the handler's side
before being sent to the first stage... So when it arrives and get called
by the 1st stage, it has everything already set up, that's why in the
sourse code of metsrv has the uri of the target as "http://xxxxxxxxxxx...";
so it is to be replaced by the correct handler uri:port, timeout... etc.

Reverse_tcp is a bit different, I think, because this connection type will
have the first stage actually create a socket first to the handler, then
call the dll with the file descriptor of the socket inherited to it, and
.dll takes it from there.

Again, this is poor understanding, if I am wrong, kindly correct me...

Sherif Eldeeb.
On Sep 13, 2012 5:38 PM, "Richard Miles" <richard.k.miles () googlemail com>
wrote:

> Hi Raphael
>
> This is nice, in special if it's working with meterpreter.
>
> Based on this I'm curious now, I looked into your code and you do exactly
> what was described and I before I was thinking that there was just one .dll
> for all meterpreters and in somehow it used the first stage connection. But
> now, looking and your code and Egypt description I think it's not possible,
> I guess that exist one .dll compiled for each meterpreter payload. Is it
> correct?
>
> The virustotal output of your file is good
>
> Thanks for share.
>
> On Wed, Sep 12, 2012 at 11:02 PM, Raphael Mudge - Raffi's House of Shells
> <contact () fastandeasyhacking com> wrote:
>
> > If anyone feels like playing, here's a working loader based on this
> > guidance:
> >
> > https://github.com/rsmudge/metasploit-loader
> >
> > It doesn't do too bad on virustotal either:
> >
> >
> > https://www.virustotal.com/file/afe34bfe2215b048915b1d55324f1679d598a0741123bc24274d4edc6e395a8d/analysis/1347507196/
> >
> > I tried connecting it to a handler for a shell payload and it died.
> > Any thoughts as to why? Works fine with meterpreter though.
> >
> > -- Raphael
> >
> > On Wed, Sep 12, 2012 at 1:00 PM,
> > <framework-request () spool metasploit com> wrote:
> >
> > > Date: Wed, 12 Sep 2012 18:07:45 +0200
> > > From: Michael Schierl <schierlm () gmx de>
> > > To: Stephen Haywood <stephen () averagesecurityguy info>
> > > Cc: "framework () spool metasploit com" <framework () spool metasploit com>
> > > Subject: Re: [framework] inline meterpreter payload
> > > Message-ID: <5050B351.2040503 () gmx de>
> > > Content-Type: text/plain; charset=ISO-8859-1
> > >
> > > [resent message as I was subscribed with the wrong email address]
> > >
> > > Am 12.09.2012 01:37, schrieb Stephen Haywood:
> > > > I've got  a C program that does exactly that but have never been able
> > > > to get it to connect back to Metasploit after the second stage is
> > > > executed.
> > >
> > > Assuming this is for X86 arch, you have to make sure that the EDI
> > > register contains your socket descriptor (the value of the ConnectSocket
> > > variable). You can do this via inline asm, but it might be easier to
> > > just prepend the 5 bytes for setting it to your shellcode:
> > >
> > > BF 78 56 34 12           mov edi, 0x12345678
> > >
> > > For 64 bit, you have to use the RDI register (and need 10 bytes):
> > >
> > > 48 BF 78 56 34 12 00 00 00 00     mov rdi, 0x12345678
> > >
> > >
> > > Hope this helps,
> > >
> > >
> > > Michael
> > >
> > > PS: This is the reason why the calling convention within Metasploit is
> > > called "sockedi" :-)
> > _______________________________________________
> > https://mail.metasploit.com/mailman/listinfo/framework
>
>
> _______________________________________________
> https://mail.metasploit.com/mailman/listinfo/framework
_______________________________________________
https://mail.metasploit.com/mailman/listinfo/framework