fuzzware icon indicating copy to clipboard operation
fuzzware copied to clipboard

Unable to identify BB 0x80002a0 in uEmu.3Dprinter

Open B03901108 opened this issue 1 year ago • 6 comments

Hi, I encountered an issue when running Fuzzware on uEmu.3Dprinter. Fuzzware seems unable to list BB 0x80002a0 in the BB trace/set of a test case that covers this BB. As a result, Fuzzware never declares the discovery of this BB during fuzzing even if some of the test cases cover this BB. BB 0x80002a0 is in valid_basic_blocks.txt. It also looks legit in the firmware disassembly. Did you come across similar issues before? Thank you.

Here are some details of the issue. I ran Fuzzware (commit d047baf) on an Intel Xeon E5-2683 v4 server (Ubuntu 22.04.3 LTS). I ran the unmodified Fuzzware on uEmu.3Dprinter five times, each time 24 hours on four cores. Then, I modified Fuzzware such that native/time.c only counts the BBs in valid_basic_blocks.txt for periodic interrupt firing and an empty code hook is used conditionally. The test harness running with a test case only applies the hook if a specific token exists in the local directory. With the modified native/time.c, the control flow of uEmu.3Dprinter running with a test case should remain the same with or without the code hook.

I ran the modified fuzzware_harness.harness on a high-coverage test case, with and without the code hook. The control flow changed when the harness applied the code hook. After debugging, I noticed that using the code hook led to extra BBs (0x80002a0) in the BB trace. Based on the BB traces with and without the code hook, the test case should cover BB 0x80002a0 anyway. I modified native/time.c again to ignore this BB for periodic interrupt firing. The control flow is then the same with or without the code hook.

So far, the modified Fuzzware (including the harness) works well for other firmware from P2IM and uEmu. Feel free to ask for additional information if that helps.

B03901108 avatar Feb 01 '24 09:02 B03901108