Faculty of Technology, Design & Environment

Assessment cover

STUDENTS, PLEASE COPY THIS PAGE AND USE AS THE COVER PAGE FOR YOUR
SUBMISSION

Module No: COMP7023 Module title: Malware Analysis

Assessment title : Coursework 1

Due date and time: Friday, 8th March 2024, 13:00

Estimated total time to be spent on assignment: 20 hours per student

LEARNING OUTCOMES
On successful completion of this module, students will be able to achieve the module following
learning outcomes (LOs): LO numbers and text copied and pasted from the module descriptor.
1. Design and create assembly language programmes, with an awareness of how assembly
programming differs from conventional programming.

Engineering Council AHEP4 LOs assessed (from S1 2022-23):

M1 Apply a comprehensive knowledge of mathematics, statistics, natural science and engineering
principles to the solution of complex problems. Much of the knowledge will be at the forefront
of the particular subject of study and informed by a critical awareness of new developments
and the wider context of engineering
M2 Formulate and analyse complex problems to reach substantiated conclusions. This will involve
evaluating available data using first principles of mathematics, statistics, natural science and
engineering principles, and using engineering judgment to work with information that may be
uncertain or incomplete, discussing the limitations of the techniques employed
M3 Select and apply appropriate computational and analytical techniques to model complex
problems, discussing the limitations of the techniques employed

Statement of Compliance
I declare that the work submitted is my own and that the work I submit is fully in accordance with the
University regulations regarding assessments (www.brookes.ac.uk/uniregulations/current)

School of Engineering, Computing & Mathematics

FORMATIVE FEEDBACK OPPORTUNITIES
You will make regular uploads of asm code to the GitHub repository you have been given, starting in
week 3, and you will be given formative feedback in the practical sessions of weeks 4, 5 and 6.

In addition, the practical exercises of weeks 1, 2 and 3 (if you do them) will ensure that you are familiar
with the basics of assembler programming before you start on the coursework.

SUMMATIVE FEEDBACK DELIVERABLES

Deliverable description and instructions – Weighting

out of 100%
Upload your report to Moodle by the deadline stated and make regular uploads to GitHub
starting from two weeks before the deadline; tardy or insufficient uploads will be
penalised as the rubric indicates.

Your report will have all of your code (screenshots may not be used) in an appendix plus
extra documentation, as detailed below, in order given below:

Definition of records and array data structures: 20

Explain your definitions and illustrate them with examples, stating every assumption you
have made beyond those explicitly listed in this specification.
Documented Code for adding badgers and staff: 20
Explain your code, reproducing the relevant part from the appendix, and include both
comments and design. Your GitHub repository should have both the final version of the
code and at least one preliminary version. Design should include details of conditional
jumps, unconditional jumps, the use of registers and memory locations.
Documented Code for deleting badgers and staff: 20
As above
Documented Code for displaying all staff and all badgers: 10
As above
Documented Code for searching for and displaying staff or badgers: 10
As above
Screenshots showing results of testing: 10
Show all working success and failure cases for all operations you have implemented
Reflection: 10
Explain what challenges you encountered whilst doing this coursework, how you
overcome them and what you would do differently next time.

This coursework is worth 40% of the module and is an individual piece of work – group work is not allowed
and the university rules concerning plagiarism, collusion and contract cheating apply. Harvard referencing
must be used where applicable. You will receive marks and feedback within three weeks of the submission
deadline.

ASSIGNMENT IN DETAIL - INTRODUCTION

