Goal of the project

In this project you design and build a chosen application as if it were going through a certification
process:

• a C++ console application
• a dynamic library (DLL/.so) that provides its security

Goal: combine every security technique you learn during the term into one product and document all
of it in a security guide (S0–S17).

Checkpoints

2. Assessment structure — weights

• Midterm = 0.6·RAP1 + 0.4·Quiz-1
• Final = 0.7·RAP2 + 0.3·Quiz-2
• Course grade = 0.4·Midterm + 0.6·Final

RAP1 (Week 7): first half of the product (S2–S5 + basic protections)
RAP2 (Week 15): full product + S16 results

Template repository

Template: ucoruh/cpp-cmake-ctest-template

• Do not fork: a fork of a public repository cannot be made private
• On the template page: Use this template → Create a new repository; name cen429-2026-2027-NNN-name-surname-cpp, Private
• Add the instructor (ucoruh) and your teammate (if any) as collaborators

!!! tip "Use the template fully"
The template provides build, CTest unit testing, documentation generation, test/documentation coverage,
and packaging. Deliverables that do not follow the template are not accepted. Produce releases; record
the version id and digests.

Showing your project locally

A private repository on GitHub Free has no GitHub Pages site. You show everything on your computer:

• 7-build-all-windows.bat (Linux/WSL: 7-build-all-linux.sh) builds, tests and makes every report
• 9-open-site-windows.bat (Linux: 9-open-site-linux.sh) opens the full site on http://localhost: every report (tests, code coverage, documentation coverage, Windows and Linux) and the API docs
• release/ holds every output: app/exe, library, reports, API docs, site.zip, source, ASSETS.md, SHA256SUMS.txt
• 10-release-windows.bat (Linux: 10-release-linux.sh) makes the GitHub Release; releases work on private repositories

Demo checklist

What you open and show, in this order:

