Actually option 2) is not any better in this particular case, since you are unable, as far as I can tell, to find a way to return into any .text segments with call ebx or ecx (which contain pointers to your shellcode in unicode form). This is not the only unicode exploit though, so you'll have a chance to use the encoder sometime soon, I'm sure. I'm not having the same problem you are with characters > 0x7f though. Did you use the % character in your shellcode? Dave Aitel VP of Research and Development Immunity, Inc. http://www.immunitysec.com/CANVAS/ "Hacking like it is in the movies." * We have two alternatives: * * 1) The easy one: find any occurrences of our ascii string (i.e. before it gets converted to * the Unicode form) in process memory. Problem: normally we should find it by debugging the * vulnerable application and then hardcode the found address (which will be the RET address) * in our exploit code. This RET address is variable, even for the same version of OS and app * (I mean, different instances of the same application in the same machine could make the * guessed RET address invalid at different moments). Now add the restriction of RET value * padded with null-bytes. Anyway, the main advantage of this method is that we will not have * to deal with 0x00-padded shellcode. * * 2) The not so-easy one: you could insert an encoded shellcode in such a way that when the app * expands the ascii string (with the encoded shellcode) to Unicode, a valid shellcode is * automagically placed into memory. Please, refer to Chris Anley's "venetian exploit" paper * to read more about this. Dave Aitel also has a good paper about this technique and indeed * he released code written in Python to encode shellcode (I'm wondering if he will release a * working tool for that purpose, since the actual code was released as part of a commercial * product, so it cannot be run without buying the whole product, despite the module itself * being free!). Problem: it is not so easy as the first method ;-) Advantage: when the over- * flow happens, some registers may point to our Unicoded string (where our Unicoded-shellcode * lives in), so we don't need to guess the address where shellcode will be placed and the * chance of a successful exploitation is greatly improved. For instance, in this case, when * IIS is overflowed, ECX register points to the Unicode string. The idea is then fill in * RET value with the fixed address of code like "call %ecx". This code may be contained in * any previosly-loaded library, for example). * On Tue, 25 Mar 2003 19:25:48 +0100 Roman Medina <roman@rs-labs.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I wrote another exploit for the nt.dll bug some days ago. > Explanation and a little documentation is included in the source > file. It compiles in Linux/gcc without any error. > > http://www.rs-labs.com/exploitsntools/rs_iis.c > [19.5 kbytes] > > Regards, > --Roman > > - -- > PGP Fingerprint: > 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742 > [Key ID: 0xEAD56742. Available at KeyServ] > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> > > iQA/AwUBPoB8TOR/in3q1WdCEQLvqgCeLnYnMNDRQggwSn3hEe5YKKPLPl8AnR6K > YV1r+FKjoQmG+nPN0BsRv6jn > =Td4v > -----END PGP SIGNATURE----- > >
