Syed Ishmum Ahnaf

Back to all work

Hardening a Forked PS4 Package Merger

Status
In Progress
Period
Personal fork hardening — in progress
Confidentiality
Public. Public fork. The inherited origin, personal hardening scope, unresolved blockers, and desktop-only verification boundary are visible.

Defensive C++ hardening for large-file split, merge, integrity, and recovery workflows, with unresolved blockers kept visible.

I substantially extended a fork through an independently initiated hardening branch covering input validation, safer output publication, a desktop splitter, SHA-256 manifests, CI, sanitizers, and multi-gigabyte verification. Desktop evidence is strong, but five failure-path blockers and unverified OpenOrbis and console behavior keep the project explicitly in progress.

Type
Personal
Categories
  • Systems Engineering
  • Software & Automation
Technologies
  • C++17
  • CMake
  • SHA-256
  • GitHub Actions
  • ASan
  • UBSan

Context

Engineers evaluating defensive file processing, integrity workflows, and release-readiness evidence.

  • The original application and concept are inherited from a fork.
  • Five destructive, durability, capacity, and arithmetic failure paths remain unresolved.
  • OpenOrbis artifacts and console filesystem behavior are unverified.

Problem

Large package-part workflows need strict identity, ordering, capacity, integrity, durability, and recovery behavior; happy-path success alone is insufficient for safe publication or hardware use.

My contribution

I extracted desktop-testable logic; added filtering, sequence and multi-game safeguards; implemented temporary output, splitting, capacity checks, synchronization paths, SHA-256 manifests and verification; added CI, sanitizers, release checks, and large-file tests; and performed adversarial review that exposed remaining false-success and data-retention risks.

Approach

Validate inputs, preflight capacity, stream through temporary files while hashing, validate manifest geometry and checksums, publish through rename and directory synchronization, retain integrity failures for inspection, and separate desktop evidence from platform readiness.

Artifacts

Outcomes

  • Combined and standalone desktop suites, ASan/UBSan, and the CMake Release build passed at the reviewed head.
  • A deterministic 2 GiB split, manifest, merge, and verification run passed in 44.75 seconds.
  • Adversarial review identified five blockers that remain release gates.

Limitations and current status

  • A forced rerun can delete an existing manifest before replacement-input validation.
  • Failed-retention and manifest-publication paths can report success without durable state.
  • Unknown free space and extreme manifest geometry are not fail-safe.
  • No OpenOrbis or hardware verification has been performed.