2025/9/28 17:27 Advanced Secure Protocol Design, Implementation and Review
Advanced Secure Protocol Design, Implementation and Review
Start Assignment
Due 26 Oct by 23:59
Points 30
Submitting a file upload
This Advanced Secure Programming assignment is designed to help students apply the theoretical concepts covered in the
lectures/RangeForce and learn about practice secure programming. This assignment is a group work assignment. In
groups of 3-5 students, you will engage in a hands-on assignment that requires the design, development, and evaluation of
a secure overlay chat system utilising a standardised protocol created by all the students in this class. This system must
adhere to class-specified protocol, have a secure implementation, have the secured implementation intentionally and
ethically "backdoored", and then be tested in a controlled code review process. The course concludes with a friendly
hackathon exercise.
Assignment Objectives
Conceptualising and standardising a secure communication protocol for a distributed overlay multi-party chat system.
There cannot be any central server handling all the communication. Rather, the system must be robust to any node or
device failure.
Develop an application that adheres to a designed protocol (by the class) and incorporates advanced secure coding
practices.
Intentionally backdoor your own implementation in an ethical way so that other groups have security flaws to find.
Perform peer reviews and engage in both manual and automated code analysis to identify vulnerabilities and
backdoors.
Critically reflect on the design and implementation process, including evaluating the protocol, the security measures
implemented, the quality of the feedback received, a reflection on your own learning and possible coding mistakes.
Have fun at an ethical hackathon to identify and exploit vulnerabilities in a controlled setting, enhancing your
understanding of real-world cybersecurity challenges.
Assignment Timeline and Deliverables
Week 2: Complete the initial design of the chat system's communication protocol.
Week 4: Collaborative standardisation of the protocol with class-wide consensus.
Week 6: Finalise detailed plans for code design and start your implementation.
Week 8: Present a functional prototype in the tutorial for initial testing and feedback. Consider this as the deadline to finish
your implementation.
Week 9: Submit the final version of the chat system for peer review. HARD DEADLINE: 06 Oct 2025. If you submit after
this day, your code won't be sent for peer review because it's unfair for your peers to receive late code for review.
Week 10: Conduct code reviews of three other groups' projects using both manual and automated code review techniques.
Provide constructive feedback on the vulnerabilities found in peer reviews. DEADLINE for peer feedback: 19 Oct 2025.
Week 11: Submit a reflective commentary discussing the protocol standards, implementation challenges, thoughts on the
embedded backdoors, and their detection difficulty. Include in your submission the backdoor-free code and your
backdoored code. DEADLINE: 26 Oct 2025.
Week 12: Participate in a friendly, ethical hackathon to test all chat systems for vulnerabilities and demonstrate proof-of-
concept attacks in a VM environment.
Participate in workshops to aid protocol development and refine implementation strategies.
Programming and Implementation Details
https://myuni.adelaide.edu.au/courses/101186/assignments/454418 1/8
2025/9/28 17:27 Advanced Secure Protocol Design, Implementation and Review
Your group is free to use any programming language it feels comfortable with, such as C, Python, Rust, or any other
suitable programming language.
Task Overview
The goal is to create a system that functions according to specified requirements and incorporates intentional vulnerabilities
(backdoors) that peers will attempt to identify and exploit. Your aim is to understand the trade-offs in protocol design at
different levels with different objectives and problems. This develops critical thinking about aspects of protocols,
programming, security, and vulnerabilities in code.
In order to achieve that, we will design and secure our own protocol (as a whole class group). We will study this using the
example of an overlay multi-party chat program. At the end of the module, we will have discussed and implemented a set of
major Internet protocols, and you will have a program that must interwork with other students' programs to provide a chat
service with:
Listing all members (currently online) in the chat system.
Private messages to a single participant: For example, your protocol is able to "forward" chat messages to the
appropriate destination (according to your "routing table"), and the appropriate recipient displays the right chat
messages.
Group messages to all participants.
Point-to-point file transfer.
What you need to consider is:
How to secure the socket from which you are receiving data.
Consider a malicious user using your program.
Consider malicious nodes participating in your protocol and/or a malicious actor "wiretapping" your communication.
While at the same time forwarding/routing messages through an overlay topology and securing the protocol
communication.
Consider core functionalities like user registration, and message sending/receiving (/w authentication).
During the workshop session, you will design a protocol where you (the cohort of students) can work together to agree on a
protocol that will be implemented within the chat program. You will then work in groups of 3-5 students to implement the
protocol independently of the other groups.
Phase 1: Protocol Design (Weeks 1-4)
Objective: Design a standardised network protocol for a chat system that supports listing members, sending private and
group messages, and conducting file transfers—a protocol specification document detailing all functional and security
aspects agreed upon by all groups.
Approach:
Weeks 1-2: Research existing secure communication protocols to understand foundational concepts. Begin drafting
protocol specifications focusing on user authentication, data integrity, and encryption methods. Use the workshop during
week 2 to communicate with your fellow students.
Weeks 3-4: Standardise the protocol in collaboration with your peers in the whole class. Ensure it includes details on
message formatting, session management, packet routing, error handling, and security measures.
Phase 2: Software Implementation (Weeks 5-9)
Objective: Implement the agreed protocol that has been "standardised". Note carefully that while the protocol specification
needs to be the same for the whole class (otherwise, you will not be able to communicate with the implementation from
https://myuni.adelaide.edu.au/courses/101186/assignments/454418 2/8
2025/9/28 17:27 Advanced Secure Protocol Design, Implementation and Review
other groups), your implementation is group-specific. A working prototype of the chat system should be submitted by every
group at the end.
Approach:
Weeks 5-6: Design the software architecture and start implementing it. While you are still in the process of focusing on
completing the last RangeForce modules, it is essential that by the workshop in week 6, you have a clear understanding of
what to code. You should use the session with your tutor to discuss any questions you might have.
Weeks 7-8: These will be the main coding weeks. If you have a well-planned and standardised protocol, you will see that
the actual implementation is not that hard. By the end of week 8, your code should really be finished. See this as the
deadline, so you have a few days to debug your code with other groups.
Tutorial in Week 8: Present a working prototype for initial testing and informal feedback from other groups and tutors.
Week 9: Finish debugging your code and add some backdoors (and/or vulnerabilities only known to your group) to the
code. There must be at least 2 intentional vulnerabilities for the other groups to find. Your friendly hackathon competition is
to make it as hard for the other groups to find those hidden vulnerabilities. However, also keep in mind that ideally, you
need to be able to exploit your own vulnerabilities and demonstrate later that you can achieve the objectives.
A hopefully obvious but important note on the intentional backdoors: The objectives are limited to within the chat system.
Do not include anything that would breach anything from the computer of the person who runs your code. The idea is proof
of concept, e.g., that you could take control of the running program, modify or alter messages on the node, sign with their
private key, etc. However, keep it ethical. Do not breach anyone's privacy or modify or delete any of the data outside of this
assignment.
On Monday in week 9, 06 Oct 2025: Submit your complete chat system (the version of your code with
backdoors/vulnerabilities) for review by other groups. Submit on the MyUni assignment page: Submission of
Implementation (https://myuni.adelaide.edu.au/courses/101186/assignments/454424) . Your submission should have your
(intentionally vulnerable) code and a detailed "README" (as ASCII) with instructions on compiling, running and using the
code.
Phase 3: Testing and Peer Review (Week 10)
Objective: Conduct thorough testing and review of the chat system to identify planted and potential unintended
vulnerabilities. Please submit a feedback review report outlining the vulnerabilities found and suggestions for improvement
for the other groups.
Approach:
Week 10: Each student gets 3 implementations from other groups to review. This is an individual sub-task in order to
practice reviewing for every student and maximise the feedback others receive. You will use a combination of manual
inspection and automated tools (e.g., static code analysis/dynamic analysis). Focus on identifying the intentional backdoors
and any other security flaws left by other groups. However, it also provides detailed feedback to other groups, highlighting
both strengths and vulnerabilities in their implementations. Your feedback is expected to be returned to the other students
no later than 19 October 2025.
Note that you can, of course, share the feedback from the individual peer review task with your group members and overall
make your code better as a group. Feedback given will also be discussed in the reflective commentary as a group.
While every group's backdoored code version is implemented ethically, always treat the code or produced binaries as if
they were malicious. The code will certainly open ports to receive messages and will have intentional and/or unintentional
vulnerabilities associated with it. Run code received from other groups only in a sandboxed and secured
environment! It is essential to practice protecting yourself from malware and learning how to become a malware
researcher, as the code you receive should only contain ethical backdoors, but nevertheless, make sure your own systems
remain safe.
https://myuni.adelaide.edu.au/courses/101186/assignments/454418 3/8
2025/9/28 17:27 Advanced Secure Protocol Design, Implementation and Review
Phase 4: Reflection and Feedback (Week 11)
Objective: Reflect on the development process and learn from the feedback received.
Approach:
Write a reflective commentary discussing your protocol's standards, implementation challenges, thoughts on the integrated
backdoors, and anticipated difficulty detecting them. As guidance, do not write more than 2000 words (~4 pages single-
spaced A4). Your code, proof of concept, and screenshots can go to a set of appendices, which do not count into those
2000 words/4 pages.
The reflective commentary should contain the following information:
1. Your reflection on the standardised protocol. Even if you had to comply with the agreed implementation (in order to
achieve interoperability), you might have had a different view. Here is the space to comment and give your thoughts on
what worked and what didn't work.
2. Describe and submit your backdoor-free version of the code. Explain design choices in the implementation.
Demonstrate how your code runs (by chatting with your own implementation or by chatting with other implementations).
Discuss lessons learned. This can also include any bugs reported by other groups.
3. Explain what backdoors/vulnerabilities you added. What were your thoughts and objectives?. Explain and demonstrate
how to exploit your backdoor.
4. Evaluate the feedback you received from other groups. Did they find your backdoors? Did they find other problems in
your code? Was the report useful feedback?
5. For what groups did you provide feedback (name the group and group members). What feedback did you provide to
other groups? What challenges did you face? How did you overcome or approach those challenges (e.g., did you talk
to the other groups)?
Phase 5: Ethical Hackathon (Week 12)
Objective: Test the security of all chat systems in a controlled, ethical environment.
Approach:
Participate in a hackathon where each group attempts to exploit vulnerabilities in others' systems. That means running your
own vulnerable code in a VM (or otherwise safe environment). Ethically, try to exploit others' code. Use only non-
destructive methods and aim to demonstrate proof of concept for potential attacks. All activities should be conducted on
isolated virtual machines (VMs) to prevent any real-world implications.
Secure Programming Assignment
https://myuni.adelaide.edu.au/courses/101186/assignments/454418 4/8
2025/9/28 17:27 Advanced Secure Protocol Design, Implementation and Review
Criteria Ratings Pts
Reflective 1.5 to >1.0 Pts 1 to >0.5 Pts 0.5 to >0.0 Pts 0 Pts
Critical reflection Reflection Thoughtful action or Non-reflective
commentary (not
including Exploration and Movement beyond introspection Superficial descriptive
critique (including self- reporting or Elaborated descriptive writing approach (fact
appendices) – Writing
critique) of descriptive writing to writing approach and reporting, vague
spectrum
assumptions, values, reflecting (i.e. impressions without impressions) without
beliefs, and/or biases attempting to deeper reflection. reflection or 1.5 pts
and the understand, question, introspection.
consequences of or analyse the
action (present and learning related to
future). Including but secure programming).
not limited to the ones
learned in the course.
Reflective 1.5 to >1.0 Pts 1 to >0.5 Pts 0.5 to >0.0 Pts 0 Pts
Reflective Aware practitioner Reflective novice Language is unclear
commentary – Clarity
practitioner Minor, infrequent There are frequent and confusing
The language is clear lapses in clarity and lapses in clarity and/or throughout
and expressive. The accuracy. accuracy. Concepts are either
reader can create a not discussed or are
mental picture of the presented 1.5 pts
situation being inaccurately, or are
described. Abstract too vague.
concepts are
explained accurately,
making sense to an
uninformed reader.
Reflective 1.5 to >1.0 Pts 1 to >0.5 Pts 0.5 to >0.0 Pts 0 Pts
commentary – Bigger picture Ability to analyse Some demonstrated Irrelevant
Relevance clearly biases, stereotypes, relevance Most of the reflection
communicated and preconceptions Attempts are made to is irrelevant and/or
The reflection The reflection demonstrate misses the bigger
demonstrates the demonstrates the relevance, but the picture of
ability of the student student's ability to relevance is unclear understanding of the
to question their own question their biases, to the reader or not topic area.
biases, stereotypes, stereotypes, and linked to the bigger
preconceptions, preconceptions. picture of the cyber
and/or assumptions security market needs
and define new and/or secure
modes of thinking as programming.
1.5 pts
a result of the
perspective of the
cyber security skill
shortage and secure
programming culture
in the world. This
could also reflect on
your own engagement
with respect how your
high quality posts on
Piazza changed the
learning for other
students, for example.
Reflective 1.5 to >1.0 Pts 1 to >0.5 Pts 0.5 to >0.0 Pts 0 Pts 1.5 pts
commentary – Critical reflection Connections Little to no attempt No attempt to
demonstrated to demonstrate demonstrate
https://myuni.adelaide.edu.au/courses/101186/assignments/454418 5/8
2025/9/28 17:27 Advanced Secure Protocol Design, Implementation and Review
Criteria Ratings Pts
Course/curriculum The reflection The reflection connections connections
context demonstrates an demonstrates There is little to no No attempt to
understanding of the connections between attempt to demonstrate
experience in relation the experience and demonstrate connections to
to material from other material from other connections between previous learning or
courses, past courses, past the learning experience.
experience, personal experience, and/or experience and
goals, and/or the personal goals. previous other
wider cybersecurity personal and/or
skill sets. learning experiences.
Reflective 1.5 to >1.0 Pts 1 to >0.5 Pts 0.5 to >0.0 Pts 0 Pts
Critical reflection Good Adequate Superficial
commentary – Use of
AI The reflection on the The reflection on the The reflection on the The reflection is
use of AI is use of AI is thorough. use of AI is clear. The superficial and shows
comprehensive. The The main reflective main reflective report a limited
main reflective report report describes how explains how AI was understanding of AI
provides a detailed AI was utilised in the used in the capabilities and
account of how AI was assignment, assignment, constraints. Or the
utilised in the specifying tasks and mentioning specific report does not detail
assignment and what results. The reflection tasks and outcomes. whether and how AI
strengths or evaluates AI's It details some was used.
weaknesses were limitations and limitations and
identified. The report shortcomings, shortcomings of AI,
1.5 pts
also critically showing a good showing an adequate
evaluates AI's understanding of its understanding of its
limitations and capabilities and capabilities and
shortcomings and limitations. constraints.
includes thoughtful
insights into what the
group learned from
using AI. Or if AI was
not used at all in no
way, the report states
that this assignment
was conducted
without the help of AI.
Reflective 1.5 to >1.0 Pts 1 to >0.5 Pts 0.5 to >0.0 Pts 0 Pts
Detailed Basic List Not present
commentary –
Contributions of The report reflects on There is a section There is just a list with There is no reflection
what every member present in the main percentages of each on the group’s
group members (at
contributed to the part of the reflective team member. contributions or
the end of the main
group and how the commentary. Still, it percentages of group
reflective
group worked on this lacks details or clarity members' overall
commentary section) assignment. This (e.g., it might just give contribution to the
includes percentages the percentages of assignment. 1.5 pts
of each group group members but
member's contribution does not reflect on
to the overall strengths or
assignment. weaknesses and how
the group
complemented each
other in the learning
experience).
Protocol Design - 1.5 to >1.0 Pts 1 to >0.5 Pts 0.5 to >0.0 Pts 0 Pts 1.5 pts
Critical reflection Non-reflective
Reflection (protocol
https://myuni.adelaide.edu.au/courses/101186/assignments/454418 6/8
2025/9/28 17:27 Advanced Secure Protocol Design, Implementation and Review
Criteria Ratings Pts
description in Reflection and critique Deeper Thoughtful action or Describes the protocol
of own contribution to understanding introspection design superficially
appendix, reflection
the protocol design, Reflects on the Provides a detailed without reflection on
in main part)
including reasoning behind description of the its effectiveness,
assumptions, design design choices, protocol design shortcomings/flaws or
decisions, and demonstrates a clear process (in the alignment with course
consequences. Also understanding of the appendix) but lacks a concepts.
discusses how their technical details, and deeper reflection on
own ideas may have how they contribute to its implications and
differed from the the consequences of effectiveness.
class-chosen protocol. the protocol.
Implementation (code 1.5 to >1.0 Pts 1 to >0.5 Pts 0.5 to >0.0 Pts 0 Pts
in GitHub) - README Good README Vague README README lacks Essential
Student names and Student names, group important information missing
group names are names, and README information Student names, group
present in all files are present, but the Student names, group names, or the
(README and all instructions for names, and README README file are
code files). The installing and/or are present, but they missing. The
README shows a running the code are lack an example of vulnerable and non- 1.5 pts
command-line vague. how to install or run vulnerable versions of
example of how to run the code. the code are not
the program, lists all clearly identified.
dependencies, and
gives guidance on
how to install the
code.
Implementation (code 4 to >2.5 Pts 2.5 to >1.0 Pts 1 to >0.0 Pts 0 Pts
in GitHub, detailed Testing methods Testing methods Testing methods Testing method not
well described adequately lack thoroughness structured or not
tests documented in
Details a testing described A systemic and adequately
GitHub files or
method (in the main The report reflects on structured testing described
appendix, reflection
document) and has a testing for method is described Testing methodology
on testing described
detailed test plan (in interoperability with but does not mention missing from the main
in main part) – appendix or GitHub other groups. Still, it interoperability tests part of the reflective 4 pts
Testing and file). Describe the does not give full with other groups in commentary or lacks
initiative of testing the details on the testing the main part of the evidence for a
Interoperability
interoperability of your procedure or lacks reflective commentary systematic testing
app with at least 1 details on what other section. approach.
other group and the groups and what has
respective results. been learned from the
testing.
Implementation (code 4 to >2.5 Pts 2.5 to >1.0 Pts 1 to >0.0 Pts 0 Pts
Outstanding Good Adequate Poor
in GitHub) – Code
Quality Code works out of the Code has some The code is functional Code lacks essential
box, has good error weaknesses (e.g., not in the use cases elements, does not
handling, and deals all corner cases described in the implement some
well with failure produce clear error README. The basics aspects of the 4 pts
scenarios (e.g., messages or good are correct, e.g., protocol, and/or does
network nodes are not handling). routing/forwarding not implement the
gracefully shut down). tables are correct, and standard correctly.
messages in the
overlay do not loop.
Feedback given 4 to >2.5 Pts 2.5 to >1.0 Pts 1 to >0.0 Pts 0 Pts 4 pts
(evidenced in the Exemplary Accomplished Intermediate Novice
https://myuni.adelaide.edu.au/courses/101186/assignments/454418 7/8
2025/9/28 17:27 Advanced Secure Protocol Design, Implementation and Review
Criteria Ratings Pts
appendix) The feedback The feedback The feedback offers a The feedback
presents clear, provides a clear and basic explanation of provides a limited or
cohesive explanations helpful explanation of how to improve the unclear explanation of
of how to improve the how to improve the code. The writing is how to improve the
code (of the other code. The writing is generally constructive code. The writing
groups). The writing is constructive and and supportive but lacks
constructive, supportive but might may lack clarity or constructiveness,
supportive, friendly, be vague in parts, or detail. The feedback offering minimal help
clear and detailed the testing provides some useful for the other group to
enough to help the methodology of the insights but misses learn or improve their
other groups learn other group's code some key areas for code. The methods to
from the feedback and lacks rigour. The tests improvement. The test the other group's
improve their code. conducted are limited methods to test the code are basic and
The methods to test in their methodology, other group's code show a limited
the other group's code and the feedback primarily rely on understanding of
go beyond the does not fully techniques learned in secure programming.
methods learned in demonstrate that all the class and
this class and aspects of the code demonstrate an
demonstrate a strong have been thoroughly adequate
understanding of reviewed. understanding of
cyber security. cyber security.
Ethical 6 to >4.0 Pts 4 to >2.0 Pts 2 to >0.0 Pts 0 Pts
Outstanding Good Adequate Superficial
backdoor/vulnerability
(described in the The ideas behind the The ideas behind the The ideas behind the The ideas behind the
ethical ethical ethical ethical
main part and
backdoor/vulnerability backdoor/vulnerability backdoor/vulnerability backdoor/vulnerability
submitted as
are complex and are well-thought-out and are clear and are basic and
quarantined file in
innovative. They demonstrate a solid demonstrate a good demonstrate a limited
GitHub) demonstrate that the understanding of secure understanding of understanding of
group deeply programming and code secure programming secure programming
understands secure weaknesses. A PoC and code and code
programming, code implementation is weaknesses. A PoC weaknesses. The
weaknesses, and submitted for at least implementation may backdoors in the
exploitation methods. one not be submitted, but vulnerable version of
6 pts
An appendix or backdoor/vulnerability, the reflective the code offer a
GitHub file details a and the reflective commentary makes it minimal challenge to
Proof of Concept commentary makes it credible that this can other groups. There
(PoC) implementation credible that all be exploited. At least might also be fewer
on how the planted backdoors/vulnerabilities 2 backdoors are than 2 backdoors in
backdoors can be can be exploited. At present in the the code.
exploited. There are least 2 backdoors are vulnerable version of
at least 2 backdoors present in the the code, providing a
that provide a vulnerable version of the moderate challenge
significant challenge code, challenging other to other groups.
to identify. groups to identify and
understand different
types of vulnerabilities.
Total points: 30
https://myuni.adelaide.edu.au/courses/101186/assignments/454418 8/8
