Hunting for buffer overflows

Is there a way to use a debugger (immunity preferably but I'll take gdb or any other debugger you know how to do this with) so that any time a piece of memory holds a particular value (say AAAAAAAA) the debugger will make a note of what line it happened and then continue on until it fully crashes.

Not just a simple watch but anytime any register or memory in use by the program contains an A to make a notation of this.  It seems like a really good idea that would take some of the hard work out of exploit development but I have yet to see any straightforward talk of this.

valgrind might

>>2
Lol dude I think they all might it seems like a really useful feature for all sorts of super-lazy debugging but I don't see any mention of it.   My developer vocabulary might just not be rich enough to form the proper google searches.

>>1
SYNTAX ERROR: LINE 1: UNTERMINATED PARENTHESIS

You'll have to modify something like Bochs or other CPU emulator to catch all memory and register writes. It will be *very* slow.

>>5
Ahh ok I think that the bochs debugger is supposed to be scriptable.  Since you were able to answer this with so much certainty and because this feature doesn't seem to already exist I have to assume this is because of the way debuggers work.

Well I guess now it's just a toss up between writing some sort of script that goes through the entire memory space and sets watches or scripting the bochs debugger (which I suspect will have a steeper learning curve), slowness isn't a factor since this will allow automated fuzzing with a great deal of the work already done for me I can just queue a bunch of software up on a box somewhere and check the results whenever I'm motivated and have the time to try and crack something.

>>5
it would be slow, but probably not much slower than valgrind, which is able to detect writes to memory not reserved with a call to malloc, for example.

>>6
I think I would try to use asserts to catch what you are looking for. Or add an equality check to this memory address, and log operations on it. If the value is being changed due to a memory error, it might not be entirely meaningful to know what is setting that value to AAA. The actual error that was responsible might have already happened, and you'd have to continue to back track. Reverse code execution sounds like it could be helpful here, but even then the error might be really far back.

>>7
I'm trying fuzz out security problems so asserts won't do it.

Store everything in memory mapped file and step through in debugger , grepping file at every step

but bochs is so fucking slooooow

>>10
How do you think cpu emulators work?

>>11
bochs is much more than an emulator, that's why it is so slow, if you are running the same architecture and don't need to step around then why oh why bochs!

>>9
Good idea
>>7
The idea being that I feed crap information like 5000 A's and see where in memory those A's end up and then who tries to read or execute those A's

Then I consider the implications of being able to write into that memory

Then I use a unique pattern of the same size to identify which As were getting spewed around in memory.

http://www.few.vu.nl/~herbertb/papers/minemu_raid11.pdf

>>13
oh, you's just trying to hax an ani aint you.