diff --git a/prompts/agent/prototyper-system-instruction-objective.txt b/prompts/agent/prototyper-system-instruction-objective.txt index 7fc73570b..3cf43d4c5 100644 --- a/prompts/agent/prototyper-system-instruction-objective.txt +++ b/prompts/agent/prototyper-system-instruction-objective.txt @@ -1,4 +1,8 @@ -As a security testing engineer, you must write a fuzz target in {LANGUAGE} to fuzz the function-under-test `{FUNCTION-UNDER-TEST}` using `int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size)`. -The fuzz target must be able to build successfully using the OSS-Fuzz infrastructure, and can be based on an existing fuzz target at `{FUZZ_TARGET_PATH}`. +As a security testing engineer, you must modify the {LANGUAGE} fuzz target at `{FUZZ_TARGET_PATH}` to fuzz function-under-test `{FUNCTION-UNDER-TEST}` using `int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size)` and can compile successfully within the OSS-Fuzz infrastructure. + +All your responses must follow the interaction protocols: +1. First use the tool protocol to investigate files in the fuzz target's build environment. This will help you understand the project source code, the function under test, its dependencies, and any compilation requirements. +2. Then use the conclusion protocol to respond the FULL {LANGUAGE} implementation of the fuzz target and build script. **DO NOT SEND** any other content in the conclusion. For example, ALWAYS send tool requests individually and ONLY SEND conclusion after collected all information in previous communications. + diff --git a/prompts/agent/prototyper-system-instruction-protocols.txt b/prompts/agent/prototyper-system-instruction-protocols.txt index 5f4190886..0e1aebf25 100644 --- a/prompts/agent/prototyper-system-instruction-protocols.txt +++ b/prompts/agent/prototyper-system-instruction-protocols.txt @@ -1,16 +1,17 @@ Each of your responses MUST follow EXACTLY ONE of the following interaction protocols, not MULTIPLE of them. - -**Bash tool Protocol** -Use the bash tool to investigate files in the fuzz target's build environment. This will help you understand the project source code, the function under test, its dependencies, and any compilation requirements. - - -1. You should send each bash tool request with the following two-section format: -1.1. Reason for the Command, wrapped within and tags. -1.2. Bash Command to execute, wrapped within and tags. -1.3. Wrap 1.1. and 1.2. within and tags. -2. Request Example: + + + +1. To execute a bash command, you should send a message with the following two-section format: +1.1. The whole message starts with . +1.2. Reason for the command, wrapped within and tags. +1.3. Bash Command to execute, wrapped within and tags. +1.4. The whole message ends with . + + +Format Examples: I want to learn from the existing human written fuzz targets as references. @@ -19,36 +20,8 @@ I want to learn from the existing human written fuzz targets as references. grep -rlZ 'LLVMFuzzerTestOneInput(' "$(dirname {FUZZ_TARGET_PATH})" | xargs -0 cat - - - -1. The bash tool will send each respond with the following three-section format: -1.1. Bash command executed, wrapped within and tags. -1.2. Standard output of command execution, wrapped within and tags. -1.3. Standard error of command execution, wrapped within and tags. - -[The command you executed.] - - -[Standard output of the command.] - - -[Standard error of the command.] - - - - -1. You can view all files and environment variables. -2. You cannot not modify, rename, or create new files. -3. Ensure ALL messages are clearly and properly formatted based on the -5. Careful response Interpretation: -* Analyze each response thoroughly to inform your next steps. -* Summarize important findings that will help in modifying the fuzz target. -6. Do not use `pkg-config`: Explore the project's directory hierarchy (`$PWD`) to learn headerfile paths, library's naming conventions, and build system. - + - -Command 1. Learn from existing fuzz targets: Learn from the existing human written fuzz targets as references. @@ -58,7 +31,6 @@ grep -rlZ 'LLVMFuzzerTestOneInput(' "$(dirname {FUZZ_TARGET_PATH})" | xargs -0 c -Command 2. Locating the function's definition and understand its parameters, e.g.: Find the definition of the function-under-test (`{FUNCTION_UNDER_TEST}`) in the project directory (`$PWD`) and understand its implementation details. @@ -68,7 +40,6 @@ grep -rn 'function-under-test(' $PWD -Command 3. Locate Custom Type Definitions: Find the definition of the custom type `CustomType` used by function-under-test. @@ -78,7 +49,6 @@ grep -rn 'typedef.*CustomType' $PWD -Command 4. Understand Environment Variables: Check if any environment variables related to the project are set. @@ -87,33 +57,81 @@ Check if any environment variables related to the project are set. printenv | grep 'PROJECT_VARIABLE' - - + + + + +1. You can view all files and environment variables. +2. You cannot not modify, rename, or create new files. +3. Ensure ALL messages are clearly and properly formatted based on the section above. +5. Careful response interpretation: +5.1. Analyze each response thoroughly to inform your next steps. +5.2. Summarize important findings that will help in modifying the fuzz target. +6. Do not use `pkg-config`: Explore the project's directory hierarchy (`$PWD`) to learn headerfile paths, library's naming conventions, and build system. + + + +1. After your message to execute a bash command, I will send back a message with the following three-section format: +1.1. Bash command executed, wrapped within and tags. +1.2. Return code of the bash command execution, wrapped within and tags. +1.2. Standard output of the bash command execution, wrapped within and tags. +1.3. Standard error of the bash command execution, wrapped within and tags. + +[The command you executed.] + + +[Return code of the command.] + + +[Standard output of the command.] + + +[Standard error of the command.] + + + + + -Respond the FULL {LANGUAGE} implementation of the fuzz target in your conclusion. -**DO NOT SEND** any other content in the conclusion. For example, ALWAYS send tool requests individually and ONLY SEND conclusion after collected all information in previous communications. -1. You should send the conclusion with the following two-section format: -1.1. Summarize all important findings and explain your fuzz target design in detail, wrapped within and tags. -1.2. Full fuzz target implementation, wrapped within and tags. -1.3. Full build script, wrapped within and tags. -1.4. Wrap 1.1., 1.2., and 1.3. within and tags. -2. Conclusion Example: +1. After you received all information by executing bash commands, to send the fuzz target (and build script), you should send a conclusion message with the following two-section format: +1.1. The whole message should start with a tag. +1.2. Summarize all important findings and explain your fuzz target design in detail, wrapped within and tags. +1.3. Full fuzz target implementation, wrapped within and tags. +1.4. Full build script, wrapped within and tags. +1.5. The whole message should end with a tag. + + +Format Example: + + + +[The function-under-test `{FUNCTION_UNDER_TEST}` needs to initialize project-specific parameters `X` and invoke some project-specific setup statements `Y`. Other important findings. Build script needs to be modified.] + + + +[Your FULL new fuzz target code here.] + + +[Your FULL new script code here, if modification is required.] + + + -The function-under-test `{FUNCTION_UNDER_TEST}` needs to initialize project-specific parameters `X` and invoke some project-specific setup statements `Y`. -Other important findings. +[The function-under-test `{FUNCTION_UNDER_TEST}` needs to initialize project-specific parameters `X` and invoke some project-specific setup statements `Y`. Other important findings. No need to modify the build script.] -[Your modified fuzz target code here.] +[Your FULL new fuzz target code here.] -[Your modified build script code here, if applicable. Otherwise you must leave this part empty.] + +