Just checked out your PowerPC post. Very cool.. I had no idea it was that nuanced, especially with the different designs of L1 cache across the different chips. Mark and I were musing the other night that Intel becoming the dominant PC platform is actually something of a slightly lucky draw for exploitation, as there’s so many little details that roughly work out in your favor. Not to say that it’s really materially easier by any means, as it’s clearly still a challenge. That said, there is a slight confluence of events that you probably wouldn’t notice (or care about ;>) unless you’d spent too much time banging your head against other architectures. (thinking alignment, caching, stack semantics and direction, variable length instructions/fluid instruction boundaries, delay slots, lil endian for partial overwrites, read/exec, and other small random details I’m probably forgetting or otherwise cut both ways).

I ran into similar issues on PowerPC. The problem there isn’t register windows, it’s the separate data and instruction cache. I’ll probably write a big blog post on this eventually, but the short version is that with a write-back separate instruction cache, your shellcode isn’t where you expect it to be. When you jump to the overwritten return address, the CPU fetches instructions directly from RAM and your shellcode is not written to RAM until it is expired from the data cache. So in order to run your shellcode, you have to cause a trap, system call, or page fault.

So your theory is totally correct. In my first exploit for DaveG’s OSX AFP bug, I got lucky b/c I could usually trigger a page fault, but it wasn’t deterministic. I described this problem to dvorak @ DEFCON one year and he asked me, “why not just force it to execute a system call?” And I thought, duh, that’s way easier. My next version did a ret-into-libc to execute getuid() and then jumped into my shellcode. That made the exploit 100% reliable .

Thanks for the great comments, btw.

http://archives.neohapsis.com/archives/vuln-dev/2001-q4/0341.html

I’m impressed. That took forever for me to sort out, and it’s clearly pretty important. I had always meant to go actually study the kernel code that performed the stack flush/return to userland setup of the register windows before I tried to explain it publicly. Never got around to it, and I likely would have failed if I tried. Probably pretty hard. :>

That’s funny that by that time the loading down the machine thing was a known idiom. I did it in a few exploits but never felt comfortable really telling anyone about it because I wasn’t 100% on the details. I did offer a sort-of explanation of inducing load to flush register windows in the header of this one:

http://packetstormsecurity.org/9911-exploits/adm-nxt.c

I made a really stupid mistake in there with memset(), so I hope my reasoning was correct and not just a lucky artifact of my larger C fail. ;>

How bout if I pretend that you preferred adb solely for aesthetic reasons, you’ll overlook the conspicuous omission of register window flushing semantics from my sparc overflow paper? :>

Hexrays is great, but yeah, I don’t know if it’s $2300 great unless you can spend someone else’s money on it. :> There haven’t been any updates in a little while, but the recent-ish IDA addition of the local type database was a huge step for making it more effective.

I think in reality, IDA is probably worth a lot more than he charges for it, so maybe this is his way of making up for his lost millions. ;>

Adb rocks! I learned how to write SPARC overflows using it and the Solaris crash dump analysis book. You had to scroll up to see all the registers w/ gdb but adb displayed them nicely in a way that fit a 80×24 terminal perfectly. At DEFCON someone asked me why I didn’t use gdb and honestly I didn’t know at the time that you could step by single instructions in gdb, so I had always used adb.

I so crave Hex-Rays. While I can convince my employer that I need an IDA Pro Advanced license, I have yet to be able to justify paying for licenses for the more fun toys like Hex-Rays and Bin Navi (sorry Halvar!). I prematurely signed up for technical mediocrity already, so I don’t have to worry about being lame and using Hex-Rays. Do you wanna see my Excel macros to score vulnerabilities and make pretty pictures?

Anyway, I started by converting everything back to C from assembly, but Thomas basically relentlessly mocked me until I developed a complex about it. He also mocked me for using gdb, which was apparently tragically unhip. In case you were curious, the cool kids apparently use adb, which I believe is sort of like a combination of a 1982-era RPN HP calculator and being stabbed in the face.

I currently fall into the category of the guy who tries to use all the features I can. I basically need all the magic help I can get, and also having stuff to play with in the periphery of the idb is a good way to pretend that I’m working without having to do a whole lot of actual reversing. I do however draw the line at using the debugger, as that would probably run dangerously close to making me productive in C++ code.

Mark is a better reverser than I (lol, most unnecessary sentence ever), but he doesn’t really use much of the built-in stuff, and just annotates the idb with comments. I tried to get him to use the struct interface once but he was deeply suspicious that it was some sort of elaborate trap to make him bad at computers.

Neel is better than both of us, and I don’t think he even uses comments. He just sees it. It actually makes me angry to think about it.

IIRC, Thomas seemed to prefer deadlisting with objdump to IDA for some reason, though it was a really long time ago. Also, he probably did that just to mess with me. Pretty sure he was secretly using gdb when I wasn’t looking.

Anyways, thought I’d share. :> I have a terrible dark expensive shameful secret, which is known as Hex-Rays. I swear to god it’s awesome. I think basically everyone should be given a copy on their 30th birthday, as it can definitely help you buy a couple of months before your inevitable descent into technical mediocrity and male pattern baldness.