If you unpack the firmware and replace file uboot and boot0 from firmware 2.3.9 you can keep root and uart.
We just need to see what anycubic changes in the new firmware that is upcoming soon.
And after that we will see.
No one in the group has made any date for the tools repo yet.
Thanks for this info, when I edit the files I decompressed via cpio and cpio a new swu the printer does not complete the update. Is there any way you can post your method for this? I am assuming if you are not doing this via cpio and flashing .swu on the printer via usb, that you are using the method previously posted with swapping the rootfs on B partition.
You just need to sign and replace all the md5 then repack it with cpio.
you can use md5sum command and sha256sum command.
Then the printer will accept .swu. as long as you have replaced the .pem in /etc with a custom one.
In sw-description
We will eventually post the tools repo after the new update that drops on the 13th.
I was figuring some sort of checksum was in place. I did replace all sha values in sw-description with values from sha256sum and I mksquash rootfs with -all-root, and generated a random .pem and replaced file in /ect, yet 3.1.0 isn’t flashing. I may be missing more info needed regarding the .pem public key and its function.
You also need to update cpio_item_md5 then you need to take your pem and do openssl dgst -sha256 -sign swupdate_private.pem sw-description >sw-description.sig
I finally got around to testing this method, and it works but with some additional information. To anyone else that is curious, you will need to cpio files in order with sw-description being the first file, and the rest of the files can be in any order, and cpio format must be crc. Here is a simple shell script you can put in your working directory and run to accomplish:
FILES="sw-description sw-description.sig boot0 \
boot-resource cpio_item_md5 dsp0 kernel rootfs uboot"
for i in $FILES;do
echo $i;done | cpio -ov -H crc > update.swu
Thanks for the guidance, I am happy to be rooted on 3.1.0 and modify as I see fit.
Are you saying the K2Max motherboard has been unlocked and fw can be changed or modified?
They have been able to get root access and have found M Codes that allow you to tweak your Printer.cfg file, but no custom firmware/full Klipper has been achieved, at least that we know of yet. They are doing most of this behind closed doors, so if they find a way to do it, it doesn’t get patched.
The firmware can be modified and root access is obtainable, but what controls the printer is an application. So for the most part, we can only control config files that are external from this application. The application was developed using an SDK that communicates through DSP, and it is expensive to obtain a license to do so. That only leaves the option of reversing the application in a program liked IDA Pro and patching it, or someone starting from scratch to provide a way for an external SBC to control with Klipper. Even if it got that far, a custom printer.cfg would have to be made for this too. The other challenge would be how an SBC would communicate seeing the printer only has 3 USB-A ports. No dedicated port for receiving instructions, so it may end up being a GPIO connection. This is just how I see it, but they might be doing some secret third thing!
Now, I’m totally lost in most of this and I’m just learning Linux, but could the USB port just be blocked by USGguard or udev rules for anything other than “drives”, and 3rd port only allowing cameras?
You can plug the camera into any USB port. But you have to patch the app. The app just listens on the first USB port. Not sure I have not looked into this.
The group digging into all of this is way smarter than me and I would assume they already checked that, but who knows. Be nice if that was the roadblock and would help with the external communication process.
Does anyone have 3.1.2 firmware link for max2? change log etc…?
What i’m doing wrong?
I’m downloading 3.1.0 firmware, decrypting to zip, unpacking update.swu, unpacking with cpio, unpacking (unsquashfs) rootfs, replacing swupdate_public.pem on my own generated by openssl, packing back rootfs with cmd ‘mksquashfs squashfs-root rootfs_new -all-root -comp xz’, replacing old rootfs with my new, now i modify md5 sum of rootfs in cpio_item_md5 file, in sw-description i’m replacing sha256 of rootfs in both sections now_A_next_B and now_B_next_A, re-sign sw-description with my own pem via openssl, getting new md5sum of sw-description(.sig) and write it in cpio_item_md5, making update.swu with script as described above
FILES=“sw-description sw-description.sig boot0
boot-resource cpio_item_md5 dsp0 kernel rootfs uboot”
for i in $FILES;do
echo $i;done | cpio -ov -H crc > update.swu
copying to flash in update folder, going printer menu, and pressing update… update failed! :(((
if i only repack update.swu, all ok, if i change rootfs and keys, nothing flashing
From where?
link above Printer.cfg for Anycubic Kobra 2 Plus/Pro/Max - #227 by ultimatelifeform
https://cdn.cloud-universe.anycubic.com/ota/prod/20023/AC104_k2MAX_V3.1.0.bin
Just wait a bit more to fix the latest firmware 3.1.2 and we will release to the public all tools we have to easy this process, as well as many other things. No Klipper for now, and most likely it will never be adapted for these printers for many reasons. If you badly need Klipper, buy an appropriate printer model and forget about Anycubic. They are not willing to help this process, so why to support their business?
And please, don’t try to reinvent the wheel. We need your energy and work to be started from our level up, not from scratch.
The only things I did in addition to that was
chown root:root *
&
chmod 777 *
all directory files before cpio script
Then I ssh/serial into /etc (on printer) and
chown root:root swupdate_public.pem
&
chmod 777 swupdate_public.pem
I had better luck not modifying the rootfs before cpio, and leaving as is and then modifying freely whenever I got in.
Hope this helps!
If you are interested to try this, it seems you might be able to force an update without .pem files by copying your update file to the printer or listing path to exUDISK and running:
swupdate -i update.swu
you can also use swupdate -i -c update.swu to check and verify your image beforehand so you don’t have to guess if it will flash or not. This is the only method I have used, and have not tried to force an update. I don’t know the outcome of doing this.
by decompiling the app, the command it issues to update includes -k and lists /etc/swupdate_public.pem for the key path.
source:
Usage swupdate [OPTION]
-f, --file : configuration file to use
-p, --postupdate : execute post-update command
-P, --preupdate : execute pre-update command
-e, --select , : Select software images set and source
Ex.: stable,main
-i, --image : Software to be installed
-l, --loglevel : logging level
-L, --syslog : enable syslog logger
-k, --key : file with public key to verify images
–cert-purpose : set expected certificate purpose
[emailProtection|codeSigning] (default: emailProtection)
–forced-signer-name : set expected common name of signer certificate
–ca-path : path to the Certificate Authority (PEM)
-n, --dry-run : run SWUpdate without installing the software
-N, --no-downgrading : not install a release older as
-R, --no-reinstalling : not install a release same as
-M, --no-transaction-marker : disable setting bootloader transaction marker
-o, --output : saves the incoming stream
-v, --verbose : be verbose, set maximum loglevel
–version : print SWUpdate version and exit
-c, --check : check image and exit, use with -i
-h, --help : print this help and exit
-d, --download [OPTIONS] : Parameters to be passed to the downloader
download arguments (mandatory arguments are marked with ‘*’):
-u, --url * is a link to the .swu update image
-r, --retries number of retries (resumed download) if connection
is broken (0 means indefinitely retries) (default: 3)
-t, --timeout timeout to check if a connection is lost (default: 300)
-a, --authentication authentication information as username:password
Alright. The 3.1.0 update and now the new one have been disappointing.
All security updates.
I agree with this, really hoping to see them follow through with local networking.