# Xinzhai / XZ investigation — consolidated understanding and handoff

Written September 6, 2026 UTC. Consolidates the investigation through report 142. This document supersedes optimistic interpretations in earlier notes where they conflict. Research status: **blocked on missing provenance, not solved**. This handoff records both the findings and the limits; it is not a claim of exhaustive internet coverage.

## 1. My current understanding

**The strongest interpretation is one related automated publishing workflow: large version-labelled encrypted objects, alongside recurring small records called knowledge and improvement plans.** The connection between `xinzhai` and `xz` is supported by their tightly interleaved posting history, not merely by the abbreviation.

The large objects convincingly match the Fernet format after two Base64 decoding steps. Their authentication has not been verified. The small records use a different visible format. They are opaque and consistent with encryption, but their cipher is not identified. Nothing has been decrypted.

There is strong evidence of automated publishing. There is **no established evidence of an agent swarm, autonomous reasoning, a Chinese lab, or even a particular human operator**. A Chinese paste host and a pinyin-looking name do not establish nationality. The original spelling is `xinzhai`, not `xinhai`; 心斋/心齋 are search hypotheses, not recovered Chinese project names.

My leading operational picture is a development/deployment session followed by unattended scheduled publishing. The large objects might be program releases or state snapshots; the small records might be checkpoints, summaries, manifests, messages or repeated encryption of nearly unchanged state. We cannot choose among these contents from the ciphertexts. One program can produce all the streams. The evidence does not require multiple agents.

**Two corrections that matter:** 30,000 characters is the observed client-side split convention, not an established site limit. Other surveyed posts exceed it. Fernet uses AES-128-CBC plus HMAC-SHA256; its combined 32-byte key does not mean AES-256.

## 2. Best evidence: counts, chronology and linkage

The fixed survey covers IDs 4548081–4552953: 4,873 positions, 4,872 validated pages, one deliberately excluded page. The selected Xinzhai/XZ cluster has **3,574 posts**:

| Family | Count | Observed content |
|---|---:|---|
| `xinzhai` tests | 3 | Readable print tests |
| Large `xinzhai` parts | 76 | Nine reassembled version-labelled objects |
| `xz_knowledge_p1` | 3,484 | Distinct small opaque bodies |
| `xz_improvement_plan_p1` | 11 | Distinct opaque bodies |

All dates below are site-displayed dates. Minute precision limits timing deductions. The apparent UTC+8 relation to the large objects' embedded timestamps is consistent, but those timestamps are not authenticated or an independent archive date.

- July 10, 21:26–21:27: initial print tests and start of the large sequence.
- July 10, 22:06–22:07: `xinzhai_v60_p1..p7`, IDs 4548540–4548546.
- 22:12: `v61_p1..p8`, IDs 4548547–4548554.
- 22:21: `v70_p1..p9`, IDs 4548555–4548563.
- 22:24: first `xz_knowledge_p1`, ID 4548564, 124 characters.
- 22:29 onward: v71; knowledge ID 4548575 appears between parts 9 and 10.
- 22:35 onward: v72; knowledge ID 4548583 appears between parts 3 and 4.
- 22:43–22:44: v73, the last observed large group.
- 22:30–23:35: two distinct small posts at each of 14 five-minute slots. Small posting continues after the bulk sequence.
- July 11, 15:11: resumes after a 936-minute gap with a different displayed cadence.
- July 12, 05:12: a plan immediately precedes the proposed knowledge lineage's 124→424-character transition.
- July 13, 11:17: another plan immediately precedes 424→488; the plan's decoded size also changes 646→647 bytes.
- July 15, 00:24: another plan immediately precedes 488→532.
- July 20, 19:20: last observed knowledge post, ID 4552377. The later 575 validated positions in the fixed survey contain no further XZ-labelled post.

**Why the shared-workflow inference is strong:** all 87 consecutive IDs 4548523–4548609 belong to this cluster; small records interrupt large multipart releases; three plan posts immediately precede three size transitions. Another size cohort continues across the latter two transitions. These are stronger signals than name resemblance.

**Limits:** only three of eleven plans have that immediate transition relationship. Initial roughly six-hour plan timing becomes irregular. Perfect alternation in an early 430-post segment eventually breaks. This is not proof of causation, two separate processes, a continuously running six-hour loop or a swarm.

Best reports: 055, 056, 067–074. Report 074 is the older detailed working overview; its appended search history is useful, but use this handoff and reports 117 onward for the final crypto interpretation.

## 3. Large objects: what the bytes establish

Observed decoding chain:

```
ordered paste parts
  → concatenate
  → standard Base64 decode
  → URL-safe Base64 text
  → URL-safe Base64 decode
  → Fernet-shaped binary object
```

