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 'IPMI_F407.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.