Unexpected Files in base_inputs and Signa6 Error During Crash Input Analysis in Fuzzware

[zhangpwxwk]

Dear author:

Issue Description

I am encountering two issues while using Fuzzware for firmware simulation:

Issue 1: Unexpected Files in base_inputs Directory

After specifying the fuzz testing input, the files in the base_inputs directory within the session directory are not the ones I specified. Instead, the directory contains the files 01_base_input_512_ones and 02_base_input_512_zeroes. I have not been able to identify the cause of this issue. The command I used is as follows:
fuzzware pipeline targetdir -i targetdir/base_inputs –run-for 24:00:0

Issue 2: Signa6 Error During Crash Input Analysis

When analyzing a crash input after fuzz testing, the input generated a signa6 error. The command I used is as follows:
fuzzware replay -M -t targetdir/fuzzware-project/main001/fuzzers/fuzzer1/crashes/id:000000,sig:06,src:000000,op:havoc,rep:128
The final write operation traced is as follows:
Write: addr= 0x00000000e000ed0c size=4 data=0x05fa0304 (pc 0x08002326)
Upon inspecting the assembly code using a disassembler, I found that this operation writes to the Application Interrupt and Reset Control Register (AIRCR) as per the Cortex-M4 Technical Reference Manual.

In the cortexm_nvic.c file, I found the following two lines of code:
uc_hook_add(uc, &hook_mmio_write_handle, UC_HOOK_MEM_WRITE, hook_sysctl_mmio_write, NULL, SYSCTL_MMIO_BASE, SYSCTL_MMIO_END);
uc_hook_add(uc, &hook_mmio_read_handle, UC_HOOK_MEM_READ, hook_sysctl_mmio_read, NULL, SYSCTL_MMIO_BASE, SYSCTL_MMIO_END);

These lines add a Unicorn hook function for read/write operations to this address range. Why does a signa6 error still occur?

[zhangpwxwk]

Dear authors,

I have submitted the simulated binary program and configuration file for review. Could you please help me identify any issues as described earlier? Additionally, I would appreciate any guidance on potential solutions. Thank you very much for your help!
IPMI.zip

[zhangpwxwk]

Dear author,

This issue has been investigated using the following command:

fuzzware emu -c config.yml -t -v -d -M /home/user/fuzzware/targets/IPMI/fuzzware-project/main001/fuzzers/fuzzer1/crashes/id:000002,sig:06,src:000000,op:havoc,rep:128
It was found that through decompilation and source code analysis, it was determined that within the HAL_RCC_OscConfig function, a read and judgment of the value at 0x40023808 register led to a return of HAL_ERROR(1). Subsequently, the Error_Handler function was invoked, which in turn called NVIC_SystemReset, resulting in a reset of the MCU, halting the simulation process.

Upon referencing the datasheet of the GD32F4xx microcontroller, it was discovered that the 0x40023808 register corresponds to the RCU_CFG0 register, similar in function to the RCC_CFGR register in the STM32F4xx microcontroller, serving as the RCC clock configuration register. The value read from this register was provided by the fuzzing engine and does not align with the actual hardware functionality of the controller. Therefore, this issue is a false positive and not a genuine bug.

[Scepticz]

Hi there,

Regarding issue 1, files may be removed as afl-cmin is used on main001/base_inputs_non_minimized, the output in main001/base_inputs is then the minimized version of the original base inputs.

Great that you have found the reason for the reset (Issue 2).

Do you have any more questions regarding this issue?

Best
Tobi

[zhangpwxwk]

Hi Tobi,

Thank you for your response .

Regarding Issue 1, thank you for explaining the process. It seems that afl-cmin is used on main001/base_inputs_non_minimized, and the output in main001/base_inputs is then the minimized version of the original base inputs. Could you please provide more details on how afl-cmin is being used in this process? Additionally, it would be helpful to understand the specific steps involved in the minimization process and how the input files are selected for minimization.

Thank you for your assistance in resolving this matter.

Best regards,
Zhang