The nine groups are `xinzhai`, `v5.2`, `v52`, `v60`, `v61`, `v70`, `v71`, `v72`, `v73`, with respectively 4, 4, 6, 7, 8, 9, 11, 13, 14 parts. Parts are split at 30,000 outer characters except the final part. A mathematically equivalent 22,500-character inner split is possible; the exact order of encoding and chunking in the writer was not recovered.

Every reconstructed binary object has the expected 0x80 version, 8-byte timestamp, 16-byte IV, block-aligned ciphertext and 32-byte authentication field. All nine IV fields differ. Across 77,644 ciphertext blocks, no 16-byte block repeats. None of the 36 object pairs shares the first ciphertext byte. This excludes literal reused ciphertext prefixes in this sample, not common plaintext or common keys.

Conditional plaintext sizes, **if standard Fernet**, after allowing 1–16 bytes of padding:

| Group | Bytes supplied to encryption |
|---|---:|
| Initial | 64,912–64,927 |
| v5.2 | 65,472–65,487 |
| v52 | 99,664–99,679 |
| v60 | 113,536–113,551 |
| v61 | 125,280–125,295 |
| v70 | 151,488–151,503 |
| v71 | 180,768–180,783 |
| v72 | 209,888–209,903 |
| v73 | 231,152–231,167 |

These could be compressed or serialized bytes. They are not recovered text lengths. Increasing size is consistent with growing releases or state, but does not establish self-modifying code.

Primary format: https://github.com/fernet/spec/blob/master/Spec.md

Best evidence: reports 068, 117, 118 and `118-crypto-layout-audit.py`.

## 4. Small records: strongest deductions and unresolved issues

Knowledge bodies have exactly ten decoded lengths:

| Raw text characters | Decoded bytes | Posts |
|---:|---:|---:|
| 124 | 93 | 178 |
| 304 | 226 | 143 |
| 364 | 271 | 71 |
| 424 | 316 | 358 |
| 428 | 319 | 300 |
| 472 | 352 | 146 |
| 488 | 364 | 239 |
| 500 | 374 | 1,153 |
| 532 | 397 | 605 |
| 572 | 428 | 291 |

All eleven plan bodies are 864 text characters: the first five decode to 646 bytes, the remaining six to 647. Do not infer equal binary length merely from equal Base64 length.

Decoding replaces spaces with `+`, then validates Base64. This yields canonical encodings; raw originals must retain their spaces. Of the knowledge records, 3,453 contain spaces, including 55 with edge spaces; 31 already satisfy the expected Base64 form. The visible editor uses multipart/form-data, which does not itself explain plus-to-space damage. A malformed custom form request or additional server decoding remains plausible. No submission experiment established the responsible layer.

Key deductions:

- No small record fits a complete Fernet token at this decoded layer. Fernet requires total length `57 + 16k`; none of their lengths satisfies it.
- One constant-size wrapper plus ordinary padded CBC ciphertext cannot explain the whole small stream: total lengths have different residues modulo 16. This does not exclude variable wrappers, different cohort formats or all possible uses of AES.
- A hypothetical 12-byte nonce plus 16-byte tag layout fits all sizes. AES-GCM and ChaCha20-Poly1305 can both fit it. Own-key synthetic controls reproduced every length with both algorithms. **That demonstrates ambiguity, not identification.**
- The 3,484 knowledge bodies are all distinct. Random-looking bytes and high aggregate entropy do not establish fresh knowledge, a secure cipher or unique nonces.
- Every eight-byte window in the small-record collection is unique, and none appears verbatim in the large objects. This excludes literal shared fragments of that size; it does not exclude related plaintext.
- Whole-record checks found no second canonical Base64 layer or valid UTF-8. No complete gzip/bzip2/XZ stream was validated. Two zlib-header candidates failed normal decoding, including one requesting a preset dictionary. Dictionary-based or raw/custom compression was not ruled out.
- None of 3,495 small records has the inspected GetPost container header or Umbra v1 manifest header. This excludes those unmodified formats under the established decoding, not arbitrary wrappers or stripped fields.

Best evidence: 056, 073–074, 085, 118–120, 124, 141. Primary AEAD documentation: https://cryptography.io/en/latest/hazmat/primitives/aead/

## 5. Explanations worth retaining, ranked by support

**A. Shared automated publisher — strongest.** Supported by consecutive IDs, interleaving, regular timing and linked size changes. It could be a conventional script, a human-directed prototype or an agent-connected system.

**B. Large releases/snapshots plus small scheduled state — leading architectural interpretation.** Explains the startup sequence and persistent small output. Contents could be code, saved state, configuration or documents. No reader has been found.

**C. Re-encryption of unchanged or slowly changing data.** Explains unique ciphertexts at long-lived fixed lengths. Repeated records do not measure how much learning happened. Neither unchanged nor changing plaintext has been proven.

