Closed conkydong closed 3 months ago
If you give me a link to the firmware, I'll take a look at it. btw.: I used binwalk for the initial analysis...
https://drive.google.com/drive/folders/1zoTlT0WOSB7iVZt8_ib8w68zSGbTQNoQ
So, if I eff my modified firmware up would I be possible to reflash the printer with the original firmware?
binwalk -b parameter.es
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 UBIFS filesystem superblock node, CRC: 0xE1D35CD2, flags: 0x4, min I/O unit size: 2048, erase block size: 126976, erase block count: 13, max erase blocks: 36, format version: 4, compression type: lzo
126976 0x1F000 UBIFS filesystem master node, CRC: 0xA4D285E9, highest inode: 64, commit number: 0
253952 0x3E000 UBIFS filesystem master node, CRC: 0xB0839ACE, highest inode: 64, commit number: 0
binwalk -b cis.es
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
According to the binwalk output, it's empty.
It's best to extract and pack the firmware without changes and if the same file comes out, it's OK. As long as the bootloader is not damaged, the S3U will start to flash the firmware after powering on, if it finds it on the USB stick. So I rescued a couple of failed attempts to modify the firmware..
But what's with customer.es? There are a few PNGs (extracted them with binwalk) I'd like to change. With the tool customer.es can't be extracted.
You haven't answered my question about the start and end offsets. 😉 Are they hardcoded in UltraFirmewareTool.jar?
Tried that. File is about 33 MBs smaller. Couldn't be, or could it?
BTW: It's not a S3U, it's a Uniformation GKTwo. It already has Samba activated, but I want to try out other things. Found out it has a functioning ethernet port, but there are no drivers installed.
I think I've figured out what the problem is:
S3U:
# File Partition: customer.es
ubi part UBI
fatload usb 0 0x21000000 $(UpgradeImage) 0x1d10008 0x2aee000
crccheck 0x21000000 0x1d10008
ubi write 0x21000000 customer 0x1D10000
GKTwo:
# File Partition: customer.es
ubi part UBI
fatload usb 0 0x21000000 $(UpgradeImage) 0x2300008 0x2a63000
crccheck 0x21000000 0x2300008
ubi write.part 0x21000000 customer 0x2300000 0x250E000
fatload usb 0 0x21000000 $(UpgradeImage) 0x20e008 0x4d64000
crccheck 0x21000000 0x20e008
ubi write.part 0x21000000 customer 0x2300000
According to the configuration, the customer consists of two parts.. I just have no idea why and how it works...
If you don't have the source code and kernel configuration, adding the driver will be quite a problem..
uboot help:
ubi write[vol] address volume size - Write volume from address with size
ubi write.part address volume size [fullsize] - Write part of a volume from address
Writing to flash:
ubi write.part 0x21000000 customer 0x2300000 0x250E000
ubi write.part 0x21000000 customer 0x2300000
But there is no description of how it works in the manual, logically it seems to me that in the second command it continues the entry at the place where the first command ended...
I looked at the code and the unpacking part is there... Merge customer.es customer.es.1 and then it works..
cat customer.es customer.es.1 > test.es
sudo ubireader_extract_files -k test.es -o customer
Thanks a lot! A really simple solution if you think about it. 😁👍
But how could I reverse it after I edited files? Or do I even have to? Do you think I could try to flash a firmware build with this all without bricking my printer?
I suppose it will be necessary to modify the UltraFirmwareToolkit. To tell you the truth, since I wrote the code, I've written about a hundred thousand lines of code on other projects... So I have no idea how much work is going to be involved..😉 If I don't get to it this weekend, please remind me once in a while.. I'm pretty busy.
It's done, try the new version.. I modified the work flow: extract.sh -> extract_partition.sh build.sh
These files are generated when you run the extract.sh: extract_partition.sh build.sh
btw.: I assume that the file splitting will have something to do with the RAM size. There's not yet a function added that will produce a new split, so don't overdo it with adding things, I assume the max size of one segment can be those 36700160 bytes.
Now it occurred to me I still forgot to adjust the total length in:
ubi write.part 0x21000000 customer 0x2300000 0x250E000
In the meantime you can edit it in the hex editor..
It's a bit strange, I have yet to look at it, don't try to upload it to the printer yet
I pushed a new version.. Hopefully that's all, now it generates the same header without any changes in the partitions and the file length is OK. At byte level it should be identical only when using the original partitions, the newly generated ones have different node IDs.. Alternatively, you can compare the original and the generated file in a text editor to see if the header is OK and if the lengths of the new partition versions match.
Thanks a lot! Will try it out later.
Could test it now, it works flawlessly. Almost...
Since the GKTwo and the Saturn are seemingly running with almost the same configuration (check /etc/os-release for example or linuxrc in rootfs) I thought I could just copy over the corresponding files for starting dropbear from Saturn firmware to GKTwo firmware.
The files are in the built firmware, I double checked it. But dropbear isn't running. Probably just an error on my side, but I can't figure it out. I would check it via serial console but apparently the port is disabled.
I am currently writing from my mobile, but it works by running my application via an existing script in the customer directory (I don't remember the name), the description how it works is here: Modified Linux startup sequence, A small application runs as a daemon /customer/customerStart it waits 35 seconds and then executes the script /customer/customer.sh This starts services from /etc/ini.t starting with RxxName, currently the following R91smb, R94wsdd2 and R96dropbear
So samba and ssh start about 35 seconds after the printer is turned on.
if that's not enough for you, details tomorrow
So you have to edit these files:
/etc/passwd
/etc/group
/etc/shadow
Add a new user, or just change the root password in shadow. Here are my versions:
https://github.com/weashadow/UltraFirmwareToolkit/tree/master/scripts/APPS-ARM/etc
(In the directory https://github.com/weashadow/UltraFirmwareToolkit/tree/master/scripts/APPS-ARM is everything I edited/added)
Generate a new password via:
openssl passwd -5 -salt TrOIigLpsaeEw
And to /etc add directory dropbear
I added the customerStar startup to /etc/init.d/rcS, if I started dropbear classically via the normal /etc/init.d/ service, dropbear shut down after starting the chitu app.
And don't forget that all files must have an owner and group root and the correct permissions...
Just did everything from scratch: copied or edited the files accordingly, set the permissions and built the firmware.
It flashes without problems, just SSH isn't working. Could you please take a look at my firmware that I built? https://file.io/1ckWkoUZO2Jh
There might be a problem with that files:
dropbear
dropbearconvert
dropbearkey
They are supposed to be symlinks and refer to dropbearmulti Copy those links from my firmware, those multi binary executables work by figuring out what command is called from the symlink from where they are called and I'm not sure it works when you rename the file directly.
Alternatively, you can add utelned to see what the dropbear outputs via the command line..
https://github.com/weashadow/UltraFirmwareToolkit/blob/master/scripts/APPS-ARM/etc/init.d/R93utelned https://github.com/weashadow/UltraFirmwareToolkit/blob/master/scripts/APPS-ARM/usr/bin/utelnetd
btw. if you want you can also try the webcam connection, compiled MJPG-streamer is here: https://github.com/weashadow/UltraFirmwareToolkit/tree/master/scripts/APPS-ARM/mjpg In start.sh edit the LD_LIBRARY_PATH according to your installation location..
Thanks!!! That did the trick, I just copied the files so they weren't symlinks like you said.
Now that I've tested it a bit, I can say that it's a really good tool. You should also mention in the readme, that it's not only for the Saturn and the firmware for the Uniformation GKTwo also is functional. 😉
You should also mention in the readme, that it's not only for the Saturn and the firmware for the Uniformation GKTwo also is functional. 😉
Today I added it there..
If you want, when you have some usable firmware ready, make a repository with it and I'll add a link to it in the readme..
I think there's no need to create an extra repository - sent you my built firmware (Original version number: 1.3.3, Modified: 1.3.4) with SSH enabled (user: gktwo OR root, pass: gktwo). Just upload it to your repo. 😁
I've already added it, thank you for your cooperation.. https://github.com/weashadow/UltraFirmwareToolkit/releases/tag/GKTwo.1.3.3
Can someone help me?
I'm trying to use this tool for the Uniformation GKTwo. It works for rootfs.es, miservice.es, appconfigs.es but some other files won't be extracted.
Some other questions:
Here are the logs: