Hi, I've searched around the internet but I could not find an answer matching exactly what I'm looking for. I'm currently working on fuzzing network protocols, with different softwares. Some are fully automated (but are not free), some are open-source but it requires I write my own scripts. Since I want to create errors with the open sources ones, I'm trying to create "Malformed packets" so the devices I'm testing have to deal with malformed data. For my tests, I'm fuzzing ARP protocol. When I'm observing "Malformed packets" with fully automated, test version of a fuzzer, I only have full well-formed packets with my self-writted fuzzing scripts. I observed differences beetween the two kinds of packets, but I couldn't find out what is the difference that let Wireshark say it's "Malformed" or it's not. Here is an example of two similar packets which I cannot understand why there is a malformed one and a "clean" one. What is the real difference beetween those two packets ? I can see the payload is starting 4 bytes earlier on the malformed one, but why isn't Wireshark saying that the "opcode" is unknown ? When I generate a packet with my open source software, I can put any byte I want anywhere so the packet is the most malformed ARP packet you've ever seen, Wireshark will still say the code is unknown, not that the packet is malformed. Has anyone an answer ? Thank you for your attention asked 23 May '16, 09:19  Pygmay |
One Answer:
Look at this answer of @Guy Harris to almost the same question asked a few weeks ago. In your particular case, the deviation from a valid packet you have caused may be so small that it can be pinpointed rather than causing one of the dissectors participating in the dissection to get out of sync and thus report a malformed packet. Unknown opcode is an example of such an error, and moreover, the dissector may still be fine if the other shifted data can be interpreted as formally valid ones. In real life, a packet corrupt that way in transmission is highly unlikely to make it to the destination application because the receiving network card would drop it due to incorrect CRC; if you forge a packet using your software, the CRC is correct (because it is calculated after you've damaged the data) so the receiving network card delivers the packet to the application (and also Wireshark, which also cannot see packets received with incorrect CRC). I.e. this way, you can test the robustness of the protocol itself and its receiver-side implementation against errors of sender-side implementation. NB: if you want us to look at the difference between two packets in detail, post them as capture files (or, in case of one or two packets, at least as hex dumps which can be imported), never as screenshots. answered 23 May '16, 13:13  sindy |
Hello, Thank you for your fast answer, that I find clearer that the one given to Guy Harris ^^'
I understand quite well this on a high level. Is it possible to read somewhere how the dissector is working on a lower level ? For example, can I find details of the behaviour of the ARP dissector in a very low level ?
NB : Got it, thanks :)
I guess this is as low as you can go. Start at
dissect_arp()and work your way from there.Thanks !!!