Jonny’s Nocturnal Zoo is a wildlife park at the far end of the county of Brookeshire. Currently the only
residents at the zoo are roughly a dozen badgers, who live in a complex of setts underneath the ground.
_,-='=- =- -`"--.__,,.._
,-;// / - - - -= - "=.
,'/// - - - = - ==-=\`.
|/// / = `. - = == - =.=_,,._ `=/|
/// - - \ - - = ,ndDMHHMM/\b \\
,' - / / / /\ = - /MM(,,._`YQMML `|
<_,=^Kkm / / / / ///H|wnWWdMKKK#""-;. `"0\ |
`""QkmmmmmnWMMM\""WHMKKMM\ `--. \> \
hjm `""' `->>> ``WHMb,. `-_<@)
`"QMM`.
`>>>

School of Engineering, Computing & Mathematics

The park is overseen by Jonny Zookeeper who knows every badger by name. However, Jonny has been
asked to rehome two hundred extra badgers next month. He is worried that he will not be able to keep
track of all the new badgers and extra staff he will need in addition to the badgers he already has.

Jonny has bought a fancy new computer to keep track of the new badgers and staff in his zoo. You have
been called in to create some new software to help Jonny organise the residents and staff in his wildlife
park. You will need to write a record keeping system to store information about all the badgers and
people in Jonny’s Zoo.

Unfortunately, there is a by-law in Brookeshire which makes all compilers and high-level languages
illegal. You will therefore have to write the system in assembly language.

ASSIGNMENT IN DETAIL – SYSTEM REQUIREMENTS

Write a simple archive system to keep track of the badgers and staff in the zoo. The system must be
written in 64-bit x86 assembly language. This coursework is designed to assess assembly language
programming, thus submissions written in other languages will be awarded zero marks.
1. You must store the following information with each badger:
 Badger ID (a unique identifier of the form bXXXXXX where XXXXXX is a 6 digit number)
 Name (a NUL-terminated string of maximum size 64 characters)
 Home sett (can be any one of Settfield, Badgerton, or Stripeville)
 Mass in kg (to the nearest whole kg)
 Number of stripes (in the range from 0 to 255)
 Sex (M or F)
 Month of birth (a whole number in the range 1 to 12 e.g. 1=January and 12=December etc.)
 Year of birth (a whole number e.g. 2017)
 Staff ID of assigned park keeper (which must be of the form pXXXXXXX as mentioned below but
it need not match a staff record)

2. You must store the following information with each staff:

 Surname (a NUL-terminated string of maximum size 64 characters)
 First Name (a NUL-terminated string of maximum size 64 characters)
 Staff ID (a unique identifer of the form pXXXXXXX where XXXXXXX is a 7 digit number)
 Department (can be any one of Park Keeper, Gift Shop or Cafe)
 Starting annual salary in £ (whole £ only)
 Year of joining (a whole number e.g. 2017)
 Email address (a NUL-terminated string of maximum size 64 characters of the form
<name>@jnz.co.uk)

3. Your system must allow the following operations:

 Add staff
 Add badger
 Delete staff
 Delete badger
 Display all staff, showing for each staff:
o years of service, calculated by:
yearsOfService = currentYear – yearOfJoining
o annual salary, which increases by £200 for each year of service
 Display all badgers, showing for each badger:
o age, calculated by:
if (currentMonth – birthMonth) >= 0
age = currentYear – yearOfBirth
else
age = currentYear – yearOfBirth – 1
School of Engineering, Computing & Mathematics
 o stripiness, calculated by:
stripiness = mass * numberOfStripes
 Search for and display (as explained above) a badger, given a badger ID
 Search for and display (as explained above) a staff member, given a Staff ID

4. Your system must satisfy the following memory requirements:

 It should be able to store a maximum of 100 staff members and 500 badgers
 It should not used dynamic memory allocation; static memory allocation at build-time should
be adequate for your purposes.
 It should not be wasteful of memory. HINT: Think how much storage you need for each of
the pieces of information in the staff and badger records and allocate only enough memory
for that. Remember that the NUL terminator requires an extra byte in memory
 In particular, it should not store in the badger record and staff records the result of the
calculations mentioned above; these calculations must be made on the fly

5. All input and output should be to and from the terminal console. All data is held only in memory and
should be saved to or loaded from disk.

6. The user should be asked to input value currentYear when the program starts.

Fail Pass Distinction Ideal

Data Structures Major flaws Records and Records and Records have all
with records arrays can be arrays can be appropriate fields
and arrays used only by used by all with no flaws,
which cannot some operations operations explained
be used by or poor without perfectly in report
operations or explanations or modification but with illuminating
no explanations evident there are minor examples. Equally
redunancy flaws in perfectly
representation or implementation of
explanation or arrays.
use of magic
numbers.
Insertion/Adding Some Correct Correct Correct
recognisable implementation of implementation of implementation of
Deletion attempt but success case but success case but success case. Full
clearly not no error cases not all error cases validation and
Display working. handled. Neither handled correctly. informative error
GitHub the design nor the Either the design handling for all
Searching respository preliminary or the preliminary error cases.
may or may not version uploaded version not Design and
contain code. to GitHub two uploaded to preliminary
No comments. weeks before the GitHub at least version of
deadline. Only two weeks before operation
occasional the deadline. uploaded to
comments or Mostly sensible GitHub at least
obvious comments. two weeks before
comments. the deadline.
Sensible but not
verbose
comments.

School of Engineering, Computing & Mathematics

Screenshots Severe lack of Only some Most cases for All success cases
understanding operations or most operations and all failure
of testing but cases shown or are documented cases for each
tests relate to student has or documentation operations,
the program somewhat could be clearer outlined with
misunderstood exceptional clarity
nature of testing
Reflection Very little Some response Thoughtful Thoughtful
attempt has to some of the response to at response to all
been made at questions though least one questions with
reflection. mostly with question but not original insights.
thoughts that are the others
self-evident.

School of Engineering, Computing & Mathematics