mailing list archives
Re: inline meterpreter payload
From: Richard Miles <richard.k.miles () googlemail com>
Date: Fri, 14 Sep 2012 15:21:19 -0500
Hi Sherif El-Deeb,
Great explanation, make a lot of sense what you told.
On the other side I think it make modifications to avoid antivirus much
harder. For example, it's not possible to use a strong packing at .dll
since it will prevent the patching in memory of the addresses that will be
used for further connections. I think this will make detection for AV
On Thu, Sep 13, 2012 at 10:14 AM, Sherif El-Deeb <archeldeeb () gmail com>wrote:
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...
On Sep 13, 2012 5:38 PM, "Richard Miles" <richard.k.miles () googlemail com>
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
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
It doesn't do too bad on virustotal either:
I tried connecting it to a handler for a shell payload and it died.
Any thoughts as to why? Works fine with meterpreter though.
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
Assuming this is for X86 arch, you have to make sure that the EDI
register contains your socket descriptor (the value of the
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,
PS: This is the reason why the calling convention within Metasploit is
called "sockedi" :-)
Re: inline meterpreter payload HD Moore (Sep 07)
Re: inline meterpreter payload Raphael Mudge - Raffi's House of Shells (Sep 13)