← Back to all projects

REVERSE ENGINEERING LINUX LEARNING PROJECTS

Reverse engineering on Linux/Unix systems breaks down into these fundamental building blocks:

Software Reverse Engineering in Linux/Unix Environments

Core Concept Analysis

Reverse engineering on Linux/Unix systems breaks down into these fundamental building blocks:

Concept Area What You Need to Understand
ELF Binary Format How executables are structured - headers, sections, segments, symbol tables
Assembly & Disassembly Reading x86-64/ARM instructions, understanding calling conventions
Static Analysis Examining binaries without execution - strings, symbols, control flow
Dynamic Analysis Tracing execution - syscalls, library calls, memory access
Debugging Breakpoints, memory inspection, register manipulation
ptrace Internals How debuggers actually control processes at the kernel level
Binary Patching Modifying executables to change behavior
Anti-RE Techniques Obfuscation, packing, anti-debugging tricks

Project 1: ELF Binary Inspector

  • File: REVERSE_ENGINEERING_LINUX_LEARNING_PROJECTS.md
  • Programming Language: C
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Reverse Engineering / Systems Programming
  • Software or Tool: readelf
  • Main Book: “Practical Binary Analysis” by Dennis Andriesse

What you’ll build: A command-line tool that parses and displays the internal structure of ELF executables—headers, sections, symbols, and dependencies—like a simplified readelf.

Why it teaches reverse engineering: Every RE task starts with understanding the binary format. By parsing ELF yourself, you’ll internalize how Linux organizes executable code, where symbols live, how dynamic linking works, and what information is available before ever running a program.

Core challenges you’ll face:

  • Parsing the ELF header and understanding magic bytes, architecture flags, entry points
  • Navigating section headers vs program headers (static vs runtime view)
  • Extracting and demangling symbol tables (.symtab, .dynsym)
  • Understanding relocations and how dynamic linking resolves addresses

Key Concepts:

  • ELF Structure: “Practical Binary Analysis” Ch. 2-3 - Dennis Andriesse
  • Binary Formats: “Computer Systems: A Programmer’s Perspective” Ch. 7 - Bryant & O’Hallaron
  • Linking & Loading: “The Linux Programming Interface” Ch. 41-42 - Michael Kerrisk

Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: C programming, basic understanding of memory addresses

Real world outcome:

  • Run your tool on any binary: ./elf-inspect /bin/ls and see a formatted display of all sections, symbols, dependencies, and entry point
  • Detect whether a binary is stripped, statically linked, or uses specific libraries
  • Export findings to JSON for further analysis

Learning milestones:

  1. Successfully parse and display ELF header fields (magic, architecture, entry point) - you understand binary file structure
  2. Navigate and display all sections with their permissions and sizes - you understand the static view of binaries
  3. Extract symbols and show imported/exported functions - you understand how programs reference external code

Project 2: System Call Tracer (strace clone)

  • File: REVERSE_ENGINEERING_LINUX_LEARNING_PROJECTS.md
  • Main Programming Language: C
  • Alternative Programming Languages: Rust, C++, Go
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 1. The “Resume Gold” (Educational/Personal Brand)
  • Difficulty: Level 3: Advanced (The Engineer)
  • Knowledge Area: Reverse Engineering, Linux Internals
  • Software or Tool: ptrace, Linux syscall interface
  • Main Book: “The Linux Programming Interface” - Michael Kerrisk

What you’ll build: A tool that intercepts and logs all system calls made by a running process, showing syscall names, arguments, and return values—a minimal strace.

Why it teaches reverse engineering: Dynamic analysis is half of RE. Understanding what a program does at runtime (files opened, network connections made, processes spawned) reveals behavior that static analysis can’t. Building this teaches you ptrace—the same mechanism debuggers use.

Core challenges you’ll face:

  • Using ptrace(PTRACE_TRACEME) and PTRACE_SYSCALL to intercept system calls
  • Reading registers to extract syscall numbers and arguments
  • Mapping syscall numbers to names (parsing syscall tables)
  • Handling multi-threaded programs and fork()

