X1Plus Firmware website link
3 Likes
Remapping the Power and Pause hardware buttons to custom actions, shell scripts, or even G-code is a really neat feature.
5 Likes
Kinda sounds like they’re not going to release information about the exploit they discovered.
Wow!!! All I can do is salivate on some of these feature. It makes me yearn for an X1… almost…
- VNC? as if SSH support wasn’t good enough. Woo-Hoo
- Custom Button Actions
- Bed Visualizer
- Printer stats - Why isn’t THIS a standard feature???
- On-Screen shell for diagnostics? Are these guys insane? Giving users the ability to diagnose from the console? Utter Madness!!!
- Wi-Fi Speed improvements? Well that couldn’t have been that hard, or at least they couldn’t have done any worse than what we have now.
The big question that remains… will they save us poor P1 users from bad firmware?
3 Likes
P1 is not linux, so “no”.
Such a buzzkill. 
They say it couldn’t be done for the X1 either… I’ll remain hopeful. 
Bad firmware? The latest firmware works fine. What are you expecting from the screen that you can’t get from Bambu Slicer or the Handy app? Keep in mind there is some stuff you cant get because of the difference in hardware with the P1 and X1 series.
Yes, it does. So, even though my warranty runs out very soon, I don’t expect move to X1+ for quite a long time. Most of the current additions might be fun to play with, but I can do without them. ( though improved network speed is attractive)
I will still be watching further developments closely, as I can imagine other improvements that could be useful, like support for an Ethernet connection, or manual settings for a static IP address.
But the ability to return to then-current Bambu firmware at any time would be essential.
wasn’t an exploit. They found out that when the X1C started it could boot from a SD Card.
You’re going to need to provide some citations for that statement.
The video on Youtube with Joel (3DPrintingNerd) discusses the installation of a boot stub on the printer. If the printer would simply boot anything you like from SD card, that wouldn’t be needed.
1 Like
Yeah. I’m very familiar with this statute because it’s heavily debated in the performance-car community (of which I am a part). I think your interpretation is not correct (notwithstanding the fact that “firmware” does not appear in the document anywhere). This statute is basically formalizing the requirements for warranties, and it defines the process both consumers and warrantors must follow when there is a claim or dispute.
There are many, many examples of manufacturers who will void a warranty if you modify the firmware on their device. Samsung is one major example I am intimately familiar with, when they rejected my Note 8 trade in because I’d rooted it (even though I’d restored the factory image before returning it. Even though they would do the exact same thing even if I hadn’t rooted it). Car manufacturers routinely reject warranty claims on engines for cars that have modified ECMs (they actively look for this, in fact. Some newer ECMs are encrypted so they can’t be modified). Yeah, if you put heavy duty shocks on your car, they can’t deny your warranty for a blown motor unless they can show that the shocks caused the motor to blow up (this is really what the M-M statute is about). But if your suspension falls apart, even if you take your modifications off before that happens, if you tell the dealer you modified and restored the suspension or they see evidence that you did, they’re not going to have to prove anything. You modified the suspension and it broke, no warranty. The presumption of guilt is on you. If you disagree with the rejected warranty claim, then you have to prove the changes you made had nothing to do with the failure. The Magnusson Moss statute defines your right to contest the denial is all.
Think about it. Anything else would be impossible for a business to manage. If the warranty return rate goes up more than expected, it can be very financially damaging. If a manufacturer had to prove the user was at fault, they would either have to service all warranty claims regardless of what the end user had done, or they would have to be prepared to invest the time and resources to prove each and every end user was at fault. They’d go bankrupt. (note: in my real-life job, my company makes a product that has Firmware and I can 100% assure you that if an end user modified the FW the warranty would be void and my company wouldn’t have to prove anything, we’d just say “denied”, although our FW is encrypted and signed with a secret key so there isn’t a way to get our product to accept unauthorized FW).
Also, BBL can absolutely stop it (see comment above). At least, for most people. Anyone with sufficient HW and FW skills can likely get around any obstacle. But BBL could easily make that a lot of work (to get around my product’s security, chips would have to be removed from the board and reprogrammed on a dedicated programmer and of course, that physical tampering is an even greater warranty transgression).
The reason for the waiver is because they can stop it, but they know some of their customers won’t be happy that it’s been stopped. Their solution is called “compromise”. If you’re not going to hold BBL responsible for problems, you can do whatever you want to your machine. Just don’t expect to be able to change it back and make pretend nothing happened.
Me, I can wait until my warranty has expired to start making changes like this.
3 Likes
My apologies. I misheard information about the topic. I think the best explanation for what they did was they found an insecure MQTT link to LAN code.
And your citation for that is where?
It still seems like you’re hypothesising rather than actually having any information.
This is now a hypothesis more than factual.
OK sure, but why do you think that?
If you’re just taking a wild stab in the dark without any reasoning, it’s not even really a hypothesis, it’s just pointless conjecture. Especially since you said “I think the best explanation”, which suggests that you have some reasoning for it and why you think it’s the best explanation.
If you’ve discovered something then please do share, as then we can all learn from it. What other explanations have you considered?
The reason I think this is alone MQTT is super insecure. while it’s a great way to communicate between machines, it still needs a backend to do the communication.
I think what happened here is BBL left some privileged command within the Access code (Based on MQTT) system that was left leveraged (which X1Plus on the installer requires) giving them the ability to access the AP Board to modify the boot loader. This is also why this couldn’t be silently patched but forced with a software update.
Keep in mind I’m basing this off knowledge that I had when I did embedded hardware, so for all I know this could all be wrong, it’s just my take at it.
I think BBL didn’t consider the possibility someone would come up with their own FW for the printer, so they did not implement any “code load protections” other than some basic tags that let the printer confirm the FW it was about to load was actually X1C firmware. So X1P could easily load their FW on the printer, they simply had to duplicate the tags the printer expected to see in the file for a legitimate BBL build.
I think BBL addressed that by modifying the FW so that a signed key is now required. If the FW being loaded doesn’t have a valid key, it’s rejected. This prevents you from being able to load any earlier version of X1C FW and it prevents the X1P FW from loading. Only BBL has the encryption key required to sign a FW image to make it “valid”. So only newer versions of BBL FW can be loaded once the 1.7 version has been loaded.
To load the X1P FW, I suspect BBL will provide a “bridge FW” that doesn’t run the machine, but that does disable the code load protection so that once the bridge FW is loaded, the X1P FW can be loaded.
I could be wrong. But this is how many companies do it.
1 Like
Have you been able to check out the Panda Touch? Seems like it adds an x1 like experience to P1s. A big name in the 3D printer space, BIGTREETECH, has released the BIGTREETECH Panda Touch for the Bambu Lab P1S and X1.
There’s an interesting new development with Big Tree Tech that may thwart some of those who want such a device. It was posted today that you may want to take a look at:
Did you notice the “X1” part? This is not for p series sir. Thanks for clearing that up in case some1 else missed that. 