Open zhangpwxwk opened 11 months ago
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.
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
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.
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.
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
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