c:153)
==16584== by 0x8048395: main (in valgrind_3)
==16584== by 0x126BBE: __libc_start_main (in /lib/libc-2.3.2.so)
==16584== by 0x80482EC: (within valgrind_3)
==16584==
==16584== LEAK SUMMARY:
==16584== definitely lost: 40 bytes in 1 blocks.
==16584== possibly lost: 0 bytes in 0 blocks.
==16584== still reachable: 0 bytes in 0 blocks.
==16584== suppressed: 0 bytes in 0 blocks.
==16584== Reachable blocks (those to which a pointer was found) are not shown.
==16584== To see them, rerun with: --show-reachable=yes
While the preceding examples are trivial, they do demonstrate the value of valgrind
as a testing tool. Should you choose to fuzz a program, valgrind can be a critical piece of
instrumentation that can help to quickly isolate memory problems, in particular, heapbased
buffer overflows, which manifest themselves as invalid reads and writes in
valgrind.
References
Process Stalker http://pedram.redhive.com/code/process_stalker/
GDE Community Edition www.oreas.com
OllyDbg www.ollydbg.de/
WinDbg www.microsoft.com/whdc/devtools/debugging
Valgrind http://valgrind.kde.org/
Fuzzing
Black box testing works because you can apply some external stimulus to a program and
observe how the program reacts to that stimulus.
Pages:
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627