Cr0wTom
commented
3 years ago Thanks for your review and comments @kasperkarlsson .
The module got developed due to real world use and needs that couldn't been covered by cc's current functionality. Clearly I am not a developer, and the whole thing started as a standalone project, but I want to help the community and I guess through cc it would have greater impact (and I support the modular nature of cc of course).
As you mentioned, many parts are taken from the uds module. One of the ideas was to extend the uds module, but I didn't want to break anything. Maybe I can move the functions there, if that's preferable, but the way the sessions are supplied, parsed and handled is completely different from the UDS module (in order to fix issues I had with uds module, like this).
As you can see, I fixed the proposed issues, so let me know if there is a different way forward that is preferred, or if some references are needed inside the code, pointing to the UDS module. :)
kasperkarlsson
Research showed that many manufacturers do not seed with enough entropy the seed/key algorithm of modern ECUs. In more detail (source):
There is also a complete research done regarding this specific topic by Sekar Kulandaivel.
After proving the vulnerability in real life testing, the need for an automated tool was apparent. In the uds_fuzz module, I implemented the following two sub-functions:
_seed_randomness_fuzzer_: Supply the seed request process used by the target ECU and fuzz it to test for possible duplicates after a supplied Hard ECUReset (with flexibility on the reset method implementation), which means that the device is possibly vulnerable.
_delayfuzzer: This is more of an exploitation sub-function, where a seed request process is supplied, alongside the seed from a single seed/key pair that a tester has acquired. The fuzzer repeats the process by incrementing the delay after each iteration and stops when the correct seed is requesting, giving the delay which was used.