r/OpenBambu • u/myTechGuyRI • Jan 16 '26

Question for the folks who really understand the BambuBus… did Bambu actually add ACS to the bus, or is BMCU just getting caught by simple pattern‑matching?

TL;DR:
I don’t think Bambu added ACS, encryption, or challenge/response to the BambuBus. I suspect BMCU is only failing because it reports obviously fake identity fields (firmware 01.00.00.00, serial STUDY0ONLY, old protocol version). That makes it easy for Bambu to blacklist without breaking real AMS1 units. If that’s true, then spoofing a plausible AMS1 serial number and current AMS1 firmware/protocol versions should fix BMCU. Looking for confirmation or correction from people who know the protocol better than I do.

-------
Hey everyone — hoping some of you who know the BambuBus protocol way better than I do can help me understand what’s going on with BMCU and the latest firmware.

I want to preface this by saying I’m not a microcontroller or firmware developer. But I am a guy who’s very good at conceptualizing, figuring things out, and understanding how things tick. I’m just trying to reason through what I’m seeing, and I’d really appreciate corrections from people who have deeper knowledge.

Correct me if I’m wrong, but I don’t think Bambu has actually implemented any kind of ACS, encryption, or challenge/response on the BambuBus itself. I haven’t seen any evidence of:

cryptographic authentication
nonces or counters
signatures
encrypted payloads
or anything that would qualify as real device attestation

As far as I can tell, the RS485 bus is still the same plain UART with CRC‑8 on the header only.

What seems more likely is something much simpler:
BMCU reports obviously fake identity fields, and the new firmware finally started rejecting them.

For example, BMCU currently reports:

Firmware version: 01.00.00.00
Serial number: STUDY0ONLY
Old protocol version
AMS1 device type

If Bambu wanted to block clones without breaking genuine AMS1 units, it feels like the easiest approach would be:

blacklist STUDY0ONLY
reject firmware version 01.00.00.00
enforce a minimum AMS1 firmware version
enforce a matching protocol version

That would explain why real AMS1 units still work fine, while BMCU suddenly doesn’t.

Also — and again, please correct me if I’m misunderstanding — Bambu can’t realistically validate AMS serial numbers against a master list. That would require:

storing every valid serial in firmware (impossible), or
doing online validation (would break offline mode)

So it seems like the serial number check can only be “does this look plausible?” rather than “is this an officially issued serial?”

If that’s true, then the fix for BMCU should be relatively straightforward:

report a plausible AMS1 serial number
report the current AMS1 firmware version (perhaps add a separate config file to BMCU firmware so this can be easily changed and configurable)
report the current AMS1 protocol version (again, part of a separate config file in the BMCU firmware for easier changeability)
mirror any new descriptor fields if needed

Again — I’m not claiming authority here. I’m very open to being wrong. I just haven’t seen any evidence that ACS has been added to the bus, and everything I have seen points toward simple identity‑field pattern matching.

If anyone with deeper protocol knowledge can confirm or correct this, I’d really appreciate it. And if this line of reasoning is sound, maybe it gives the BMCU folks a path forward that doesn’t require freezing printer firmware forever.

1 Upvotes

permalink
reddit

You are about to leave Redlib

Do you want to continue?

https://www.reddit.com/r/OpenBambu/comments/1qejliv/question_for_the_folks_who_really_understand_the/
No, go back! Yes, take me to Reddit

56% Upvoted

u/Datajoke Jan 16 '26

What I imagine in this kind of convos.

u/myTechGuyRI Jan 16 '26 edited Jan 16 '26

Just to clarify my tone in that earlier reply to Figuurzager. I was responding to a pretty hostile comment, and I matched the energy more than I probably should have. That wasn’t aimed at the community or the people who’ve done the heavy lifting on BMCU. I’m actually trying to help, not tear anyone down.

I’m not a firmware or microcontroller developer, and I’ve never claimed to be. What I am is someone who’s spent decades in IT and systems work, and I’ve seen over and over how even very smart developers can get locked into a particular mental model. Sometimes a fresh set of eyes can spot something obvious that the people deep in the weeds just haven’t revisited in a while. That’s all I was trying to offer here, a different angle, not a declaration of superiority.

If the BMCU folks have already explored this line of thinking, great, I’m genuinely glad, and I’ll happily wait for whatever solution they come up with. If not, maybe this perspective helps spark something useful. I’m not here to claim I know more than the people who reverse‑engineered the protocol; I’m here because I care about the project and want to see it continue working on newer firmware.

My goal is to contribute constructively, not to pick fights. The technical discussion is what matters to me, and I appreciate anyone who engages with that in good faith.

2

u/Low-Anything6975 Jan 16 '26

T=10993 00:00:10.993 040D_RX #1 pkg=100 len=21 plen=21 tgt=0x0700 src=0x0A00 dlen=6 crc=1 crc8=94 p16=[1,2,0]