1. The home page of the local site (9-open-site-..., on http://localhost).
2. Each report page: tests, code coverage, documentation coverage (Windows and Linux).
3. The API docs.
4. The release/ folder listing.
5. Run the app from the release archive.
6. The GitHub Release page of your private repository (the instructor is a collaborator).

Project layout

• lib/ — security library (DLL/.so): cryptography, RASP, code obfuscation, data-protection functions
• app/ — console application: the user interface that uses the library
• test/ — CTest unit tests (crypto and protection functions)

For environment setup and background knowledge, see the Prerequisites page.

4. Topic selection

Project topics are in the Appendix — Project topic list at the end of the guide page (100
topics).

Each topic box gives:

• A short description of the application
• Its key features
• The assets to protect
• The security requirements that stand out for that topic

How to choose

1. Browse the list at the end of the guide page and choose one topic
2. Record your choice in the shared team and topic list (link in the Teams post) — each topic can be
   taken by only one team, the first team to record it gets it
3. Have it approved by the instructor together with your project plan; once approved, the topic cannot
   be changed

Rules for topic selection

• All 15 requirements in Section 5 apply to every project; the "highlighted requirements" in a topic
  box show where they fit most naturally and earn the most credit for that topic
• If you have an idea not on the list, you may choose it with the instructor's approval
• If you are retaking this course, choose a topic different from your previous project

5.1 Midterm scope (RAP1)

4.1 Development environment security

Weeks 1, 12 · S13

• Software development flow and change management (baseline → request → classify → approve →
  release → verify)
• Version control with Git; access logging; signed releases
• Development host/server security (short policy)

4.2 Data-in-use security

Weeks 3, 6 · S7

• Sensitive data in memory is wiped securely after use (memset_s-like)
• Runtime data protection (shadow copy / integrity — Week 6)

4.3 Data-in-transit security

Weeks 3, 10 · S6, S11

• TLS 1.3; certificate chain + SAN validation; pinning + backup pin
• Encrypted session key; device/version binding; integrity + authentication; server verification
  code

4.4 Data-at-rest security

Weeks 3, 10, 11 · S8

• File/DB encryption with AEAD (AES-GCM); non-repeating nonce
• For sensitive keys, whitebox or SoftHSM/PKCS#11; justify the choice (Week 11)

4.8 Interface definitions and protection

Weeks 1, 4 · S3, S6

• All interfaces protected with access control + authentication
• Input validated at the trust boundary

4.9 Code hardening

Weeks 4, 9, 14 · S9

• Opaque loops/predicates, name/file/string/arithmetic obfuscation, opaque booleans, bogus ops/dead
  branches
• Control-flow flattening + random exit, logging off in release
• Measure the cost (Week 9/14 demos)

4.10 RASP

Week 6 · S10

• Checksum integrity, caller hash/signature verification
• Root/emulator detection, hook/anti-debug
• Tamper detection + response, control-flow counter

4.11 Memory protection

Week 4 · S9

• Compiler/OS protections (stack canary, PIE, RELRO, NX, CFI)
• Sensitive memory cleared after use

5.2 Final scope (RAP2)

4.5 Static asset protection

Weeks 1, 4, 9 · S5, S9

Secret keys, digests, source code, resources: encryption + access control + obfuscation

4.6 Dynamic asset protection

Weeks 3, 6 · S5, S8

Device/app fingerprints, session data, dynamic keys are encrypted

4.7 Asset management

Weeks 1, 3, 13 · S5

Per asset: name, description, location (table/column), source, size, creation/destruction time,
default, protection scheme (C/I/I+)

4.12 Cryptography and certificates

Weeks 3, 10 · S8, S11

• Correct algorithm/mode/padding
• Signature verification (==1, version coverage)
• SSL/TLS + pinning + mutual authentication

4.13 Certification and penetration test plan

Weeks 12, 13 · S16, S14, S17

• Standards mapping (ETSI/EMVCo/GSMA/PCI/MASVS)
• Penetration test plan (scope, rules, methodology, test card) and its results
• Attack potential + CVSS

4.14 Binary application protection

Weeks 6, 9, 11, 14 · S9, S10, S15

• Detection (checksum, anti-debug, emulator)
• Defence (obfuscation, string/resource encryption, call hiding)
• Deterrence (response/shutdown policy)

4.15 OWASP and build/deploy pipeline

Weeks 5, 14 · S13, S15

• OWASP MASVS/ASVS principles
• SBOM (CycloneDX) + dependency scan
• Build pipeline with obfuscation + signing

5.3 Rules for both checkpoints

• All values must be synthetic; no real secret, key, or personal data may be in the repository
• Every requirement item must be visible in the code and documented in the matching S section;
  an undocumented implementation counts as unmet
• If a requirement cannot be met, record the justification in S14; it cannot be silently skipped
• The application runs only on your own computer (localhost); it must not harm any other system or data

Single ZIP archive structure

cen429-2026-2027-NNN-midterm.zip           # final: cen429-2026-2027-NNN-final.zip
└── cen429-2026-2027-NNN-name-surname-cpp/      # clone of the GitHub repo
    ├── lib/                              # security library (DLL/.so)
    ├── app/                              # console application
    ├── test/                             # CTest unit tests
    ├── docs/                             # Doxygen output
    ├── security-guide/                   # S0–S17 security guide
    ├── sbom/                             # CycloneDX SBOM (final)
    ├── test-coverage/                    # CTest coverage report
    └── README.md

Naming

• Repository: cen429-2026-2027-NNN-name-surname-cpp
• Archive: cen429-2026-2027-NNN-midterm.zip / cen429-2026-2027-NNN-final.zip
• Security guide file: cen429-2026-2027-NNN-security-guide.docx

The cover page of the report/guide must include the GitHub repository link.

7. Team workflow (1/2)

• GitHub Flow: main is protected and never committed to directly; each task gets its own feature
  branch, merged through a pull request
• Commit message convention: Conventional Commits, e.g.
  feat(crypto): add AES-GCM wrapper, fix(rasp): correct debugger detection

7. Team workflow (2/2)

• Pull request + review: every PR is reviewed by at least one teammate
• Issues + Projects board: Backlog → In Progress → In Review → Done
• No merge without green CI
• Version tags: midterm midterm-v1.0, final final-v1.0
• Definition of Done: builds and runs · unit tests exist · coverage did not drop · PR approved · CI
  green · guide updated

8.1 Achievement levels

9. Acceptance conditions

Submissions are not accepted if…

• there is no GitHub repository, it is not private, or team members have no commits
• the proportion of requirements met is below the minimum threshold
• the repository or archive contains binary files (compiled .exe/.dll/.so)
• no release has been produced, the application does not build/run on Windows or WSL/Linux
• the repository contains a real secret, key, or personal data, or plagiarism is detected

10. Questions asked in the demo (1/2)

• Git/GitHub: Did you create the repository from the template with the correct name? Is the repository private, is the
  instructor a collaborator? Does every member have commits?
• Setup and build: Build the application and the library on Windows and in WSL/Linux; show the
  lib/app/test split

10. Questions asked in the demo (2/2)

• Topic (line by line): Explain your chosen security requirement line by line in the code
• Tests and documentation: Open the unit tests and coverage report; show the matching S section
• File/data operations: Add a record, close and reopen the program, show that the data comes back
  encrypted
• Programming: Memory management, pointers, compiler/OS protections, debugger inspection

11. Professional responsibility and academic integrity

• You must be able to explain every line you submit
• Cite the source if you reuse someone else's code or text
• All examples and values must be synthetic
• Plagiarism and unauthorized copying cause failure
• A ghost commit (committing on someone else's behalf) counts as plagiarism

Safe and legal frame

Penetration testing is only done on your own project.

Examples and values must be synthetic; no real secret, key, or personal data may enter the repo.

Your application must not harm anyone else's system or data.

12. Frequently asked questions (1/2)

Can I form a team by myself?
Yes. The team is at most 5 students; teams are fixed at the end of week 3 (04.10.2026).

Can I change my topic after it is approved?
No. Once approved, the topic cannot be changed.

12. Frequently asked questions (2/2)

What happens if I cannot fully meet a requirement?
You may defer it by recording your justification in S14.

Can a requirement left incomplete at RAP1 be finished at RAP2?
Yes, but the RAP1 grade reflects the state at the time of that demo and is not updated afterwards.

Are late submissions accepted?
No — the rules in the syllabus apply.

Sample topic — 01

Offline Payment Wallet

A wallet that lets a user make small payments without an internet connection. The balance and single-use
payment keys live on the device; transactions reconcile with the server once connectivity returns.

Highlighted requirements: 4.4 Data-at-rest (AES-GCM + SoftHSM), 4.3 Data-in-transit (TLS 1.3 +
pinning), 4.10 RASP (keys wiped when a debugger is detected)

Sample topic — 26

Personal Health Record Vault

An application where a user keeps synthetic diagnosis, medication and allergy records in a local vault.
The attacker is whoever gains hold of the device or finds a lost one.

Highlighted requirements: 4.4 Data-at-rest (SQLite + AES-GCM + SoftHSM), 4.2 Data-in-use (plaintext
kept in memory only briefly), 4.11 Memory protection (a viewed record is wiped once closed)

Where is the full list?

The remaining 98 topics, each in the same format (short description, key features, assets to
protect, highlighted requirements), are in the Appendix — Project topic list at the end of the
Project Guide page.

ucoruh.github.io/cen429-secure-programming/en/project-guide/