The personal wiki of ...

Hack-a-Vote: Phase 2 Group Report

Here are some guidelines on what the report should look like, its length and content. Note that the intention is for this to be a lightweight report. Please make sure you spellcheck and look for simple grammatical errors before you submit it.

With regard to formatting issues. Please use a single column format, Times font or simiar and use numbered sections/subsections (for example, the first section will start with 1 and the first subsection will start with 1.1). There is no need for a bibliography.

LaTeX users My preference would be for you NOT to use the School's report layout because it wastes a lot of space and is hard to read. Also please avoid double columns as they are also hard to read! I would suggest using the vanilla default article format as this provides the format described in the previous paragraph. Note that if you omit the abstract that LaTeX will not complain.

Remember when writing reports that the focus should be on whether you have addressed all the required points rather than the number of words. If in doubt whether you have written enough, try looking at you have written and asking if you have addressed WHAT, HOW and WHY for each claim you make in a report. You may find that your HOW and WHY have to be further decomposed. You might also be interested in checking out the Writers Diet's waistline test).

What follows is the report structure. I've provided example section names and tried to provide some commentary (the stuff in italics).

Report Title

Author, student ID number, institution, date of printing.

1. Methodology (1-2 pages)

What approach did you take to analyze the code? Describe in detail, including software tools you used. Include approaches you tried that didn't work. Why didn't they work? Knowing what you do now after having analyzed the code, how would you have approached your analysis differently?

2. Problems identified in the code (1-4 pages)

Identify problems found in the code. These may include problems or errors that are unintentional as well as problems you suspect may have been intentionally introduced. Try and provide a summary and indicate the areas of the program where the problems exist. You do not have to include the full detail (i.e. code listing) of each problem.

3. Deliberately introduced problems (max 1 page per problem)

If you found problems that seem to have been introduced deliberately, what do you think the motivation was for introducing them (ie what vulnerability has been introduced)? Who is likely to benefit from the modifications you found? How would you mitigate the risks represented by these problems?

Note that in some cases, there were more than one motivation or each problem was introduced to meet a different motivation.

4. Reflection on the exercise (1 page)

Could you have found the potentially malicious problems if you had not had access to the source code of the voting machine? Why or why not? How much did access to the source speed your analysis?
Contact Us | Section Map | Disclaimer | RSS feed RSS FeedBack to top ^

Valid XHTML and CSS | Built on Foswiki

Page Updated: 14 Jan 2012 by ian. © Victoria University of Wellington, New Zealand, unless otherwise stated