Binary reference

integrity-check

A system integrity checker for verifying script and configuration files

Version10.0.3Size3.9MBAuthorWarith Al MaawaliLicenseProprietaryWebsitehttps://digi77.com

File Information

Property	Value
Binary Name	integrity-check
Version	10.0.3
Build Date	Not disclosed
Rust Version	1.82.0
File Size	3.9MB
Author	Warith Al Maawali
License	Proprietary
Category	Kodachi Binary
Description	A system integrity checker for verifying script and configuration files
Git Commit	unknown
Metadata Generated	2026-09-29T22:00:18Z
Binary Timestamp	Unknown
JSON Data	View Raw JSON

SHA256 Checksum

653bba192d07ef90909c72d1f6952849c42b655432e70cd85d3135ebccbac894

Features

#	Feature
1	File integrity verification using SHA-256 hashes
2	Cryptographic signature verification
3	Version checking against remote repositories
4	Configuration file validation
5	Offline mode support
6	Comprehensive logging and reporting

Security Features

Feature	Description
Authentication	Certificate pinning for secure connections
Encryption	TLS 1.3 for all network communications
Input Validation	All inputs validated and sanitized
Rate Limiting	Maximum 3 retries with configurable timeouts

System Requirements

Requirement	Value
OS	Linux (Debian-based)
Privileges	sudo for 'generate', 'check-signatures' and 'check-all'. The read-only checks run as your normal user, but anything that writes into the install directory (the generated and remote hash manifests) needs write access to it
Dependencies	OpenSSL, curl

Global Options

Flag	Description
`-h, --help`	Print help information
`-v, --version`	Print version information
`-n, --info`	Display detailed information
`-e, --examples`	Show usage examples
`--json`	Output in JSON format
`--json-pretty`	Pretty-print JSON output
`--json-filter <FIELDS>`	Filter JSON output fields
`--verbose`	Enable verbose output
`--quiet`	Suppress non-essential output
`--no-color`	Disable colored output
`--config <FILE>`	Use custom configuration file
`--timeout <SECS>`	Set timeout (default: 30)
`--retry <COUNT>`	Retry attempts, 1-20 [default: 3]. This is the flag that actually sets the retry count
`--json-human`	Colorized, jq-style JSON output
`--fields <FIELDS>`	Select which fields to keep in JSON output
`--limit <N>`	Limit the number of records in JSON output
`--offset <N>`	Skip the first N records in JSON output
`-o, --output-format <FORMAT>`	Output format (text\|json) [default: text]
`--base-dir <DIR>`	Base directory for the application. Rejects '..', shell metacharacters and the system prefixes /etc, /sys, /proc, /dev, /root
`-d, --work-dir <DIR>`	Working directory for the process
`--port <PORT>`	Override the network port used for remote lookups
`-V, --verbosity <LEVEL>`	Verbosity level (0-3) [default: 1]
`--log-level <LEVEL>`	Logging level (error\|warn\|info\|debug\|trace)
`--no-network`	Offline mode: skip every remote call, verify against the local manifest only
`--strict`	Require the online comparison to count when it applies to the current build
`--lenient`	Treat local-only files missing from the remote manifest as advisory; hash mismatches and missing local files still fail

Commands

Integrity Operations

`check-integrity`

Online hash comparison (version-aware, advisory). Compares tracked files against the published manifest for the CURRENT build. If your build is behind/ahead of the latest published build, the test does not apply and is reported as an advisory, not a failure. For authoritative tamper detection use check-signatures.

Usage:

integrity-check check-integrity [OPTIONS]

Options:

--base-dir <DIR>: Run against a different install root instead of the detected one
--no-network: Offline mode: compare against the cached local manifest, no remote fetch
--strict: Force the online comparison to count even when your build differs from the latest published build
--lenient: Report local-only files absent from the remote manifest without failing; hash mismatches and missing local files still fail
--timeout <SECS>: Network timeout for fetching the remote manifest [default: 30]
--retry <COUNT>: Retry attempts for the remote fetch, 1-20 [default: 3]
-V, --verbosity <LEVEL>: Detail level 0-3 [default: 1]
--json / --json-pretty / --json-human: Machine readable output for scripting or the dashboard