Resources for key challenges:

  • “Playing with ptrace” series by Pradeep Padala - Step-by-step ptrace tutorial
  • “The Linux Programming Interface” Ch. 26 (Process Tracing) - Michael Kerrisk

Key Concepts:

  • ptrace API: “The Linux Programming Interface” Ch. 26 - Michael Kerrisk
  • System Calls: “Linux System Programming” Ch. 1-2 - Robert Love
  • x86-64 Calling Convention: “Computer Systems: A Programmer’s Perspective” Ch. 3 - Bryant & O’Hallaron

Difficulty: Intermediate-Advanced Time estimate: 1-2 weeks Prerequisites: C programming, basic Linux syscall knowledge, understanding of processes

Real world outcome:

  • Run ./mytrace /bin/cat /etc/passwd and see every syscall: open("/etc/passwd", O_RDONLY) = 3, read(3, "root:x:0:0:...", 4096) = 1823
  • Trace a program and discover what files it accesses, what network connections it makes
  • Detect suspicious behavior like unexpected file access or network activity

Learning milestones:

  1. Successfully attach to a process and catch syscall entry/exit - you understand process control
  2. Decode syscall arguments from registers - you understand calling conventions
  3. Pretty-print common syscalls with decoded arguments - you can interpret program behavior

Project 3: Interactive Binary Debugger

  • File: REVERSE_ENGINEERING_LINUX_LEARNING_PROJECTS.md
  • Programming Language: C
  • Coolness Level: Level 5: Pure Magic (Super Cool)
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 4: Expert
  • Knowledge Area: Debugging / Assembly
  • Software or Tool: GDB / Ptrace
  • Main Book: “The Art of Debugging” by Norman Matloff

What you’ll build: A command-line debugger that can set breakpoints, single-step through instructions, inspect registers and memory, and disassemble code—a minimal GDB.

Why it teaches reverse engineering: Debuggers are the primary RE tool. Building one teaches you exactly how breakpoints work (INT3 injection), how single-stepping uses CPU trap flags, and how to read process memory. You’ll understand what GDB does “under the hood.”

Core challenges you’ll face:

  • Injecting 0xCC (INT3) for breakpoints and restoring original bytes
  • Using PTRACE_SINGLESTEP and understanding the trap flag
  • Reading/writing process memory with PTRACE_PEEKDATA/PTRACE_POKEDATA
  • Integrating a disassembler library (Capstone) to show instructions

Resources for key challenges:

  • “Writing a Linux Debugger” by Sy Brand - Complete tutorial series on building a debugger
  • “Building a Debugger” by Sy Brand - No Starch Press book (if available)

Key Concepts:

  • Breakpoint Mechanics: “The Art of Debugging with GDB, DDD, and Eclipse” Ch. 1-2 - Norman Matloff
  • x86 Debug Registers: Intel Software Developer Manual Vol. 3, Ch. 17
  • ptrace Deep Dive: “The Linux Programming Interface” Ch. 26 - Michael Kerrisk
  • Disassembly: Capstone Engine documentation

Difficulty: Advanced Time estimate: 2-4 weeks Prerequisites: Completed Project 2, x86-64 assembly basics, comfort with pointers

Real world outcome:

  • Debug any program: ./mydbg /bin/ls
  • Commands like break main, run, step, regs, mem 0x7fff..., disas
  • Set a breakpoint, hit it, inspect registers, see disassembled instructions around the current IP
  • Single-step through code watching register changes

Learning milestones:

  1. Set a breakpoint and stop execution when hit - you understand how debuggers intercept execution
  2. Single-step and display register state - you understand CPU state inspection
  3. Disassemble and show instructions around current IP - you can follow execution flow

Project 4: Binary Patcher / Crackme Solver

  • File: REVERSE_ENGINEERING_LINUX_LEARNING_PROJECTS.md
  • Main Programming Language: C
  • Alternative Programming Languages: Python, Rust, Assembly
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 1. The “Resume Gold” (Educational/Personal Brand)
  • Difficulty: Level 2: Intermediate (The Developer)
  • Knowledge Area: Reverse Engineering, Binary Analysis
  • Software or Tool: Ghidra, radare2, objdump
  • Main Book: “Practical Binary Analysis” - Dennis Andriesse

