Project 8: Complete Cardputer Security Toolkit (Capstone)

Build a unified firmware that combines WiFi analysis, BLE tooling, IR control, USB HID, and GPS wardriving into a single coherent system with shared settings and consistent UI.

Quick Reference

Attribute Value
Difficulty Master
Time Estimate 2-3 months
Language C/C++ (ESP-IDF recommended)
Hardware Cardputer + microSD + GPS module + IR receiver
Key Topics architecture, shared services, OTA, power management

Goal

You will integrate multiple complex subsystems into a stable, field-usable firmware. This project teaches you system architecture, task orchestration, shared resource management, and reliability engineering on a constrained device.

Why This Project Matters

This is a real product-level build. You are not just writing apps; you are building a platform that coordinates radios, storage, UI, and hardware peripherals without crashes or data loss. The result is a portfolio-grade firmware.

System Architecture

                  +-------------------------+
                  |        Launcher         |
                  +-----------+-------------+
                              |
                 +------------v-------------+
                 |     Shared Services      |
                 | UI | Input | Storage |   |
                 | WiFi | BLE | USB | IR |  |
                 +------------+-------------+
                              |
   +--------------------------+--------------------------+
   |                          |                          |
WiFi Tools               BLE HID Tools                IR Tools
(sniffer/map)            (keyboard/macro)            (learn/replay)
   |                          |                          |
   +-------------+------------+--------------+-----------+
                 |                           |
             GPS Logger                  Payload Engine

Implementation Plan

Phase 1: Platform and UI

  • Create a unified launcher
  • Add a shared services layer
  • Implement settings and theme persistence

Phase 2: Tool Integration

  • Integrate WiFi sniffer and wardriving tools
  • Integrate BLE HID and USB HID
  • Add IR learning and replay

Phase 3: Reliability

  • Add watchdog and crash recovery
  • Centralize logging and error reporting
  • Implement safe mode on boot

Phase 4: OTA and Power

  • Add OTA update pipeline
  • Implement battery-aware throttling

Real World Outcome

You boot a single firmware and can switch between WiFi scanning, BLE macros, IR remotes, and USB HID without rebooting. Logs are saved and the UI stays consistent across tools.

Example output:

CARDPUTER TOOLKIT
[1] WiFi Sniffer
[2] Wardriving
[3] BLE HID
[4] USB HID
[5] IR Remote
[6] Settings

The Core Question You’re Answering

How do you unify multiple high-demand subsystems into a stable, user-friendly embedded platform?

Concepts You Must Understand First

  • Service architecture and dependency boundaries
  • Task scheduling and priority management
  • Storage layout and schema versioning
  • Boot flows and safe-mode recovery

Questions to Guide Your Design

  • Which services are global vs per-tool?
  • How do you handle conflicting radio usage?
  • How do you ensure logs are never corrupted?
  • What happens if a tool crashes mid-session?

Thinking Exercise

Draw a resource map of every peripheral (WiFi, BLE, USB, SD, display, keyboard). Mark which tools own them and when.

Interview Questions They’ll Ask

1) How do you design shared services for embedded tools? 2) How do you prevent one task from starving others? 3) How do you build an OTA system without bricking devices? 4) How do you validate a multi-tool firmware release?

Hints in Layers

1) Start with a launcher that only switches between dummy apps. 2) Add services one by one (display, input, storage). 3) Integrate one tool at a time and stabilize it before the next. 4) Add OTA and safe mode last.

Books That Will Help

| Book | Chapters | Why it helps | |——|———-|————–| | Clean Architecture | Core chapters | System boundaries | | Making Embedded Systems | Ch. 9-10 | Resource management | | Effective C | Ch. 10-12 | Safety in large codebases |

Common Pitfalls and Debugging

Problem: “Random resets when switching tools”

  • Why: Conflicting resource ownership or memory leaks
  • Fix: Centralize resource access and enforce ownership
  • Quick test: Switch tools 50 times with heap tracing enabled

Problem: “Logs corrupted after crash”

  • Why: Unflushed buffers or partial writes
  • Fix: Implement atomic write or journaling
  • Quick test: Simulate power loss during writes

Definition of Done

  • All tools share a single launcher and settings
  • Switching tools never reboots the device
  • OTA update succeeds with rollback
  • Logs remain valid after forced reset
  • Battery runtime exceeds 2 hours in mixed use

Extensions

  • Add a plugin system for new tools
  • Add remote sync of logs
  • Add signed firmware updates