**D. One generic uploader with different caller formats.** Fernet already returns Base64 text; a raw AEAD function returns bytes. Base64-encoding both at the upload layer could explain the extra layer on large objects. A public Stack Overflow answer juxtaposed these functions in November 2022, but there is no evidence it was copied by this writer. Report 137.

**E. Small manifests, pointers or protocol state.** A knowledge-labelled record could point elsewhere. Umbra is an actual encrypted chunk-and-manifest implementation, but its format does not match. Reports 139, 141. This remains a hypothesis about XZ, not a decoded pointer.

**F. Versioned sealed publication or priority records.** A Chinese OFIRM author explicitly described Pastebin as convenient publication with a timestamp for priority claims. Their March 2026 public project and manuscript provide a real precedent. No XZ link, encrypted matching format or working AGI implementation was established. Reports 132, 134.

**G. Persona preservation, synthetic workload, write-only backup or messaging.** These can explain some behavior. July persona-export tools exist, but inspected implementations did not match. A prior encrypted website messaging proposal also exists. Neither supplies attribution. Reports 126–128, 138.

Do not assign numerical probabilities: we have no calibrated model or representative base rates. The main uncertainty is missing provenance, not choosing a better-sounding analogy.

## 6. Search coverage and lessons

The investigation included exact labels, pinyin/Chinese variants, hostnames, form fields, encoding/chunk constants, source-file searches, repository metadata, public community posts, upload attachments and independent corpus scans. Treat every negative as bounded by its recorded scope.

- All 4,872 validated authored bodies in the fixed local survey were hash-checked and screened for readable source clues. No uploader explanation emerged. Report 075.
- Cross-site local scans covered 132,140 saved paste/wiki files, including duplicates and metadata. No tested literal ciphertext-prefix copy emerged; transformations and other representations can evade such searches. Reports 082, 084, 103.
- August Common Crawl scans completed across 100,000 corpus files / 2,083,525,558 text records. The second representation scan is the same corpus, not extra unique pages. Reports 092, 106.
- July scan completed across 100,000 files / 2,093,746,605 text records, with no tested match. July and August can repeat pages; never sum as unique web documents. Report 111.
- GitHub, Sourcegraph, Gitee, GitCode, Hugging Face, ModelScope and package-index checks found no matching writer. Some queries were limited, fuzzy or incomplete; signed-out project search is not global code search.
- Gitee and GitCode project browsing proved reachable from this machine. Baidu and other hosts challenged requests; later Sourcegraph/direct paste-index requests returned403. These are access failures, not evidence of absence.
- `paste.ubuntu.com.cn` supplied an exact corresponding record; treat it as an alias/shared service or mirror, not an independent witness. A historical robots artifact disallowing CCBot helps explain missing crawl coverage but does not independently date XZ bodies. Reports 076–077, 081.
- July 9–20 IRC logs contained no XZ reference in the inspected English channel; the Chinese channel was effectively empty, so it provided almost no conversational coverage. Report 131.
- The last directly verified earlier index observation reached ID4552955. The latest direct recheck failed403; the web tool's indexed rendering showed no XZ label. Do not present it as a verified current complete listing. Reports107,142.

Concrete namesakes and analogues were checked rather than accepted from descriptions. Guanxinzhai, a Coze 心斋 skill and WenDao were not linked to XZ. RentBuddy's public demo claimed encryption through a status message but its inspected function only changed UI state. Alfred similarly had a Fernet helper without the claimed memory integration. A README, badge or architecture diagram is not proof of implementation.

Infrastructure lesson: a legitimately available China/Hong Kong browser or network vantage could improve access to specific challenged public sources. It cannot solve absent indexing, unavailable source, authentication requirements or cryptographic ambiguity by itself. No new infrastructure was purchased. The original broad-hunt handoff describes existing infrastructure; confirm current ownership/process/billing state before using it. Do not assume old infrastructure status remains current.

## 7. Where everything lives

Working root: `/home/sophia/search`

