[framework] Using encoders directly
Krpata, Tyler
tkrpata at bjs.com
Wed Dec 27 14:09:33 CST 2006
Sorry, didn't realize I hadn't included the message. The message I get
without messing with the encoder file at all is:
Exploit failed: wrong number of arguments (1 for 2)
In generic.rb under lib/rex/encoder/alpha2, the Generic.encode method
calls encode_byte with one argument, where it expects a second
"badchars" argument.
If I change the call in the encode method to:
encoded += encode_byte(block, "")
I get the message:
Exploit failed: Negative
Which seems to be an exception raised by the encode_byte method. The
"second" value looks like it is derived from the gen_second method in
unicode_mixed.rb.
If I try to use the AlphaMixed encoder instead of the UnicodeMixed
encoder after I have made that change in the Generic.encode method, it
seems to work ok, though I haven't verified that the payload was
actually encoded properly.
> -----Original Message-----
> From: mmiller at hick.org [mailto:mmiller at hick.org]
> Sent: Wednesday, December 27, 2006 2:25 PM
> To: framework at metasploit.com
> Subject: Re: [framework] Using encoders directly
>
> On Thu, Dec 21, 2006 at 11:19:56AM -0500, Krpata, Tyler wrote:
> > I think this question got lost in my last post, so I thought I'd
start a
> > new thread about it.
> >
> > Should I be able to use the encoders in Metasploit directly? What
I'd
> > like to do is use the Alpha2 encoder something like:
> > payload =
Rex::Encoder::Alpha2::UnicodeMixed.encode(shellcode,"EBX",0)
> >
> > The "shellcode" argument in this case is actually the code retrieved
> > from the "egghunter" class.
>
> Apologies for the late reply, I've been out of town.
>
> Right now the API that's exposed to encode arbitrary (non-payload)
> buffers isn't very easy to use. It'd be better if we added a method
to
> the EncodedPayload class that would allow you to specify a buffer
> rather than a payload instance. With that said, your use of the
encode
> method looks correct. Can you include the actual exception message
> that's displayed (aside from just the call stack)? That might help
> narrow down a bit more what's going on.
More information about the framework
mailing list