[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