On Thu, Oct 30, 2008 at 11:25 AM, Vlad Tsyrklevich <[EMAIL PROTECTED]> wrote: > 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.
Yeah, that's interesting. Is rdtsc the only 2 byte instruction in the 0x0f escape group? Have you added it and generated the before / after byte distribution tables? Would be interesting to see the difference, it all depends on how often 0x31 is generated I guess. As for CPU support, yeah, that's annoying. I don't really think we should care, but I guess it would be nice to have it documented or a way of switching that instruction on or off. But yeah, I mean, I wonder what else would fail. Do we have any old 486 machines to see what happens? Does it illegal instruction? > >> > >> > 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
