On Thu, Oct 30, 2008 at 2:41 AM, spoonm <[EMAIL PROTECTED]> wrote:
>
> 2008/10/28 Vlad Tsyrklevich <[EMAIL PROTECTED]>:
> > I have been looking at Opty2Nop recently and I made a couple of changes.
> >
> > 1) Fixed a minor bug, sometimes Opty2 would generate C1 /6 instructions
> > which most processors will execute but which are not technically valid (they
> > would exist for SAL but SAL is an alias for SHL so it is defined as C1 /4).
>
> Did you find any processors that wouldn't execute it?  I remember this
> case, and I realized it was technically invalid, although I couldn't
> find a processor that cared (and when you think about it, there is no
> reason to care).

I didn't find any. The reason I even looked into it is because a
ndisasm of my nops file ended up having bad instructions in it and I
found this. I'd be happy to put it back, I took it out figuring it was
better to err on safety and I didn't realize it was already
considered.

> > 2) I changed the 0x90 nop instruction so that it is no longer considered
> > that 0x90 changes the eax register.
>
> Oh yeah, it's xchg eax, eax, I autogenerated those tables :\  Btw, has
> anyone seen the original table generation code laying around?

Yeah I plan to make mov reg, reg and xchg reg, reg also not change any
registers if I ever get around to it.

> > 3) Removed o16/0x66 prepend byte from 0x0f, this is currently unused anyways
> > but might prevent some poor person from debugging it in the future.
>
> Oh yeah, good catch
>
> > 4) Previously short jumps would only make positive jumps, I added the
> > capability for them to make a "-1" jump which would basically just start
> > executing at the offset byte. For example it could generate something like
> > EB FF XX YY ... where EB FF jumps to FF XX YY ...
>
> Oh dang, smart.  And by positive I think you mean non-negative, since
> it would generate for 0.
>
> > 5) I added support for the instructions mov reg, segreg (8C), mov reg,
> > imm8/imm32 (C6/C7), and lea reg, mem (8D). I implemented LEA so that it only
> > allows memory references to be in ModR/M form and not be in SIB form (I
> > don't think it's possible to allow SIB in the way Opty2 works at the
> > moment).
>
> Yeah, I don't think so either, the pivot tables are all based on 1
> byte of context, and you would need 2 bytes of context for the SIB
> byte.

Yeah realistically it wouldn't be a problem if we didn't have the
context if there weren't SIB encodings that were "bad," but there are.

While I still got you on the line, I was looking at one more thing to
add to Opty2. Do you think RDSTC (0F 31) is safe to add? It's a
two-byter, but 0x31 is a valid instruction prefix. The problem is that
it was added in the 586, and is unsupported by some mid-90s Cyrix
CPUs. I figure that's not a big concern since those CPUs masked
themselves as being 486s anyway, but I was unsure if you knew of any
other cases where RDTSC was not supported by the CPU. Would be nice to
add since it would be the only two-byte instruction generated by Opty2
and it would add one more number to the byte distribution.

> >
> > I tested this just running about 50,000 bytes worth of nops with different
> > save register settings and it ran as expected.I believe that this should be
> > good to go though I haven't actually tested this with any exploit modules!
> > The svn diff of the opty2_tables.rb file is attached.
>
> Word mannnn.  Nice work.  Thanks.
>
> >
> >  - Vlad Tsyrklevich
> >
> > _______________________________________________
> > Framework-Hackers mailing list
> > Framework-Hackers@spool.metasploit.com
> > http://spool.metasploit.com/mailman/listinfo/framework-hackers
> >
> >
_______________________________________________
Framework-Hackers mailing list
Framework-Hackers@spool.metasploit.com
http://spool.metasploit.com/mailman/listinfo/framework-hackers

Reply via email to