Live data from Hacker News

Reverse Engineering Bambu Connect

wiki.rossmanngroup.com

211–220 of 367 posts

Re: Reverse Engineering Bambu Connect

#213

Earlier quoted context omitted.

AFAIK, Apple has never retroactively removed functionality from devices people already purchased Selling a walled garden is one thing, building walls around a garden you already bought is another thing entirely

This is the Google model then. Base everything on open source, even allow unofficial builds of your operating system (LineageOS, Graphene), but slowly introduce more and more device attestation and DRM so it becomes de facto impossible to actually use anything but the closed builds because everything from banking apps and electronic identification apps to streaming apps will refuse to run on your "unsafe" operating s…

Did Google ever introduce more device attestation and DRM into an already released device though?

Re: Reverse Engineering Bambu Connect

#214

Earlier quoted context omitted.

I do wonder how much friction it'll really add, since the slicers can send the data to Connect via a protocol handler. It also means that Connect could act as a farm / queueing system as well, more like a print driver vs. individual printer support within the app.

Its pretty much this, nothing seems to be blocking any third party slicer like Orca from working with bambu printers as they are now.. just the print button would now send the file to Bambu Connect, where you would most likely only press an extra button.. Getting info from the printer or AMS? MQTT still works. They specifically said they are not touching that. Sadly the usual groups of people are screaming, and the o…

Did you happen to see this? Interesting development, they are basically going to keep the current wide-open-barely-auth'd state and call it a developer mode. And submitted a PR to make Orca Slicer work with the new auth: https://blog.bambulab.com/updates-and-third-party-integratio...

And yeah, I'm realizing that about the downvotes. It's sad the state of things, but SKY-IS-FALLING-GET-PITCHFORKS wins the day over technical analysis, even on purportedly technical forums. But alas, that's an aside.

I'm really looking forward to this rolling out, as I want to monitor my printer with Home Assistant but I /really/ don't like how much control the current (non-beta, non-future) state gives HA. I /want/ auth of some sort when submitting jobs, and it looks like I'll have that.

(I also really want the slicer decoupled from the print management stuff, because I tend to keep a few slicers open and experiment.)

Re: Reverse Engineering Bambu Connect

#215

Earlier quoted context omitted.

the problem isn't that they've done it. the problem is that user got no choice. Some might prefer degraded performance, others might prefer to charge their devices more often. Also seller should have no business touching anything that they've already sold - they do might offer support, but it should be up to user to accept it or not.

It's not a matter of "charging more often". The phone just shut down when the battery was somewhere between 0-40% Source: had two 6S's in the family. In the cold it could just suddenly shut down mid-call from 60% battery.

Indeed; while I've not had this specific issue with the phones, I do still have a mid-2013 MacBook Air lying around (it's now too old to realistically sell), and the battery on that was so worn by the time I got an M-something to replace it that would go from "fine" to "emergency shutdown" during boot if I forgot to plug it in. And then report something like 20% if I plugged it in and immediately booted it again.

Re: Reverse Engineering Bambu Connect

#216

Earlier quoted context omitted.

Can you link to some specific detail on that, because I keep seeing that claim, but without any technical info. I have a P1S which currently can print completely isolated from the internet. Unfortunately (or maybe not?) the new firmware isn't available for my printer, so I can't dig into it myself yet. But I'd really like to see some sort of "when I try to do X it tries to connect to Y" or "I used to be able to do X,…

I don't have a definitive source readily available, but from talking to people who were investigating the technical aspects, connection between the printer and slicer software will be mutually authenticated using a certificate that will issued by Bambu Cloud, issued only to blessed 1st party software, and verified by the printer upon connection over the local network. So your blessed Bambu Studio instance connects to…

I sorta get what you're saying, and the flowchart here (https://blog.bambulab.com/updates-and-third-party-integratio...) somewhat agrees.

But where I disagree is with that cert stuff.

1) That cert is on the /client/ side, not in the printer. It has nothing to do with printer functionality, only with talking to the printer.

