IFN657 - Analyse Any Open Source Project In C/C++ - IT/Computer Science Assignment Help

Assignment Task

Overview 
This assessment is individual work to be submitted via Blackboard. While you can discuss the assessment with your tutors and peers, your submissions must be your own original work. 
We have had some experience of buffer overflow and other common software vulnerabilities. The objective of this assignment is to analyse vulnerabilities in real-world software with basic fuzzing. You will gain hands-on experience with investigating and documenting vulnerabilities (optionally exploiting them) and understand some of the benefits and costs of fuzz testing. 
Choose a Target 
You are free to analyse any open-source project in C/C?? (so that AFL can instrument the source code). Any target project should contain at least 3000 lines of code and optionally include a test suite. You may find many different projects listed on GitHub, SourceForge, GNU, or other public repositories of open-source software. For example, just to name a few common software: openssl, boringssl, c-ares, json, lcms, libarchive, libxml2, openthread, pcre2, re2, sqlite, vorbis, woff2. 
You can choose some older outdated software where it may be easier to find bugs, or some newer up-to-date software where finding bugs may be harder but also more interesting. Moreover, the more well-known the software is, the less number of vulnerabilities it will likely have (you aren't the only one looking for bugs). To keep it simple, choose some software that can take a single file as input on the command line. Please ask if you have questions about the suitability of particular software. 
Keep in mind that there is always a possibility that AFL cannot find any bug in some software or some versions of the software. After all, the fuzzing process is probabilistic and the software may be largely bug-free. Therefore, you may need to scan multiple software with AFL until you find bugs. But you only need to report the software of your best attempt. 
Investigate Vulnerabilities 
You should investigate the crashes reported by AFL and find out if they are vulnerable. For each vulnerability, you should provide the following details in your report: 
What is the cause of the vulnerability? (i.e. what is the fundamental bug in the code that causes it)? You should be very specific (e.g. if it's a buffer overflow, explain what the specific error with use of buffer is, and how the given input file triggers this error). 
Where does the vulnerability take place (i.e. where in the code of the target is it located)? Please specify the source file and line number, as well as any other functions that are relevant to creating the conditions of the bug. 
How exploitable is this vulnerability? Does it just crash the program, or can the attacker take advantage of it to do more things (inject shellcode, corrupt metadata used by memory management, etc.?? What would an attacker need to do in order to exploit? 
How would you fix this vulnerability? (i.e. how would you modify the specific code of the program to prevent this vulnerability?? 
Include at least one input file that reproduces the vulnerability. If the input is text-based, you can include it in the appendix of the report; otherwise, submit along with the report (you report should provide the instruction of using the input to reproduce the vulnerability). 
Please note that some vulnerabilities are more interesting and/or easier to document than others. In case that AFL reports lots of vulnerabilities, feel free to investigate several before picking the specific ones you want to document. 
If the vulnerabilities you find are already documented where else, you must give references to previous reports (and/or their CVE numbers if available). You should provide full evidence of how you detect the known vulnerabilities by your own analysis (see the marking criteria below).
Exploit Vulnerabilities  
For students seeking challenges, you may optionally construct a working exploit (along with instructions on using it) that successfully leverages one of the vulnerabilities you find to exploit the software in some manner. At a minimum, the exploit must do more than just crash the program. If you include an exploit, please also include the following in your report: 
The expected consequence of using your exploit on the software, as well as some proof showing that the exploit works. 
Detailed instructions on how to compile and run the exploit code, as well as how to verify the results. 
A brief description of why the exploit works and how it leverages the vulnerability you find in the software. 
Please note, in order to receive any bonus credit, your exploit must be original and created by yourself. You exploit code needs to be submitted along with the report. 
Document the Process 
You will document the details of your experience with fuzzing in a report. You must explain your approach and report your findings in a self-contained and understandable way. For us to understand the report better, you may include screenshots or other means (e.g. graphs or diagrams) as evidence of successful fuzzing, which must be clearly visible and easy to read. If gdb is used to analyse the vulnerabilities, you may use screenshots to explain how you use gdb to find out the memory or code information. Screenshots can be either placed in the main text of the report or in the appendix (in which case they should be clearly marked and referenced in the main text). Remember, the goal of your report is to clearly show what you have done. 
In the last part of your report, you should reflect on the challenges you faced during this process, as well as your approaches to overcome them. You should observe the strengths and weaknesses of the fuzzing and/or sanitiser tools you used for the projects you examined. If any, are these reflected in your results and why?
In addition to the write-up, you should also include (in the appendix) any test harnesses, input test files corresponding to vulnerabilities along with the output of the overall testing process. As previously mentioned, you should submit any non-text inputs (e.g. images, sounds or other binary formats) along with the report. 
While you are free to organise your report in any suitable way, you may choose to use the following structure as a guideline. 
Introduction 
Target Software (e.g. details and characteristics of a chosen software such as size/features) 
Fuzzing Process (e.g. compilation including necessary modification of the build process, harness, statistics of fuzzing runtime such as time/crashes/coverage etc.) 
Result Analysis (e.g. investigation of AFL outputs, identification of vulnerabilities and suggestion of fixes) 
Optional) Exploitation (e.g. the process of exploitation) 

This IFN657 - IT/Computer Science Assignment has been solved by our IT/Computer Science Experts at My Uni Paper. Our Assignment Writing Experts are efficient to provide a fresh solution to this question. We are serving more than 10000+ Students in Australia, UK & US by helping them to score HD in their academics. Our Experts are well trained to follow all marking rubrics & referencing style.

Be it a used or new solution, the quality of the work submitted by our assignment experts remains unhampered. You may continue to expect the same or even better quality with the used and new assignment solution files respectively. There’s one thing to be noticed that you could choose one between the two and acquire an HD either way. You could choose a new assignment solution file to get yourself an exclusive, plagiarism (with free Turnitin file), expert quality assignment or order an old solution file that was considered worthy of the highest distinction.