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
