Static protocol content often includes protocol-defined
keywords and tag values, while dynamic protocol content generally consists of user-supplied
values. How do you deal with situations in which an application is using a proprietary
protocol whose specifications you don??™t have access to? In this case, you must
reverse-engineer the protocol to some degree if you hope to develop a useful fuzzer. The
goals of the reverse-engineering effort should be similar to your goals in reading an RFC:
identifying static versus dynamic protocol fields. Without resorting to reverse-engineering
a program binary, one of the few ways you can hope to learn about an unknown protocol
is by observing communications to and from the program. Network sniffing tools
might be very helpful in this regard. The WireShark network monitoring tool, for example,
can capture all traffic to and from an application and display it in such a way as to
isolate the application layer data that you want to focus on. Initial development of a
fuzzer for a new protocol might simply build a fuzzer that can mimic a valid transaction
that you have observed. As protocol discovery progresses, the fuzzer is modified to preserve
known static fields while attempting to mangle known dynamic fields.
Pages:
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635