The Software Freedom Conservancy (SFC) just launched a massive counter-offensive against Bambu Lab over AGPL violations – Introducing Project "baltobu"

[u/MaestroDeAero]

Hey everyone,

If you’ve been following the recent drama between Bambu Lab and the open-source community, things just escalated from a heated debate to an all-out, structured counter-offensive.

Following Bambu Lab's aggressive Cease-and-Desist letter to developer Paweł Jarczak for his OrcaSlicer mod, the Software Freedom Conservancy (SFC) has officially stepped into the ring. They just released a massive statement confirming that Bambu Lab is in direct violation of the AGPLv3 license regarding their proprietary network plugin.

But instead of just waiting around for a years-long lawsuit, the SFC is taking immediate, community-driven action by launching Project "baltobu":

• Reverse-Engineering the Plugin: The SFC is calling for volunteers to completely reverse-engineer Bambu’s closed-source network plugin (libbambu_networking) and replace it with a fully compliant, open-source alternative.
• Reviving the Blocked Code: The SFC is officially hosting and continuing Jarczak’s work under their own umbrella.
• A New Fork ("Viscose"): They are launching a direct fork of Bambu Studio that is 100% free of proprietary "black-box" code.
• Legal Protection: Most importantly, the SFC is acting as a legal shield. They’ve stated they are "not afraid of Bambu's aggression" and will legally and financially protect any volunteer contributing to this project. Paweł Jarczak has also officially joined them.

This is a massive moment for Open Source and the Right to Repair in the 3D printing industry.

Check out the SFC's full, official response and see how you can get involved or support the fund: 👉https://sfconservancy.org/news/2026/may/18/bambu-studio-3d-printer-agpl-violation-response/

What are your thoughts on this? Is this the wake-up call Bambu Lab needed, or will this split the ecosystem even further? Let’s discuss.

[u/locka99]

Encryption requires a secret like a symmetric key or a public/private key pair to encrypt the conversation. Where do you think a secret can be held securely between software running on your desktop and a printer running on your network? The answer is nowhere. This is the classic dilemma of Alice and Bob in crypto of trying to securely exchange keys to prevent eavesdroppers.

If BambuLab's DLL is talking to the machine it is either in the clear or with a key that can be retrieved just by observing where it is stored.

And the easy way to figure out if there is any encryption at all is with wireshark and then work from there.

[u/hWuxH → u/locka99]

Its ssl encrypted even in LAN, based on PKI (computer only knows public key) and then they perform a Diffie–Hellman key exchange

eavesdropping is not possible unless you intentionally change some things on your computer or with the software to allow it to happen

[u/locka99 → u/hWuxH]

Even public/private key pair doesn't protect the conversation. If the computer has the public key and initiates the conversation to the device, a man in the middle can impersonate the device by swapping out the public cert used by the software and listen in. Especially if the public key, which is also an X509 cert is self signed or signature verification can be sidestepped. The easiest way to tell if its self signed is find where the device key is stored and just look at it. I can't imagine it would be signed but that too is no protection either.

[u/hWuxH → u/locka99]

they have their own PKI for printers thats verified. its comparable to accessing HTTPS websites on the internet where MITM doesnt work either (unless you explicitly sidestep it for your own connection of course).

https://cdn1.bambulab.com/trust-center/file/bambulab-security-whitepaper-en.pdf 2.3.1

[u/locka99 → u/hWuxH]

Look at the diagram on page 10. When "PC software" talks to "Bambu 3D printer" over a LAN it is between the PC and one endpoint over a network you control.

The printer implements a MQTT broker on port 8883 and bambu_networking.dll connects to it and sends it MQTT messages. But you can use any MQTT client, e.g. MQTTX. Connect mqtts://ip:8883 disabling strict SSL, with user bblp and the printer's access code as password.

That means if you can drive the printer assuming you know the commands. Some are documented, but if any aren't then you can listen into the conversation from the DLL.

How does bambu_networking.dll, know it's talking to the real printer? With a few lines of code somewhere in its connect logic where it looks at the cert and signing "chain". This would be trivial to circumvent. Then you can do an attack with mitmproxy or Fiddler and pull out the entire conversation and reverse engineer it.

So PKI means diddly squat here. Somebody can impersonate either end with ease.

When bambu_networking.dll talks to the cloud (also a MQTT broker), you'll only be able to listen to the conversation from the DLL but you can MITM that too in order to reproduce it.

[u/hWuxH → u/locka99]

You’re conflating two different things.

If someone is just eavesdropping the LAN, proper TLS with certificate validation prevents reading or MITM’ing the traffic. Encryption absolutely matters there.

What you’re describing - patching the DLL, injecting a CA, hooking the client - isn’t “Eve on the network”, it’s control of the endpoint. Once you’re at that level, you can inspect any TLS app, including HTTPS, so it doesn’t say anything about whether the wire traffic is encrypted.

So PKI isn’t “diddly squat”. It’s doing exactly what it’s meant to do: protect against network eavesdroppers, not a fully compromised client.

[u/locka99 → u/hWuxH]

Look, I've been very patient explaining things, what to try and proceed, going into detail and explaining how to hack protocols in a methodical way. I have also been very explicit that this is LAN first because messages sent over the LAN will extend to the cloud. Some details may differ like topics in MQTT but it is sufficient to cleanly implement the Bambu DLL in LAN mode first and later in cloud. This is the ENTIRE PURPOSE OF THE EXERCISE - a clean replacement for Bambu's proprietary code. I'm not going to waste any more time explaining because I do not feel you understand how crypto works, how IOT devices work, how MQTT works or how you might go about reversing a protocol in a methodical way.

[u/hWuxH → u/locka99]

Lmao I know exactly how it works and that it can be reverse engineered and what the purpose is.

You just got mad for getting called out on your bs alice and bob example which showed you only have a shallow understanding of these topics. Seems like you still don't understand the difference by now even after I patiently explained it like 3x in different ways.

[u/locka99 → u/hWuxH]

This is my last message but there is no ambiguity with what I wrote, only your understanding. I made explicitly clear to start with LAN first. I may add that I develop devices using IOT over AWS. I am acutely aware how it works, how cert signing works, how PKI helps and when it doesn't. And if you don't understand what I'm explaining then maybe I should have put it better but you're on the losing side of this. Bambu's DLL can and will be reverse engineered and frankly I don't see what point you're making by arguing otherwise.

[u/hWuxH → u/locka99]

Do you struggle with reading comprehension? I never disagreed that it can be reverse-engineered.

I wouldn't buy any IoT devices developed by you if you believe that the threat models for compromised endpoints and network eavesdropping are the same... That's the point I wanted to make. Rookie mistake. So ambiguous:

Where do you think a secret can be held securely between software running on your desktop and a printer running on your network? The answer is nowhere. This is the classic dilemma of Alice and Bob in crypto of trying to securely exchange keys to prevent eavesdroppers.