Examples:

integrity-check check-integrity

integrity-check check-integrity --json

`generate`

Generate new hash file for all tracked files

Usage:

integrity-check generate [OPTIONS]

Options:

--base-dir <DIR>: Run against a different install root instead of the detected one
--no-network: Offline mode: hash local files only, do not contact the server
--strict: Enable strict validation while hashing
-V, --verbosity <LEVEL>: Detail level 0-3 [default: 1]
--json / --json-pretty / --json-human: Machine readable output for scripting or the dashboard

Examples:

integrity-check generate

integrity-check generate --json

`check-signatures`

AUTHORITATIVE tamper check. Verifies every expected binary against its detached RSA signature using a pinned public key, fully offline (works on Tor/airgapped). Fails on a bad signature, a missing expected binary or signature, a duplicate, or a signature for a file not in the trusted inventory. This is the verdict to trust for 'is my install authentic'.

Usage:

integrity-check check-signatures [OPTIONS]

Options:

--base-dir <DIR>: Run against a different install root instead of the detected one
--strict: Fail on any signature mismatch instead of only reporting it
-V, --verbosity <LEVEL>: Detail level 0-3 [default: 1]
--json / --json-pretty / --json-human: Machine readable output for scripting or the dashboard

Examples:

integrity-check check-signatures

integrity-check check-signatures --json

Verification Operations

`check-version`

Compare local package versions against remote repositories

Usage:

integrity-check check-version [OPTIONS]

Options:

--no-network: Offline mode. Version checking needs the network, so this leaves nothing to compare
--timeout <SECS>: Network timeout for the remote version lookup [default: 30]
--retry <COUNT>: Retry attempts for the remote lookup, 1-20 [default: 3]
-V, --verbosity <LEVEL>: Detail level 0-3 [default: 1]
--json / --json-pretty / --json-human: Machine readable output for scripting or the dashboard

Examples:

integrity-check check-version

integrity-check check-version --json

`check-config`

Verify the integrity and format of configuration files

Usage:

integrity-check check-config [OPTIONS]

Options:

--base-dir <DIR>: Run against a different install root instead of the detected one
--strict: Enable strict validation of the configuration files
-V, --verbosity <LEVEL>: Detail level 0-3 [default: 1]
--json / --json-pretty / --json-human: Machine readable output for scripting or the dashboard

Examples:

integrity-check check-config

integrity-check check-config --json

`check-all`

Comprehensive check. Runs the AUTHORITATIVE offline signature verification FIRST (its verdict decides pass/fail), then the version-aware online hash comparison as an advisory. A bad signature fails; being behind the latest published build does not.

Usage:

integrity-check check-all [OPTIONS]

Options:

--base-dir <DIR>: Run against a different install root instead of the detected one
--no-network: Offline mode: run the local integrity pass only, skip the remote manifest
--strict: Require an applicable current-build online comparison to pass
--lenient: Report local-only files absent from the remote manifest without failing the online comparison
--timeout <SECS>: Network timeout, raise it for a slow link [default: 30]
--retry <COUNT>: Retry attempts for the remote fetch, 1-20 [default: 3]
-V, --verbosity <LEVEL>: Detail level 0-3 [default: 1]
--json / --json-pretty / --json-human: Machine readable output for scripting or the dashboard

Examples:

integrity-check check-all

integrity-check check-all --json

Utility Operations

`view-logs`

Display the most recent integrity check logs

Usage:

integrity-check view-logs [OPTIONS]

Options:

-V, --verbosity <LEVEL>: Detail level 0-3 [default: 1]
--json / --json-pretty / --json-human: Machine readable output for scripting or the dashboard
--limit <N>: Show at most N log records

Examples:

integrity-check view-logs