2) Expired certs do not mean things automatically get rejected. Using and allowing expired or self-signed certs is routine in the IoT world where certs on devices can't readily be updated. But again, that cert isn't from the printer.

3) Expired certs, just like the self-signed certs that are so commonly used, still result in things being encrypted on the wire. And often that's the point.

It seems to me that someone found/exported the cert, and is trying to make all sorts of WHAT-IF or THIS-COULD-MEAN-THE-WORST claims but are lacking some significant understanding. Without understanding the architecture and the rest of the code, and perhaps seeing that cert be used, this is just an artifact found in the distributed beta application.

Re: Reverse Engineering Bambu Connect

#217
post #4

Earlier quoted context omitted.

The A1 mini was my first printer and it just works. Is there another brand that is idiot proof?

I am an idiot, and my Prusa MK3S+ (bought assembled, not as a kit) has been me-proof for years, and delivered fantastic print quality all along. My wife is not a techie and she gets good use out of it too. Their newer printers seem to be even better.

Out of ignorance and curiosity about 3d printing I bought a Prusa Mini a few years ago. My 10 year old (at the time) son took to using it immediately and figured out how to use it almost entirely on his own. It has been a great experience. I was thinking of upgrading to something larger and this drama has made the decision an easy one for me.

Re: Reverse Engineering Bambu Connect

#218
post #34

I am angry at the bait-and-switch Bambu is pulling. I bought one of their printers in the Black Friday sale on the understanding it was reasonably hackable and open. Now they're trying to lock it down so I can't print on my own printer without using their approved software and DRM chain. It's outrageous. More info on the hacking (the first in what may be a long stupid fight): https://hackaday.com/2025/01/19/bambu-con…

bait-and-switch? We, those who advocate for open source 3D printers, saw it coming from miles away. This has very very clearly been their plan all along, they themselves said as much (e.g. they are doing the "apple model"). They have been very transparent about this, yet people still fell for it.

Good for you. Kind of a non sequitur, though, and gaslight-ey at that.

Re: Reverse Engineering Bambu Connect

#219
I'm interested what others think of their existing design and whether there are any fundamental security issues that will be resolved by their proposed change.

They are proposing requiring a secret signed certificate to carry out any actions beyond monitoring for both the cloud and local (on printer) MQTT servers. These certificates would be issued at the discretion of Bambu by their CSR, currently only for "Bambu Studio" their slicer, Bambu Handy (their mobile app) and "Bambu Connect" which will enable upload G-Code generated by third party slicer (a workaround for existing functionality being removed). This "secret" certificate has already been extracted from the Bambu Connect application as per the article as their new security model requires embedded this certificate into desktop applications.

The current design:

https://github.com/Doridian/OpenBambuAPI/blob/main/mqtt.md

Connecting to their cloud MQTT requires a username and token already. These details are obtained via a HTTPS request to their login server using your bambu account (which requires a valid email & possibly captcha) to obtain a token. The cloud MQTT is TLS secured, although this is just to encrypt the traffic (aka HTTPS), it is not mutual authentication.

Connecting to the MQTT server hosted on the printer (aka LAN mode) requires a fixed username and a local access token (a random 8 digit number). This can be found via the physical display of the printer in a menu (or apparently cloud MQTT!?). This access token can be refreshed via a menu option again physically at the printer. To be clear, this token only allows to you connect directly to the local MQTT server running on the IP address of the printer, so in most environments this should only be the local network. This is also the password for the FTP server that can be used to upload/download sliced 3mf/gcode files.

Personally - this design seems ok to me? With an MQTT service properly configured to isolate user accounts from each other, this is a pattern widely deployed for embedded devices (Azure IoT, AWS IoT etc).

I don't see how the "DDOS" related issues they are claiming would be related to this specific design. If the issue is in the login server - well, that's prior to authentication anyway so nothing they are doing here will fix that.

If it's problems with your cloud MQTT service not being properly isolated - maybe fix that? If the DDOS is at L2, auth isn't going to help. You require logins tied to an email, you can block clients that misbehave once they are logged in.

