Project 14: Secure String and Buffer Library

A security-focused string and buffer library implementing Annex K interfaces, with fuzzing tests and formal verification considerations.

Quick Reference

Attribute Value
Primary Language C
Alternative Languages None
Difficulty Level 4 - Expert
Time Estimate See main guide
Knowledge Area Security, Memory Safety
Tooling GCC, AddressSanitizer, Fuzzing tools
Prerequisites See main guide

What You Will Build

A security-focused string and buffer library implementing Annex K interfaces, with fuzzing tests and formal verification considerations.

Why It Matters

This project builds core skills that appear repeatedly in real-world systems and tooling.

Core Challenges

  • Bounds-checking interfaces → Maps to Annex K _s functions
  • Defensive design → Maps to fail-safe patterns
  • Security testing → Maps to fuzzing and verification

Key Concepts

  • Map the project to core concepts before you code.

Real-World Outcome

# 1. Secure string operations
$ ./secure_demo strings
Standard (DANGEROUS):
  strcpy(dst, src) with src="AAAA...AA" (100 bytes)
  BUFFER OVERFLOW - wrote past dst[10]

Secure version:
  strcpy_s(dst, 10, src) with src="AAAA...AA" (100 bytes)
  Result: EINVAL (buffer too small)
  dst contents: "" (zeroed on error)

# 2. Constraint handler
$ ./secure_demo constraint
Setting constraint handler to abort_handler_s...
strcpy_s(dst, 10, NULL);
CONSTRAINT VIOLATION: src is NULL
  Called from: demo.c:42
  Calling abort()...
Aborted

# 3. Fuzzing results
$ ./fuzz_test -max_len=1000 -runs=1000000
Running 1000000 fuzzing iterations...
No crashes found in secure_strcpy_s
No crashes found in secure_strcat_s
1 edge case found in secure_sprintf_s:
  - Empty format string with args triggers assertion
Coverage: 98.5% of security-critical paths

Implementation Guide

  1. Reproduce the simplest happy-path scenario.
  2. Build the smallest working version of the core feature.
  3. Add input validation and error handling.
  4. Add instrumentation/logging to confirm behavior.
  5. Refactor into clean modules with tests.

Milestones

  • Milestone 1: Minimal working program that runs end-to-end.
  • Milestone 2: Correct outputs for typical inputs.
  • Milestone 3: Robust handling of edge cases.
  • Milestone 4: Clean structure and documented usage.

Validation Checklist

  • Output matches the real-world outcome example
  • Handles invalid inputs safely
  • Provides clear errors and exit codes
  • Repeatable results across runs

References

  • Main guide: PROFESSIONAL_C_PROGRAMMING_MASTERY.md
  • Effective C, 2nd Edition by Robert C. Seacord