integrity-check view-logs --json

Operational Scenarios

Scenario-oriented workflows generated from the binary's built-in -e --json examples.

Scenario 1: Basic Usage

Core integrity checking. check-integrity is the version-aware ONLINE hash comparison against the current published build; for the authoritative 'is my install authentic' answer use check-signatures (offline).

Step 1: Online hash comparison (version-aware)

integrity-check check-integrity

Expected Output: If your build equals the latest published build: a per-file pass/fail list and exit 10 on a real mismatch. If your build is behind/ahead/unknown: 'Online hash comparison: NOT APPLICABLE' with an advisory and exit 0. Rely on check-signatures for tamper detection.

Note

This refreshes the cached remote manifest inside the install directory, so on a root-owned install (for example /opt) prefix it with sudo or pass --no-network.

Step 2: Online hash comparison with JSON output

integrity-check check-integrity --json

Step 3: Report known local-only legacy files without failing

integrity-check check-integrity --lenient

Expected Output: Local-only files remain listed, but only hash mismatches or files missing locally fail the comparison

Note

The default is fail-closed. Use this only after reviewing every local-only file.

Step 4: Check a second Kodachi install instead of the detected one

integrity-check check-integrity --base-dir /opt/kodachi/dashboard/hooks

Expected Output: Integrity results for the files under that directory

Note

