I am seemingly having some issues getting fields to mutate within a defined structure. The simplest way to reproduce this is to remove the Fixup implementation on the example_fuzzer and comment out the connecting, and sending packets.
The mutator will also ignore any #[lain(ignore)] flags on the first field of the structure and still do a walking bit-flip pass. While this is just odd behavior, the real problem is the lack of mutation on the fields within the structure even during Havoc mode mutations. I have run this through 300 million iterations looking for a change in length with this setup and have yet to see one. Additionally, typ does not seem to mutate after the initial run through bit flips. Looking through the code it looks like there may be an issue with duplicated unsigned fields? I am not sure how this could happen, and I am still looking around the code, but obviously offset is being mutated properly. Based on the trace! info, typ is getting into the macro generated mutate function, but then failing to call mutate_from_mutation_mode. Meanwhile the length field seems to be placed under what looks to be an ignore flag, by trying to get the 1% chance to ignore the flag.
Obviously this could be chalked up to the mutator focusing on a single field first, but that is not my understanding of how Havoc works, so I am curious if there is any other insight on this issue, or if it is reproducible for other people.
Sending packet: PacketData { typ: Invalid(2), offset: 17328406766963615603, length: 16032434953803588567, data: [] }
[2019-09-04T00:26:03Z TRACE lain::mutator] generating number between 0 and 2
[2019-09-04T00:26:03Z TRACE lain::mutator] got 0
[2019-09-04T00:26:03Z INFO lain::mutator] Havoc
[2019-09-04T00:26:03Z INFO lain::mutator] num is: 2
[2019-09-04T00:26:03Z INFO lain::mutator] 0, 1, 1, 543
[2019-09-04T00:26:03Z TRACE lain::mutatable] Mutating unsigned value
[2019-09-04T00:26:03Z INFO lain::mutator] Havoc
[2019-09-04T00:26:03Z INFO lain::mutator] num is: 17328406766963615603
[2019-09-04T00:26:03Z INFO lain::mutator] 1, 1, 1, 543
[2019-09-04T00:26:03Z TRACE lain::mutator] Operation selected: BitFlip
[2019-09-04T00:26:03Z TRACE lain::mutator] xoring bit 33
[2019-09-04T00:26:03Z TRACE lain::mutatable] Mutating unsigned value
[2019-09-04T00:26:03Z INFO lain::mutator] Havoc
[2019-09-04T00:26:03Z INFO lain::mutator] num is: 16032434953803588567
[2019-09-04T00:26:03Z INFO lain::mutator] 2, 1, 1, 543
[2019-09-04T00:26:03Z TRACE lain::mutator] generating number between 0 and 100
[2019-09-04T00:26:03Z TRACE lain::mutator] got 85.98688
[2019-09-04T00:26:03Z TRACE lain::mutator] generating 1% chance. got 85.98688, so returning false
[2019-09-04T00:26:04Z TRACE lain::mutator] generating number between 0 and 100
[2019-09-04T00:26:04Z TRACE lain::mutator] got 72.75632
[2019-09-04T00:26:04Z TRACE lain::mutator] generating 1% chance. got 72.75632, so returning false
[2019-09-04T00:26:04Z DEBUG example_fuzzer] getting serialized size of PacketData
[2019-09-04T00:26:04Z TRACE lain::buffer] getting serialized size for Vec
[2019-09-04T00:26:04Z TRACE lain::buffer] returning 0 since there's no elements
[2019-09-04T00:26:04Z DEBUG example_fuzzer] size of PacketData is 0x14
[2019-09-04T00:26:04Z DEBUG example_fuzzer] getting serialized size of PacketData
[2019-09-04T00:26:04Z TRACE lain::buffer] getting serialized size for Vec
[2019-09-04T00:26:04Z TRACE lain::buffer] returning 0 since there's no elements
[2019-09-04T00:26:04Z DEBUG example_fuzzer] size of PacketData is 0x14
Sending packet: PacketData { typ: Invalid(2), offset: 17328406775553550195, length: 16032434953803588567, data: [] }
I am seemingly having some issues getting fields to mutate within a defined structure. The simplest way to reproduce this is to remove the
Fixup
implementation on the example_fuzzer and comment out the connecting, and sending packets.The mutator will also ignore any #[lain(ignore)] flags on the first field of the structure and still do a walking bit-flip pass. While this is just odd behavior, the real problem is the lack of mutation on the fields within the structure even during Havoc mode mutations. I have run this through 300 million iterations looking for a change in
length
with this setup and have yet to see one. Additionally,typ
does not seem to mutate after the initial run through bit flips. Looking through the code it looks like there may be an issue with duplicated unsigned fields? I am not sure how this could happen, and I am still looking around the code, but obviouslyoffset
is being mutated properly. Based on the trace! info,typ
is getting into the macro generatedmutate
function, but then failing to callmutate_from_mutation_mode
. Meanwhile thelength
field seems to be placed under what looks to be anignore
flag, by trying to get the 1% chance to ignore the flag.Obviously this could be chalked up to the mutator focusing on a single field first, but that is not my understanding of how Havoc works, so I am curious if there is any other insight on this issue, or if it is reproducible for other people.