During the testing phase, the fuzzer will generate packets to test the target server and process the test results. First, the fuzzer will send a request to the forkserver asking it to fork a new instance for testing. This test instance is executed from where the forkerver logic is detected. As a result, the test instance can skip executing tests for logic not relevant to the test. Once the test instance starts executing, it will notify the fuzzer to proceed. The fuzzer will then generate a new SOME/IP packet through structural mutation and send it to the test instance. After the packet is received, the test instance will process it. The mutated data header helps to test the packet parsing component, while the mutated packet body helps to test the server’s business logic. After the test instance has finished executing, the forked server will collect its exit status and execution coverage information. The collected data is then reported to the fuzzer. Ori’s test result processing is similar to other coverage-based gray-box fuzzers. If that packet crashes the test instance, the fuzzer will keep it for future analysis. If this packet can increase code coverage, the fuzzer will keep it as a seed to generate new test cases. This marks the end of a round of testing. If the user does not stop the fuzzer or target server, the whole process will continue with a new round of testing.