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 : Due date and time: Estimated total time to be spent on assignment: Coursework 1 M1 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. M2 OXFORD BROOKES UNIVERSITY 1. Design and create assembly language programmes, with an awareness of how assembly programming differs from conventional programming. M3 20 hours per student Engineering Council AHEP4 LOs assessed (from S1 2022-23): 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 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 Select and apply appropriate computational and analytical techniques to model complex problems, discussing the limitations of the techniques employed School of Engineering, Computing & Mathematics 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) 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 - 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: 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: 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: As above Documented Code for displaying all staff and all badgers: As above Documented Code for searching for and displaying staff or badgers: As above Screenshots showing results of testing: Show all working success and failure cases for all operations you have implemented Reflection: Explain what challenges you encountered whilst doing this coursework, how you overcome them and what you would do differently next time. ,-;71 1 =^Kkm / hjm ,ndDMHHMM/\b /MM (,,. YQMML ///H|wnWWdMKKK#""-; . `"0\ ` " "Qkmmmmmn WMMM\" "WHMKKMM III 1 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. WHMb, . "QMM` 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. ,-=¹== `>>> Weighting out of 100% | \>\ `-<@) 20 School of Engineering, Computing & Mathematics 20 20 10 10 10 10 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) ● ● ● 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 @jnz.co.uk) ● ● 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) ● 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: ● yearOfJoining yearsOfService = currentYear 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 - School of Engineering, Computing & Mathematics - 1 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. Deletion 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 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. Display Searching 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 Fail Data Structures Major flaws Insertion/Adding with records and arrays which cannot be used by operations or no explanations Some recognisable attempt but clearly not working. GitHub respository may or may not contain code. No comments. Pass Records and arrays can be used only by some operations or poor explanations or evident redunancy Correct implementation of success case but no error cases handled. Neither the design nor the preliminary version uploaded to GitHub two weeks before the deadline. Only occasional comments or obvious comments. School of Engineering, Computing & Mathematics Distinction Records and arrays can be used by all operations without modification but there are minor flaws in representation or explanation or use of magic numbers. Correct implementation of success case but not all error cases handled correctly. Either the design or the preliminary version not uploaded to GitHub at least two weeks before the deadline. Mostly sensible comments. Ideal Records have all appropriate fields with no flaws, explained perfectly in report with illuminating examples. Equally perfectly implementation of arrays. Correct implementation of success case. Full validation and informative error handling for all error cases. Design and preliminary version of operation uploaded to GitHub at least two weeks before the deadline. Sensible but not verbose comments. Screenshots Reflection Severe lack of understanding of testing but tests relate to the program Very little attempt has been made at reflection. Only some operations or cases shown or student has somewhat misunderstood nature of testing Some response to some of the questions though mostly with thoughts that are self-evident. School of Engineering, Computing & Mathematics Most cases for most operations are documented or documentation could be clearer Thoughtful response to at least one question but not the others All success cases and all failure cases for each operations, outlined with exceptional clarity Thoughtful response to all questions with original insights.