ObFuzzer: Object-Oriented Hybrid Fuzzer for Binaries
Round 1
Reviewer 1 Report
In Figure 6 (a, b and c), please ad more clarification about boundary conditions in case if there are pointers involved (they can change variable value at any time).
In line 521 you are using word "dangerous" - explain pls.
In line 683-691 you are explaining the overhead of overhead introduced by Intel Processor Trace. What about the impact of it in AFL and AFL-Honeybee?
In my opinion the chapter 7 , Related word, should be treated much earlier i.e. it should be in chapter 2 or 3.
Author Response
Please see the attachment.
Author Response File: Author Response.docx
Reviewer 2 Report
Dear editor
The study is interesting. However, the contribution of this work is not clear for the reader. In addition, the presentation of the paper needs significant improvements. Some recommendations about the paper are given below:
Some recommendations about the paper are given below:
1. Clarify what is the paper contribution and what parts of the paper are original.
2. The aim and objectives are not clearly defined and presented. These need to be specific and relate to the actual research conducted, not generic.
3. I would like to see more discussion of the literature so that I can clearly identify the article relates to competing ideas.
4. It would be best to explain more about the background of this subject.
5. The major part of the sections 3 is about basic theory. The authors are suggested to rewrite this section in order to present their contribution clearly.
6. The authors are recommended to add Figure for the schematic diagram of the optimized methodology.
7. The results are not presented very well. In addition, it is not clear for the readers.
8. There are several grammatical mistakes. Please work close to a native English speaker to refine the language of this paper.
9. The word’’ we’’ is not used in academic writing style.
Author Response
Please see the attachment.
Author Response File: Author Response.docx
Reviewer 3 Report
The authors must provide:
Details of the algorithms (using algorithmic notation) used by them should be provided for statics analysis, scoring potential error points and different aspects of test-case generation. Further, they should explicitly state the novelty in their approach for each component.
Annotation of the axes in Figure 10
It would be interesting to see how the proposed approach works for programs involving instances of more complex objects like stacks, queues, binary trees, and so on.
Ideally, the authors should provide at least an executable version of the software and the programs on which it has been evaluated along with instructions for using the software. The article fails to document even the test cases generated by the proposed tool and which of those test cases were also being generated by the existing tools.
The article also needs to be improved grammatically. For example,
line 7: we get the information of basic blocks with more complex object operations by static analysis: It would be nice to discuss the degree of complexity in the main text.
line 26: When the target program is been executed: Please replace been by 'being'.
lines 32-34: "Therefore, many vulnerabilities have been found in this technology. As the coverage-guided fuzzer has been extensively used. The fuzzer guided by coverage is getting harder to discover vulnerabilities." Needs rewriting.
line 48: In fact, the authors are stating additional facts rather than contradicting when they say: "We can find that these types of vulnerabilities break the assumption that program vulnerabilities exist in code that has not been executed in the traditional coverage-guided fuzzing technology."
line 324, " ... real-world program more difficult it is for the programmer to guarantee its reliability.", Reliability touches upon dimensions other than correctness.
Author Response
Please see the attachment.
Author Response File: Author Response.docx
Round 2
Reviewer 2 Report
The authors have answered the comments.