Skip to content

Rusty-CAN-Factory/rusty-can-fuzzer

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

57 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

CS410P Rust Final Group Project

Andrew Niven & Brian O'Neill 6/7/2021, 8:05pm Tu/Th w/ Bart Massey

Final Group Project Rust Language CANopen Specified Format Randomizer | Rusty-CAN-Fuzzer

What is Rusty-CAN-Fuzzer?

Rusty-CAN-Fuzzer was born out of a desire for more sophisticated randomization of CANopen format messages, which came about as a need when working on the CANopen Monitor project (owned by oresat on Github, that Brian has worked on extensively). The issue arose when we found that the pure message randomization just created a bunch of garbage data without any way to make it adhere to a particular specified message format, which caused issues when we wanted to test specific CANopen formats like PDO, SDO and EMCY.

Rusty-CAN-Fuzzer replicates and greatly expands upon the original python script we used for CANopen test output on canopen-monitor, allowing the use of user generated JSON files defining any kind of existing (or entirely new) CAN formats they desire to create randomized messages that are guaranteed to match the desired behavior/formats.

In testing it has been used most often with canopen-monitor: (https://github.com/oresat/CANopen-monitor)

But can theoretically be used with any CAN compatible interface, as long as the user specifies the correct bus.

How to Demo Application

These steps require a linux system to run successfully

First install the canopen-monitor

pip install canopen-monitor

canopen-monitor is used to view the CAN messages generated by our application.

Run with message format

cargo run -- --message-format assets/emcy.json -r -1

In a new terminal:

canopen-monitor

Ctrl+c to exit

Run with random values

cargo run -- --random-id --random-message -r -1

In a new terminal:

canopen-monitor

Ctrl+c to exit

Run with defined message

cargo run -- --id 80 --message 81 30 00 00 00 00 00 00 -r -1

ctrl+c to exit

In a new terminal:

canopen-monitor

Ctrl+c to exit

Run with Listening Mode on

First, start a listening terminal (which will be in charge of starting and closing the can bus):

cargo run -- -l --listen-log log-file-name -r -1

Start a sending terminal (which should have the --no-destroy option so the can bus isn't destroyed prematurely):

cargo run -- --message-format msgfmt-directory-file-name -r -1 --no-destroy

ctrl+c both terminals to exit

View Help to see all options

clear && cargo run -- -h

How to run automated tests with printlns intact

(which should show our hard-coded test_msg format, and the output of can_id randomization, which should always be within the "cob_id_range" defined at the top of the test_msg_format)

cargo test -- --nocapture

Testing

We have used a combination of automated and manual tests throughout development to build and verify functionality. Due to the randomized nature of the messages, we have had some difficulty creating entirely automated tests, because it is difficult to use an assert_eq! macro, when using randomized numbers.

Process

We were able to achieve our primary goals, that being:

  • Replicate the original socketcan-dev.py functionality from canopen-monitor
  • Create structured formatting message generation
  • Allow the user to generate messages from a CAN message format defined in a JSON file

In addition, further development has been planned on:

  • Creating more sophisticated automated testing with dependency injection
  • Add listen mode to listen for responses from other devices and log responses into a provided log file.
  • Accept multiple msg_format files from a directory to output multiple types of messages

One thing that didn't work as well as we would have liked was that in main.rs, we were trying to pass functions from the msg_format module into other functions as closures so that, for example, we could pass in "random_cob_id" or "random_cob_id_with_format" depending on the user's choice of flags and options, but there was difficulty working with Rust's function type system and closures.

Other than that we are satisfied with our work on the project, as it works as originally intended.

License Information

We used the MIT License, further information is in the file named "LICENSE".

Releases

No releases published

Packages

No packages published

Languages