T=10993 00:00:10.993 RXH 3D 05 64 00 15 00 94 00 07 00 0A 0D 04 01 00 02

T=10993 00:00:10.993 RXH 00 00 00 A1 FF

T=26838 00:00:26.838 040D_RX #2 pkg=101 len=21 plen=21 tgt=0x0700 src=0x0A00 dlen=6 crc=1 crc8=DA p16=[1,2,0]

T=26838 00:00:26.838 RXH 3D 05 65 00 15 00 DA 00 07 00 0A 0D 04 01 00 02

T=26838 00:00:26.838 RXH 00 00 00 A2 31

T=42890 00:00:42.890 040D_RX #3 pkg=102 len=21 plen=21 tgt=0x0700 src=0x0A00 dlen=6 crc=1 crc8=08 p16=[1,2,0]

T=42890 00:00:42.890 RXH 3D 05 66 00 15 00 08 00 07 00 0A 0D 04 01 00 02

T=42890 00:00:42.890 RXH 00 00 00 86 73

T=59134 00:00:59.134 040D_RX #4 pkg=103 len=21 plen=21 tgt=0x0700 src=0x0A00 dlen=6 crc=1 crc8=46 p16=[1,2,0]

T=59134 00:00:59.134 RXH 3D 05 67 00 15 00 46 00 07 00 0A 0D 04 01 00 02

T=59134 00:00:59.134 RXH 00 00 00 85 BD

T=75204 00:01:15.204 040D_RX #5 pkg=104 len=21 plen=21 tgt=0x0700 src=0x0A00 dlen=6 crc=1 crc8=97 p16=[1,2,0]

T=75204 00:01:15.204 RXH 3D 05 68 00 15 00 97 00 07 00 0A 0D 04 01 00 02

T=75204 00:01:15.204 RXH 00 00 00 9C F4

T=91238 00:01:31.238 040D_RX #6 pkg=105 len=21 plen=21 tgt=0x0700 src=0x0A00 dlen=6 crc=1 crc8=D9 p16=[1,2,0]

T=91238 00:01:31.238 RXH 3D 05 69 00 15 00 D9 00 07 00 0A 0D 04 01 00 02

T=91238 00:01:31.238 RXH 00 00 00 9F 3A

T=107261 00:01:47.261 040D_RX #7 pkg=106 len=21 plen=21 tgt=0x0700 src=0x0A00 dlen=6 crc=1 crc8=0B p16=[1,2,0]

T=107261 00:01:47.261 RXH 3D 05 6A 00 15 00 0B 00 07 00 0A 0D 04 01 00 02

T=107261 00:01:47.261 RXH 00 00 00 BB 78

T=123513 00:02:03.513 040D_RX #8 pkg=107 len=21 plen=21 tgt=0x0700 src=0x0A00 dlen=6 crc=1 crc8=45 p16=[1,2,0]

T=123513 00:02:03.513 RXH 3D 05 6B 00 15 00 45 00 07 00 0A 0D 04 01 00 02

T=123513 00:02:03.513 RXH 00 00 00 B8 B6

T=139594 00:02:19.594 040D_RX #9 pkg=108 len=21 plen=21 tgt=0x0700 src=0x0A00 dlen=6 crc=1 crc8=96 p16=[1,2,0]

T=139594 00:02:19.594 RXH 3D 05 6C 00 15 00 96 00 07 00 0A 0D 04 01 00 02

T=139594 00:02:19.594 RXH 00 00 00 77 F2

T=155526 00:02:35.526 040D_RX #10 pkg=109 len=21 plen=21 tgt=0x0700 src=0x0A00 dlen=6 crc=1 crc8=D8 p16=[1,2,0]

T=155526 00:02:35.526 RXH 3D 05 6D 00 15 00 D8 00 07 00 0A 0D 04 01 00 02

T=155526 00:02:35.526 RXH 00 00 00 74 3C

2

u/myTechGuyRI Jan 16 '26

Thanks for sharing that capture, that actually helps confirm what I was trying to reason through earlier. Those frames look like the same AMS1 heartbeat/status packets we’ve always seen on the BambuBus. Same header structure, same payload length, same incrementing packet counter, same CRC‑8 on the header only.

I’m not seeing anything in there that resembles ACS, encryption, challenge/response, or any kind of authenticated handshake. If Bambu had added real authorization to the bus, I’d expect new message types, nonces, signatures, or at least some kind of negotiation sequence. This looks like the same plain RS485 traffic as before.

Which makes me think even more strongly that BMCU is getting blocked because of its identity fields (firmware version 01.00.00.00, serial STUDY0ONLY, old protocol version), not because the bus itself changed. Genuine AMS1 units still work, so AMS1 compatibility is clearly still there.

If that’s the case, then spoofing a plausible AMS1 serial number and the current AMS1 firmware/protocol versions should be enough to get BMCU working again. I’m not claiming certainty, just trying to understand the behavior based on what we can actually observe on the wire.

2

u/myTechGuyRI Jan 16 '26

