It requires understanding the Defensics protocol.

Sometimes, when we are testing embedded devices, when we trigger the test cases, the target will crash immediately. It is very difficult for us to identify the root cause of the crash because they do not provide sophisticated tools on the target side. They cover only the client-side application, and from that we can generate automated test cases, but what happens on the target device, what is the reason for the crash, for that we have to do manual debugging. They do not have diagnostic tools for the target side. Rather, they have them but they are very minimal and not very helpful. They can improve a lot on that.

Codenomicon Defensics should be more advanced for the testing sector. It should be somewhat easy and flexible to install. 

What I see in the documentation isn't that. Even if something doesn't malfunction, sometimes it is hard to install and execute. The product needs video documentation. This would help a lot more.

• You can't implement proprietary ciphering algorithms, nor can you modify protocol models if you need to test customized public protocols.
• You can't use the program at all without the USB license dongle. This would be useful for instance to export results, prepare the wizard, and so on. It can be inconvenient if several teams use the license.
• Time estimation: order of magnitude is not always respected.
• To test ARP on the client side, you have to clear the MAC table of the SUT. A feature such as sending ping requests to the SUT with a different virtual IP/MAC address each time to force the client to send ARP request would be great.
• No automatic bug reproduction (as Peach has for example).
• You can't create a protocol model from scratch using the GUI. You can use the traffic capture fuzzer, import a PCAP file and generate tests cases from it. Known protocols are described according to a wireshark dissector, proprietary protocols have to be defined manually (by defining a label on a part of the data). It seems that we can go further with the Java SDK, but we didn't have enough time to test it.
• When using the GUI, you can't run fuzzing sessions both sequentially and in parallel at the same time, for instance for testing different protocols on different devices. One possible workaround is to use the CLI of Defensics and to use different configuration folders.
• When you choose the network interface to use, there is an «auto-configuration» box ticked by default. It means that Defensics will try to guess the interface you will use, but it often lead to mistakes.