Skip to content

Latest commit

 

History

History
84 lines (62 loc) · 2.85 KB

File metadata and controls

84 lines (62 loc) · 2.85 KB

Client Plugin Internals

Notes on a few compile-time constants observed inside the network plugin that ships with BambuStudio (the slicer's network agent process).

These are baked into the plugin binary and appear to be identical for every installation — they are not derived from anything user-specific and anyone can re-extract them from their own slicer install. They are only useful for inspecting your own slicer's behaviour (e.g. decrypting your own network log files for debugging).

Debug log encryption

The network plugin writes its internal log stream to files of the form:

~/.config/BambuStudio/log/debug_network_<timestamp>.log.enc

(equivalent paths on macOS / Windows under the per-user BambuStudio data directory)

These files are an spdlog stream encrypted with AES-128-ECB using a 16-byte ASCII key embedded in the plugin:

yyuBcftO2jkZeucy

A one-liner to decrypt your own log file:

openssl enc -d -aes-128-ecb -nopad \
  -K "$(printf yyuBcftO2jkZeucy | xxd -p)" \
  -in ~/.config/BambuStudio/log/debug_network_*.log.enc | strings

The decrypted stream contains spdlog binary format-ID prefixes interleaved with the formatted message text, so piping through strings (or a small spdlog-aware parser) gives the most readable output. Each record begins with a timestamp like [2025-…] [I] [T <tid>]: followed by the message.

This is handy for debugging your own slicer's MQTT / HTTPS behaviour without having to attach a debugger.

Analytics upload encryption

The plugin periodically uploads *_track_*.zip.enc and *_cache_*.zip.enc bundles for analytics / crash reporting. The encryption is AES-256-CBC and three baked-in ASCII constants are visible adjacent to the relevant code:

IXdE2DUTsO7b6k58rwZn1b0bWHZysj8d   (32 bytes)
p6nTAFdtBS4G4PiE                   (16 bytes)
hCUSRUX6huMKP7I9                   (16 bytes)

The 32-byte string is the AES-256 key; the two 16-byte strings appear to be IVs for the two upload categories (_track_ vs _cache_), but the exact pairing is best confirmed against a captured bundle.

These are noted here mostly for completeness — if you care about what your slicer is sending home, you can decrypt the bundles you find on disk before they're uploaded.

Plugin self-version string

The plugin reports its own version internally as e.g.:

bambu_network_agent/02.07.00.50

This version is independent of the slicer it ships alongside — for example a slicer build labelled 02.07.00.55 may carry a plugin whose internal version is 02.07.00.50. If you're correlating bug reports or log files across installs, the agent version string is what matters for the network layer, not the slicer's user-facing version.


Corrections and additions welcome — these are observations from a single slicer build, and behaviour may differ across platforms or versions.