docs: use canonical cybercx.com domain for the usnjrnl_rewind credit

Both cybercx.com and cybercx.com.au serve the article; .com is the global
corporate domain. Verified the link resolves to the real post (HTTP 200, title
'NTFS Usnjrnl Rewind | CyberCX', self-canonical).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: h4x0r

CHANGELOG.md

@@ -13,7 +13,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 - Feature `$UsnJrnl:$J` full-path reconstruction (the *Rewind* engine) as the
   headline capability, with a worked example, and credit the technique's
-  originator, [CyberCX](https://cybercx.com.au/blog/ntfs-usnjrnl-rewind/)
+  originator, [CyberCX](https://cybercx.com/blog/ntfs-usnjrnl-rewind/)
   ([`CyberCX-DFIR/usnjrnl_rewind`](https://github.com/CyberCX-DFIR/usnjrnl_rewind)).
   Docs-only; no code change.
 

README.md

@@ -132,7 +132,7 @@ for resolved in engine.rewind(&ntfs_core::usn::parse_usn_journal(&usn_bytes)?) {
 
 `RewindEngine` runs **two passes — reverse, then forward** — so a rename or an MFT-entry reuse part-way through the journal resolves to the *correct* path at each point in time. Events whose parent is no longer present in the live `$MFT` still resolve from the journal's own create/rename history, tagged `RecordSource::Carved` or `Ghost`. For journals too large to hold in memory, `UsnJournalReader` streams them; `carve_usn_records` recovers events from journal slack and unallocated space; and `RefsAnalyzer` handles ReFS's 128-bit USN V3 references.
 
-> **Credit:** the journal-`$J` path-reconstruction technique was pioneered by **CyberCX** — see their writeup [*NTFS Usnjrnl Rewind*](https://cybercx.com.au/blog/ntfs-usnjrnl-rewind/) (April 2024) and the reference tool [`CyberCX-DFIR/usnjrnl_rewind`](https://github.com/CyberCX-DFIR/usnjrnl_rewind). This is an independent, clean-room Rust implementation built on `ntfs-core`'s own parsers; its SQLite export is column-compatible with `usnjrnl_rewind`.
+> **Credit:** the journal-`$J` path-reconstruction technique was pioneered by **CyberCX** — see their writeup [*NTFS Usnjrnl Rewind*](https://cybercx.com/blog/ntfs-usnjrnl-rewind/) (April 2024) and the reference tool [`CyberCX-DFIR/usnjrnl_rewind`](https://github.com/CyberCX-DFIR/usnjrnl_rewind). This is an independent, clean-room Rust implementation built on `ntfs-core`'s own parsers; its SQLite export is column-compatible with `usnjrnl_rewind`.
 
 ## Reader API (`ntfs-core`)
 

core/README.md

@@ -58,7 +58,7 @@ for resolved in engine.rewind(&ntfs_core::usn::parse_usn_journal(&usn_bytes)?) {
 - `carve_usn_records` — recover USN records from free space and corrupt journals (V2/V3, timestamp-range gated).
 - `RefsAnalyzer` / `RefsFileId` — ReFS USN V3 support (128-bit file IDs, journal-rewind-only path reconstruction).
 
-> **Credit:** the journal-`$J` path-reconstruction technique was pioneered by **CyberCX** — [*NTFS Usnjrnl Rewind*](https://cybercx.com.au/blog/ntfs-usnjrnl-rewind/) (April 2024) · [`CyberCX-DFIR/usnjrnl_rewind`](https://github.com/CyberCX-DFIR/usnjrnl_rewind). `RewindEngine` is an independent, clean-room Rust implementation.
+> **Credit:** the journal-`$J` path-reconstruction technique was pioneered by **CyberCX** — [*NTFS Usnjrnl Rewind*](https://cybercx.com/blog/ntfs-usnjrnl-rewind/) (April 2024) · [`CyberCX-DFIR/usnjrnl_rewind`](https://github.com/CyberCX-DFIR/usnjrnl_rewind). `RewindEngine` is an independent, clean-room Rust implementation.
 
 ## Trust, but verify
 

forensic/README.md

@@ -63,7 +63,7 @@ Beyond MFT-record anomalies, this crate analyses the USN change journal (decoded
 - `correlation` — cross-references USN ↔ `$LogFile` ↔ `$MFT` to surface ghost records, coverage gaps, entry reuse, and timestamp conflicts.
 - `triage` — a `TriageEngine` with 12 built-in investigative questions over reconstructed records.
 
-The "reconstructed records" these analyse come from `ntfs-core`'s `RewindEngine`, which rebuilds the full path of every journal event — even for deleted, MFT-reused files — via the *Rewind* algorithm pioneered by **CyberCX** ([*NTFS Usnjrnl Rewind*](https://cybercx.com.au/blog/ntfs-usnjrnl-rewind/) · [`CyberCX-DFIR/usnjrnl_rewind`](https://github.com/CyberCX-DFIR/usnjrnl_rewind)).
+The "reconstructed records" these analyse come from `ntfs-core`'s `RewindEngine`, which rebuilds the full path of every journal event — even for deleted, MFT-reused files — via the *Rewind* algorithm pioneered by **CyberCX** ([*NTFS Usnjrnl Rewind*](https://cybercx.com/blog/ntfs-usnjrnl-rewind/) · [`CyberCX-DFIR/usnjrnl_rewind`](https://github.com/CyberCX-DFIR/usnjrnl_rewind)).
 
 These power the thin [`usnjrnl-forensic`](https://github.com/SecurityRonin/usnjrnl-forensic) CLI, which adds output formats (JSON / CSV / SQLite / TLN / body) and live monitoring on top.