Re: add %ebx, (%esi)

[Dave Aitel <dave () immunityinc com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bee Binger wrote:
> I was messing around with your assembler.py and found a couple
> points of interest.
>
> When using the 'bt' instruction the assembler throws the "error
> ..(sorry)" message.  I was sending part of my sys_select code into
> the app and my fd_isset uses the bt instruction to check if a fd is
> set and it seems the script did not know this instruction. ( not a
> bug but would make me have to rewrite a bit of my socket apps )
>
> Also it seems to throw that same error on many "rep" operations ( I
> couldnt find a valid combination of registers/rep instructions
> without getting the error thrown )
"rep movsb" works for me. I'm not sure we support this very well
though. Piotr noticed we don't do 16 bit addressing very well at all.
Which so far hasn't hurt us, since our shellcode doesn't use it. This
is very much a shellcode/proglet assembler. I added bt this morning,
so that should work nicely for you now. For bonus credit I added
bswap. :> Also Skylined pointed out there are three add %ebx, (%esi)
possibilities, not two.

> This last part was more my curiosity than anything but it is making
> me wonder alot..
>
> for the default xor %eax,%eax in the textbox I was expecting to see
> 31 and c0 for the opcodes but  I saw  0x33 and 0xc0. I looked at
> the intel manuals and it said:
>
> 31 / r     XOR r/m32,r32 r/m32     XOR r32 33 / r     XOR r32,r/m32
> r8         XOR r/m8
>
> There was also similar results with the add, sub, and other math
> instructions in your script always using the r32 choice as the left
> operand instead of the r/m32. Is this some optimization trick?  If
> both are registers then they would use the same amount of clock
> cycles, but it seems to be limited only register manipulation and
> not addresses. I couldnt figure out how in the text box to declare
> sections because I was wondering if  31 would be produced for xor
> if a variable from the.data section was the source operand since it
> seems 33 would break on this or not be allowed.
You can't really define sections for this assembler - but we haven't
had any problems. Let me know if there's something wacky here about
the x86 arch I didn't understand properly. We have been using a
similar (though much slower) assembler for a few years now in all of
our exploits (which is why I can finish an assembler in a week, rather
than a month or two). Once the C parser is rewritten, I'll release it
all as LGPL and you can fix it :>.

I really like the idea of a web service for shellcode decoder
creation. This was part of the original idea for the CANVAS World
Service (which we're still going to do some day). One of the major
advantages is that people who invest lots of time for their own
customized polymorphic decoders could offer them as a web service
attached to CANVAS World Service and then charge a buck every time
they are used, for example. And having them as a web service also
means IDS companies can't easily write signatures, since you can
change them every day and they never see the code that generates the
shellcode decoder itself.

For now, having an assembler web service is pretty fun. :>

- -dave
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGn6mLB8JNm+PA+iURApXtAJsEXfRAedswtwHYk+AJ7D7WPmjF5ACeJnYZ
5FEJBd+5ubFCJCXSYQOkReE=
=RiFT
-----END PGP SIGNATURE-----

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave