boofuzz
boofuzz copied to clipboard
jtpereyda
Fuzz a bitfield of various fixed bit sizes
A requirement for protocol fuzzing is to have protocol header(s) split into various fixed size fields (e.g. 4b, 20b, 8b etc.) for protocol options. These fields require to be defined separately, specified as fuzzable or non-fuzzable and afterwards assembled together to be sent to the target socket. Currently Boofuzz pads the bitfield to the next byte boundary, therefore introducing unneeded bytes into the protocol header.
Consider an IPv6 header test case:
s_bit_field(0b0110, 4, fuzzable = False, name = "Version") s_bit_field(0b00000000, 8, name = "Traffic_Class") s_bit_field(0b00000000000000000000, 20, name = "Flow_Label") s_bit_field(0b0000000000100000, 16, name = "Payload_Length") s_bit_field(0x06, 8, name = "Next_Header") s_bit_field(0xff, 8, name = "Hop_Limit") s_binary("0x2a071180000200000000000000bb0001", name = "Source_Address") s_binary("0x2a071180000200000000000000bb0002", name = "Destination_Address")
A Bofuzz feature supporting this would be highly required in order to ensure raw binary (e.g. L2,L3) protocol fuzzing.
More information on feature discussion is here: https://groups.google.com/forum/#!topic/boofuzz/7rZeBYnEyV0
[First of all: Is it better to discuss this issue here or on the mailing list thread?]
I really need this feature, and I'm thinking about giving it a shot in the next few days. I saw some directions on the code I'd need to touch on the mail, so I'll start trying to implement it.
I've tried the sulley_l2 pointed out in the mail thread as well, but it gives me the same packet here (with padded bitfields).
Both work, but the Github issue is just fine; it's a good reference for future implementers or for finding the reasoning behind changes.
God speed. Let me know if you have any questions. On Mon, May 15, 2017 at 7:15 PM Bruno Melo [email protected] wrote:
[First of all: Is it better to discuss this issue here or on the mailing list thread?]
I really need this feature, and I'm thinking about giving it a shot in the next few days. I saw some directions on the code I'd need to touch on the mail, so I'll start trying to implement it.
I've tried the sulley_l2 pointed out in the mail thread as well, but it gives me the same packet here (with padded bitfields).
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jtpereyda/boofuzz/issues/88#issuecomment-301647587, or mute the thread https://github.com/notifications/unsubscribe-auth/AAO86X50lt6ZgDlYmL0b-FCk7nmYX__2ks5r6PjKgaJpZM4KGQB0 .
This one will be really useful. As a solution we could somewhat combine two bitfields with shift and or. The algo may be quite simple, assume that FIRST and SECOND is a bitfields then we can combine it just like that:
FIRST << 8 - FIRST.width | SECOND
will work if FIRST and SECOND is a big-endian bitfields
I am taking a look at the several discussions on this topic to learn about the issues and desired enhancement.
I spent time digging into the code and I cannot see that it has the ability to support bit field manipulation. I also see the strong potential for user disagreement on endianess interpretation so to make this work there needs to be some clear definitions on which bit we are manipulating. So - I am concerned that this may be a fruitless effort. I need some advice from this group and discussion on what we could hope to achieve. Thanks for the reminder! I look forward to keeping this discussion going. Currently my open source contribution time is being used on my other open source project: https://github.com/CycloneDX/cyclonedx-buildroot which is making progress as a new project.
@ptdropper This is not a trivial change at the moment, certainly, but the requirements are basically to allow BitField to take a number of bits not divisible by 8. What questions about endianness do you have in mind?