I have this Ubiquiti firmware and I successfully extract the firmware and rebuild it, I modify Squashfs filesystem and rebuild it using build-firmware.sh script from firmware-mod-kit, but the problem I have is CRC Not the same as the original value, so how can I bypass CRC checksum also what is this "CRC32 polynomial table, big endian"

this output for original firmware

Scan Time:     2016-03-16 11:23:35
Target File:   /home/security/Desktop/XW.v5.6.3-beta3.28377.150922.1830_2.bin
MD5 Checksum:  c7227eeeb31a1c5a8fbcbfc7f70587f0
Signatures:    351
0             0x0             Ubiquiti firmware header, header size: 264 bytes, ~CRC32: 0xB49B5747, version: "XW.ar934x.v5.6.3-beta3.28377.150922.1830"
260           0x104           Ubiquiti partition header, header size: 56 bytes, name: "PARTu-boot", base address: 0x00000000, data size: 0 bytes
127444        0x1F1D4         Certificate in DER format (x509 v3), header length: 4, sequence length: 64
151956        0x25194         U-Boot version string, "U-Boot 1.1.4-s958 (Jun 10 2015 - 10:56:20)"
152244        0x252B4         CRC32 polynomial table, big endian
222808        0x36658         CRC32 polynomial table, big endian
225032        0x36F08         Ubiquiti end header, header size: 12 bytes, cumulative ~CRC32: 0x454E442E
228848        0x37DF0         Ubiquiti partition header, header size: 56 bytes, name: "PARTkernel", base address: 0x00000001, data size: -2147475456 bytes
228912        0x37E30         uImage header, header size: 64 bytes, header CRC: 0x4A2F55E8, created: 2015-09-22 15:31:31, image size: 952264 bytes, Data Address: 0x80002000, Entry Point: 0x80002000, data CRC: 0x533245A9, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS Ubiquiti Linux-"
228976        0x37E70         LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 2783164 bytes
1181240       0x120638        Ubiquiti partition header, header size: 56 bytes, name: "PARTrootfs", base address: 0x00000002, data size: 0 bytes
1181304       0x120678        Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 5877613 bytes, 1185 inodes, blocksize: 131072 bytes, created: 2015-09-22 15:31:33
7210680       0x6E06B8        gzip compressed data, from Unix, last modified: 2015-09-22 15:30:15

the output for modified firmware is here http://pastebin.com/uWxG59pu
*also can i make fake CRC to look like the original value

2 Answers 2


You cannot bypass it, you must recalculate all required checksums.

Ubiquiti XW firmware is made from parts below:

UBNT <version-string> CRC32(header part) <4byte padding>
PART u-boot <content> CRC32(u-boot part) <4byte padding>
PART kernel <content> CRC32(kernel part) <4byte padding>
PART rootfs <content><squashfs md5 checksum> CRC32(rootfs part) <4byte padding>
EXEC script <content> CRC32(script part) <4byte padding>
END. CRC32(all parts above> <4byte padding>

If you replace content of rootfs part, you mast recalculate CRC32 for that part and recalculate CRC in END. part

BTW firmware-mod-kit creates very broken images for Ubiquiti, ignores all content after squash filesystem, and not recalculate final END. checksum.

  • so is there any other tool I can use instead of firmware-mod-kit to create working Ubiquiti firmware.
    – adrián
    Jul 4, 2016 at 20:45

If you modify the firmware and rebuild it, then the CRC values should be changed. So, the new CRC values may be correct.

You don't have to do anything with the CRC32 polynomial table, because it means only that binwalk found a CRC32 table in the boot loader. This table is used to calculate the CRC32 value in a fast way.

  • it give me "corrupted firmware file is uploaded. please upload the correct file and try again." so may be the problem from CRC32
    – adrián
    Mar 17, 2016 at 11:53
  • Unfortunately I don't know the Ubiquiti firmware format, but the corrupted firmware file may mean that the CRC value is not correct, but the firmware may contain other checks also, such as digital signatures. If GPL source pack is available for that firmware, it may contain the correct firmware packing method. Otherwise you may have to reverse the boot loader or the binary responsible for firmware update.
    – ebux
    Mar 17, 2016 at 12:11
  • binwalk github.com/devttys0/binwalk/blob/master/src/binwalk/magic/… Have well documented format, also GPL Archive dl.ubnt.com/firmwares/XN-fw/v5.6.3/GPL.UBNT.v5.6.3.tar.bz2
    – adrián
    Mar 17, 2016 at 13:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.