Slashdot Mirror
Including Source for a Potential Hacking Tool?
rajinder asks: "What are the experiences of Slashdot folk when it comes to including the source code of a security tool in their final year dissertation? I have a project in mind that I want to submit that can be used by admins to evaluate the security of their wireless network(s), but it could just as easily be used for their nefarious purposes. Before I submit the idea, I wanted to see if anyone knew of potential hurdles I would have to face. Anybody ever done something similar? The official rules about what is allowed is available in this PDF [or the HTML version], but I don't see anything relevant to my dilemma (the relevant section is 2.4, page 9) UK university-system specific info would be appreciated, but I plan on carrying on my education in the US, so info from either side of the pond would be good. Does anyone know if I would be able to GPL the code afterwards and put it out there? Would it remain property of the University or the student that wrote it?"
For that you have to contact your undergrad advisor.
For me it was possible to GPL the code.
Some profs however like to keep it.
Some universities have different rules as to this sort of thing.
Sometimes you can get away with a simple NDA in the Document.
I would ask you specific registrar/school office about the detailed rules that you have to abide by.
Unless specified by your university the final year dissertation is your own, or at most it can be your and your advisor's, or similar things. You're required to give a (certain number of) copy(es) to your university library, and they will let the public see it, but that's not public domain.
Of course different universities have different policies, so you may end up with stricter conditions, here the rule is to ask local competent people (if reading the official rules doesn't help).
A few things:
1) Unless you sign an IP agreement (usually for an industry funded research project) you can GPL it.
2) The dirty little secret the mainstream security industry doesn't want you to know is that all the useful & good tools security tools are open source. In general, you risk losing credibility among your peers if your software is NOT open source.
3) If your project has to do with wireless (in)security it's likely not going to be very novel. Just about all the wireless encryption standards (GSM A/51, W/TLS, WEP) are all broken with implementations to verify this.
4) Security researchers long ago realised that full disclosure is the only way to fix security vulnerabilities. Besides as another poster pointed out kiddiez will not understand your paper, only serious security researchers. And in general, they probably already know whatever it is your paper is going to be about.