emulate error

[zhangpwxwk]

Hello Tobi: When I emulate my firmware, some errors occor. fuzzware emu -c config.yml -v -d -M IPMI_F407.bin >emu.log The errors: Basic Block: addr= 0x0000000008001358 (lr=0x0) Basic Block: addr= 0x0000000008001358 (lr=0x0) Basic Block: addr= 0x0000000008001358 (lr=0x0) Basic Block: addr= 0x0000000008001358 (lr=0x0) Basic Block: addr= 0x0000000008001358 (lr=0x0) Basic Block: addr= 0x0000000008001358 (lr=0x0) Basic Block: addr= 0x0000000008001358 (lr=0x0) Basic Block: addr= 0x0000000008001358 (lr=0x0) Basic Block: addr= 0x0000000008001358 (lr=0x0) Basic Block: addr= 0x0000000008001358 (lr=0x0) Basic Block: addr= 0x0000000008001358 (lr=0x0) Basic Block: addr= 0x0000000008001358 (lr=0x0) Fuzzing input not consumed for 150000 basic blocks, exiting [FORKSERVER SETUP] It looks like we are not running under AFL, going for single input [ERROR] Could not retrieve the number of required ticks during discovery forking

The mcu I use is GD32F407 compatible with stm32f407.
I check the source code of my firm, I get the assembly code:
 /* Copy the data segment initializers from flash to SRAM */  
 movs  r1, #0
 b  LoopCopyDataInit

 CopyDataInit:
 ldr  r3, =_sidata
 ldr  r3, [r3, r1]
 str  r3, [r0, r1]
 adds  r1, r1, #4

LoopCopyDataInit: ldr r0, =_sdata ldr r3, =_edata adds r2, r0, r1 cmp r2, r3 bcc CopyDataInit ldr r2, =_sbss b LoopFillZerobss

    Should I change the limit of fuzz_consumption_timeout(150000) ?     Do you have any good Ideas？

Best ZP

[Scepticz]

Yes, this firmware may just have a too long initialization sequence. You can increse the limit if you like. For the memset operation you can also consider removing/patching out the zero-setting loop (in case the memory is newly mapped as null bytes anyways.

[zhangpwxwk]

Hello Tobi: I try to increase the limit use the command below: fuzzware emu -c config.yml -v -d -M --fuzz-consumption-timeout 1000000 IPMI_F407.bin >emu1.log The error still occurred. Basic Block: addr= 0x0000000008001358 (lr=0x0) Basic Block: addr= 0x0000000008001358 (lr=0x0) Basic Block: addr= 0x0000000008001358 (lr=0x0) Basic Block: addr= 0x0000000008001358 (lr=0x0) Fuzzing input not consumed for 1000000 basic blocks, exiting [FORKSERVER SETUP] It looks like we are not running under AFL, going for single input [ERROR] Could not retrieve the number of required ticks during discovery forking

My firmware is a real-world MCU firmware, so I think some firemware can't be fuzzed by fuzzware.The reason is unknown. I try some other firmwares run on GD32F407, They can successfully run on fuzzware,and many crashes occur. I think if we can find the reason , we can improve the fuzzware. How can we solve this problem? Is a debugger(such as gdb) integrated by fuzzware? Best ZP

[Scepticz]

Did you look into the firmware and see what code resides at that address? It is likely a simple/tight infinite loop which is triggered due to an assertion. There most likely is the assertion code just before that.

You can use fuzzware emu -c config.yml -v -d -M --fuzz-consumption-timeout 1000000 -b 0x0000000008001358 IPMI_F407.bin to get an interactive Python shell for debugging. However, it will likely make more sense to just reverse engineer what is happening at that point in the code. If I had to guess blindly, this could be because an MMIO region outside the usual 0x40000000 range is present on the board and is missing an entry as an MMIO range.

[zhangpwxwk]

Hello: I'm glad to tell you that my firmware 'IPMIF407.bin' can now run on fuzzware. I adopted Scepticz's suggestion and reverse 'IPMI F407. elf' using IDA_pro_7.7. I found a problem. The 'entry_point' of my firmware is 0x8001340. The instruction is: LDR.W SP, =0x20020000 When I search the instruction LDR.W SP, =0x20020000 in 'IPMI_F407.bin' whitch is generated by fuzzware genconfig IPMI_F407.elf , I find the instruction address is 0x8001308 not equal to 0x8001340. Then I check the 'IPMI_F407.bin' whitch is generated by compile, The instruction in address 0x8001340 is LDR.W SP, =0x20020000. So when I emulate 'IPMI_F407.bin' whitch is generated by fuzzware genconfig IPMI_F407.elf ,the errors occor. It seems that , somtimes , the bin file genrated by genconfig has an address offset from the actual bin file.I think this is an uncommon mistake. I also try some other firmware, I didn't find this error.