All students must complete a self-directed research project to pass the course. Students can choose their own topics, but they must relate to one of the skills covered in the course and demonstrate their mastery of it.
Goals of the project
- Allow you to explore whichever technical skill in the course you're most interested in
- Display your mastery of that technical skill
- Document your experience for others like you to follow and learn from
- Vulnerability assessment of an application, including web or mobile applications, plugins, or network services
- Reversing of a malware for vulnerability discovery and potential exploitation
- Reversing of undocumented functionality or protocols (talk to me first)
- Completing a moderate-to-difficult CTF challenge, bomb lab, or wargame
- Demonstration of exploit techniques beyond jumping to the stack and generic SEH overwrites
- Redevelopment of unreliable, untested, and undocumented public exploit code to Metasploit code
- Development of shellcode for a non-x86 CPU architecture
- Interesting, creative or unique post-exploitation tools or scripts
- Development and use of a fuzzer module for an unexplored area of functionality or application
- Development of static analysis tools for application-specific bugs, particularly web app plugins
- Anything else you propose that fits with the theme of the class
- The paper describing your project must be written on the HowToHack wiki
- There is no length minimum or maximum, as long as the paper meets the stated goals of the project
- Any code included in the project must be thoroughly documented
- You must arrange be on campus for your snake fight before you can receive a grade
I always get asked for interesting, specific targets to analyze so I've taken to maintaining a list here. You might also want to look at some past projects that students have done (although I have been awful at maintaining that list).
- Any document readers are usually easy to write fuzzer modules for. In particular, 3rd party PDF readers seem to lack many exploit mitigations and lack thoroughly audited code.
- Indigenous software is always a fun target. Try to break or exploit a popular piece of software that's only found in a foreign country (your home country).
- IM clients seem attractive at first, but there is actually quite a bit of setup involved in practically auditing and exploiting them since you need two clients, a server, and some means to encode your communications in the targeted protocol. Same with VoIP clients.
- I love seeing applications written for security fail, particularly password managers that leave key material exposed in memory.
- Academic software is almost universally awful, but avoid Blackboard since they have been known to sue researchers. Anything in use at Poly that you can get a copy of or any up-and-coming academic software like the Canvas LMS would be great targets though.
- There are dozens of exploits for Wordpress begging to be integrated with something like wpscan. There are also hundreds more vulnerabilities like those waiting to be found in other plugins, including plugins for similar PHP projects like Drupal.
- It might be interesting to analyze a group of browser plugins (IE or Firefox) for vulnerabilities. The attack surface is limited, so you might want to focus on one class of flaws and automate your discovery of them across a larger set of plugins.
- If you're doing anything exploit-related, look at: PortingExploits, AdvisoryToExploit, ContributingToMetasploit
- If you're doing anything fuzzer-related, you should stick to Peach unless you have a good reason not to.