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).
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 | stringsThe 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.
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.
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.