What you’ll build: A tool that can analyze simple “crackme” binaries, identify password checks, and patch them to bypass protection—plus create your own crackmes for others to solve.

Why it teaches reverse engineering: This is applied RE. You’ll combine static analysis (finding the comparison), dynamic analysis (understanding the logic), and patching (modifying the binary). Creating crackmes teaches you to think like a protector.

Core challenges you’ll face:

  • Identifying comparison instructions (CMP, TEST) and conditional jumps
  • Understanding control flow to find the “success” vs “failure” paths
  • Patching JNE to JE (or NOPing checks) while maintaining valid ELF structure
  • Creating anti-debugging checks for your own crackmes

Key Concepts:

  • x86 Control Flow: “Practical Binary Analysis” Ch. 6 - Dennis Andriesse
  • Patching Techniques: “Reverse Engineering for Beginners” by Dennis Yurichev (free PDF)
  • Assembly Patterns: “The Art of Assembly Language” Ch. 7-8 - Randall Hyde

Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: Basic x86-64 assembly, ELF understanding from Project 1

Real world outcome:

  • Given a crackme binary, use your analysis skills to find and patch the check
  • Run ./crackme → “Access Denied” → patch → run again → “Access Granted!”
  • Create 3 progressively harder crackmes that require: simple string compare patch, multi-condition patch, and anti-debugging bypass
  • Share crackmes with friends to solve

Learning milestones:

  1. Identify the password check in a simple crackme - you can read assembly for meaning
  2. Patch the binary and bypass the check - you understand binary modification
  3. Create a crackme with anti-debugging - you understand both sides of RE

Project 5: Library Call Interception Framework

  • File: REVERSE_ENGINEERING_LINUX_LEARNING_PROJECTS.md
  • Programming Language: C
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Instrumentation / Hooking
  • Software or Tool: LD_PRELOAD
  • Main Book: “Practical Binary Analysis” by Dennis Andriesse

What you’ll build: A framework using LD_PRELOAD that intercepts library calls (malloc, free, open, connect, SSL_read) to log, modify, or inject behavior into existing programs without source code.

Why it teaches reverse engineering: Understanding how dynamic linking can be exploited is crucial for RE. This technique is used for debugging, instrumentation, and even malware. You’ll learn how the dynamic linker resolves symbols and how to hijack that process.

Core challenges you’ll face:

  • Creating shared libraries with RTLD_NEXT to call original functions
  • Intercepting crypto functions to log plaintext before encryption
  • Hooking memory allocators to detect leaks or heap corruption
  • Making hooks transparent (timing, side effects)

Key Concepts:

  • Dynamic Linking: “The Linux Programming Interface” Ch. 41-42 - Michael Kerrisk
  • LD_PRELOAD Mechanics: “How to Write Shared Libraries” by Ulrich Drepper
  • GOT/PLT: “Practical Binary Analysis” Ch. 2 - Dennis Andriesse

Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: C programming, shared library basics, understanding of linking

Real world outcome:

  • Run LD_PRELOAD=./malloc_trace.so /bin/ls and see every allocation logged
  • Intercept SSL_read/SSL_write on an HTTPS client to see plaintext data
  • Build a “universal logger” that can trace any library call in any program
  • Create a “chaos monkey” that randomly fails malloc calls to test program resilience

Learning milestones:

  1. Intercept malloc and log allocations - you understand symbol resolution hijacking
  2. Intercept connect() and log all network connections - you can monitor program behavior
  3. Intercept SSL functions and log decrypted traffic - you understand why runtime analysis is powerful

Project Comparison Table

Project Difficulty Time Depth of Understanding Fun Factor
ELF Binary Inspector Intermediate 1-2 weeks ⭐⭐⭐ Binary format fundamentals ⭐⭐⭐ Seeing inside binaries
System Call Tracer Intermediate-Advanced 1-2 weeks ⭐⭐⭐⭐ Process control & syscalls ⭐⭐⭐⭐ Spying on programs
Interactive Debugger Advanced 2-4 weeks ⭐⭐⭐⭐⭐ Deep ptrace & CPU mechanics ⭐⭐⭐⭐ Building a real tool
Binary Patcher/Crackme Intermediate 1-2 weeks ⭐⭐⭐ Applied analysis & patching ⭐⭐⭐⭐⭐ CTF-style challenges
Library Interception Intermediate 1-2 weeks ⭐⭐⭐⭐ Dynamic linking internals ⭐⭐⭐⭐ Hijacking programs

