Few questions about primitive sequence verification and occupation modes

[Hanseltu]

Hi,

Thanks for your inspired and impressive work. I have read your paper and some of the code you have released, but some points in the paper and code are not clear to me. Could you help clarify them? Thanks!

• How does BAGUA exactly verify whether a generated primitive sequence is valid or not? From my understanding, the primitive sequence is code snippets constructed by different primitives, and they are all code. As mentioned in the paper, it's relatively easy for interpreters to combine the primitive sequence with the crash input because the primitive sequence can be put into the input file. When interpreters execute the input file with the primitive sequence, the heap layout in the interpreters can be manipulated, and then the expected heap layout will help exploit certain vulnerabilities. However, how can general-purpose programs, such as the sudo program, achieve the desired heap layout when executing the sudo program by combing the primitive sequence and crashing input? As Section V.F(2) mentioned, we launch new fuzzing campaigns to generate concrete inputs and leverage symbolic execution to facilitate input byte inference when the fuzzer is stuck. The test cases from the fuzzing campaigns in §V-A that trigger desired primitives in the sequence are kept as the initial seeds for the new fuzzing campaigns., I am not sure how to consume it. From my current understanding, does this mean instead of using the initial crash input (the one that can trigger the vulnerability), BAGUA adopts fuzzing and symbolic execution to construct a new input that can both trigger the vulnerability and the expected primitive sequence so that the heap layout in sudo program can be expected during its execution? Is my understanding correct? Thanks.
• The workflow of split and normal occupy_mode in hplayout_generator.py. I can run hplayout_generator.py in my machine now after your fixing on #3 (thanks for your help again!), and the example Exim involves do_split_generate that uses a split mode to generate the expected heap layout. Since I am more interested in using normal mode (within basic capability) for the occupation to analyze some programs, can a normal occupation be used to generate a heap layout for the current Exim example? (I enforced to set the occupy_mode to normal, but I got errors because the size of the target hole and TO is pretty large). Since you may still work on the code cleaning for the final release, can you provide a simple example that can run the normal occupation mode for studying purposes?

Thank you very much for your time and help!

Best regards, Haoxin

[Stab1el]

Thanks for your concern on our paper and code. Firstly, as has been stated in the paper, our work starts from a crash input that triggers and could generate an input which could achieve a desired heap layout before triggering the vulnerability. Secondly, we will give an example using normal mode for manipulation soon to help you better understand our implementation.