How to fix CRC32 checksum in an xz-compressed folder without corrupting the data?

Question

I need to fix the CRC32 checksum of a modified xz folder so that it has the same checksum as the original folder. This is part of a mod firmware project for a router. The router rejects the upload of any minimally modified firmware.

I extracted the files from the xz folder, made the necessary modifications and recompiled using mksquashfs.

How do I fix the checksum in the modified folder?

I even tried to fix it using a program called CRC-manipulator. It adds 4 bytes to the end of the file so that the modified folder has the same CRC32 as the original folder. But that didn't work. I tried to fix it manually, adding the necessary bytes to the binaries in the folder using HxD. But anywhere I try to add these bytes, the folder will end up corrupting. Even in the header or footer. Maybe I'm not editing the correct location? Where is the correct place to make this correction?

This is the original xz-compressed folder, without any modification.

https://drive.google.com/file/d/1UDI5cLC1QbnxFizy7PyyXqa-H3EfQPZb

This is the folder with the files already modified, just needing to make the correction of the CRC32.

https://https://drive.google.com/file/d/10L4mEiRANHoujGvh_LFHJvIKRz83QrpZ

Thank you in advance.

---

rogdham's solution to fix CRC32 checksum in xz folder, really works, and answers my question, but unfortunately it was not the solution to the problem. My router keeps rejecting the modified firmware, even performing CRC32 checksum corrections in multiple blocks. There is a block near the end of the file that starts with the byte sequence 4E 49 54 42 46 which is invisible to binwalk and which I believe could include some sort of additional check for the xz squashfs folder, like MD5 for example. But this is just a guess.

This is the original firmware in its full build: https://drive.google.com/file/d/1xWcJ_U8P3qjjWSIt8TqDXoA0KSkmIT61

This is the modified firmware, already finalized and with the necessary CRC32 corrections implemented (as far as possible). https://drive.google.com/file/d/1FdlTaWyJisA9_QSdh5AH31M5pbdUqEuB

If anyone can suggest other alternatives, (that aren't too complex, because I'm a newbie) I would be very grateful.

Answer 1

I am assuming you want to modify the second squashfs filesystem you have attached so that the CRC32 value of that file is the same as for the first file.

CRC32 checksums are not secure hash functions, and they are only 4 bytes long. This means that if we can modify 4 bytes at some place in the data, we should be able to reach any CRC32 value for the whole data.

This description of the squashfs binary format shows that it starts with a superblock, and bytes 8 to 12 correspond to the last modification time. So we should be able to change them without changing the content of the squashfs filesystem.

A little bruteforcing shows that using the 4 bytes 62 f7 41 36 seems to work as expected:

### modifying bytes 8 to 12 of rootfs-modified into rootfs-modified2
$ head -c 8 rootfs-modified > rootfs-modified2
$ echo -ne '\x62\xf7\x41\x36' >> rootfs-modified2
$ tail -c +13 rootfs-modified >> rootfs-modified2

$ sha256sum rootfs-*
6c996db82c00acc5f4dea396e7921a955c58f7c4181a3d4bac6df8c7057cc9a1  rootfs-modified
4da2044ff6a52346f2e12b1a89047978e2861f40a62eb55a3e5ca81b5296ede4  rootfs-modified2
145d8a5e87ee2039008809e5a22194d1b408f63d86ac3c8702a6914de61cb8b1  rootfs-original


### making sure that the CRC32 of rootfs-modified2 is the expected one
$ crc32 rootfs-*
b1fbd11b  rootfs-modified
7138f65c  rootfs-modified2
7138f65c  rootfs-original

Feel free to send me an email if that's not clear (check my profile), I feel like your question may need some back and forth which may not be the best for stackoverflow.

Also note that the provided rootfs-modified file does not seems to be a valid squashfs filesystem in the first place, so this may create issues down the road when you try to use it:

$ unsquashfs rootfs-modified
Read on filesystem failed because EOF
read_block: failed to read block @0x4f1a4a
read_id_table: failed to read id table block
FATAL ERROR: File system corruption detected