- **This handoff:** `/home/sophia/search/HANDOFF_XINZHAI_CURRENT.md`
- Original broader mission/infrastructure: `HANDOFF_CODEX.md`. Start there for the earlier American-swarm analogy and wider China search; use this document for current XZ conclusions.
- Reports: `investigation/china/NNN-*.txt`. Detailed evidence is split into numbered reports; see the reading order below.
- Private captures/scripts/analysis: `investigation/china/NNN-private/`. Do not publish these directories wholesale.
- Current state: `investigation/china/crypto-evidence-status.json`.
- Frozen authoritative checkpoint: `investigation/china/039-private/checkpoint-0036-20260905T143712065390Z.json` and its `.metadata.jsonl` sibling.
- User-supplied archive: `investigation/china/uploads/xz-ubuntu-cn-2026-09-05.tar.gz`.
- Body member inside archive: `xz-ubuntu-cn-2026-09-05/bodies.jsonl`. Select records using the checkpoint; do not indiscriminately extract/browse all raw pages.
- Other harness: `xzsolve/`. Its85 DONE records all report solved=False; no SOLVED output was present in the last audit. RESULT.md may contain generated scripts rather than results. Do not execute or count them as verified tests merely because they exist. Report140.
- Broad bot research: `swarmhunt/runs/`, `swarmhunt/findings.jsonl`, `swarmhunt/queries.log`, `swarmhunt/cache/`. At the last dashboard generation175 task reports were terminal. These are candidate-generating outputs requiring independent verification.
- Cross-site scraped material: `pastebins/data/`, `pastebins/agents/`, and associated investigation reports. Do not sum files as unique posts.

Archive SHA256:
`4a202ecd9dbe3dfcc40c1dac00984573cdffb38102e9d4ba4e04ce09b9a9105c`

Frozen checkpoint SHA256:
`620d6dcc62fd2f4eefa396c631b43f57e308fcbd31e5c097994eca4aa5005f40`

The archive is9,911,019bytes with3,920members. All3,574 selected cluster bodies were reconciled against our hashes. Eight separately saved large tokens match reassembly; the ninth, initial group is recoverable from the selected bodies. The included1,142-post mirror matches our public subset and is not independent corroboration. No writer source was found among the inspected nonpage files. Report117.

Public site:

- Main: http://178.105.23.35:8090/china/
- Working overview: http://178.105.23.35:8090/china/xinzhai.html
- Crypto evidence: http://178.105.23.35:8090/china/xz-crypto.html
- Explanations and latest checks: http://178.105.23.35:8090/china/xz-ideas.html
- Explorer: http://178.105.23.35:8090/china/explore-xinzhai.html
- Prior writing: http://178.105.23.35:8090/china/xz-analogues.html
- Chinese projects: http://178.105.23.35:8090/china/chinese-community.html
- Access notes: http://178.105.23.35:8090/china/access.html
- Reviewed reports: `/china/reports/`
- Fixed public export: http://178.105.23.35:8090/posts/ and `/posts.zip` —1,142posts, not the full3,574cluster or3,484knowledge records.

Server document root: `/home/sophia/search/public`. The generators are `investigation/china/build_xinzhai_overview.py`, `118-build-crypto-page.py`, `121-build-analogues-page.py`, `122-build-community-page.py`, `126-build-ideas-page.py`, and `swarmhunt/china_dashboard.py --once`. The dashboard copies reviewed top-level numbered text reports; never move private/raw files there casually. Updating the website does not mean autonomous research jobs are active.

Suggested reading order: **074 → 117 → 118 → 119 → 120 → 067–073 → 121–142**, using the report catalog for specific questions. For reproducible data checks start with118's audit script,119's overlap check,124's wrapper check and141's header check. For the original survey boundaries use039,055,056.

## 8. What would move this forward

A source or reader tied to these exact labels/URLs would be the best next evidence. Then trace serialization, compression, key derivation, nonce/IV placement, associated data, authentication tag, Base64 layer and upload naming before attempting authentication/decryption.

Other useful changes: an operator-authored explanation, a provenance-linked plaintext/ciphertext example, an independently dated copy, or a supplied usable key together with sufficient format information. A plaintext-looking guess alone is not enough: require authentication where supported and check multiple records.

Without such evidence, do not repeat the same corpus scans, measure entropy again, treat another cipher with matching lengths as identification, or keep collecting unrelated AI namesakes. Missing provenance is why the goal is blocked. It is not proof that the answer does not exist elsewhere.

## 9. Handling rules for a successor

- **Never fetch, open, extract for inspection or publish excluded paste4552394.** The supplied archive includes its raw page; selective reads are essential.
- Preserve raw spaces and hashes. Keep normalization as a separate analysis step.
- Keep raw payloads, private captures and keys out of public summaries. The authorized fixed export already exists; do not expand it automatically.
- Read-only research on external targets: no posts, comments, messages, account creation, counter-triggering endpoints, authentication bypass or captcha bypass.
- Do not execute pasted code or downloaded project code. The inspections described here read source text; synthetic controls used investigator-owned data and keys.
- No credential harvesting or arbitrary key guessing. Do not expose credentials from local configuration, logs or remote command output.
- Respect the original handoff's excluded remote file and infrastructure rules. Do not delete corpora, terminate machines or purchase infrastructure based on this summary.
- Maintain source dates, capture hashes, query limitations and the distinction between observation, inference and speculation.

The unresolved questions are still: **what produces the small records, what they contain, and whether the system involves agents at all.**