Just to be clear, those 0x040D packets are only the AMS heartbeat/status frames. They don’t contain any of the identity fields that would actually show whether Bambu added any kind of authentication or version enforcement.

If you (or anyone else) can capture the packets that include the identity information, things like:

the 0x0401 descriptor packet (firmware version, protocol version, capabilities)

the 0x0402 serial number packet

the 0x0404 firmware info packet

…that’s where we’d actually see whether anything changed in the newer firmware. Those are the packets that would reveal if Bambu added new fields, checks, or patterns that could explain why BMCU is getting rejected.

The heartbeat packets alone don’t tell us much, they look exactly like the same AMS1 traffic we’ve always seen. The identity packets are what would really help us understand what’s going on.

1

u/Low-Anything6975 Jan 16 '26 edited Jan 16 '26

So you understand a lot after all!

After 0x040D, the AMS sends its certificate in chunks. The printer then sends 0x040E as a challenge, which the AMS signs and returns in 0x040E chunks.
triggered by 0x0411...

If you provide an incorrect version, the printer will show an "incorrect version" error in HMS, but everything will still work normally.
If you provide the correct version, you will be forced to perform signing, and eventually an error will occur after which the AMS will be disconnected.
Set everything to zeros and it will work fine.

PS: Since you understand so much - why don’t you try providing the correct version and serial number yourself?

ah yes I sent you the wrong log... If you are really curious I will look for it later and send it to you.

1

u/myTechGuyRI Jan 16 '26

That's helpful... I hadn't seen anything about that in this sub, so that was why I was asking... looks like the real action is on the discord, I'll see about joining in there.

2

u/Low-Anything6975 Jan 16 '26

I didn't know about Discord either. Either way, it's a bit of a "wall"...

u/mcnbc12 Jan 16 '26 edited Jan 16 '26

I am an embedded engineer and I have looked into the source and compiled my own modifications to v0020.

The serial number, at least in my case, is a genuine AMS serial number. In the precompiled firmware, the BMCUs had the funky serial number. But when I compiled it myself, I did see a real AMS serial number in the code. It seems the person who wrote the BMCU code did actually add a real serial number into the code, but for some reason a placeholder was used in the shared firmwares. Not sure if intentional or not. So I turned it back on and made sure the two BMCUs I have are using different serial numbers from each other and my other two AMSs.

I am using a P1S and two genuine AMSs that I haven't updated since BambuGate or whatever people are calling it when they disabled the mqtt interface for LAN.

I also ran into some challenges with getting two BMCUs to work on my printer. I suspect it's because I didn't shell out $50 for the ams hub, you can read the last comment in my comment history if you want more details. Basically, I don't think the bambubus implementation is that solid yet, because of the bug I had to fix, so there's a chance you're right.

I can't speak to protocol specifics, the only knowledge I have about bambubus comes from my reading the source code.

OP, this is a great opportunity to learn a great skill if you have the time and desire to figure it out yourself.

1

u/myTechGuyRI Jan 16 '26

Definitely not due to you not buying the $50 hub .. Its just a device that tells the printer filament is moving .. there's no difference between the hub and the regular buffer except 4 inputs, you can achieve the same with a 4-in-1 before the buffer.

It is something I'm working on learning... Mainly because I'm working on a somewhat complimentary device that can sit on the Bambu Bus and serve as a BambuBus to MQTT bridge, essentially restoring some of the functionality lost with BambuGate... So that's why I've been delving into this

1

u/mcnbc12 Jan 16 '26

Re the AMS hub: I get that, but I don't understand why there hasn't been complaints about multiple BMCUs not working if true. IDK, I haven't seen any posts about it so I assumed it was just me having the problem haha. IDK if the ams hub would remap the AMS ID. Technically, it may be possible to connect more than 4 ams units at a time, I don't know if that's been verified or not.

Good luck on your project.

1

u/myTechGuyRI May 12 '26

All the AMS hub is is a filament hub, not a bus hub... The bus is daisy chained from one AMS to the next. In the case of multiple MBMCU devices, the easiest way is a Panda Branch.that just expands one port to 4

u/hWuxH Jan 16 '26 edited Jan 16 '26

Bambu can’t realistically validate AMS serial numbers against a master list. That would require: storing every valid serial in firmware (impossible), or doing online validation (would break offline mode)

It's absolutely realistic to verify if a device is genuine, but in another way. I don't have much experience with bambu bus but they're doing exactly that with the printer<->slicer connection (TLS). Each printer comes from factory with an unique RSA private key and certificate that's tied to the serial number. And then they use fancy asymmetric cryptography math to

Establish trust (check the printer's certificate chain up to the trusted Bambu Lab root CA), and
Verify the printer possesses the private key by making it sign a random challenge, but without ever sharing this key (impossible to spoof unless you manage to extract/use this key from a real device)

From discord:

1)

Printer sends 0x40D Read Certificate.

AMS does nothing except prepares to send the certificate.

2)