On 29/11/05, Segin <[EMAIL PROTECTED]> wrote: > Has anyone thought of trying a return-to-libc type of exploit? I know > that the library "D3D9" is DirectX 9's Direct3D library. See if we can > find some exploits on a standard x86 PC regarding that, then see if we > can apply them on a xbox 360.
Correct me if I'm wrong, but a return-into-libc (or return into any lib) exploit depends on the functionalíty provided by the library. Unix return-to-libc exploits use system() to open a shell. There are probably much more interesting libs than the Direct 3D lib. There's been a lot of suggestions on buffer overflows, but even with my limited experience in buffer overflows, I cannot emphasize enough that for a succesfull buffer overflow exploit you need lots of information: 1) For a regular buffer overflow, you need to know the stack location to be able to produce a return address to your exploit code before/after the return pointer on stack. Same goes for non-return-address-pointer exploits (code on heap). 2) For a return-to-libc call you need to know the memory locations for the desired library functions. Basically you need at least a detailed memory map. If you cannot debug or examine the memory of a running system, bruteforcing the addresses can be a time-consuming task (even with lots of NOP padding in the exploit code, 256 megabytes of memory is a huge space for a few kilobytes of code). Disassembly of the affected function(s) is almost a requirement too. If the stack in a memory page marked non-executable or protected using software generated canaries, you obviously need to use a return to libc exploit or a stack bypassing technique (such as one described in Phrack #56). I think there's still much groundwork to be done before a buffer overflow can be successful. Sometimes people mistake just about any crash on a system which is being fed invalid data as a buffer overflow. If you can't reverse-engineer the crashing routine, you might be banging your head against a wall for a long time trying to get exploit code running. I might sound a bit negative, but I believe this is the reality we're facing. However, new information seems to keep coming every day and I'm looking forward for first decrypted binaries that can be fed through a disassembler. -smo ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ free60-devel mailing list free60-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/free60-devel