On Wed, Dec 21, 2016 at 1:38 PM, Moshe <m...@moshekaplan.com> wrote:
> I apologize for my lack of clarity. Peter is correct, I am interested in
> fuzzing dissectors.
>
> My plan is to have the sequence of raw bytes represent a pcap file. There
> can be many packets in a single pcap, which would allow testing state
> interactions.
>
I will be also interessing to fuzze also libwiretap because often found
some issue on this part of code
about cmake VS autotool
cmake is now the default for Windows (and macOS ?) but there is always
autotool and no plan to remove for the moment...
But i think better to use cmake !
>
> Moshe
>
>
> On Dec 21, 2016 6:19 AM, "Guy Harris" <g...@alum.mit.edu> wrote:
>
> On Dec 21, 2016, at 2:12 AM, Peter Wu <pe...@lekensteyn.nl> wrote:
>
> > From the efforts that I have seen, Moshe seems to be targeting the
> > dissectors functions. Since these may appear over the network, it is
> > probably one of the more interesting parts to tackle first.
>
> Then I'm not sure how well
>
> > The second step is to create a fuzzing interface. The fuzzing interface
> needs to have the following signature:
> >
> > extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) {
> > DoSomethingInterestingWithMyAPI(Data, Size);
> > return 0; // Non-zero return values are reserved for future use.
> > }
>
> matches the way it works.
>
> If you have a program called "rednose", that takes a JPEG image, looks for
> noses, and colors them red, you could have an API that takes a pointer to
> an array of bytes containing a JPEG image, and a size_t giving the total
> number of bytes in the image, and call the nose-detector-and-colorer API
> (although, given that the argument is a const pointer, it'd have to provide
> some output buffer).
>
> I guess you *could* have an API that takes a *single* blob of data and
> hands it to the frame dissector, with enough metadata to have it
> interpreted as an Ethernet frame, and that would catch *some* issues. It
> wouldn't catch any issues that would only show up with a sequence of
> packets.
>
> Is there some way to fuzz code that's *not* stateless, and that takes a
> *sequence* of bits of input, in order?
>
> ____________________________________________________________
> _______________
> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscr
> ibe
>
>
>
> ____________________________________________________________
> _______________
> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=
> unsubscribe
>
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
