First input byte in 04-crash-analysis/08

[dingiso]

I have encountered a curious problem which have bothered me for hours. Ask for help :sob:

I'm working on how unicorn accept the input from fuzz. I compared the crashing_input with the log generated by replay command and everything goes right except the first byte

this log entry is like this

>>> Read: addr= 0x0000000040023808 size=4 data=0x00000000 (pc 0x08001b04)

and the model generated by fuzzware is

set:
    pc_08001b04_mmio_40023808:
      access_size: 0x4
      addr: 0x40023808
      pc: 0x8001b04
      vals:
      - 0x0
      - 0x4
      - 0x8

the first byte generated by fuzzer is 0x20 so the data should be

data = vals[0x20 % len(vals)]
     = vals[32 % 3]
     = vals[2]
     = 0x8

But the data in log is 0x0. Other read operations are all right , so I think it's not my model's wrong. Is there any hints or something I misunderstood ?

Thanks.

[Scepticz]

Hi dingiso,

one option that you can enable to analyze this a bit further is the DEBUG define here: https://github.com/fuzzware-fuzzer/fuzzware-emulator/blob/20a3deb9227606f2efd88baa345bc3ad695d34a2/harness/fuzzware_harness/native/native_hooks.h#L8

Commenting this in and re-building the native library (make clean all in the native dir should provide more debug output for this.

Did you use the most recent version of the emulator? We fixed an issue with the set model parsing here: https://github.com/fuzzware-fuzzer/fuzzware-emulator/commit/20a3deb9227606f2efd88baa345bc3ad695d34a2. However, for the crash reproduction, using the most recent emulator version may lead to the firmware no longer crashing, as the emulator behavior changed. Unfortunately, the behavior of the firmware is very timing dependent, so that even smallest changes to the emulator can change control flow during firmware emulation.

Best Tobias

[dingiso]

Thanks Tobias. I will try