Based on the scope of reverse engineering, I recommend this progressive path:

  1. Start with Project 1 (ELF Inspector) - You need to understand binary format before anything else. This gives you the vocabulary and mental model for everything that follows.

  2. Then Project 2 (Syscall Tracer) - Learn ptrace fundamentals and dynamic analysis. This is more immediately useful and builds toward the debugger.

  3. Then Project 3 (Debugger) - The capstone project. Once you’ve built a debugger, you truly understand how RE tools work.

  4. Interleave Project 4 (Crackmes) - Do this alongside or after Project 2-3 as “practice” applying your skills.

  5. Project 5 (LD_PRELOAD) - A different angle on instrumentation that complements ptrace-based analysis.

Final Capstone Project: Malware Analysis Sandbox

What you’ll build: A complete isolated analysis environment that automatically executes suspicious binaries and produces behavioral reports—combining all previous projects into an automated analysis pipeline.

Why it teaches reverse engineering: Real-world RE often means analyzing unknown, potentially malicious code. This project integrates static analysis (ELF parsing), dynamic analysis (syscall tracing), and instrumentation (library hooking) into a cohesive automated system that produces actionable intelligence.

Core challenges you’ll face:

  • Creating isolated execution environments (containers, VMs, or seccomp sandboxes)
  • Combining your ELF inspector for static indicators (strings, imports, sections)
  • Using your syscall tracer to capture all runtime behavior
  • Detecting anti-analysis techniques (VM detection, timing checks, ptrace detection)
  • Generating human-readable reports with behavioral indicators

Resources for key challenges:

  • “Practical Malware Analysis” by Sikorski & Honig - The definitive guide
  • Cuckoo Sandbox architecture documentation - How real sandboxes work

Key Concepts:

  • Sandbox Design: “Practical Malware Analysis” Ch. 2-4 - Sikorski & Honig
  • Behavioral Analysis: “Practical Malware Analysis” Ch. 3 - Sikorski & Honig
  • Container Isolation: Linux namespaces and seccomp documentation
  • Anti-Analysis Detection: “Practical Malware Analysis” Ch. 16-17 - Sikorski & Honig

Difficulty: Advanced Time estimate: 1 month+ Prerequisites: All previous projects completed, container/VM familiarity

Real world outcome:

  • Submit any binary: ./sandbox analyze suspicious_binary
  • Get a report showing:
    • Static indicators: suspicious strings, imports, sections
    • Network activity: connections attempted, DNS queries
    • File activity: files created, modified, read
    • Process activity: children spawned, injections attempted
    • Behavioral classification: “This binary appears to be a reverse shell that…”
  • Web dashboard showing analysis history and threat indicators
  • Export IOCs (Indicators of Compromise) in standard formats

Learning milestones:

  1. Isolated execution that contains any malicious behavior - you understand sandboxing
  2. Automated static + dynamic analysis with structured output - you’ve integrated your tools
  3. Detection of anti-analysis and evasion attempts - you understand adversarial thinking
  4. Production-quality reports useful for incident response - you’ve built something professionals use

Additional Resources

CTF Platforms for Practice

  • pwnable.kr - Binary exploitation challenges
  • crackmes.one - Reverse engineering challenges
  • picoCTF - Beginner-friendly CTF with RE categories
  • Reverse Engineering challenges on HackTheBox

Essential Tools to Master

  • objdump, readelf, nm - Basic static analysis
  • strace, ltrace - System/library call tracing
  • gdb with pwndbg/peda/gef - Enhanced debugging
  • Ghidra - Free decompiler from NSA
  • Radare2/Cutter - Open source RE framework
  • Capstone - Disassembly framework for your tools