ZCode encrypted a 313MB snapshot of a commercial repo to a key only its server holds

Look at the archive that failed. It is the informative one. The local state file records 345,549,173 bytes of workspace going in and 313,070,842 bytes of ciphertext coming out ^[4]. A tar.gz and an AES pass removed about nine percent ^[21]. The manifest explains it. LFS objects, commit objects and reflogs account for 298.9MB of the snapshot ^[22], and those bytes are already compressed. The 538-file public repository that did reach the server was mostly source text, and it went out at roughly 15KB ^[7].

So the size limit that the credential endpoint hands back ^[9] kept a commercial project on local disk. By the time ferstar looked the client had tried 564 times ^[4], and the archive was still on the machine ^[6].

ferstar calls the scheme standard envelope encryption, and says that is exactly the problem ^[18]. Contents go under a random AES-256-CTR key, and that key is wrapped with RSA-OAEP-SHA256 using a public key the server supplies at upload time ^[10]. The private half stays in the cloud. ferstar tried every private key on the machine against the envelope and none of them opened it ^[14]. As a backup format it has one unusual property: the owner of the data cannot restore from it. According to the writeup, a tool built for crash recovery or cross-device sync would keep the decryption key on the machine, the way Git and Time Machine data does ^[23].

The transfer path makes this hard to see from the network. The client asks zcode.z.ai for credentials at POST /api/v1/snapshot/upload-credential and gets back OSS form credentials, a size limit and the RSA public key ^[9]. The bytes then go to Aliyun OSS as an HTTP POST form ^[11]. OSS calls the backend so the upload gets recorded ^[12]. A live check on the running process found persistent connections to zcode.z.ai and to two Aliyun OSS nodes ^[13]. The app's logs did not include upload URLs, and ferstar read the endpoints out of the unpacked app.asar bundle ^[8].

An allowlist written around a vendor's API domain passes this upload, because the volume goes to an object-store host. The signal available to a defender is bytes per destination, and a data directory that has grown past 700MB ^[3].

A recipient gets history. Reflogs are only 0.6MB of the manifest, and they record activity on local branches that were never pushed ^[16]. ferstar lists secrets deleted or overwritten long ago but still present in history, unpushed branch names that expose unreleased product direction, and .git/config, which often carries internal GitLab hostnames and repository paths ^[19]. The client also builds a repo_snapshot_extra_manifest that hashes the global ZCode settings file and bundles it across workspaces into every snapshot ^[20]. The project totaled 10GB, and ferstar describes almost everything in the snapshot, once dependencies are excluded, as core intellectual property ^[5].

This rests on one researcher, one machine and one commercial project, plus Zhipu's confirmation of the upload behavior on the day of publication ^[2]. ferstar mapped each settings toggle against the code; the text available here stops before that mapping, so what switching snapshots off actually prevents is still unknown. The method transfers whether or not other clients behave this way: unpack the Electron bundle, read the upload code, then watch the data directory and the destination hosts.