Download
Obtain the signed executable from ByteCase or the matching official GitHub release.
Running ByteCase
Portable tools with visible local records.
How ByteCase desktop tools are distributed, launched, verified, stored, and operated, including current platform expectations and release behavior.
Expected baseline
Provisional system requirements for desktop releases.
64-bit desktop editions are the primary target.
Hashing performance will scale with processor, storage, and file count.
Higher memory may benefit large manifests and future multi-record workflows.
Separate storage is required for case records, reports, and selected source material.
Administrative access may still be required to reach protected sources or locations.
Internet may be needed only to obtain releases, documentation, or external references.
These are suite-level provisional targets, not final promises for every module. Each signed release should publish tested operating systems, architecture, privileges, storage needs, and known environmental limitations.
Local storage
A predictable folder instead of an invisible record.
ByteCase tools are designed to save visible files under a shared case structure. This keeps important records portable, reviewable, and available even when a module is not open.
Human-readable outputsReports and summaries intended for review outside the application.
Reopenable recordsStructured module data intended to support later editing or verification.
Module separationEach tool uses its own subfolder under the shared case number.
No evidence repository claimThe ByteCase folder is a workflow record, not automatically the laboratory evidence store.
Path.home() / "ByteCase" / <case_number> /
├── bytecase-intake/
├── bytecase-acquire/
├── bytecase-verify/
├── bytecase-notes/
├── exhibits/
├── timeline/
└── reports/Release trust
How an official ByteCase executable should be verified.
Official location
Use a direct ByteCase download or the linked release asset from an official Forensics Byte repository.
Publisher signature
Confirm that Windows reports a valid digital signature from the exact validated Forensics Byte publisher identity.
Published SHA-256
Calculate the final signed file's hash and compare it with the value shown on the release page.
Matching source tag
Use the linked repository tag or commit to inspect the source associated with the official release.
PowerShell verification examples
Get-AuthenticodeSignature .\\ByteCase-Verify-v0.9.0.exe
Get-FileHash .\\ByteCase-Verify-v0.9.0.exe -Algorithm SHA256Privacy direction
Local-first does not remove the need for disclosure.
Each release should identify whether it makes any network connection, checks for updates, collects telemetry, submits crash information, or accesses external services.
The current core direction is local operation without uploading case information to Forensics Byte. That statement must be confirmed against each released build.
Operational boundary
Portable does not mean unrestricted.
Users remain responsible for agency policy, approved software procedures, endpoint controls, evidence access, storage security, validation, and determining whether a tool is appropriate for a particular environment.
Release-specific documentation
The final answer belongs with the version.
As signed releases are published, each module will receive version-specific requirements, release notes, hashes, known limitations, build references, and exact operating behavior.