Advanced Practical Course - Secure Coding (IN2106, IN4202)

Course 0000001099 in WS 2016/7

General Data

Course Type	practical training
Semester Weekly Hours	6 SWS
Organisational Unit	Informatics 4 - Chair of Software & Systems Engineering (Prof. Pretschner)
Lecturers	Sebastian Banescu Responsible/Coordination: Alexander Pretschner
Dates

Assignment to Modules

IN2106: Master-Praktikum / Advanced Practical Course
This module is included in the following catalogs:
- Further Modules from Other Disciplines

Further Information

Courses are together with exams the building blocks for modules. Please keep in mind that information on the contents, learning outcomes and, especially examination conditions are given on the module level only – see section "Assignment to Modules" above.

additional remarks	The goal of this lab is to teach students how to protect software applications against so called Man-At-The-End (MATE) attackers. MATE attackers control the system on which the application is running and their goals include but are not limited to: reverse engineering a proprietary algorithm, cracking software, cheating in games, bypassing license checks or extracting secret keys embedded in software. MATE attackers have capabilities that exceed those of remote attackers, e.g. MATE attackers can perform interactive debugging on applications and modify their code and/or memory values during execution. They can do this without needing to exploit any vulnerability of the target application. This lab will focus on applications written in C, because MATE attacks are often performed at binary level. To defend against MATE attackers we will first present tools and techniques used in reverse engineering and then present tools and techniques for software protection. We will cover an array of techniques employed in state-of-the-art software protection such as: obfuscation, tamper-proofing, watermarking, anti-disassembly, anti-decompiling, anti-debugging, etc. This lab will be accompanied by a hands-on project that will be divided into 5 phases (each phase will be graded): Phase 1 “Application Protection”: Groups of 2 students will be asked to protect software apps using either existing tools and/or (possibly) self-developed tools/scripts. All groups will be given a set of assets that they must protect against MATE attackers. The protection tools and techniques employed by each group will be documented. Phase 2 “Reverse Engineering”: Each group of students will exchange their apps and documentation from Phase 1 with another group. Each group will have a set of reverse engineering tasks to perform on the apps which they received using at least one tool specified by the instructors and any other tools they choose or develop. All tasks must be documented (using screenshots or screen-casts) such that they can be reproduced by any other group in Phase 3. Phase 3 “Verifying Findings”: Each group of students will get the apps of another group form Phase 1 and the reverse engineering documentation from Phase 2 corresponding to the apps. Each group will verify the reverse-engineering findings of another team from Phase 2 by reproducing the tasks according to the documentation. Each task from Phase 2, must be reproduced and recorded as a screen-cast. Incorrect, missing or incompletely documented tasks from Phase 2 will be documented and corrected if possible. Phase 4 “Application Hardening”: Each group will have to apply additional protection mechanisms to their own apps such that as many attacks as possible from Phases 2 and 3 are mitigated. Each team will have to document which protection techniques were added, why they were employed and which attacks they should defend against. Phase 5 “Verifying Hardening”: Finally, each group of students will receive the hardened apps and documentation (from Phase 4) of another group and the documentation corresponding to the apps from Phases 2 and 3. Each group will verify which protections added in Phase 4 defend against which attacks from Phases 2 and 3. Results must be documented in a final report and recorded as screen-casts for each reverse-engineering task.
Links	E-Learning course (e. g. Moodle) TUMonline entry

additional remarks

The goal of this lab is to teach students how to protect software applications against so called Man-At-The-End (MATE) attackers. MATE attackers control the system on which the application is running and their goals include but are not limited to: reverse engineering a proprietary algorithm, cracking software, cheating in games, bypassing license checks or extracting secret keys embedded in software. MATE attackers have capabilities that exceed those of remote attackers, e.g. MATE attackers can perform interactive debugging on applications and modify their code and/or memory values during execution. They can do this without needing to exploit any vulnerability of the target application. This lab will focus on applications written in C, because MATE attacks are often performed at binary level. To defend against MATE attackers we will first present tools and techniques used in reverse engineering and then present tools and techniques for software protection. We will cover an array of techniques employed in state-of-the-art software protection such as: obfuscation, tamper-proofing, watermarking, anti-disassembly, anti-decompiling, anti-debugging, etc. This lab will be accompanied by a hands-on project that will be divided into 5 phases (each phase will be graded): Phase 1 “Application Protection”: Groups of 2 students will be asked to protect software apps using either existing tools and/or (possibly) self-developed tools/scripts. All groups will be given a set of assets that they must protect against MATE attackers. The protection tools and techniques employed by each group will be documented. Phase 2 “Reverse Engineering”: Each group of students will exchange their apps and documentation from Phase 1 with another group. Each group will have a set of reverse engineering tasks to perform on the apps which they received using at least one tool specified by the instructors and any other tools they choose or develop. All tasks must be documented (using screenshots or screen-casts) such that they can be reproduced by any other group in Phase 3. Phase 3 “Verifying Findings”: Each group of students will get the apps of another group form Phase 1 and the reverse engineering documentation from Phase 2 corresponding to the apps. Each group will verify the reverse-engineering findings of another team from Phase 2 by reproducing the tasks according to the documentation. Each task from Phase 2, must be reproduced and recorded as a screen-cast. Incorrect, missing or incompletely documented tasks from Phase 2 will be documented and corrected if possible. Phase 4 “Application Hardening”: Each group will have to apply additional protection mechanisms to their own apps such that as many attacks as possible from Phases 2 and 3 are mitigated. Each team will have to document which protection techniques were added, why they were employed and which attacks they should defend against. Phase 5 “Verifying Hardening”: Finally, each group of students will receive the hardened apps and documentation (from Phase 4) of another group and the documentation corresponding to the apps from Phases 2 and 3. Each group will verify which protections added in Phase 4 defend against which attacks from Phases 2 and 3. Results must be documented in a final report and recorded as screen-casts for each reverse-engineering task.

Links

E-Learning course (e. g. Moodle)
TUMonline entry