--base-dir is validated: '..', shell metacharacters (* ? { } ( ) ; | & $ ` < >) and the system prefixes /etc, /sys, /proc, /dev and /root are all rejected.

Step 5: Same check against a custom install root, as JSON

integrity-check check-integrity --base-dir /opt/kodachi/dashboard/hooks --json

Expected Output: JSON envelope with the results for that directory

Scenario 2: Comprehensive System Checks

check-all runs the authoritative offline signature verification FIRST, then the version-aware online hash comparison as an advisory, and writes the refreshed remote manifest into the install directory, which is why it wants root.

Step 1: Complete system verification (offline-authoritative)

sudo integrity-check check-all

Expected Output: 'Offline signature verification (authoritative): PASS/FAIL' first; a signature failure fails the run. Then the online hash comparison, shown as NOT APPLICABLE with an advisory when your build is not the latest published one. Exit 10 only on a real tamper (or a strict online mismatch).

Note

Needs root because it rewrites the cached manifest inside a root-owned install directory.

Step 2: Full system verification over a slow or Tor-routed link

sudo integrity-check check-all --timeout 300

Expected Output: The same report, with up to 300 seconds allowed per network call

Note

--timeout accepts 1 to 300 seconds. The default of 30 is often too short over Tor.

Step 3: Strict: also fail on an applicable current-build online mismatch

sudo integrity-check check-all --strict --json

Expected Output: JSON envelope. Offline signatures still decide tamper; with --strict an applicable current-build online mismatch fails the run. Local-only files fail unless --lenient is also passed

Note

Without --strict, an online mismatch on the current build is a publish-consistency advisory (exit 0), not a failure.

Scenario 3: Hash Generation

Creating and managing file integrity hashes

Step 1: Create a new hash manifest covering all tracked files

sudo integrity-check generate

Expected Output: The generated hash manifest is written into the install directory, replacing the previous one

Note

Needs root. This OVERWRITES the existing manifest: whatever is on disk right now becomes the new baseline, so only run it when you trust the current state of the system. Running it on a tampered system makes the tampering the reference.

Step 2: Hash generation with JSON output for automation

sudo integrity-check generate --json

Expected Output: JSON envelope reporting how many files were hashed and where the manifest was written

Scenario 4: Version Checking

Package version verification against remote repositories

Step 1: Compare local package versions against remote repositories

integrity-check check-version

Expected Output: A per-package comparison of the local version against the remote one, and a list of any mismatches

Note

Needs network access. With --no-network there is nothing to compare against.

Step 2: Version check with JSON output for scripting

integrity-check check-version --json

Expected Output: JSON envelope with the local and remote version of each tracked package

Scenario 5: Configuration Management

Configuration file verification and validation

Step 1: Verify the integrity and format of configuration files

integrity-check check-config

Expected Output: A pass/fail line per configuration file, with the parse error shown for any file that is malformed

Step 2: Configuration check with JSON output

integrity-check check-config --json

Expected Output: JSON envelope listing each configuration file and whether it validated

Scenario 6: Signature Verification

Authoritative offline tamper detection. Verifies every expected binary against a pinned public key and fails on coverage gaps.

Step 1: Authoritative 'is my install authentic' check (offline)

sudo integrity-check check-signatures

Expected Output: A verified/failed line per binary, checked against the pinned public key, plus any coverage gap (an expected binary or signature missing), duplicate signature, or signature for a file outside the trusted inventory. Any of these fails the run.

Note

Works with no network (Tor/airgapped). Only a key whose fingerprint is pinned into the tool is trusted. Needs root to read the protected signature material.

Step 2: Signature verification with JSON output

sudo integrity-check check-signatures --json

Expected Output: JSON with success and per-file status plus inventory_missing, duplicate_signatures and unexpected_signatures lists

Step 3: Strict signature verification

sudo integrity-check check-signatures --strict

Expected Output: The same report, but the command exits non-zero on the first signature that does not verify

Note

Use this in automation: without --strict a mismatch is reported but does not fail the run.

Scenario 7: Log Management

Viewing and managing integrity check logs

Step 1: Display the most recent integrity check logs

integrity-check view-logs

Expected Output: The most recent log entries, newest last

Step 2: View logs in JSON format for parsing

integrity-check view-logs --json

Expected Output: JSON envelope with one object per log record

Note

Useful for log analysis tools

Scenario 8: Offline and Hardened Operation

--no-network is the headline offline mode: it skips every remote call so the check runs entirely against the local manifest, which is what you want on an air-gapped machine or when you do not want the box reaching out at all. --strict tightens what counts as a failure, and --verbosity controls how much detail is printed.

Step 1: Verify files offline, against the manifest already on disk

integrity-check check-integrity --no-network

Expected Output: The usual pass/fail list, with no remote fetch and no manifest rewrite

Note

Nothing leaves the machine. The cached remote manifest is not refreshed, so results are only as current as the last online run.

Step 2: Rebuild the hash manifest from local files only

sudo integrity-check generate --no-network --strict

Expected Output: A regenerated hash file covering every tracked file

Note

Needs root: it writes the manifest into the install directory. Run it after a deliberate system update, otherwise a later check-integrity will report your own changes as tampering.

Step 3: Show more detail about each file as it is checked

integrity-check check-integrity --verbosity 2

Expected Output: Per-file progress lines in addition to the summary

Note

Levels are 0 (quiet) to 3 (most detail). Default is 1.

Step 4: Automation-friendly run with an explicit retry budget

sudo integrity-check check-all --output-format json --timeout 60 --retry 5

Expected Output: A single JSON envelope, retrying each failed network call up to 5 times

Note

--retry accepts 1 to 20. The older --max-retries flag is deprecated and ignored: only --retry changes the retry count.

Environment Variables

Variable	Description	Default	Values
`RUST_LOG`	Set logging level	info	error\|warn\|info\|debug\|trace
`NO_COLOR`	Disable all colored output when set	unset	1\|true\|yes (any value disables color)
`HTTP_PROXY`	HTTP proxy for network requests	unset	http://proxy:port
`HTTPS_PROXY`	HTTPS proxy for secure requests	unset	https://proxy:port

Exit Codes

Code	Description
0	Success
1	General error
10	Check failure - tampering (offline signature failure) or, when your build is the current published build, a real hash mismatch. Being behind the latest published build is NOT a failure (exit 0 with an advisory).
2	Invalid arguments
3	Permission denied
4	Network error
5	File not found
6	Timeout error
7	Authentication error
8	Internal error
9	Validation error