Codecov Report

Merging #3140 (b02a799) into master (18b71dd) will increase coverage by 0.00%.
The diff coverage is 84.33%.

@@           Coverage Diff            @@
##           master    #3140    +/-   ##
========================================
  Coverage   85.32%   85.32%            
========================================
  Files         262      265     +3     
  Lines       54731    54946   +215     
========================================
+ Hits        46697    46881   +184     
- Misses       8034     8065    +31     

@gpotter2 Would it be possible to get this PR in, so that I can continue with the split of #3054

@gpotter2 Sorry for the confusion with the name AutomotiveTestCase and AutomotiveTestCaseExecutor.
Prior to my refactoring, I called these classes Enumerator and Scanner. But during multiple practical tests, I found these two classes very useful for further purposes. For example, I used an Enumerator class to validate if a certain vulnerability is present in a Electronic Control Unit of a car. Therefore I came up with a more generic naming for these two classes. I changed the base class for Enumerator into AutomotiveTestCase and Scanner into AutomotiveTestCaseExecutor. The derived classes still remain the name Enumerator and Scanner.

The AutomotiveTestCase class basically defines a generic interface for the AutomotiveTestCaseExecutor. The unique part of this two classes is the automated aggregation (reverse engineering) of a device under tests "system state" in a directed graph. Since automotive control units are very state driven, for my scanners, it's very important to identify the current system state in order to obtain reproducible and reliable results.

Regarding the AutomotiveTestCaseExecutor, currently I derive Scanner classes from this base class. On my current experiments, I also use this class for a Fuzzer of automotive protocols with system state awareness. Also in this use case, I find it more natural to derive "AutomotiveFuzzer" and "Scanner" from "AutomotiveTestCaseExecutor". The old naming scheme would lead to a inheritance of "AutomotiveFuzzer" from "Scanner", which I find stranger.

To summarize that.. I've chosen this names to express a broader use of these base-classes, not only for enumeration and scanning. I'm currently experimenting with more use cases and plan to release for example AutomotiveFuzzers in the future.

@gpotter2 could this PR get merged, please? My paper about automotive protocol scanners, I've implemented with Scapy, got accepted and will be published on 12.5.2021. I would be happy, if by that time, the relevant code (#3054) got merged.