Teaching Reverse Engineering for LAC4 - My Experience
Introduction
In June 2024, I applied for a call for action from the EU CyberNet. The task at hand was a teaching project for Latin American students that intent to participate in the ENISA International Cybersecurity Challenge 2024. The project was organized by the Latin America and Caribbean Cyber Competence Center (LAC4), an EU-funded institution that wants to provide cybersecurity expertise to Latin America.
As this was my first call for action from the EU CyberNet, I was excited for the experience.
Getting selected
When you want to follow a call for action from the EU CyberNet, you need to send a short application. It is more like an informal message that explains why you think you are a suitable candidate for the announced task. My message focused on my previous teaching experiences and my work on reverse engineering projects.
After a few days, I received a message that invited me to a short video call with the project manager and the customer from Latin America. The meeting was a short introduction, and it was also explained what exactly I would be teaching (more on that later). It was a nice exchange, and I was told that I’m selected.
Following this, we agreed on the dates for the workshop, and I was provided with a course concept.
Besides this, there were few formalities. From my point of view, the whole process was kept as simple as possible, and there was no overhead from formalities.
Working on a reverse engineering teaching program
I started to work on the program right away, as the selected dates were close.
The provided concept lined out various topics that are needed for reverse engineering. Starting from legal and ethical aspects, over assembly instructions and opcodes to obfuscation and anti-debugging mechanisms. I applied some changes to the concept and set a few focus points. I ended up with a workshop concept that targets computer science students (or similar fields) that know the fundamental concepts of computers but have no experience with reverse engineering.
During the preparations, I also was told that I should prepare the students for challenges that are similar to the ones from openECSC 2024. This made me question the workshop concept, as a beginner-level training was probably not enough to successfully solve such challenges. The project managers and I agreed that a more practical and advanced training would be beneficial for the students. Furthermore, I send out a survey to the students to learn more about their level of experience.
Only 7 students filled out my questionnaire. But those already had experiences with reverse engineering, ranging from intermediate to advanced. Hence, I decided to start over and work out a new, practice driven course concept.
The final agenda
The workshop was split into 4 sessions of 3 or 4 hours. My program started with a very brief theoretical lecture and then switched over to practice. I wanted to keep the practice as close to a real security challenge as possible while addressing intermediate topics. Therefore, I created multiple challenges that the students would solve.
This was the final agenda:
- Day 1
- Day 2
- Data structures
- How do arrays, lists and structs look in assembly?
- Challenge 3 and 4
- Identification of data structures in practice
- Identification of hash functions in assembly code
- Introduction to dynamic analysis
- How can program be analyzed during execution?
- Introduction to frida
- Challenge 5 and 6
- Dynamic manipulation of programs
- Make the programs accept any input
- Challenge 7
- Server-based program
- Reverse engineering licence-key algorithms
- Identification of hash functions
- Data structures
- Day 3
- Introduction on SMT/SAT solvers
- Challenge 8 and 9
- Solving challenges with the
angr
framework
- Solving challenges with the
- Day 4
- Introduction to anti-reverse engineering and anti-debugging mechanisms
- Code encryption
- Debugger detection
- Defenses against debuggers
- Anti-frida techniques
- Various obfuscation techniques
- Challenge 10
- Identification of anti-debugging techniques
- Developing using anti-anti debugging techniques
- Introduction to anti-reverse engineering and anti-debugging mechanisms
The students would work on the challenges on their own. After some time, I would ask for solutions and then discuss them in the group. Also, I prepared solutions myself that I would show if no solutions were found. I also used my solutions to discuss different approaches if a student found another way to solve a challenge.
I solved various challenges in the past, but being on the other side of a challenge was an interesting experience. I learned many new things during the preparation.
My experience during the workshop
On the first day, the workshop was opened by the project managers and the responsible person in Latin America. I was introduced and then started the workshop with half an hour of theory. After that, I switched to practice and only added a few slides of theory when it was needed.
The first challenge was designed to be easy if the students could identify the core issue. As it turned out, at least one student did so within 5 minutes. The student in question explained his solution, but I noticed that most of the other students were not that engaging during the discussion. This would stay the same for the remainder of the workshop. Out of 30 students, only 3 or 4 asked questions or presented solutions. However, the students were present as they re-joined the Zoom-call after it was closed accidentally later on.
The students were able to handle most of the challenges as I intended them to be solved. Usually, there was at least one solution that was presented. Often I could further elaborate on the solution and add some background knowledge or show a tool or technique that could help with similar challenges.
The only issue I noticed during the workshop was timing. As mentioned above, the sessions were planned to last 3 to 4 hours. This put me on a strict schedule, and some challenges were ended before the students could find a (full) solution.
While most of the students were not that engaging via voice or video, some were writing feedback in the chat. I was happy to see when students wrote that they learned something new or that they did not know about a certain thing beforehand. This way, I gathered ideas to adapt the workshop concept, in case I’ll use it in the future.
Future improvements
My most important takeaway is the integration of low-level engagements. 7 students responded to my questionnaire, but only 3 or 4 participated in the discussions. Therefore, I think that the live setting might be a reason for the low engagement. I often had the experience that people have things to say during workshops, but often they don’t feel like doing so in front of others. If I get to teach in this setting again, I will use tools like Mentimeter or Slido. This way, the students can interact with me without having to talk in public.
Another point noted is the schedule. To provide the students with more time to solve the challenges, I would add another day to the program. Alternatively, one or two challenges could be dropped to focus on the more interesting challenges.
Besides this, I learned a lot about how students approach my challenges and what they liked about them. I will use these learnings to improve my challenges and make them more interesting and beneficial.
Conclusion
Overall, teaching reverse engineering for LAC4 was a fulfilling experience, and I had a lot of fun while working with the students. Preparing the workshop program was also educational for myself. Furthermore, I experienced the process of applying to an EU CyberNet call for action.
I hope that the students learned new things that will help them for their participation in the ENISA challenge. I also hope that the LAC4 will offer this workshop again next year and that maybe I can be the trainer again.