Nobody is brute forcing the local MQTT server via XSS or something, because JS doesn't allow for raw TCP connections. Are they concerned about malicious software already on the network? Then rate limiting on the printer side or switch to a random length alphanum LAN token to increase keyspace.

I'm curious what more qualified people think, I cannot see any justications for their proposed design improving security. So either;

a) They've decided they are incapable of properly securing their MQTT cloud stuff and instead of fixing that just want to assume every client connected to their cloud MQTT servers is fully trusted. I'm sure that'll work great. Doesn't justify adding this to the local MQTT servers on the printers - if anything that reduces security, as to roll certificates you now have a long tail of printer firmware updates.

b) It's not about security

Re: Reverse Engineering Bambu Connect

#220

I am angry at the bait-and-switch Bambu is pulling. I bought one of their printers in the Black Friday sale on the understanding it was reasonably hackable and open. Now they're trying to lock it down so I can't print on my own printer without using their approved software and DRM chain. It's outrageous. More info on the hacking (the first in what may be a long stupid fight): https://hackaday.com/2025/01/19/bambu-con…

> on the understanding it was reasonably hackable and open

While this lock down doesn't seem right it is far from unexpected, I question the amount of research done prior to your Black Friday purchase (BF and well-thought-out-decisions often do not go hang-in-hand!)…

I bought one (an A1 with the multi-material add-on) some months before that in full knowledge that the company would prefer to funnel people into a walled garden because if you look anywhere you'll find proponents of other makes warning that exactly this is possible & likely, with the "must take many steps to print without talking to their servers" being the key evidence in those warnings.

Good reasons to buy a BBL machine (at least my reasoning when I did):

* They work out of the box more so than many of the competition (many will say "X is better or better value, if you spend Y amount of time tuning" which while often correct, I wasn't looking to spend that time tuning), certainly more so than others at similar prices.

* QoL features (good auto leveling, dynamic flow control) that weren't exactly ubiquitous on similarly priced or cheaper machines.

* Certainly in the case of the newest A1/A1-Mini line: a working MMU option cheaper than you find in other ranges (some manufacturers have started addressing this and the out-of-box experience, in their product lines, 2025 could be an interesting year), and very easy nozzle changes (useful if you want to both do detailed minis (without going resin) and mostly larger items).

* For me, the handling of the A1 issues early last year (quickly acknowledging a potential safety issue and publishing mitigation guidelines, full recall or fix-at-home options when it became clear the issue was more significant) was a point in their favour wrt after-sales giving-a-shit. Obviously not a point against others as we don't know how they'd react until it happens, of course. There are regular complaints of slow support response more generally, but there are for other printer manufacturers too and, well, pretty much all consumer facing industry these days.

* The official documentation & videos, maintenance & troubleshooting guides etc, seemed to me to be more coherent than some other offerings (though searching for " reddit" is still a thing!).

Absolutely terrible reasons to buy into BBL, long before this storm:

* Openness (software). From the get go their offering has the trappings of a more controlled garden than the 3D printing community were used to.

* Openness (hardware). While there are some compatible 3rd party after-market parts, there isn't the able-to-build-your-own feel you see elsewhere with people using different extruder nozzles, cooling options, and so on.

--------

This isn't a great analogy, but: BBL is an Apple (though not quite on price) to the rest of the 3D printing industry's Linux and it only takes a small amount of information to see that before buying.

If I upgrade (or have to replace, or just decide to get a second) then maybe I'll go elsewhere. I'm more confident I could get other others working well, manufacturers are addressing the points that have allowed BBL to take so much of the market & mindshare in a short time, but the key thing against BBL (not being open like much of the rest of 3D printing) is something I was well aware of when buying (it did make me think twice) so I can't be too mad about it.

Now if they try stop people using 3rd party filament, like the traditional printing industry with ink & toner, which is far from impossible, then I'll feel they've conned me.

Post reply on HN